Insteon Sensor Not Updating Reliably

[NickDorak]

The problem

I have an Insteon I/O Linc device that is connected to Home Assistant. The sensor for this device within Home Assistant is wrong most of the time or not in sync with the device. I also have the same I/O Linc connected to a 8 button keypad, and they are always reliably in sync. Since two devices are working together well I feel that the issue must be within Home Assistant somewhere. I can see in the diagnostic logs, traffic from this device when the sensor is changed. It seems like Home Assistant only updates the sensor when it wants.

I am running Home Assistant Yellow running version 2024.1.5. On Insteon side, I am using a 2245-555 Hub (Firmware: a5) & 2450 I/O Linc (Firmware: 41). The sensor I have tested with included in the logs has address: 2f7476 (binary_sensor.i_o_linc_2f_74_76_sensor)

Here are the diagnostic logs for when the sensor changes state, but old state is still shown (not changed) on HA... home-assistant_insteon_2024-01-27T21-14-14.257Z.log

What version of Home Assistant Core has the issue?

core-2024.1.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Insteon

Link to integration documentation on our website

https://www.home-assistant.io/integrations/insteon

Diagnostics information

home-assistant_insteon_2024-01-27T21-14-14.257Z.log

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @teharris1, mind taking a look at this issue as it has been labeled with an integration (insteon) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `insteon` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign insteon` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

insteon documentation insteon source _{^{(message by IssueLinks)}}

[teharris1]

Can you confirm that the default links are created in the IO link in question?

[teharris1]

Ignore the above question.

The issue is that device 2F.74.76 never responds to status requests. Every time an IO link device changes it is required to send two status requests in order to see if the sensor or the switch changed. The status requests are being sent successfully but the device is never responding to them. The first thing I would try is to unplug the device for 10 seconds and then plug it back in.

[rslick]

@teharris1 Just to check: The two status commands you are sending are 1900 and 1901 the two replies are 1900 - 1900 or 19FF and 1901 - 1900 or 1901 and you are saying you weren't seeing any ACK from the I/Olinc ?

[teharris1]

@rslick yes, I don't see the direct ACK from the device. You can see the following lines in the log (lines 20 and 39) for the outbound status request and the modem ACK:

(line 20) TX: msg_id: 0x62, address: 2f7476, flags: 0x0f, cmd1: 0x19, cmd2: 0x01
(line 39) RX: msg_id: 0x62, address: 2f7476, flags: 0x0f, cmd1: 0x19, cmd2: 0x01, ack: 0x06

But we never see the DirectACK from the device. There is a retry of the status 0x01 again at line 79 but again there is no DirectACK. There is also a status 0x00 sent on line 192 with no DirectACK either.

[teharris1]

On second look, I was partially wrong. The DirectACK is coming back for status type 0x00 but not 0x01 so the responses are intermittent. @rslick you will also see the message type 0x5c to indicate timeout (keep in mind these show up as an invalid message still. I am working to build that into the library).