Query Alarm Tables for Old/Active Alarms

I need to generate a weekly report that will show all alarms that have been active for more than 7 days.
I see that when an alarm goes active it gets assigned an “eventid” in the alarm_events table (at least i think it does) as well as an eventtype of 0 indicating it is active. When the alarm clears another entry is inserted with the same eventid and an eventtype of 1.
Writing a query to get the alarms that went active more than 7 days ago is easy, i am having trouble then adding a filter to see if the alarm cleared or not in that time.
Can someone help me out?
Thanks,

i am thinking i may be able to use the system.alert.queryAlertHistory() function.
does this function still work with the newer releases (ver. 7.6.4)?
if so, what is the alert storage profile name? i tried the journal name but does not work.
thanks for any help.
Scott

Hi Scott,

I had troubles with the system.alert functions. It looks like they may possibly be deprecated and that as of 7.6 we should be using the system.alarm functions.

From what’s available I haven’t seen a way to cleanly query alarms of a certain state from a certain time. The system.alarm.queryJournal function does take states and start/end dates, but from my standpoint what it returns is not really useful - there could be tons of objects for each individual alarm and it would be up to you to combine them all and figure out what the real state of the alarm is.

The system.alarm.queryStatus does take a state that you’re looking for, but not start & end times. But it does return useful alarm data. One way to solve your problem would be to make a list of the alarms, then walk the list and ignore any alarms that are out of your desired date range.

Unfortunately I have no idea on how to get any of the date/time information from the alarms, but hopefully someone will fill me in soon: viewtopic.php?f=70&t=12245

Mix of pseudo/jython (sorry for the formatting - the code blocks strip the whitespace; not ideal for python!)

Of course, the queryStatus function has no way to temporally limit the results. So I have no idea how well the ignition alarm system will work in practice after a site has a year of alarms saved up - you’d likely have to purge the database of alarms every once in a while. Not sure how they overlooked that, or maybe I’ve just been using queryStatus in a way that wasn’t originally intended…

Hope this helps you out…
Charles

I think you’re mixing things up again - the status system will never have a years worth of alarms in it - it’s only the current status of the alarming system.

How far back does the system go for results? When I queryStatus for alarms with status=[“ClearUnacked”,“ClearAcked”,“ActiveUnacked”,“ActiveAcked”] then I get all alarms that have occurred since the system came online (less than a month ago) which is what I though I should expect.

I suppose we might have different definitions of what the “current status” of an alarm is - I take that to mean “what the alarm looks like when you consider all of the most recent entries for that alarm in the journal.” In this case I’d be expecting queryStatus to always give me every alarm, but only to give me the most recent state of it - even if the most recent state change was years ago.

I also made some assumptions about what Scott is trying to do - if he just wants to see which alarms are still Active after 7 days then he doesn’t need to look through any Cleared alarms and this would be a non-issue. However I assumed he wanted to be able to answer things like “In the last week, how many alarms were active for longer than 7 days?” which would require analysis of the Cleared alarms as well.

So my question now is at what age will an alarm no longer show up in the results of queryStatus()? And if we wanted to look at older alarms than that how would we do it?

Regards,
Charles

Use system.alarm.queryJournal, filtering rfesults with the desired “states” (ActiveUnacked & ActiveAcked) and “startDate” the current date minus 7 days