Using the below config I am able to receive a email anytime my voice port is in any other state than ON HOOK. The problem I have is the script runs every 30 seconds and I receive an email every 30 seconds the line is in any other state than "ON-HOOK".
Is there a way to have only one email generated ONLY when the state changes from the previous state?
example : the line is on-hook, changes to off-hook or park or whatever- a email would be generated. ( only One email). not one every 30 seconds...
The line goes from Off-Hook back to IDLE. - A email would be generated to advise the line has been restored to a IDLE state.
I know what you're thinking why? Well I was thinking of using the analog ports as kind of a poor man's slightly intelligent surveillance system. If port 1/0/0 goes off hook or shorted, then this is an alarm condition. A email would be generated. I just don't need a email every 30 seconds.
scheduler allocate 20000 1000 event manager environment _email_from firstname.lastname@example.org event manager environment _email_to email email@example.com event manager environment _email_server smtp-server.isp.net event manager applet check_1/0/0_if_NOT_ONHOOK event timer watchdog time 30 action 001 cli command "enable" action 002 cli command "show voice port summ | include 1/0/0" action 003 foreach line "$_cli_result" "\n" action 004 regexp "on-hook" "$line" action 005 if $_regexp_result eq "1" action 006 exit 0 action 007 end action 008 end action 009 syslog msg "PORT_1_is_in_any_other_state_then_on-HooK!" action 1.0 mail server "$_email_server" to "$_email_to" from "$_email_from" subject "$_event_pub_time:Test EEM port 1/0/0 is SHORTED ie IN ALARM" body "TEST Body" ! end
Look at EEM context to save the value of a variable across policy runs. So you could retrieve the value of the context and compare it to the current value, if they are different then send an email and if they are the same then no action.
The first time your updated policy runs and executes the context retrieve there will not be a value since you have to do a context save first. To get around this make a second policy that runs at reboot to do a context save of the "on-hook" state.