4.3.1 Insteon binding does not properly read the PLM all link database

Add-ons Bindings
1

The 4.3.1 Insteon binding doesn’t properly read the PLM all link database. The command insteon modem listDatabase returns:

openhab> insteon modem listDatabase
The all-link database for modem 24.11.9D contains 46 devices:
17.94.B0: modem controls no groups and responds to groups [1]
19.8B.65: modem controls no groups and responds to groups [1]
22.F6.88: modem controls groups [4, 5, 6, 254] and responds to groups [1, 4, 5, 6]
22.F8.74: modem controls no groups and responds to groups [1, 3, 4, 5, 6]
22.F8.B8: modem controls groups [254] and responds to groups [1, 3, 4, 5, 6]
23.9D.6B: modem controls no groups and responds to groups [1]
23.9D.86: modem controls groups [254] and responds to groups [1]
23.9D.93: modem controls groups [254] and responds to groups [1]
23.9D.94: modem controls no groups and responds to groups [1]
23.9D.AC: modem controls groups [254] and responds to no groups
23.9D.E8: modem controls no groups and responds to groups [1]
23.9D.FA: modem controls no groups and responds to groups [1]
23.9E.12: modem controls no groups and responds to groups [1]
23.9E.17: modem controls no groups and responds to groups [1]
23.9E.2E: modem controls no groups and responds to groups [1]
23.9E.43: modem controls no groups and responds to groups [1]
23.9E.7B: modem controls no groups and responds to groups [1]
23.9E.8A: modem controls groups [254] and responds to groups [1]
23.9F.26: modem controls no groups and responds to groups [1]
23.9F.2D: modem controls no groups and responds to groups [1]
23.9F.55: modem controls no groups and responds to groups [1]
23.9F.6C: modem controls groups [254] and responds to groups [1]
23.9F.82: modem controls groups [254] and responds to groups [1]
23.9F.AD: modem controls groups [254] and responds to groups [1]
23.9F.AF: modem controls no groups and responds to groups [1]
23.9F.BA: modem controls no groups and responds to groups [1]
23.9F.C9: modem controls no groups and responds to groups [1]
23.9F.F0: modem controls no groups and responds to groups [1]
23.9F.FE: modem controls no groups and responds to groups [1]
23.A0.1E: modem controls no groups and responds to groups [1]
23.A0.37: modem controls no groups and responds to groups [1]
23.A0.44: modem controls no groups and responds to groups [1]
23.A0.51: modem controls no groups and responds to groups [1]
23.A0.73: modem controls no groups and responds to groups [1]
23.A0.7A: modem controls no groups and responds to groups [1]
23.A0.7E: modem controls groups [254] and responds to no groups
23.A0.AD: modem controls groups [254] and responds to groups [1]
24.30.8F: modem controls no groups and responds to groups [1]
24.31.A0: modem controls no groups and responds to groups [1]
24.32.18: modem controls no groups and responds to groups [1]
24.33.8F: modem controls no groups and responds to groups [1]
24.F2.7E: modem controls no groups and responds to groups [1]
31.6F.4B: modem controls groups [254] and responds to no groups
31.6F.53: modem controls groups [254] and responds to no groups
47.02.39: modem controls groups [254] and responds to groups [1]
54.69.D5: modem controls no groups and responds to groups [1]

The 4.2.3 Insteon binding (and earlier versions) return the correct results The command insteon display_local_database returns:

openhab> insteon display_local_database
local database contains 58 entries
17.93.87: plm controls groups (254) and responds to groups (1)
17.94.B0: plm controls groups (254) and responds to groups (1)
19.8A.2B: plm controls groups (254) and responds to groups (1)
19.8B.65: plm controls groups (254) and responds to groups (1)
21.F7.75: plm controls groups (254) and responds to groups ()
22.F6.88: plm controls groups (3,4,5,6,254) and responds to groups (1,3,4,5,6)
22.F8.74: plm controls groups (3,4,5,6,254) and responds to groups (1,3,4,5,6)
22.F8.B8: plm controls groups (3,4,5,6,254) and responds to groups (1,3,4,5,6)
23.9D.6B: plm controls groups (254) and responds to groups (1)
23.9D.86: plm controls groups (254) and responds to groups (1)
23.9D.93: plm controls groups (254) and responds to groups (1)
23.9D.94: plm controls groups (254) and responds to groups (1)
23.9D.AC: plm controls groups (254) and responds to groups (1)
23.9D.E8: plm controls groups (254) and responds to groups (1)
23.9D.FA: plm controls groups (254) and responds to groups (1)
23.9E.12: plm controls groups (254) and responds to groups (1)
23.9E.17: plm controls groups (254) and responds to groups (1)
23.9E.2E: plm controls groups (254) and responds to groups (1)
23.9E.35: plm controls groups (254) and responds to groups (1)
23.9E.43: plm controls groups (254) and responds to groups (1)
23.9E.7B: plm controls groups (254) and responds to groups (1)
23.9E.8A: plm controls groups (254) and responds to groups (1)
23.9E.9D: plm controls groups (254) and responds to groups (1)
23.9F.25: plm controls groups (254) and responds to groups (1)
23.9F.26: plm controls groups (254) and responds to groups (1)
23.9F.2D: plm controls groups (254) and responds to groups (1)
23.9F.55: plm controls groups (254) and responds to groups (1)
23.9F.6C: plm controls groups (254) and responds to groups (1)
23.9F.82: plm controls groups (254) and responds to groups (1)
23.9F.AD: plm controls groups (254) and responds to groups (1)
23.9F.AF: plm controls groups (254) and responds to groups (1)
23.9F.BA: plm controls groups (254) and responds to groups (1)
23.9F.C9: plm controls groups (254) and responds to groups (1)
23.9F.D0: plm controls groups (254) and responds to groups (1)
23.9F.F0: plm controls groups (254) and responds to groups (1)
23.9F.FE: plm controls groups (254) and responds to groups (1)
23.A0.1E: plm controls groups (254) and responds to groups (1)
23.A0.37: plm controls groups (254) and responds to groups (1)
23.A0.44: plm controls groups (254) and responds to groups (1)
23.A0.51: plm controls groups (254) and responds to groups (1)
23.A0.73: plm controls groups (254) and responds to groups (1)
23.A0.7A: plm controls groups (254) and responds to groups (1)
23.A0.7E: plm controls groups (254) and responds to groups (1)
23.A0.96: plm controls groups (254) and responds to groups (1)
23.A0.AD: plm controls groups (254) and responds to groups (1)
24.11.9D: plm (/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6028K03-if00-port0)
24.30.8F: plm controls groups (254) and responds to groups (1)
24.31.81: plm controls groups (254) and responds to groups (1)
24.31.A0: plm controls groups (254) and responds to groups (1)
24.32.18: plm controls groups (254) and responds to groups (1)
24.33.8F: plm controls groups (254) and responds to groups (1)
24.33.F7: plm controls groups (254) and responds to groups (1)
24.34.65: plm controls groups (254) and responds to groups (1)
24.F2.7E: plm controls groups (254) and responds to groups (1)
31.6F.4B: plm controls groups (254) and responds to groups (1)
31.6F.53: plm controls groups (254) and responds to groups (1)
47.02.39: plm controls groups (254) and responds to groups (1)
54.69.D5: plm controls groups (254) and responds to groups (1)
1 Like
2

Hi @ranielsen,

Thanks for reporting this issue. I have been working with several users on this matter. This seems to affect serial based PLM only when downloading the modem database records. I use a hub modem which doesn’t seem to be affected.

To be clear this affects the new implementation and not the legacy one part of 4.3.1. If you want to help troubleshooting, you can download the latest beta release in which I made an attempt to fix this one. If you do so, could you provide me with trace logs after you issued console command insteon modem reloadDatabase? Thanks

3

This version appears to download the database correctly. The only difference from the 4.2.3 is the following:

24.11.9D: plm (/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6028K03-if00-port0)

It’s been over an hour since the devices were discovered and added as devices from the inbox. Here’s the current issues I’m experiencing:

  • 3 Insteon 2466DW ToggleLinc Dimmer’s that are in the state: UNKNOWN Waiting for product data
  • 2 Insteon 2423A1 iMeter Solo’s that are in the state: CONFIGURATION_PENDING Waiting for link database
  • many device AA.BB.CC has missing default links [dimmer], run ‘insteon device addMissingLinks’ command via openhab console to fix

The iMeter Solo’s have been flakey for awhile and may be a valid state.

4

I’ve been helping with testing for @jeshab

I have a few devices that act the same way. My 2477D dimmer that is pretty far away and on quite old wiring (I’m in a >100 year old house) never seems to respond. Several times I’ve had to go and hit a button then it communicates its ID to the PLM and everything is good.

I think this is the difference with this idea of going and polling off of the devices in the PLMs link db for their IDs / device types rather than how in the past we had to tell the software what type of device it was by manually selecting the product key. Some devices (be it the device itself or old / long wiring etc) act flaky and just don’t like to respond.

You might want to just go hit a button on your devices you are waiting for and see if they then come up.

5

I’ve done that multiple times… One of them is in the same room as the breaker box.

6

This is expected. The modem device is now the bridge thing (which has now channels). And scenes have their own thing type. The legacy binding was just adding that device in order to control scenes but wasn’t representative of an actual device part of the modem database.

So I did some additional troubleshoot with the trace logs I got from several users with serial PLMs. It seems that the rate of messages being sent to these modems is too fast. I believe this is how it was in the legacy binding but less apparent because it didn’t retrieve the amount of data from each device that the new one is doing. So I am currently working in slowing that rate to prevent the high amount of pure NAK I am seeing in these logs, which seem to affect the ability to get all the data necessary for the new binding to show an accurate picture.

What’s the ID of that device so I can check in the logs you providing me? I may have to increase the timeout when the product data requests are sent.

Which device type?

7

Its 43.48.88. Its not every time, but it has happened a few times.

8

2466D and 2466S

9

I just uploaded a new build at the link above that should address this issue. Hopefully it resolves some of the data inconstancy that serial PLM users are experiencing with the new implementation. If you are still experiencing issues after installing that version, can you please provide trace logs during the modem database loading process?

The fix includes the following changes:

  • Modem database record queries will be sent first followed by product data requests. Previously, these queries were intertwined which a serial PLM doesn’t seem to handle very well.
  • Improved the transport writer waiting for reply acknowledgement accuracy. Previously, that process would use any message reply to confirm the acknowledgement of the last message sent to the modem. This caused collisions and pure naks when the modem is dealing with a high amount of traffic.
  • Increased the interval between writes to limit pure naks from being generated by the PLM.
10

No improvement from prior test binding, This one is 5.0.0.202501082307. I’ll PM you the logs.

11

Thanks very much for providing the logs. There were close to no pure naks which is an improvement to me. :smiley:

Related to your iMeter Solo devices being stuck in CONFIGURATION_PENDING, I had to update the first record location configuration to 0x00FF compare to the default 0x0FFF. This was causing the loaded records verification process to incorrectly mark the status as uncompleted. I have open the below PR to fix this one and uploaded a new build including this fix so you can confirm that this issue is resolved and confirm that these devices are working properly.

As a side note, I noticed that these devices are sending unsolicited 0x88 extended messages. Do you know what these are related to? The developer documentation doesn’t mention these.

2025-01-09 11:34:38.587 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x51|fromAddress:19.8A.2B|toAddress:24.11.9D|messageFlags:0x1B=DIRECT:2:3|command1:0x88|command2:0x00|userData1:0x00|userData2:0x02|userData3:0xA5|userData4:0x61|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0x00|

Related to your two 2466S device in unknown state, the binding isn’t getting the expected broadcast message with the product information. I am not sure if this is linking issue on the device side or a communication issue if far away from the PLM.

2025-01-09 11:34:42.966 [DEBUG] [ding.insteon.internal.transport.Port] - writing: OUT:Cmd:0x62|toAddress:24.32.18|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
2025-01-09 11:34:42.966 [TRACE] [ternal.device.database.ModemDBReader] - starting product request timer for 24.32.18
2025-01-09 11:34:42.999 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x62|toAddress:24.32.18|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|ACK/NACK:0x06|
2025-01-09 11:34:43.306 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x50|fromAddress:24.32.18|toAddress:24.11.9D|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x10|command2:0x00|
2025-01-09 11:34:45.967 [DEBUG] [ternal.device.database.ModemDBReader] - product request timed out for 24.32.18

2025-01-09 11:34:56.450 [DEBUG] [ding.insteon.internal.transport.Port] - writing: OUT:Cmd:0x62|toAddress:24.33.8F|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
2025-01-09 11:34:56.450 [TRACE] [ternal.device.database.ModemDBReader] - starting product request timer for 24.33.8F
2025-01-09 11:34:56.489 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x62|toAddress:24.33.8F|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|ACK/NACK:0x06|
2025-01-09 11:34:59.451 [DEBUG] [ternal.device.database.ModemDBReader] - product request timed out for 24.33.8F

Can you try to press on the on/off on one of these devices and provide trace logs at the time you do so? Basically the binding will try to send a product id request 0x10 once it receives the all link broadcast button press event. I am curious if in this situation, these devices would answer that request.

12

I tried the latest build and now the iMeter Solo’s change to ONLINE.

I’ll try to look into the other two switches tomorrow and get back to you with my findings.

13

Thanks for confirming. Could you check if the iMeter Solo is working as expected? Keep in mind that the legacy update channel was replaced by supporting the REFRESH command.

14

I air gapped both switches and one of them started working. The other one isn’t and it’s behaving very weird. With the pre 4.3 binding, its notified when the switch is turned on/off, but it can’t control the device. Using my old config tool, it can’t read the database either. When I get time, I’ll reset the device and try to add it back.

I am not using the 4.3 binding, only in a test instance of openhab to see how the binding behaves. My production instance is using the 4.2.3 version.

Also, as I pointed out above, I’m getting a bunch of warnings like:

2025-01-10 06:57:26.672 [WARN ] [nsteon.internal.device.InsteonDevice] - device 17.93.87 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.

I also noticed this in the file:

2025-01-10 07:18:37.452 [WARN ] [.internal.device.ProductDataRegistry] - unknown product for devCat:0x51 subCat:0x1F in device products xml file
15

Is there a way you could link the channels to a test item on your test instance? Just wanted to make sure that the output values are as expected.

Could you try to do a modem database reload and see if the product information for that switch is getting sent during that process?

Could you provide the missing links and database output for that device along with the modem side? Other users have reported this one and I need to update the determination logic if these warnings are actual false positives.

insteon device listMissingLinks 17.93.87

insteon device listDatabase 17.93.87

insteon modem listDatabase --records | grep 17.93.87

That’s an interesting one. Are you getting this warning consistently? If so, would you be able to get the trace logs around the time that warning is triggered. This would indicate that the binding received an unknown product information. However, device category 0x51 doesn’t exist. So I would be inclined to say, a corrupted message caused this warning to be generated.

16

I’m not seeing any data after about a 1/2 hour, energy and power usage are NULL. I haven’t used them for awhile since they were’t working before either. Sorry that I can’t provide more info.

The product information looks correct, I compared it to another device.

openhab> insteon device listMissingLinks 17.93.87
There are 1 missing links from the link database for device 17.93.87:
dimmer: 24.11.9D CTRL group: 0x01 data1: 0x03 data2: 0x1C data3: 0x01
openhab> insteon device listDatabase 17.93.87
The all-link database for device 17.93.87 contains 1 records:
0x0FFF 00.00.00 LAST group: 0x00 data1: 0x00 data2: 0x00 data3: 0x00
openhab> insteon modem listDatabase --records | grep 17.93.87
17.93.87 CTRL group: 0xFE data1: 0x01 data2: 0x05 data3: 0x2D
17.93.87 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x01

This was the first time I noticed it.

17

Could you provide the message event log for that device? Let it run for at least a poll interval. I could try to fix if this is an issue with the binding implementation.

insteon debug startMonitoring 19.8B.65

Understood, I just wanted to see if the binding can get the product information this time around after you powercycled the device without you having to take a manual action. I am looking to update the documentation based on this use case.

So this looks to be a valid missing link. What kind of device is this?

So probably a one off due to a corrupted message.

18

That device is a Insteon 2484DWH8 KeypadLinc Dimmer Countdown Timer. It’s connected to a bathroom fan. I’m getting the warning with:

  • 1 - 2334-232
  • 2 - 2484DWH8
  • 37 - 2466D

Here’s the output from one of the 2466D’s:

openhab> insteon device listMissingLinks 24.F2.7E
There are 1 missing links from the link database for device 24.F2.7E:
dimmer: 24.11.9D CTRL group: 0x01 data1: 0x03 data2: 0x1C data3: 0x01
There are 1 missing links from the modem database for device 24.F2.7E:
dimmer: 24.F2.7E RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
openhab> insteon device listDatabase 24.F2.7E
The all-link database for device 24.F2.7E contains 3 records:
0x0FFF 24.11.9D RESP group: 0xFE data1: 0x00 data2: 0x1C data3: 0x00
0x0FF7 24.11.9D CTRL group: 0x01 data1: 0x03 data2: 0x1C data3: 0x00
0x0FEF 00.00.00 LAST group: 0x00 data1: 0x00 data2: 0x00 data3: 0x00
openhab> insteon modem listDatabase --records | grep 24.F2.7E
24.F2.7E CTRL group: 0xFE data1: 0x01 data2: 0x1F data3: 0x41

I started all over with a fresh version of OH 4.3.1, and the latest Insteon binding. The first time it showed up in the inbox as Insteon Device 23.9E.17. I left it in the inbox and then did a insteon modem reloadDatabase comand. The device was discovered correctly the 2nd time around as a Insteon 2466DW ToggleLinc Dimmer. Something similar to this happed last time where it took multiple attempts to properly discover one of the devices. This time around I got some errors for devices that I shouldn’t have:

2025-01-10 12:01:02.741 [WARN ] [nsteon.internal.device.InsteonDevice] - device 23.9F.AD not found in the modem database. Did you forget to link?
2025-01-10 12:01:02.755 [WARN ] [nsteon.internal.device.InsteonDevice] - device 23.9D.86 not found in the modem database. Did you forget to link?
19

In this instance, the device database missing link for 24.F2.7E is a false positive while the modem database for that same device one isn’t.

Sorry for asking again, I would need trace logs to see if there were any pure naks generated during the database loading process.

20

Yeah, These devices have been configured and worked properly since OH 1 days.

I sent you a PM with log files with the 5.0.0.202501110404 version of the binding. The log files are from initial configuration of the binding which didn’t correctly discover one device Insteon Device 31.6F.4B (I/O Link), followed by a database reload which properly discovered it.