Problem with stability of Insteon on OH 4.3.2

Add-ons Bindings
1

Hardware: Docker running on Synology RS1221
OS: Linux 4.4.302
Java Runtime Environment: 17.0.13
openHAB version: 4.3.2

I’m at a loss but to ask if anyone has any suggestions as to how to debug an issue.

I recently upgrade to the newest release of Openhab. I had previously used 3.x with all configuration done in the UI. I’ve always wanted to do file based configuration so I took this opportunity to do a new install and configuring everything in files.

The problem I am having is after starting the system it runs for a few hours and then all my Insteon devices stop working. They show the status of ONLINE but when I try to turn a device ON or OFF the logs show it works (received command OFF, predicted to become OFF, changed from ON to OFF) but the device doesn’t do anything. Nothing else in the logs like a connection error, etc.

I’ve turned on detail logging for the Insteon logs.

The devices work fine from the Insteon App.

Never had any problem previously with the old version of OH.

I’ve searched the Forums, and it doesn’t appear anyone else has had this issue. What more can I do to track down the issue?

Scott

2

Could you provide some information on your Insteon environment? What type of modem are you using? How many devices are linked to it?

3

I used the hub2 using the following Bridge setup:
Bridge insteon:hub2:home [hostname=“10.27.27.200”, username=“XXX”, password=“YYY”]

Here is an example of a thing. Most are all like this:
Thing insteon:device:4FE672 “Guest Bedroom Switched Floor Outlets” (insteon:hub2:home) @ “Guest Bedroom” [address=“4F.E6.72”]

I have a total of 71 Insteon Devices.

Yesterday I created a new OH3.2 Environment and reconfigured the Insteon Devices (add product key). It seems to be stable with it still working at this time. 4.3.2 has never gone more than a couple hours without becoming “Disconnected”.

Scott

4

Can you try the latest beta version in the link below? Some changes related to the transport flow control were added to prevent overwhelming the modem in environment with a lot of Insteon devices such as yours.

5

Yes, I can do that. I’ve never done a manual install before. Is it correct I copy the 5.0-SNAPSHOT jar into the addons and remove the Insteon Binding?

6

I removed the Binding and copied the jar into the addons directory. I am now about 15 hours into the reboot and everything is working. I’ll let you know if I have any further issues. What version will this be in a released version so I can upgrade at that time?

7

Can you confirm that all your devices are showing as online and none of them are showing as CONFIGURATION_PENDING?

The changes related to the transport flow control still need to get reviewed. I am still waiting on additional users testing them. At the very least, these will be included in OH 5.0 and any upcoming milestone version (probably not the first one though). I will look to get these in the next OH 4.3.x patch release as well once these get merged.

8

I do have one with Thing with a status of CONFIGURATION_PENDING. However, this has been this way for awhile (Insteon Motion Detector) and I just haven’t had a chance to look into it in more detail. Most of my Leak Detectors show UNKNOWN and seem to not be getting data from the Insteon database as they are configured identically as the ones that are working. Other than that all of the things show ONLINE.

9

Most likely, the binding wasn’t able to download the device database the first time around. For sensors such as motion detectors, It can only be downloaded when the device is awake.

As mentioned above, sensors need to be awake to be polled. Unless triggered, these usually wake up once a day when they send a heartbeat. So most likely, the leak detectors that sent their heartbeat while the binding was running are showing ONLINE and the ones that haven’t yet would still show as UNKNOWN. These should update within 24 hours.

10

Thanks for the reply. I’ve been working on trying to get these working for a while and I was aware of the “wake” issue. I’ll see how thing proceed and let you know. Thanks so much for all your help.

1 Like
11

FIRST: Thanks OpenHab Team. :heart:
OH is fantastic and I have used it reliably for years (mostly)
Ever since “Insteon -1st gen” went out of business.

SECOND:
I had a similar issue with OH 4.3.3.
I am using a hub2. and OH on Lenovo ThinkCenter (8 GB, quad-core I5 CPU, wired ethernet)
with a fresh install of Debian 12. Did a manual install of OH 4.3.3 with: apt-get install openhab

Added the hub and all 30 devices using the WEB-UI. (all Insteon, mostly light switches)
Before I was done adding all devices, I started getting
“CONFIGURATION_PENDING” and “Error: Comm” on “things”.

Some devices were worse then others, but the only consistency was about a 20% failure rate.
To try and resolve the issue I:

  • disabled/re-enabled devices (this cleared the “Error:comm” for about 5 minutes.
  • deleted/re-added devices (didn’t help)
  • Waited an hour (resetting switches, turning on/off manually and with OH)
  • Multiple reboots and cycling services: systemctl stop openhab
  • re-linking my devices to the hub (this helped sometimes… for 5 minutes)
    and did fix one “unknown” error.
  • removed “unknown things”
  • increased “hub polling” from 1000 to 2500 ms (2.5 seconds)
    This resolved most “Error: comm”, but they flipped to “CONFIGURATION PENDING”

Ultimately, I downgraded with: apt-get install openhab=4.1.1-1
I did have to re-add the bridge, and change the bridge on all my “things”,
BUT all is stable and really “peppy”.

I suspect trying to continually get full device info (especially with missing devices)
is just overloading the poor “Insteon Mesh Network”. With a mesh network,
there is not a direct link to each device, but a broadcast in the tree.
Scanning for a missing devices means hitting every node in the tree at least once.
Maybe only scanning “on demand” would be a better option.
Most folks know when their “things” change.

I did have an “OpenHabian 3.x and 4.x” installed on a Pi4, but it would kill
USB drives and occasionally hang for several minutes (probably over heating)

12

Unfortunately, the version of Insteon binding I used to maintain prior to 4.3 was replaced with the current version with wasn’t vetted well enough. I objected to the changes, but was overruled by one of the addon maintainers. Because of this, I stepped down as the maintainer of the Insteon binding.

BTW. I am running the 4.2.3 Insteon binding with 4.3 by uninstalling the Insteon binding and putting the 4.2.3 binding in the addons directory. If you want to give it a try, you can get the binding from org.openhab.binding.insteon-4.2.3.jar - Google Drive

1 Like
13

Rob, I gave 4.2.2 a try… that worked well. Nice to know 4.2.3 will work too.
Please let them know I appreciate your support and assistance through 4.2.3
I wish them well, and hope they do better in future releases.

14

Have you tried the beta version listed above?

15

jeshab Jeremy, Thanks for reaching out. I am stable now.
The Beta version mentioned was pre-4.3.3, and from last year.

I don’t want to break my “production system”, BUT…

IF you would like me to Beta Test THEN
Let me know and I will build a 2nd system and do some brief testing.
I have a fairly homogeneous Insteon system, mostly switches and plugs.
Let me know if you would like any special testing:

  • Add/remove switches
  • Unplug an added device
  • Thermostat features (read temp, set temp, change mode, …)
  • Add a water sensor.
  • …
16

Just checking in. It’s now been over a month and have had no further issues with Insteon Devices. I removed and added the Leak Detectors that were having the issues and that fixed them. I decided to change my motion detectors to FIBARO z-wave devices (which also do temp, etc.) so I sidestepped that problem. Scott

1 Like
17

Don’t go by the date of the release. Instead look at the upload timestamp on the attached files at the bottom of the release page. The same release was kept for ease of use so that the same link can be used. The beta release has been updated over that period with new bug fixes and enhancements with some not included in the latest patch release.

Another point is that you shouldn’t have to use a pre-OH 4.3.0 version, the current binding is backward compatible using the legacy network and device things.

Assuming that the configuration pending description was “Waiting for link database”, this is expected. Keep in mind that the device will show as online in that state and will respond to commands it receives. That state usually clears within one device poll interval.

As far as the second error, if you could provide the exact description, that would be helpful in providing what could have been the underlying cause.

For reference, the new binding doesn’t continually get the full device info. It has caching built in. It is true that the first time you start the binding, it may take a few device poll cycles to stabilize depending on the number of devices linked to the modem, but once all the information is retrieved and cached, only devices with linked channels will be polled in line to how the legacy binding was operating.

The data used to determine missing devices (and scenes) is based on the modem database. This was done the same way in the legacy binding. The only difference here is that the new binding is polling product data to determine the device model while previously you had to manually configure it.

It would be much appreciated if you could try the latest beta release and let me know if you are experiencing any issues. I am particular interested in getting feedback with the thermostat device. I have yet to have someone to do a full test with the new binding. Thanks.

18

jeshab Jeremy, The “short answer” is:
Q: [could you] try the latest beta?
A: Yes, I’ll get that setup…
it might take me a few days.
I will respond with progress no later than Tuesday.

19

Physical server: Lenovo ThinkCenter (8 GB, quad-core I5 CPU, wired ethernet)
Fresh install of Debian 12, OpenJDK-JRE 17, and latest OpenHab.4.3.4
Dedicated machine JUST for this testing.
Installed Insteon snapshot5.0 (hard not to :slightly_smiling_face: )

Short answer:
Pretty much the same result. “Error: Comm”, “Pending Config”

Medium answer:
Setup took a bit (always does), but that is done.

Excluding setup, looks to be over an hour of testing
Two notable events:
 *** SMART PLUG:  Hung.  Not even manual control worked.
 *** WEB UI:  Hung

I did set "log level" of Insteon to [DEBUG].  About 8 MB of logs (uncompressed)

Excerpt of log /var/log/openhab/openhab.log*
   19:39:36.990 [DEBUG] ... - bundle org.openhab.binding.insteon:5.0.0.202503301327
Let me know what logs (if any) you would like.

Long answer:

Over an hour of testing… Below is the mostly RAW Journal

Used WebUI to add 31 devices (did not configure channels yet)
     After 20 minutes, all of the "config pending" completed
     All but two of the "Error: comm" cleared
     "pause/unpause" cleared the "Error: comm"
     2 "unknown devices"

Unknown devices
     "Flame"=  LampLinc 2456D3 (older) Moving closer to hub fixed
     "Table"=  LampLinc 2457D2 (newer) Moving closer => Config Pending.

Started to configuring a few channels:
After 30 minutes:   Error: Comm: "Spareroom"
After 40 minutes:   Error: comm:  "Bedroom"
"Work" (LampLinc Dimmer smart plug) worked
"Office" (no control)

1 hour in: 
BEFORE reboot: 
    2x comm error (no control)
    1x Config Pending
    1x online, but no-control
    1x full control

AFTER reboot: (ie: systemctl stop/start openhab)
    Within 2 minutes, all devices online (except config pending)
    Full control of Configured "Items" 

Within 4 minutes, started getting "Comm: Error"
   "Desk"=Comm Error.. pause/unpause..  online... but no control
   *** Worse yet, manual switch would not work until plug power cycled ***
   THEN full control enabled

Comm Error: Desk, DinningRoom, Office, Spareroom 
"Table" had "Config Pending", but that cleared,  but no control (yet)

"Heat": added "Heat" channel
     I could read the temperature, but not change it
     Changed from "point" to "setpoint" so I could change
     Change temp worked

20 minutes after cycling service, still 4 "Error: Comm"
"Table" smart plug:  Unplugged/replugged 
     *** WEB UI Hung *** - reloaded the web page
     Eventually, I had full control of the smart plug "Table"

Error Comm: Office, Dinningroom, Desk, Bedroom, Spareroom
  "Office": no control
  "Spareroom": no control
   I did not check the others

After 40 minutes, tried:  systemctl restart openhab
    Less then two minutes, all online
    Configed "Items" seem to work

4 minutes in:
    comm error: desk, bedroom, office
    config pending, Dinning room
    Heat still working fine

closing down experiment
20

Thanks for doing this testing.

So if I understand correctly, after 20 minutes, all but two devices were online. Later on, you started to get devices that randomly were marked as offline in OH with communication error (device not responding?). It is expected that the binding will not process commands if a given device is marked as offline.

I have been working with another user experiencing similar offline issues. The binding will marked a device offline after 5 consecutive failed message. I am in the process of either adding a setting to ignore that threshold at the device or bridge level, or decreasing the sensitivity of the current implementation. It seems that users with an environment with a lot of noise affecting the Insteon communication are more prone to experience such use-case.

As far as an online device that wasn’t responding to command, I would be interesting if you can replicate and provide with the steps along with the device type. Could it be that the command response was delayed?

Related to the thermostat testing, it seems that it is working as intended?