Please disable ALL ON in FW for 2443-222 modules

[kzboray]

The current .49 version of the 2443-222 is still responding to the ALL ON command. This is not a desirable feature. Please remove it in the next FW release.

[INSTEON John]

The current .49 version of the 2443-222 is still responding to the ALL ON command.

KZ, help me check this out and get it fixed.

Please attached a screenshot of your main controller's property-definitions page for this device so I can check using the same firmware version you are using.

Thanks, John

[kzboray]

<nodeInfo>
<node flag="128" nodeDefId="RelayLampSwitch_ADV">
<address>70 B8 3A 1</address>
<name>70.B8.3A.1</name>
<hint>0.0.0.0</hint>
<type>2.47.73.0</type>
<enabled>true</enabled>
<deviceClass>0</deviceClass>
<wattage>0</wattage>
<dcPeriod>0</dcPeriod>
<startDelay>0</startDelay>
<endDelay>0</endDelay>
<pnode>70 B8 3A 1</pnode>
<property name="" uom="100" formatted="Off" value="0" id="ST"/>
</node>
<properties>
<property name="" uom="100" formatted="100%" value="255" id="OL"/>
<property name="" uom="25" formatted="28" value="28" id="RR"/>
<property name="" uom="100" formatted="Off" value="0" id="ST"/>
</properties>
</nodeInfo>

20240123_154126.jpg

[INSTEON John]

KZ, thanks for sharing the picture and description!

Your module is a recently-made unit that has about 20 hardware improvements since the old company last made them. There was one change to the firmware going from 0x48 to 0x49 and that was to increase the default LED color brightness a few steps. Nothing was done to the All On command awareness.

My only notes on your question was applied to firmware 48 back in 2015 were they were trying to fix the All On Issue coming out of ISY controllers:
3. Removed response to All-On/All OFF group command (0xFF) (effects ControLinc &amp; RemoteLinc I)
4. Does not accept group commands from group 0

Are you able to reproduce this issue or is it something that randomly happens?

John

[kzboray]

John,

We meaning the Insteon HA community suspect we understand how this happens. It is a well known problem that has plagued Insteon since it's very beginnings. The communities best guess at this time about how this happens comes down to data collisions. Power-line and over the air transmissions. I would also note that this problem has been previously eliminated from several Insteon products so the documentation as to the how and a fix must exist somewhere.

It was originally thought that the data collisions occurred on the power-line as well. We always questioned whether the CRC shown in the Insteon protocol actually existed. In recent years I have re-read some of LeeG's posts and come to the realization that collisions at the PLM/controller interface are far more likely. This would explain how corruption could occur with a correct CRC - the PLM ADDS the CRC after the corruption.

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 below)

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 power-line 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.

Is 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.


image.png.f90407fc83c63414fd772e219114ccad.png


image.png.076a0cbe7eb85f27f42e8178a8a00374.png


Here's an example of data corruption causing an ALL ON event.

Wed 08/02/2023 12:10:09 PM : [INST-TX-I1 ] 02 62 00 00 27 CF 12 00

What is broadcast by the PLM

Wed 08/02/2023 09:17:29 AM : [INST-TX-I1 ] 02 62 00 00 FF CF 12 00

There are many other bit corruptions other than the "FF" or "all linked devices" possible. The valid transmission below could just as easily have been any number between 00 and FF. I have 146 scenes linked to my PLM (92 Hex). The bit corruption could have activated any of them.

Wed 08/02/2023 12:10:09 PM : [INST-TX-I1 ] 02 62 00 00 27 CF 12 00

Last Scene (92 Hex) : 02 62 00 00 92 CF 12 00

All linked devices: 02 62 00 00 FF CF 12 00

Because this happens on the micro switches, IOLincs which are used to control other devices i.e. relays attached to gates, garage doors, fire-pits, sprinkler systems, pool pumps etc. Any one of these ALL ON events can result in thousands of dollars of damage and potentially catastrophic loss to property and life. It no longer happens on light switches or from the current testing any of the i3 products, so it is something that can be eliminated, the how I can't help with, as it requires changes to the firmware.

Ultimately the holy grail fix is to eliminate this from the PLM, but I don't know if that is doable given how the Insteon protocol actually works without adding to the protocol. At the very least it is something worth looking into.

In the mean time I am moving all my clients from Insteon to alternative technologies until this is resolved.

Let me also say I am an Insteon fan boy and have been using it personally and professionally since 2005. No product does a better job of handling scenes, and for lighting Insteon is my first choice, having lights come on randomly in the middle of the night is one thing, but having your fire-pit come on resulting in a fire or your pool pump running dry is something completely different.