I have traps sent by our wireless controllers when an access point disassociates from a controller. This is our primary notification that an access point has gone down(all of our AP's are not polled). How ever from time to time they disassociate for a short time and we don't need a notification waking someone up in the middle of the night. I would like to be able to auto-ack these, but I would need to match one of the trap's parameters sent. I think this could be useful for other applications as well. This might be something to be targeted when alarms becomes art of the notification process.
The new enhancements committed on master on revision 305bc744e69e684878a2c0bf522177cd9dd7c9c4 should address this feature.
Alejandro Galue February 13, 2014 at 1:17 PM
Edited
Here is a proposed patch.
It works beautifully using 1.12.4-SNAPSHOT
The SQL query may take a little bit more than the old one as it requires to join the events table with the notifications table in order to work.
I've added another version of the SQL query (commented), to join notifications with alarms using lasteventid (which is technically not the same thing, but should be faster).
It accepts something like this:
Besides specifying the name of the parameter it also possible to specify the parameter number, for example:
Mike Huot September 19, 2012 at 12:41 PM
Somebody has created a work around for some of the use cases associated with this -
I have traps sent by our wireless controllers when an access point disassociates from a controller. This is our primary notification that an access point has gone down(all of our AP's are not polled). How ever from time to time they disassociate for a short time and we don't need a notification waking someone up in the middle of the night. I would like to be able to auto-ack these, but I would need to match one of the trap's parameters sent. I think this could be useful for other applications as well.
This might be something to be targeted when alarms becomes art of the notification process.