Insteon on request not executed by module

Posted on
Wed Jan 02, 2019 9:08 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Insteon on request not executed by module

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)

Posted on
Thu Jan 03, 2019 12:24 pm
matt (support) offline
Site Admin
User avatar
Posts: 19175
Joined: Jan 27, 2003
Location: Texas

Re: Insteon on request not executed by module

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.

Image

Posted on
Thu Jan 03, 2019 7:28 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Re: Insteon on request not executed by module

Will do. Next time it happens, I'll post the logs here.

Posted on
Mon Jan 07, 2019 10:31 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Re: Insteon on request not executed by module

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)

Posted on
Thu Jan 10, 2019 3:28 pm
jltnol offline
Posts: 399
Joined: Oct 15, 2013

Re: Insteon on request not executed by module

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.

Posted on
Sat Jan 12, 2019 1:36 pm
matt (support) offline
Site Admin
User avatar
Posts: 19175
Joined: Jan 27, 2003
Location: Texas

Re: Insteon on request not executed by module

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.

Image

Posted on
Sat Jan 12, 2019 4:18 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Re: Insteon on request not executed by module

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.

Posted on
Sat Jan 12, 2019 6:12 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Re: Insteon on request not executed by module

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).
Last edited by peszko on Sat Jan 12, 2019 7:52 pm, edited 1 time in total.

Posted on
Sat Jan 12, 2019 7:51 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Re: Insteon on request not executed by module

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.

Posted on
Sun Jan 13, 2019 2:17 pm
rehafer offline
Posts: 225
Joined: Feb 08, 2013

Re: Insteon on request not executed by module

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.

Posted on
Sun Jan 13, 2019 2:44 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Re: Insteon on request not executed by module


Posted on
Sun Jan 13, 2019 3:01 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Re: Insteon on request not executed by module

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)

Posted on
Wed Jan 16, 2019 6:19 pm
matt (support) offline
Site Admin
User avatar
Posts: 19175
Joined: Jan 27, 2003
Location: Texas

Re: Insteon on request not executed by module

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.

Image

Posted on
Wed Jan 16, 2019 7:09 pm
peszko offline
Posts: 152
Joined: Mar 07, 2012

Re: Insteon on request not executed by module

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.

Posted on
Thu Jan 17, 2019 10:10 pm
RogueProeliator offline
User avatar
Posts: 2223
Joined: Nov 13, 2012
Location: Baton Rouge, LA

Re: Insteon on request not executed by module

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

Who is online

Users browsing this forum: No registered users and 0 guests