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

Configuration
13

Can you show me the automation you are using? Does the automation trigger the error every time?

14

my problem is similar yours, I have an automation, that detect when an button is pressed, and after 2 hours power off this device, but if you power off manually it before reach this 2 hours, HA fail, with this error.
My automation is simple:

  • id: ‘1557535057760’
    alias: Radiador off - 2 horas
    trigger:
    • entity_id: switch.keypadlinc_on_off_4c_12_56_button_a
      platform: state
      to: ‘on’
      condition: []
      action:
    • delay: 02:00:10
    • data:
      entity_id: group.radiador
      service: homeassistant.turn_off

Sometimes fail every time, other no, I couldn’t detect why sometime fail, sometimes no.

15

I am pushing a change that will keep HA from stopping but does not fix the underlying issue. However, it will better log the issue so we can identify why this is happening. I hope this will be in 0.96.0

16

Hi @teharris1, do you have news about the change?

17

This should be in the current release, 0.96.1. Just keep in mind it will not prevent the error from occurring, it will just prevent the Insteon component from stopping and it will better log the issue. When you see the issue in the log (debug mode not required). please post it here so I can find the true underlying cause.

1 Like
18

Hi @teharris1, I don’t know is the debug log is more extensive now, but, I’m attaching a new log, (it failed again)

19

Can you confirm what version of HA you are on? This message indicates you are on a version prior to 0.96. The latest version will not stop the modem for this issue. It will only log the issue and restart the writer.

20

I’m 0.96.5

I have an automation that restart HA after this issue happen, I deactivated it after upgrade to 0.96.5.
But not worked, so, the automation was reactivated, and today, my system working restarting every 36 or 40 hours aprox, sometimes more…

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: