Page 1 of 2

Insteon on request not executed by module

PostPosted: Wed Jan 02, 2019 9:08 pm
by peszko
I'm having a problem with some insteon devices not turning on/off when requested. Once in a while when a device is sent an off/on event from indigo, the device doesn't react without generating a error log in indigo. Indigo seems to assume that the device executed the action and shows what it things happened which is not correct. After a request for status (which I have running once in a while) it then corrects the device status. This is quite a problem for me as things don't turn on when motion is detected, and even worse, don't turn off on timeouts (powerful garage and yard lights stay on all night) (I'm slowly changing to z-wave hoping its more reliable, but I can't afford to change everything at once)

Re: Insteon on request not executed by module

PostPosted: Thu Jan 03, 2019 12:24 pm
by matt (support)
The next time it occurs, copy/paste the Event Log window contents and explain in detail what happened and what should have happened. We'll then better be able to tell you what occurred.

Re: Insteon on request not executed by module

PostPosted: Thu Jan 03, 2019 7:28 pm
by peszko
Will do. Next time it happens, I'll post the logs here.

Re: Insteon on request not executed by module

PostPosted: Mon Jan 07, 2019 10:31 pm
by peszko
I have factory reset most of my modules, and changed how they are called (insteon scene sent twice) This has seem to solve (so far)the not responding issue, but... I still have a more urgent issue. My garage door opened at night again (-15C here in Canada and garage is heated) Here are the relevant log entries. This seem to have happened right after my a scripted status request to the IO link. Which resulted in reply mismatch error. I have now disconnected the IO module as I can't have my garage just open. I hope z-wave is better at handling communication. Having modules respond to spurious/corrupted signals is the most fundamental error. I can understand not responding on com error, but responding incorrectly is just unacceptable.

2019-01-07 22:01:27.680 Received INSTEON "FY_Porch_OCP" on (button 19)
2019-01-07 22:01:32.431 Script Status request to: L1_GAR_Main_DR
2019-01-07 22:01:32.457 Error resending previous command (reply mismatch)
2019-01-07 22:01:32.458 Trigger LogErrorFound
2019-01-07 22:01:33.129 Sent INSTEON "L1_GAR_Main_DR" status request (received input sensor: open)
2019-01-07 22:01:33.896 Sent INSTEON "L1_GAR_Main_DR" status request (received output relay: on)
2019-01-07 22:01:34.968 Trigger L1_GAR_Main_DR_Open_VAR
2019-01-07 22:01:34.969 Trigger L1_GAR_Main_DR_Open_NTFY
2019-01-07 22:01:34.970 Trigger L1_GAR_Main_DR_Open_ACTN
2019-01-07 22:01:34.978 Trigger Action Log Update
2019-01-07 22:01:34.986 Trigger L1_GAR_VOCP_ON_VAR
2019-01-07 22:01:34.987 Trigger L1_GAR_VOCP_LT_ON
2019-01-07 22:01:34.987 Action Group L1_Garage_LT_ON
2019-01-07 22:01:34.988 Trigger L1_GAR_VOCP_IMG
2019-01-07 22:01:34.988 Action Group L1_GAR_IMG
2019-01-07 22:01:34.991 Trigger L1_GAR_VOCP_ACTN_VAR
2019-01-07 22:01:35.009 DSC Alarm Alarm Zone 'L1_GAR_Main_DSC_DR' Opened.
2019-01-07 22:01:35.178 Z-Wave sent "L1_GAR_LTZ" on
2019-01-07 22:01:35.301 Pushover Sent: Garage door opened
2019-01-07 22:01:36.440 Schedule L1_GAR_VOCP_IMG (delayed action)
2019-01-07 22:01:36.550 Hikvision NVR Image garage.jpg downloaded for camera 13 Garage.
2019-01-07 22:01:38.196 Email Sent to "peszko@peszko.com"; subject "Error in logs"
2019-01-07 22:01:39.437 Schedule L1_GAR_VOCP_IMG (delayed action)

Re: Insteon on request not executed by module

PostPosted: Thu Jan 10, 2019 3:28 pm
by jltnol
FWIW, I've got about 30 Insteon devices controlled by Indigo, and I'd say the system works perfectly about 90% of the time. I don't for a second think this is an issue with Indigo, but rather with Insteon. Insteon used to make a break box device that would connect both legs of the service into the house to make all the communications wired, as opposed to a combination of wired/wireless... but I don't see it online anymore or I'd buy one.

From where I sit, the communication protocol used by Insteon is dated at best, and bordering on obsolete at worse. I don't have a crystal ball, but I wouldn't be surprised if Insteon develops a third communication layer based on WiFi, hopefully in the new future.

As far as errors go, I have a KPL that when I push button 6, it turns on the main load for the same KPL. Indigo sees button the button push, but I get NO ACK on the command to turn on the load of the same KPL. So why/how does the command get to Indigo, but not back to the KPL? That's got to be a comm error.

I digress.

In the end, I just don't think Insteon is ever going to work 100% of the time. But that's just my 2ยข's worth.

Re: Insteon on request not executed by module

PostPosted: Sat Jan 12, 2019 1:36 pm
by matt (support)
peszko wrote:
This seem to have happened right after my a scripted status request to the IO link. Which resulted in reply mismatch error.

So it looks like you have an incoming Insteon message that causes a Trigger which executes your script that sends Insteon status request messages, right?

If that is the case, then add a delay before your script is executed. The problem might be that the original Insteon module (FY_Porch_OCP) is still sending Insteon clean-up commands which then collide with your script's outgoing status request commands. Normally this doesn't happen, but given the right circumstances (how many hops away the module is, possible other Insteon network congestion, retries, etc.) there can be collisions from the clean-up commands and outgoing commands Indigo sends. In theory the Insteon protocol is supposed to handle that correctly with retries, but in practice sometimes adding a 2 second delay can greatly improve the reliability.

Re: Insteon on request not executed by module

PostPosted: Sat Jan 12, 2019 4:18 pm
by peszko
matt (support) wrote:
peszko wrote:
This seem to have happened right after my a scripted status request to the IO link. Which resulted in reply mismatch error.

So it looks like you have an incoming Insteon message that causes a Trigger which executes your script that sends Insteon status request messages, right?

If that is the case, then add a delay before your script is executed. The problem might be that the original Insteon module (FY_Porch_OCP) is still sending Insteon clean-up commands which then collide with your script's outgoing status request commands.


No. The FY_Porch_OCP is the insteon motion sensor 2 and in last couple weeks, it started to regularly (like every minute) sending button 19. I couldn't find out what button 19 is. (further making me doubt insteon reliability) The status request script is run every half hour give or take 5 min (random). The scripts enumerates all non battery devices and every 30 seconds sends a status request. This was done due to the reliability (or lack thereof) of my insteon setup. I get modules out of sync once in a while and this fixes that. In this case, it just happened to come at almost the same time (possibly thats what causes it). The flurry of triggers happen because of the garage door being turned on. the _VAR update the virtual occupancy, _NTFY send notifications (push over and email with images from cameras from the _IMG triggers) LogUpdate rotates my latest action variables, Since garage is on DSC sensor, it gets tripped as the door openes. I know its lots of things happening, but really not a lot of insteon traffic. Most of it is within Indigo, which handles them all perfectly. I really think, Insteon is just not a reliable protocol, and the hardware seems to have some quality issues as well. At this point, I'm going to remove all insteon sensors and replace them with z-wave (in time). BTW, I have turned off group scene cleanup messages at the interface for performance. If its on, my larger scenes hold up all communication for up to a minute.

Re: Insteon on request not executed by module

PostPosted: Sat Jan 12, 2019 6:12 pm
by peszko
I figured out what is the Button 19 message. Turns out its an undocumented temperature warning. It's below zero here, so the sensor started to send warnings. Apparently it's an undocumented feature which has an error in it. It should send a warning and stop, but it doesn't. I found instructions here on the forum on how to stop it. Again one more reason against Insteon reliability. I'll be slowly switching all my sensors over to z-wave (as time and money permits).

Re: Insteon on request not executed by module

PostPosted: Sat Jan 12, 2019 7:51 pm
by peszko
Ok, so I went to look at the Insteon developer guide, done some reading on the Insteon protocol and scoured the net for "insteon collision". From what I understand its actually not that hard to get message corruption, especially in the I2 engine (I have a lot of I2 devices) I2cs seems to improve it, but not really radically. On top of that, messages can be repeated up to 5 times and seem to be blindly transmitted to the host (multiples not filtered out). This is made worse, by the wireless portion as it will try to re-transmit signals when dual band. Insteon claim that more devices make the protocol more reliable also seems to be true only up to a point. To me it actually seems that at some point, especially with many wireless sensors the advantage turns to disadvantage. This is further exasperated if the logic between sensors and switches becomes more extensive (more simultaneous messages). Also if there are enough devices and associated logic the message corruption seems to increase dramatically. In my case having over hundred insteon devices and substantial logic that turns things on and off based on sensors, I may be seeing this problem more.

Mat can you comment based on your experience if my understanding is in the ballpark?

If this is the case, then the insteon protocol is really mainly appropriate for small and basic installations with not too many devices and rules. Insteon looks to me like what my professor called, a "work mostly circuit", which he explained as a circuit (or system) where under most low to moderate usage or deployment scenarios it works properly, however when pushed harder or deployed en masse, problems start to show up. Inseon looks to me like a perfect example of the system my professor warned us not to create.

Re: Insteon on request not executed by module

PostPosted: Sun Jan 13, 2019 2:17 pm
by rehafer
peszko wrote:
I figured out what is the Button 19 message. Turns out its an undocumented temperature warning. It's below zero here, so the sensor started to send warnings. Apparently it's an undocumented feature which has an error in it. It should send a warning and stop, but it doesn't. I found instructions here on the forum on how to stop it.

Can you post a link to those instructions? It's cold here too.

Re: Insteon on request not executed by module

PostPosted: Sun Jan 13, 2019 2:44 pm
by peszko

Re: Insteon on request not executed by module

PostPosted: Sun Jan 13, 2019 3:01 pm
by peszko
One more comment on the checksum of Insteon. After further digging in to the checksum that is used by Insteon (2's complement) it seems that at best it has a 1% chance of not detecting corruption. Thats one in a hundred corrupted message being not identified. Now assuming that corruption is not that prevalent lets say that one in a thousand messages is corrupted, and in my case I have about 10k insteon messages (checked in the logs) running around, so that means that I should see a corrupted message get through about once every two days. Now not all corrupted message will result in an action, especially action that I notice, so it is quite reasonable to get one noticeable action a month to occur. Which is consistent with what I'm seeing.

I'll go now to investigate the z-wave protocol to see if its better. (can't really be worse)

Re: Insteon on request not executed by module

PostPosted: Wed Jan 16, 2019 6:19 pm
by matt (support)
I definitely agree that if you have over 100 Insteon devices and have a good amount of logic reacting to sensors/device states/button pushes that is then sending out additional commands you might start to run into collisions/corruptions that aren't handled well.

You might want to look into using Z-Wave for sensors, but still use Insteon for lighting, etc. That might offload enough of the work away from the Insteon network to get it to an acceptable level of reliability.

Re: Insteon on request not executed by module

PostPosted: Wed Jan 16, 2019 7:09 pm
by peszko
I agree. Thats exactly my plan right now. It's quite expensive for me to replace all modules anyway. I'll start by replacing the oldest sensors first (the ones with i2 engine) and keypadLinks. I'm really happy that Indigo added z-wave support some time ago. This allows me to make slow or partial transition while keeping my logic in tact.

Re: Insteon on request not executed by module

PostPosted: Thu Jan 17, 2019 10:10 pm
by RogueProeliator
If this is the case, then the insteon protocol is really mainly appropriate for small and basic installations with not too many devices and rules. Insteon looks to me like what my professor called, a "work mostly circuit", which he explained as a circuit (or system) where under most low to moderate usage or deployment scenarios it works properly, however when pushed harder or deployed en masse, problems start to show up. Inseon looks to me like a perfect example of the system my professor warned us not to create.

FWIW, I have 82 INSTEON devices and they have been rock solid since we built the house, save maybe 3 dead switches (though I think one was dead on arrival I just didn't notice). The vast majority of them are dual band and I have followed best practices here for sending multiple commands (1-2s delay as appropriate). I don't have a ton of triggers on the devices that send other INSTEON commands, at least not relative to the number of devices.

Interestingly, I could detect INSTEON communication via our baby monitor whenever my son was little -- it would show interference any time a switch was hit and you could tell the length of cleanup and "bouncing commands" until it settled down. It did seem excessive for what it was doing (e.g. turning off a light without any triggers). We had one device that must have been bad or had a band link or something as it would generate about 1 full minute of communication any time it was tapped. That doesn't seem very prudent from a reliability standpoint.

I have no reason to move off INSTEON devices, but I do have all sensors and other quick-transmitting devices on Z-Wave and that protocol has been solid as well, save some distance issues which were solved with a repeater. A PITA to setup a new device, to me, but maybe because I haven't done it enough...

Adam