Recovering Insteon plug-in after a power outage...

[RoChess]

Who ever wired my kitchen ran the stove hood power improperly.

Wait till you come across a place where they fused the neutral on a single pole breaker, and you flip the breaker, proceed to cut the wire and melt your clipper between hot and ground. Good times

[jono]

I was having that problem where the PLM would not communicate with HS3 after a power failure. Had to replug the PLM and restart HS3 to get it going again. I determined it was because the PLM was down (no power), but the plugin didn't know it because it was still happily running on the UPS. The plugin keeps trying to send commands to the dead PLM and eventually locks up. So, when the power comes back on, the comm to the PLM was dead.

Solution: I use the BLUPS plugin to interface the UPS to HS3 and tell HS3 when there is a power failure. As soon as power failure is detected, I use the "Insteon - Disable Interface" action so the plugin stops trying to communicate with the dead PLM. Then when power is restored I use the "Insteon - Enable Interface" action to start it back up. Then after a 10 second delay it does a "Poll all Insteon devices with a 4 second delay" to update the status of all devices. Works like a charm and I no longer have the lockup problems you're referring to.

I’d also suggest making sure all of your Insteon I/O lincs are set properly. I have one controlling an aqua stat to cut off my hot water heater and after a power outage it always resets to off. Most Insteon devices return to their pre power outage status, but not I/O lincs.

[joegr]

I was having that problem where the PLM would not communicate with HS3 after a power failure. Had to replug the PLM and restart HS3 to get it going again. I determined it was because the PLM was down (no power), but the plugin didn't know it because it was still happily running on the UPS. The plugin keeps trying to send commands to the dead PLM and eventually locks up. So, when the power comes back on, the comm to the PLM was dead.

Solution: I use the BLUPS plugin to interface the UPS to HS3 and tell HS3 when there is a power failure. As soon as power failure is detected, I use the "Insteon - Disable Interface" action so the plugin stops trying to communicate with the dead PLM. Then when power is restored I use the "Insteon - Enable Interface" action to start it back up. Then after a 10 second delay it does a "Poll all Insteon devices with a 4 second delay" to update the status of all devices. Works like a charm and I no longer have the lockup problems you're referring to.

This is where I was going with the question about the PC being on the same circuit. This is exactly what I do, and so far it is working for me.

[codemonkey]

Thanks guys, the BLUPS plugin is in my back pocket but until then my test of the ini change Mark suggested seems to work.

[mnsandler]

Thanks guys, the BLUPS plugin is in my back pocket but until then my test of the ini change Mark suggested seems to work.

thanks for reporting back

[baudi]

Originally posted by baudi View Post
I couldn't make this setting stick in the insteon.ini. Here's what I tried.

- Disable plugin, add the setting and save the file, enable plug in.

- Stop homeseer, add the setting and save the file, start homeseer.

- Disable plugin, stop homeseer, add the setting and save the file, start homeseer, enable plug in.

After each of these attempts, the setting disappeared from insteon.ini. Strange.

You might need to reboot the server first. The file is being cached somewhere. I recall seeing this before.

This turned out to be PEBCAK. I inserted the "PortType=USB" line right after the line that said "InterfacePort=COM3". When I restarted it looked like it was gone, but it had simply moved to its rightful place in alphabetical order.

[upstatemike]

A usb to serial adapter & serial plm are susceptible to the same thing as the usb plm (which basically has a usb to serial adapter built in)

I use the serial plm connected to a physical serial port and don't have this issue during power flashes.

Thinking more about this answer and it occurs to me that the main difference between the USB PLM and a seril PLM plus USB to serial adapter is the location of the adapter. If the adapter is built in to the USB PLM then a power failure on the PLM also brings down the adapter. With a serial PLM the USB adapter is located on the battery backed Homeseer PC so the adapter never goes down during a power failure. Wouldn't that prevent the problem?

[Atticka]

This seems like a regular issue with Insteon on Homeseer, I just finished reading multiple threads about losing the interface after a power outages... going back years.

This recently happened to me, my PI is on a UPS and the USB PLM of course is not, and I had event triggers to restart the plugin that "might" have fired but were unsuccessful, my log file rapidly filled up with "Port_DataReceived Error..." at the rate of about 50+ entries per second (filled the log file until Homeseer flushed the data). Power was out for about 40min and the plugin never recovered.

The plugin needs to be more robust at handling power failures and reestablishing connectivity to the PLM,

[mnsandler]

This seems like a regular issue with Insteon on Homeseer, I just finished reading multiple threads about losing the interface after a power outages... going back years.

This recently happened to me, my PI is on a UPS and the USB PLM of course is not, and I had event triggers to restart the plugin that "might" have fired but were unsuccessful, my log file rapidly filled up with "Port_DataReceived Error..." at the rate of about 50+ entries per second (filled the log file until Homeseer flushed the data). Power was out for about 40min and the plugin never recovered.

The plugin needs to be more robust at handling power failures and reestablishing connectivity to the PLM,

the plugin has no way of knowing if the power goes out. there are insteon actions you can use to shutdown the plugin interface in a power event, and then restart the plugin interface once power is restored.

typically the plugin will try to reconnect to the interface and then shut itself down if it is unsuccessful after 10 tries; this is probably what you are seeing in the log. You can lower the retry count if you want.

[allenc3]

I agree the plug-in should be bullet proof on power fail recovery as well as the Insteon PLM. I travel away from home for a month at a time and have no way to restart anything until I get back. I had this exact problem with a power fail from a failed UPS of all things. Power failed for several hours and the UPS shutdown after the battery died. Later when power was restored the UPS did not start up. One fix was to remove the UPS as it is not needed so long as everything restarts and events are recovered to current time. This power loss happened before I converted from PC based HS2 and X10 to HS3 ZEE S2 and Insteon. The house lights stopped working until I got back 4 weeks later. One main purpose of home automation is to make the house look lived in when I'm gone.

Edit:
And I also agree this is not only a Plug-in issue, but also the HS ZEE S2 box (in my case) and HomeSeer need to know what has happened with power and act accordingly. I do not know at this point exactly what is known about power state by each of these three components.

[Atticka]

the plugin has no way of knowing if the power goes out. there are insteon actions you can use to shutdown the plugin interface in a power event, and then restart the plugin interface once power is restored.

typically the plugin will try to reconnect to the interface and then shut itself down if it is unsuccessful after 10 tries; this is probably what you are seeing in the log. You can lower the retry count if you want.

Hi Mark,

Not saying this is an easy fix, a lot of UPS's do not have data ports for example to do what you are suggesting. I'm looking into alternate ways to indicate to Homeseer that a power failure is taking place, it seems this is an overlooked, common place, event that should be handled gracefully.

I use Insteon+Homeseer+SDJVStat to control heating in a greenhouse to ensure the plants don't freeze when is -32C, this is an important issue (to me and my plants).

If the PLM is lost, why can't the plugin try to re-initiate the connection every 10-20 seconds or so? It seems like some added logic to the software can help mitigate these issues, for example why do we have to manually create the "restart interface" events when this capability should be built right in or at least an option in the plugin settings?

There might be a number of reasons the PLM disconnects, but I'd suggest that power failure is the #1 cause (through power failure, or simply being unplugged). Does the USB connection not provide any updated status codes when the PLM comes back up?

Last thing, why does the log file fill up with thousands of this error? I had 304 entries being generated every 2 seconds....

Port_DataReceived Error: Specified port is not open.

Food for thought, residential power is unreliable and more so in the countryside.

[Burrington]

There is one more thing that locks up the PLM when using either: the USB PLM; or, a Serial PLM with a USB to Serial interface. This applies to Windows for sure, and possibly other platforms as well. Windows comes with all USB ports defaulted to turn off the power after a period of inactivity. I found that if there was no Insteon action for a while, Windows would shut off the USB port, which kills USB power to the interface. The PI would then not see the interface and lock up.

Here is the simple fix:

1) Right click the Windows symbol
2) Click "Device Manager"
3) Click "Universal Serial Bus Controllers"
4) Double-click the USB interface that has the PLM on it
5) Click "Power Management" tab
6) Un-check the option "Allow the computer to turn off this device to save power"

I have a USB hub, on which I have several USB to serial adapters. If you have this, be sure to turn off the power save option for the USB Hub as well as all the adapters.

Mark, Atticka's suggestion above for a periodic attempt to re-establish comms might solve this problem too. I assume Windows must restore the USB power if something tries to use the port. But I know that the PI never restored it, probably because once it loses comm with the PLM, it locks up permanently until reboot.

[mnsandler]

Most of the logic is all there already. i can help you config the plugin based on your set. what interface you are using (serial or USB)? and do you have a power loss trigger?

if you don't have a mechanism for identifying a power loss then all we can do is shutdown the plugin when comm fails, and you will have to restart it manually when power is restored.

i have a 10 sec delay in the usb recovery code. I may need to add a delay in the serial port recovery code

can you post a few dozen log entries that is flooding the hs log.

[baudi]

If you have a power failure/restore event, you can use Jon00 Plugin utility to Disable/Enable the Insteon PI.

[joegr]

If you have a power failure/restore event, you can use Jon00 Plugin utility to Disable/Enable the Insteon PI.

There's no need to do this. If you have an event at power failure to disable the interface (one of Insteon plugin actions), and then an event when power is restored to re-enable it, all is well. The problem/crash only happens if the plugin continues to try and send commands while the power is out. I guess it overruns a buffer or something. I haven't had any problems since adding this logic.