In my application, I have configured two separate alarms for a single digital point, one for 0, and one for 1.
Below is a snippet of my sqlt_as table for a given digital tag.
id tagid statename severity low high flags
354 36 High Alarm 4 1 1 0
355 36 Low Alarm 3 0 0 0
In my application, I use the severity level to determine what color a point gets displayed in. I have a “Status” screen with a table that monitors all points. For analog points, Hi/Lo (severity of 3/1) alarms will cause that point’s row in the table to be highlighted yellow, HiHi/LoLo (4/0) = Red, OK (2) = white. Now, for these custom digital alarms I am letting the user pick what color each alarm will be displayed in. I am doing this by changing the severity of the alarm as I configure it.
The problem I am encountering is that if both the alarm for 0 and alarm for 1 have the same severity level, notification e-mails are not sent if the point is switched to and from high and low. Since I am not 100% sure how the system triggers alarms, I am assuming the problem is explained by one of the two following reasons:
- An alarm is not triggered unless there is a change in severity
or
- There is some internal SQL query that is not returning the right alarm ID. If both severity levels were set to, lets say 2 in the snippet above, SELECT id FROM sqlt_as WHERE tagid = 36 AND severity = 2 would not guarantee that the correct id is returned.
I guess if I knew exactly why the alarm was not triggered I would know how to work around the problem. Hopefully this one isn’t too difficult to understand. If I was unclear please let me know and I will try to explain it again.
Thanks again.
EDIT: I also noticed that these alarms are in fact showing up in my alarm log, there just seems to be a problem with the notifications.
My quess would be because you are changing SQLtag parameters during runtime, you need to set a column in the sqlt_core folder to let FactorySQL know that a parameter has changed, or else it wont reload the parameters. I dont believe the SQLt_core table is being constantly monitored for changes to the tags. I could be wrong though. Also, your query SELECT id FROM sqlt_as WHERE tagid = 36 and severity = 2 will return the first row it finds, depending on how you order the table. If you ORDER BY id DESC, id 355 will be returned
I forgot to mention that I am ‘touching’ the sqlt_core table properly and updating the configchange field with current_timestamp.
That SQL query I mentioned was just an example of how I think the service “could” be evaluating the alarm. I really have no idea how the service takes care of all this. I’m hoping you guys can clear that up for me. Since I am still seeing these alarms in the alarmlog, I’m assuming that the service handling the alarm notifications (SQLTags?) is grabbing the wrong entry in the that table since the entries would be very similar (if the severity levels were the same). I think I can solve this problem if I know exactly how the service is carrying out the notification process. I mean I COULD make the Low alarm use severities 0 and 1, and have the High alarm use 3 and 4, but I still run into a problem if both alarms are using 2 (OK severity). I guess I also could add a 5, denoting another OK severity level. But if there is a simpler approach that can solve this issue without presenting the need to update all my script modules, I would rather do that.
One other thing about doing this direct against the tables: the “alertmode” property for the tag needs to be set correctly in the sqlt_meta table.
If you do the following: “SELECT * FROM sqlt_meta WHERE tagid=36”, There should be an alert mode set to 2 (which stands for analog alert- which is what you’re trying to do, even though it’s a digital tag). If it’s not 2, set it and then update the configchange on the core table.
If that’s not the problem let us know and we’ll look at the next possibility!
Regards,
Yes, the alertmode is set to 2 in sqlt_meta when I write the points to the table. The notification problem only arises when both alarms have the same severity number.
Update: I just decided to add another OK severity level of 5 and switch the low alarms to use 0,1,2 and the high alarms to use 5,4,3. This solved the problem.