Insteon commands from rules held up for days, then transmitted

[Auto_Exec (Basil)]

Hi everyone,
Long time listener, first time caller.
I have an Openhab 2.4.0-1 on RPI, Insteon hub (2245-222) with about 50 devices and insteonplm1 - 1.13.0.
I also have a home-made ESP32-based garage door sensor/controller which uses mqtt to communicate with OH.
When the garage door is opened after sunset, the rule sends commands to five different Insteon light switches, when the door closes, it restores the previous state of each of the five lights. The rules are heavily logged and announced on Alexa using TTS.
The setup has been working for about two weeks. But twice in that period the following happened:

1. The garage door opens and is reported (Alexa and log file) but the lights would not turn on.
2. This continues to happen for about two days.
3. At night with the garage door closed and lights off, all the commands from previous opens/closes start executing, causing the five lights to turn on then off in the programmed sequence. This repeats about as many times as the garage door was opened/closed.
4. None of the rule log entries are generated when this occurs so rules are not running
5. In both cases, after the ‘backlog’ of commands execute, the lights go back working as expected when garage door opens/closes.

I doubt this is related to activation on poll issue reported by the following threads since only the five lights are involved in the exact sequence programmed in the rule:

Insteon Devices Randomly Firing

So last night my son’s bathroom fan switched on multiple times when we were not even home, then again at 2am. It happens reliably when the device is queried. Rather than responding to the query, it suddenly acknowledges the receipt of a “ramp rate on command” cmd1=0x2e cmd2=0x02. No such command was ever sent to the device from anywhere. The switch is only linked to the modem, so no other device can possibly trigger it. How come it claims to have gotten a 0x2e 0x02 command? It turns out that 3…

Insteon polling seems to have turned a light on and then off at separate intervals

I am using the ISY99 to manage Insteon devices and scenes. It sits between OH and the PLM. Uses a different binding. The ISY is really necessary in a larger Insteon network - devices fail and an easy way to replace them makes managing the network helps. In OH, I mostly reference scenes rather than Insteon devices directly. That way if (when) a device fails, I just need to use the “replace device” feature on the ISY99 and not change code in OH.

Any ideas what could cause this to happen?
Any advice on how to troubleshoot it?

Thanks in advance for your help and a big thank you to this forum for all the solutions already provided for my multitude of issues while setting up the system!

[Thedannymullen (Danny mullen)]

I used to have ghost switching. Found out it was a bad keypad. Since then the ghost switching gone.

I am interested to hear what others have to say also.

[tommycw10 (Tom)]

Do you use a scene for the 5 lights or do you trigger individually?

I’ve found the bandwidth of the insteon bus sux and commanding that many lights causes havoc. I’ve turned to doing everything more than one or two lights with scenes (and then manually setting all of the openHAB items to the proper state to match the scene) because weird stuff happens any other way.

On the return to previous state, you’ll obviously have to command one at a time. When I have to do this, I make OH pause between each one. This seems to have solved all my issues. Probably the OH Insteon could be better at this on its own, but it’s not.

Something I’ve heard is that there is a separate software out there that is an Insteon <-> MQTT bridge that is supposed to function much better than the old OH plugin. Then you just integrate to OH via MQTT. I’ve wanted to try it out but seems like a lot of work…

[Auto_Exec (Basil)]

Thank you both for your thoughts,

tommycw10 I’m using individual commands for each of the 5 lights. I think the bus bandwidth is already an issue because linked switches and hub commands are often sluggish. I’ll try your idea of a delay between commands and see if that makes a difference. I’ll also look into the MQTT bridge, it sounds interesting.

Thedannymullen, I doubt this is ghost switching, since the lights are switching on/off in the exact sequence and roughly the number of times they should have.

What puzzles me is where could the ‘backlog’ of insteon commands be held up for tens of hours? I can’t imagine them sitting in the hub, so it kind of points to the binding, since the rule has long since sent the commands.

[mjcumming (Michael Cumming)]

Hard to believe the hub is queuing those commands for that long. I do recommend the ISY994 for anyone with an insteon setup. Its the best way to manage and maintain an insteon network.

Ghost events happen for a variety of reasons. Insteon has 2 basic types of commands known as SD and ED. The SD commands do not have any error checking so if there is noise on your powerline these commands can get corrupted leading to lights turning on and off at night especially if you are polling devices for their state. ED commands use CRC error checking but ED commands are not normally used to control turning lights on/off.

[tommycw10 (Tom)]

…I’d also recommend against ever using an Insteon Hub in an Openhab setup. If you are going to use Insteon in OH, I’d highly recommend using the PLM. While they “work” they don’t work great. There is extra lag getting your commands moved over the LAN and then out onto the Insteon bus with translation time etc. My setup became much more solid with the purchase of a PLM (albeit not perfect still)

Michael - I’ve seen these ISY units around for a long time. How do they work with integrating with Openhab? They seem to be stand alone units that have their own place to write rules etc. I’ve always wondered how this works.

Tom

[mjcumming (Michael Cumming)]

Tom, the ISY is a great device to manage your insteon network - scene creation, device replacement, etc. If you have a large install it really makes life much easier.

The binding for the ISY works well. Unfortunately it no longer has an active maintainer but it works fine in its current version for Insteon devices only.

The ISY does allow for some basic programming. I use some programs on it do manage keypadlinc buttons and scene tracking. Otherwise all other programming is on OH.

[Auto_Exec (Basil)]

I’ve heard about the ISY before but to be honest, I am so fed up with Insteon, I hesitate to invest more time or money into it. In the past 10 years, I’ve had at least 40% hardware failure rate, no to mention other issues, add to that the change in Smarthome management and I doubt it will survive much longer.

But… I do have a USB PLM that I can redeploy, what would I have to do in order to use it with OH? and would adding the PLM further aggravate the lack of bus bandwidth?

I appreciate your responses.

[tommycw10 (Tom)]

It’s a lot of work, but basically you’d unpair all of your devices from your hub and pair them with the PLM. In a large system like yours I know that isn’t trivial. You could leave the devices paired to the hub as well, but like you said now you’ve got more bandwidth issues.

After that you just change the line in your config file for OH to use the PLM instead of the hub. Pretty straight forward.

[Auto_Exec (Basil)]

Thanks for the info, I’ll keep it in mind in case adding the delay between commands doesn’t fix the issue.