Is there a way to setup the group expression to only allow mixer2\fault to send an email?
I guess what I am after is being able to setup 1 alert notification profile that has all of my contacts and then build groups that can contain an expression that can filter down to the tag level.
also, what If I wanted to send all tags that start with mixer1?
shouldnt this expression only allow mixer1/fault to be emailed to the group
If you want to filter down to the tag level do the following:{[ITEM_PATH]} = ''mixer1/fault"To filter a group based on tags that start with mixer1 do the following:{[ITEM_PATH]} LIKE "mixer1%"Hope that helps.
ok, I was able to get that to work. I have noticed something a little strange though.
it seems as though the alarm state does not change quickly enough so it is not always correct. for example, if I trigger the alarm the email message shows the alarm state as clear. If I then clear it it shows low. Ive tried changing the time deadband but that doesnt seem to make a difference.
when I watch the properties of the tag in the designer, it looks like it takes about 5-10 seconds for the alertactive and alertstate properties to change. not sure if that has something to do with it. It seems as though the email gets sent almost instantly.
also, is there a way to get emails just based on value without setting up alerting? lets say I have a tag that doesnt have any alerting setup on it.
mixer1/batteryvoltage
Can I setup a group that looks at this tag and if its < 12 send an email? My thoughts are centered around giving users the ability to setup custom emails that arent tied to setting up different states.
Regarding your first question, can you post a screenshot of the alert configuration for that tag? I think you have your states mixed up. Also, what is the scan class associated with that tag (located on General tab of tag edit window)? Maybe your scan class is really slow causing the 5 second delay. We need to see more information in order to find out what is going on.
Without setting up alerting on a tag, the only way to email when a tag meets some condition is to use scripting. You can make a Gateway Event Script > Tag Change and when the tag’s value < 12 (for example) you can use system.net.sendEmail to send an email. The tag change script allows you to listen on multiple tags at the same time.
Since your scan class is every 5 seconds we will only evaluate the alert conditions every 5 seconds. That is why it is taking so long to see the alert active bit go high. The alarm seems configured correctly.
I tried every second and it does the same thing. is there a way to make it wait before sending the email?
I tried adding a datediff and comparing the {[Time]} between now on second, and having it fire if >15 but even though it showed valid, it never would send.
That is what the time deadband is for. Set the time deadband to 15 seconds while the scan class is 1 second. You have to set it on both the low and high states.
It still does it with the scan class set at 1 second and both time deadbands set to 15 seconds.
I setup the email to include the value of the tag, the state, the low setpoint db tag, and the high setpoint db tag.
here is the email from when I set it into alarm
Value = 136.0
State = LOW
low setpoint = 200
high setpoint = 20000
here is a copy of the email that I get when it clears. note that the low setpoint is 0.
Value = 136.0
State = LOW
low setpoint = 0
high setpoint = 20000
I even tried setting the scan class down to 750ms, and also using the tag.alertcurrentstate instead of the {[State]} but that made no difference. I also tried using the auto generated message, but it does the same thing. It does show that the alarm cleared, but the state still does not show up correctly.
can I do a datediff expression in the group kind of like what I posted earlier? I have some other comm alarms that I would like to have setup to only email me if they have been down for multiple hours.
I tried this but it doesnt seem to work, I only get a alert clear email.
{[ITEM_PATH]} like ‘%8091079/flow%’ && dateDiff({[TIME]}, now(),“hour”) >= 2
I dont want to use the time deadband because I actually want the system to register it as an alarm right away, I just dont want to get the email unless it has been in alarm for more than 2 hours.
I didn’t follow this thread from the start, but I tried to read up on it and replicate the setup. I can’t re-create a problem with the state taking a long time to update, but I’m almost certainly missing some part of your setup.
Here’s one thing to check, though: Try going into the gateway turning the logger for “Alerting.AlertBus” to TRACE. This will print out the events as they’re placed on the “alert bus”, which is what all parts of the system listen to for updates about alerts. For example, the emails get sent off of it, and the status system gets updated from it. The current state property of the tag, however, does not come from the bus- it comes from inside the tag.
Try triggering a few different alerts, and observing how long the state property takes to change. You might want to drag it onto a label in a window or something to help watch it. Ideally you would also use something like WinTail on the wrapper.log file to watch the output from the logger, but if nothing else, after a few events, open that file and paste the messages into a post here.
The fact that your message shows the low setpoint to be 0 is suspicious to me. Is there anything (a script or something) writing to these setpoint tags? Also, to be clear, the alarmed tag is an OPC tag in SQLTags, right, not in a sqlbridge transaction group?
It looks like the state on the tag changes almost instantly once I change the setpoint.
I was changing the low setpoint db tag back and forth between 0 and something that was higher than the value in the .flow sqltag. Thats why 0 was showing up on the clear messages.
and yes, this is an opc tag in sqltags. No scripts are using the setpoint db tags at all.
Ok, for reference, the numbers after the path equate to 2=Active, 12=Cleared+Acknowledged. 1=Initialized, so 13=Cleared+Acknowledged+Initialized.
Did you turn your custom message off? The message should also be printed out there. Of course, I guess I should ask what version of Ignition this is, because it may not have always been that way… but it has been for a while.
Colby, I did it a few more times with the custom message and you can see it is the same result. I noticed also that for some reason it showed a high state, which I never triggered and the value never went over 20,000 which is the high setpoint. I also never saw the current state show up as high while I watched it in the designer.
