alarmprocess is a shell script that the app_alarmreceiver calls when it receives an event. It's job is to process the event, insert the data in a database table and call an external program to do something else.
getalarm is a shell script which can be called by alarmprocess and uses addtional database tables to determine how to handle each alarm based on Account, group, trip/restore, zone, alarm type, etc. The ideas is you build a database table with commands that match criteria for alarms and this will figure out which command to run. I use it to page overhead when somone presents their access card at the door and comes in my house. The logic works like this:
1) Look for Account, Group, Qualifier, Event and Zone. If that an exact match isn't found, start narrowing down.
2) This is the next best match, we don't look for the zone. (Account, Group, Qualifier, Event). Failing that we try one last time.
3) This is the last guess. We look for a command with No Zone and No Event type. This is the default for account,group,qualifier
An action is a Unix system call. I've written little shell scripts to do different things based on the alarm type. Sometimes I just log the entry, sometimes I send a text message to my pager, etc. I started putting actions in /usr/local/bin then I thought I'd make subdirectories for each "account". If you were doing this for yourself and had only one panel calling in, I don't think you'd need to have the directory mess.
Some might ask "why wouldn't you just do it all from the alarmprocess script instead of having it call getalarm?
Well, you could. Probably you should, but I started from two different directions. The nice thing about having two seperate programs is it's easy to call "getalarm 20060714225927-14527" while you are debugging your logic.
In the future, I'll probably add some stuff to indicate if the alarm has been acknowledged. You might auto-ack log events, but have some other process (like calling out) that would require you to hit a button or something to ACK the alarm. Another process would keep checking for un-acked alarms and follow some rules to keep notifiying until it's been acked or some other logic expires.
For Example:
We get a 602 (Periodic test report). We enter the event in the database and mark the ACK column automatically.
We get a 422 (Access granted). We enter the event in the database, call another action to announce the access over the PA and mark the ACK column.
We get a 370 (Protection Loop). We enter the event in the database and call a process which will attempt to contact a list of people by phone. Once somone has received the alarm, they hit "1" and the event is acked in the database. No more calling will happen.
It's unlikely that I'll do any more work on this until sometime after summer is over ;)