HA/Insteon - toggleLinc repeatedly being turned on

Configuration
1

tl;dr: In the past few days, an Insteon ToggleLinc wall on/off switch seems to be told every 20 minutes or so to turn on.

The integration of this switch into HA has been working fine since April. I’ve rolled back any HA updates I’ve installed since the problem started but it hasn’t helped. The Insteon hub is blocked from communicating with the restored Insteon servers by a firewall.

I added debug logging to pyInsteon and had a go at understanding the Insteon protocol and digging into pyInsteon source code, but although I’ve done decades of C++, python is new to me. I’m also having a bit of difficulty matching the msg fields in the logs to the Insteon msg fields (e.g. msg_id?? ack?)

What I think is relevant are the following logs:

2022-08-24 21:56:30.481 DEBUG (MainThread) [pyinsteon.messages] TX: b'\x02a\x0c\x11\x00
2022-08-24 21:56:30.576 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x61, group: 0x0c, cmd1: 0x11, cmd2: 0x00, ack: 0x15
2022-08-24 21:56:30.576 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 3000b5, flags: 0x05, cmd1: 0x11, cmd2: 0xff, ack: 0x06

I’m not sure how to decode the TX message (raw bytes??) but it seems to be sending a “Turn On” command (0x11 0x00) to a link group or perhaps a dev class/subclass - not sure. The last log is from address 0x3000b4, which is the light switch, which I think is acking the command (and turning on). I’m also unsure as to why this command is being sent in the first place.

What is also odd is that I have a lot of identical instances of the first two logs (TX, then RX from I guess group 0x0c) which are never followed by the light switch ack.

FWIW the toggleLinc devices is Category: 0x02 subcat: 0x01A

Anyone have any ideas? Is the switch responding to the msg TX’d by HA, or is there perhaps some other device commanding the switch to turn off that is not being captured in the logs?

Home Assistant 2022.8.6
Supervisor 2022.08.3
Operating System 8.4
Frontend 20220802.0 - latest

Update: found another instance of reception of an acknowledgement of a command to turn off the switch, so it’s not related to the previous TX msg above:

2022-08-24 20:07:41.925 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 3000b5, flags: 0x05, cmd1: 0x11, cmd2: 0xff, ack: 0x06
2022-08-24 20:07:42.530 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 3000b5, target: 52fa6f, flags: 0x26, cmd1: 0x11, cmd2: 0xff

What is the second log with “target” indicating? (target id is the Insteon hub).

Thanks.

2

If you find the device in the Insteon Control Panel, is it possibly attached to some scene?

3

Second answer first … you send a command from HA to the Hub (the target) to tell it to turn on 30.00.B5. The Hub is a PLM so it sends this command powerline and RF and other switches repeat that message until it is received at the switch or it not after three hops (I believe).

have you tried setting log as:

logger:
  default: error
  logs:
    homeassistant.components.insteon: debug
    pyinsteon.topics: debug
    pyinsteon.messages: debug

This will give a lot of information, not just the messages.

4

I’ll try the new log settings - thanks. FWIW I did a few more tests:

  • pulling the Ethernet cable from the hub
  • pulling the power cord from the hub

The results were that the switch was still being turned on with the Ethernet cable pulled, but not when the power cord was removed.

Because the switch was still being turned on when the Ethernet cable was pulled, it can’t be because HA is it sending commands to do so. And because it stopped when the hub had no power, I’m thinking that something in the hub is autonomously sending the commands. Or, I suppose, some other Insteon device has become linked to the switch and is commanding it to turn on, but I don’t think those messages need to be routed though the hub. So I suspect that for whatever reason something has come alive in the hub that wasn’t a problem before.

I’ll see what the new additional logging can show, but I’m thinking I need to factory reset the hub. When I converted Insteon to HA this spring, I removed the groups (scenes) from the hub and didn’t factory reset it, but it has worked perfectly until a few days ago.

5

If you look with the insteon control panel you may find it is in some scene. That scene may be in a schedule in the Hub. Therefore you would get exactly what you saw. It would not use Ethernet and only need power.

Now you don’t need to reset. You can make the scene inactive setting in_use to false in the ALDB.

6

I think that’s what I did back in April. If I look at the Insteon Configuration page in HA, I see all my devices, but nothing else. I can’t recall - would scenes appear as additional devices on that page?

7

Do you have this installed?

Eventually would lead you to here:

If not, that is what you need examine the ALDB deeper, see what things are in scenes and be able to control them.

Best to watch this video: Recording #4

8

I do have it installed, but I had forgotten how to access the aldb for each device (it’s actually now a bit different than what is shown in the video). Double-checking now, I had set any scene-related records to “not in use” for all devices when I set things up in April. Thanks for your direction.

I managed to find a more recent Insteon Developer Guide which explained the various messages in a lot more detail. I also noticed another anomaly - HA seemed to be spewing out the following at a high rate (several times a second):

2022-08-24 21:56:30.481 DEBUG (MainThread) [pyinsteon.messages] TX: b'\x02a\x0c\x11\x00' 
2022-08-24 21:56:30.576 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x61, group: 0x0c, cmd1: 0x11, cmd2: 0x00, ack: 0x15     !!! 0x11 = ON
2022-08-24 21:56:30.576 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 3000b5, flags: 0x05, cmd1: 0x11, cmd2: 0xff, ack: 0x06

This turns out to be a “Turn on group 12” command, which the hub is NAKing but the front door switch is ACKing, if I’m interpreting who is ACKing and NACKing correctly.

At any rate, the only change I made was to enable a disabled record in the switch and then disable it again, writing it back to the switch aldb. But some time later in the weekend, things just started working properly again. The switch was not being turned on, and the “Turn on group 12” commands ceased.

So all is well again, but I have no idea what cured the issue.