Insteon Binding (Beta) [3.3.0;3.5.0)

Thanks for your quick response. What you describe is what I thought the current state to be. For me doing a manual restore for over 100 devices would be a daunting task, especially in a panic situation as a disaster recovery. For now I will stay with what I have but if a backup/restore feature is added to the binding, I will be all in. Thanks again for your effort and support of the platform.

The error has not occurred again, I happened about 4 times after the OH 4.3 upgrade, maybe something related to the cleanup after upgrade? Thing will show channels after OG reload. Just finished converting all the devices from device legacy and everything is working except few lamplinc modules and a leak module.

image

Backup and restore functionality would be great since USB PLM are prone to fail, i’m personally on my third PLM and it is only a matter of time.

1 Like

What’s the unknown status description on these devices?

They say ā€œWaiting for product dataā€ I assume they have not ping back

It makes sense for your leak sensor. You can speed up the process by pressing the set button on that device.

As far as your LampLinc modules in unknown state, are these actually connected? If not, you need to power them on so that the binding can get their device configuration. After that, these would end up showing offline if disconnected.

I have open a PR adding that feature. Once it gets merged, you will be able to use it with the OH 5.0 snapshot. The database dump is a binary file which won’t be easily editable. I figured that any changes would be done directly on the database prior to backing it up.

https://github.com/openhab/openhab-addons/pull/17958

1 Like

Does the command ā€œinsteon device addMissingLinksā€ actually work. I’m getting a lot of errors messages in my OH logs for device missing default links, I have run ā€œopenhab:insteon device addMissingLinks 2E.B8.D0ā€ and/or ā€œopenhab:insteon device addMissingLinks --allā€ but the WARN continue in the logs.

2024-12-26 13:26:34.475 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.475 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.475 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.475 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.476 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.476 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.476 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.476 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.476 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.477 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.477 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.477 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.477 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.478 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.478 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.478 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.478 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.
2024-12-26 13:26:34.478 [WARN ] [nsteon.internal.device.InsteonDevice] - device 2E.B4.20 has missing default links [dimmer], run 'insteon device addMissingLinks' command via openhab console to fix.

Can you provide the output of these console commands?

insteon device listMissingLinks 2E.B4.20
insteon device listDatabase 2E.B4.20
insteon modem listDatabase --records | grep 2E.B4.20

Also, what console output did you get when running the addMissingLinks command?

@John_Siemon if you want to give a try, you use the build attached to the beta release below. This is for OH 4.3.

Please see below for output

openhab> openhab:insteon device addMissingLinks 2E.B8.D0
Adding 1 missing links for device 2E.B8.D0 to its link database...

openhab> insteon device listMissingLinks 2E.B4.20
There are 1 missing links from the link database for device 2E.B4.20:
dimmer: 49.FA.46 CTRL group: 0x01 data1: 0x03 data2: 0x1C data3: 0x01
openhab> insteon device listDatabase 2E.B4.20
The all-link database for device 2E.B4.20 contains 4 records:
0x0FFF 49.FA.46 RESP group: 0x01 data1: 0xFF data2: 0x1C data3: 0x00
0x0FF7 49.FA.46 CTRL group: 0x01 data1: 0x03 data2: 0x1C data3: 0x00
0x0FEF 00.00.00 LAST group: 0x00 data1: 0x00 data2: 0x00 data3: 0x00
0x0FE7 00.00.00 LAST group: 0x00 data1: 0x00 data2: 0x00 data3: 0x00
openhab> insteon modem listDatabase --records | grep 2E.B4.20
2E.B4.20 CTRL group: 0x01 data1: 0x01 data2: 0x0E data3: 0x43
2E.B4.20 CTRL group: 0x01 data1: 0x01 data2: 0x0E data3: 0x43
2E.B4.20 RESP group: 0x01 data1: 0x01 data2: 0x0E data3: 0x43

openhab> openhab:insteon device addMissingLinks --all
There are no missing links for device 4B.0E.26.
There are no missing links for device 34.75.1C.
There are no missing links for device 23.FC.A4.
Adding 1 missing links for device 14.2B.53 to its link database...
There are no missing links for device 25.4B.F4.
There are no missing links for device 1B.3D.90.
There are no missing links for device 24.F0.F1.
Adding 1 missing links for device 41.8D.E2 to its link database...
There are no missing links for device 42.BD.9F.
There are no missing links for device 15.64.7D.
Adding 1 missing links for device 2E.B4.20 to its link database...
There are no missing links for device 14.66.EA.
There are no missing links for device 15.63.AF.
The link database for device LL2EB8D0 has pending changes.
The link database for device leaksen2 is not loaded yet.
Adding 1 missing links for device 15.97.5A to the modem database...
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The link database for device leaksen1 is not loaded yet.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The link database for device motion1 is not loaded yet.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The modem database has pending changes.
The link database for device bathfankp is not loaded yet.
The modem database has pending changes.

@jeshab Thank you for providing a jar file with the most recent updates including the ability to backup and restore the PLM. This is a game changer for me. I did install the jar and after a restart of OH it loaded as expected. I did not have much time to fully test it, but I was able to create several backups of the PLM DB. I have not tried a restore, but the backup worked without any errors or other issues. I do have one device, an outletLinc dimmer outlet, that seems to be stubbornly stuck at configPending (green) but I have not had time to fully evaluate this. Perhaps it just needed to be turned on/off at the device for it to fully register. I am hoping that in the next few days I will be able to do a more complete evaluation. Thanks again for your support and effort in enhancing this binding.

1 Like

I assume it is pending on the device link database. The binding seems to not be able to download it successfully. Can you run the following console debug command and provide the event messages log for this device?

insteon debug startMonitoring <address>

@jeshab I took your suggestion to debug monitor the devices that are stuck ā€œconfigPending Waiting for Link Databaseā€ but I’m not seeing any logs created and the Things remain stuck. One is a garage door sensor IOLink 2450 and the other is the outletLink Dimmer 2472DWH. What is interesting to me is that I have more of these devices installed that are recognized and working fine, so it’s just these two that have issues. Any thoughts as to why or what I might try short of deleting the devices from the PLM and relinking?

What’s odd is that the binding was able to retrieve the product data from these devices. I would expect polling to be done every 5 minutes at that point and therefore, some message events (at the very least the ones sent by the binding) should be logged if you set up the monitoring accordingly.

Can you set the monitoring on one of your working device to compare? Also, can you try to disable and reenable the faulty things while having the monitoring already in place? Check for any errors in the server logs as well just in case. If this doesn’t work, you will need to enable debug log.

I just set the debugMonitoring to --all, but so far i’m not seeing any log in my userdata/insteon folder. When I did the database backup, the file was written to this folder without issue so it’s not likely a permissions problem. The server log seems clean, but I’ll try a couple more restarts but so far that hasn’t helped after 2-3 restarts. However this time I’ll pay close attention to the startup logs. Just for clarity, I’m running 4.3M4.

@jeshab just passing along some info based on my testing today. I was not able to get the configPending on 2 Things to resolve after many restarts using your latest binding linked above. I tried removing the cache and the tmp folders, I removed the binding from addon folder, restarted, added the binding back to the addon folder, restarted, all to no avail. Further, during my testing I found that ALL of my devices were non-responsive, meaning that I could not actuate them from the OH UI, even though they were mostly ONLINE(green), except for the 2 devices pending. Finally I decided to revert back to the binding that shipped with 4.3M4 and this resolved the non-responsive devices. I still have 2 Things pending, but in spite of them being pending I can actuate them (ie turn the light on/off and dim on the outletLink Dimmer). Of course with the 4.3M4 binding I have no ability to backup or restore the database, but that is where I am for now. Like I said previously, other than testing that I could backup the PLM, I really didn’t have a chance to evaluate the binding before today. When you tested your new binding with backup/restore capability, did you notice any Thing/device responsiveness issues? Did I need to recreate all of things when using the latest binding, because I did not do that?

One last point. The debug startMonitoring is working with your binding from 4.3M4. A log file created.