Insteon issue: Stopping Insteon Modem writer due to byte must be in range(0, 256)

Configuration
21

I did just push a change since it does not appear the version upgrade that I thought was pushed actually appears in 0.96. Also, is the entity switch.keypadlinc_on_off_4c_12_56_button_a in the group.radiador?

22

Yes, button_a is in the group.radiador

23

Hi @teharris1. I finally loaded the latest version (took a while because I upgraded my OS in order to get Python 3.7).

The latest change unfortunately hasn’t helped me. When it fails, it writes the following error to the log:

ERROR (MainThread) [insteonplm.plm] Restarting Insteon Modem writer due to byte must be in range(0, 256)

But it doesn’t actually restart and it doesn’t log the message. It looks like it is generating an unhandled exception when it attempts to log the message that caused the exception.

I’ve been able to come up with a way to consistently reproduce the issue using my 6 button switch. Below is my procedure:

  1. Start with everything in off state
  2. Turn on keypad B locally (push the button - issue doesn’t happen if I turn it on from HASS instead)
  3. Turn on keypad D from HASS
  4. Turn off keypad D from HASS - exception happens here

Now that I can reproduce it, I spent some more time tracing it through the code. It looks like the issue appears at the point where the checksum is added to the message. Here is the message before msg.set_checksum() is called:

{'code': 0x62, 'address': 4C.F6.77, 'flags': 0x10, 'cmd1': 0x2e, 'cmd2': 0x00, 'userdata': 0x01.09.c8.00.00.00.00.00.00.00.00.00.00.00, 'acknak': 0xNone}

After calling set_checksum(), when I attempt to print the message it generates the exception. Not sure if the issue is something wrong in the set_checksum() function or if there is something wrong with the message we’re feeding it.

As noted above in step 2, I don’t have the issue if I turn on keypad B from HASS instead of locally. In that case, the message prior to adding the checksum is:

{'code': 0x62, 'address': 4C.F6.77, 'flags': 0x10, 'cmd1': 0x2e, 'cmd2': 0x00, 'userdata': 0x01.09.08.00.00.00.00.00.00.00.00.00.00.c0, 'acknak': 0xNone}

Hope that helps. Let me know if you need more data or want me to try anything else. I’m currently running HASS 0.100.2.

24

Let me look at this. Great info. Thanks.

1 Like
25

Any update on the Insteon integration. Mine has not working consistantly for over a month. I am running latest release 102.2. Switches stop responding to requests after about 30 minutes. Happy to provide logs if that would help. I am also using Insteon Hub 2245.

Thanks!

26

Similar to rlust, when I updated from 102.1 to 102.3 a few days ago, all my insteon switches and automations stopped working. I rolled back to 102.1 last night, and all insteon functions are working again.
I’m using an Insteon 2245 hub for my connectivity.

2 Likes
27

I just started experiencing the same issue after upgrading to 103. It was working fine on 102.3. Happy to provide anything that may be helpful tracking the issue down. I do have a couple KPL switches.

1 Like
28

I used to have this problem however would happen once a week, now it happens on daily bases on 103.

29

Can your describe your setup. Are you running on a raspberry pi and if so what model?

30

I am running on unraid as a VM. Using an Insteon 2245 Hub V2.

31

FINALLY! I have a fix. I was able to simulate (but not reproduce the issue) with @kbpro message example. Now I am able to actually reproduce the issue. Here is what I did:

  1. Turn everything off (manually or via HA makes no difference)
  2. Use HA to turn on the following buttons on an 8 button KPL D, G, H. It does not matter the order of how you turn them on. The error occurs when you turn the third one on. I cannot find any other combination that triggers this error.

This issue is sort of with the set_checksum method because that is where the bad data is being produced. The reason I say “sort of” is because the method is doing exactly what the Insteon developer guide says to do and it is still failing. I should have thought about it more and I would have seen their mistake.

(For those of you with a tech background the checksum is performing a complement of the last byte then adding one. If the complement is 0xff then adding one makes it 0x0100 which is the reason for the failure. So I have to make an assumption of what they expect in this case. My assumption is they want a simple 8 bit checksum which would then be 0x00)

I have tested the fix and it works. For those who want to fix it now rather than wait for the next release, you can change line 160 in extendedSend.py to:

        self._userdata["d14"] = chksum & 0xff

This file is in the insteonplm/messages directory in your python site-packages. The exact location is platform and version specific.

The official fix will likely be in 0.105 but I am not sure it will get into 0.105.0.

32

I have just released a new version of the Insteon component for beta testing. It is available as a custom component and the details can be found in this post: