Heartbeat for PLM

[skimis]

Several times my PLM has gone offline for various reasons. Of course, when this happens all the automation configured from events and scripts ceases. I want to do a heartbeat on the PLM so I can send a text if it fails. I know there is a command "isResponding", but I can't seem to figure out how to get it to work in a script. Any ideas?

[mnsandler]

Several times my PLM has gone offline for various reasons. Of course, when this happens all the automation configured from events and scripts ceases. I want to do a heartbeat on the PLM so I can send a text if it fails. I know there is a command "isResponding", but I can't seem to figure out how to get it to work in a script. Any ideas?

please try v1.5.2.22 posted on the original v1.5.2 thread.

there is a new feature that will attempt to restart the com port if for some reason the plugin gets an error when trying to send or recv. if the port can't be restarted there is a new trigger "Interface Crashes" that will be called and you can do whatever you decide to get your system running again. usually just restarting hs is enough.

as part of this upgrade, i suggest you upgrade your ftdi chipset drivers to the latest v2.8.8

feedback welcome

[skimis]

Thanks. I'm already running 1.5.2.22. I upgraded the PLM drivers as you suggested. Then I created an event trigger for device "RF PLM Interface" when "Interface Crashes". I unplugged my PLM and then sent and OFF command to another device. The event does not fire. Perhaps a non-reponse is different than a crash? Unfortunately being unplugged is too common a problem here because of family just doesn't get it.
Here are the log entries:
1/28/2011 5:39:26 PM Device Control Device: Office Candles (]25) OFF
1/28/2011 5:39:26 PM Insteon Processing SetIOEx for device - ]25 Cmd: 3 Bright: 0 Data1: 0 Data2: 0
1/28/2011 5:39:26 PM Insteon Setting status and value for device ]25. Old status:2 Old Value:100, New Status:3 New Value:0
1/28/2011 5:39:26 PM Insteon Sending command 02 62 15 88 8A 0A 13 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
1/28/2011 5:39:30 PM Insteon ..Got junk instead of ACK/NAK for command 00 00 00 00 00 00 00 00 00
1/28/2011 5:39:30 PM Insteon ..Retry #1 required. Pausing 250ms for RF PLM to clear...
1/28/2011 5:39:34 PM Insteon ..Got junk instead of ACK/NAK for command 00 00 00 00 00 00 00 00 00
1/28/2011 5:39:34 PM Insteon ..Retry #2 required. Pausing 250ms for RF PLM to clear...
1/28/2011 5:39:39 PM Insteon ..Got junk instead of ACK/NAK for command 00 00 00 00 00 00 00 00 00

[mnsandler]

so you had the usb cable disconnected during the scenario you posted and you still got a response from the plm?

your log does not indicate a problem other than the PLM NAK'd your cmd.

i'm confused

the trigger will not fire unless the com port dies (closes, etc) and the plugin cannot restart it after a few minutes.

[skimis]

so you had the usb cable disconnected during the scenario you posted and you still got a response from the plm?

your log does not indicate a problem other than the PLM NAK'd your cmd.

i'm confused

the trigger will not fire unless the com port dies (closes, etc) and the plugin cannot restart it after a few minutes.

Oh no, sorry. I unplugged the PLM from the wall. USB still connected. Don't understand how the PLM could even NAK as it is not powered any longer.

So I think I understand that the trigger won't work for me. I need some other way to identify that things are not working. I thought I can write a script to try some command or query to the PLM, and if it does not reply I'll assume it's dead and send a notification.

[mnsandler]

Oh no, sorry. I unplugged the PLM from the wall. USB still connected. Don't understand how the PLM could even NAK as it is not powered any longer.

So I think I understand that the trigger won't work for me. I need some other way to identify that things are not working. I thought I can write a script to try some command or query to the PLM, and if it does not reply I'll assume it's dead and send a notification.

ok, i understand the issue. Disconnecting the plm from the wall does not shutoff the plm or close the com port. so this is not a situation that i can trap. the PLM gets its power from the usb like any other usb device. so the reason it NAK'd your cmd is because it couldn't actually send it out to the powerline.

If an "unplugged plm" is the situation that you are trying to discover through script, i don't think its possible.

i suppose i could add a trigger that would fire if the plm NAK'd 5 cmds in a row, but this could still cause a false-positive.

what do you think?

[skimis]

ok, i understand the issue. Disconnecting the plm from the wall does not shutoff the plm or close the com port. so this is not a situation that i can trap. the PLM gets its power from the usb like any other usb device. so the reason it NAK'd your cmd is because it couldn't actually send it out to the powerline.

If an "unplugged plm" is the situation that you are trying to discover through script, i don't think its possible.

i suppose i could add a trigger that would fire if the plm NAK'd 5 cmds in a row, but this could still cause a false-positive.

what do you think?

That all makes sense now. I looked over the modem developer's guide and I guess there's no notification of power loss. That'd be a great feature. [Wonder how bad it would be if I put my PLM behind my UPS and I could use and IOLINC and a relay to signal loss of power in general]...another day. Ok, so I like your idea of a trigger after 'n' NAKs. I'd probably use that to run an event to set some virtual device, wait a minute and operate some real device again to try to see if the event re-triggered... that'd help avoid almost all false-positives. It would be a decent indicator of loss of power to the PLM. If that's a trigger you can implement I'll put it through the ropes.

Thanks!