Random all on including opening garage door!

[ericmaas]

I upgraded from my 994i to a Eisy and now get this random all on event that happens. I have not been able to reliably replicate the issue. I have tried multiple things I read online only to have it happen again. It never did this with my 994i. I did use my backup from 994i for the new Eisy. I tried deleting scenes that had devices controlle in programs. Deleted entire sections of programs etc... I did full restore/rewrite to all devices and PLM. Any help would be Soooooooo appreciated. I do have a log but forgot the time when it happened and the log is several days. 

[Techman]

Take a look at this article.  If you have any Insteon Motion Sensors they are notorious for causing all on events when their batteries are low.

All on events won't show up in your event log.

https://wiki.universal-devices.com/INSTEON_Random_All_On_Events

Edited November 13 by Techman

[kzboray]

All on events are the devil. They are probably caused by collisons at the PLM/controller interface.

When the controller issues a broadcast group command to the PLM it takes the form (fast on):

02 62 00 00 XX CF 14 00  (Where XX is the group number to activate) 

The PLM transmits the following onto the power line per the Insteon Message Summary 

YY YY YY 00 00 XX CF 14 00 ZZ  (Where YY YY YY is the PLM address and ZZ is a CRC). 

For a random collision on the powerline to produce YY XX and ZZ would be extremely unlikely.

If we assume a collision at the PLM powerline (assume the PLM address YY YY YY is intact) we still need a valid XX and a correct ZZ (crc).  Still rather unlikely. 

It seems far more probable that the collision (at the PLM/controller interface) affects the XX group number.  Assuming it was a valid group number for the PLM, it would simply append the PLM address (YY) calculate the CRC (ZZ) and put it on the powerline.



What all this means is the ALL ON events can be created by any device on the Insteon network. From personal experience the 2450 Garage door controller, 2443-2222 micro module, and 2475F fan controller have caused the most ALL ON events for the installations I manage.

The real fix for all of this is to update the PLM to eliminate the Group 0 broadcast group without completely breaking the entire protocol stack.

I can't say much but I can share that Insteon is aware of this issue and as already shared in other posts there is a new PLM making it's way through FCC certification. So fingers crossed this will soon become a non-issue.

Edited November 13 by kzboray

[ericmaas]

I saw that article on insteon motion sensors. I do not have those I am using Elk sensors for M1 gold system. Thank you for your reply!

[ericmaas]

Wow, you are very smart with Insteon setups!!! I will keep eye out for new PLM when it comes out. I do have two micro modules and garage door controller. Maybe will disconnect and see if it goes away. THANK YOU kzboray!!!

[GTench]

@ericmaas I experienced a similar problem but with random lights coming on (with older insteon modules since newer ones do not seem to respond to all on commands). Mine were triggered by DSC motion sensors which activated lights using programs when motion occurred. I believe the motion detectors were triggering too often creating collisions sometimes. I have restructured my programs to minimize the ONs being sent which has so far I believe been helpful.

I had originally tried including the motion detectors as controllers in scenes but this did not work as I could not restrict them to only sending ON and not OFF commands

Gary