Insteon Binding (Beta) [4.1.0.0;4.3.0.0)

This is a rewrite of the Insteon binding adding some much needed improvements.

Apart from simplifying the user experience by retrieving all the configuration directly from the device when possible, and improving the way the Insteon things are configured in MainUI, here is an exhaustive list of the changes:

  • Introduced device configuration automated determination
  • Converted mode-based number items to string type with descriptive states
  • Added number items uom support
  • Added scenes and X10 device things
  • Added distinct bridge things for supported Hub/PLM devices
  • Added button event trigger channels
  • Added device products configuration layer
  • Added device link database support
  • Added device cache storage
  • Added device operating flags controls
  • Added modem configuration flags controls
  • Added related devices synchronization feature
  • Added heartbeat timeout monitor
  • Added ability to link/unlink a device to the modem
  • Added ability to add missing default links
  • Added link database & scene management support
  • Added scene state support
  • Added new i3 devices basic support (untested)
  • Added EZRain sprinkler device support
  • Revamped console commands with auto-completion support
  • Improved discovery service
  • Improved thing status

For more details, see the updated documentation.

If switching from a previous release, you will need to reconfigure your Insteon environment with the new bridges, things and channels to take advantage of these enhancements. However, the new binding is fully backward compatible by supporting the legacy things. On the first start, existing device things connected to a network bridge will be migrated to the legacy-device thing type while still keeping the same ids to prevent any breakage. It is important to note that once the migration has occurred, downgrading to a legacy version will not be possible.

To install this beta version, you must first uninstall the official Insteon binding.
If you are deploying the jar file, you need to install the transport serial feature via the console:

feature:install openhab-transport-serial

Changelog

Version 20240920

  • Rename channels per naming convention (Breaking change)
  • Add remote device battery level support

Version 20240913

  • Add remote device button config support
  • Fix link db read write mode for i2 devices

Version 20240912

  • Fix remote device not polled when awake

Version 20240820

  • Add backward compatibility support

Version 20240531

  • Add ezrain sprinkler device support

Version 20240225

  • Improve link database management support

Version 20240224

  • Initial 4.x Release

Resources

  • Latest release kar file: here
  • Latest release jar file: here
  • Source code: here
  • Pull request: here

I’ve noticed running this on OH 4.1.2 that I get “Handler_Missing” errors after a reboot. Uninstalling the beta add-on and reinstalling it solves the problem until next reboot. I’m running on an rpi4 with an openhabian image. Any known issues, or ideas on what might be the cause?

I am not exactly sure but I noticed that the 3.x version is somehow showing in the add-on store causing two versions of the beta add-on to be displayed. It could be at startup the 3.x version is getting loaded instead of the 4.x one. This would prevent the addon from loading and cause the “Handler_Missing” error. Do you see any errors in your OH server logs?

In the meantime, I have opened an issue since the 3.x version should be ignored by OH 4.x servers.

Thanks for getting back to me. I do see three entries for Insteon when I search, but if I just scroll through the full list in the community marketplace add-on’s I only see the 4.1.0;5.0.0 Beta.

I have noticed that the regular insteon binding is showing as installed again after the uninstall/reinstall process. Is that normal? I definitely uninstalled it originally before I installed this addon.

I did some digging and I don’t see anyting in the openhab.log or events.log until I uninstalled and reinstalled. I do see something about a missing 4.2.0 Snapshot xml during boot. 4.2.0 Snapshot is the version listed for the regular insteon binding. Maybe its related?

java.lang.RuntimeException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:4.2.0-SNAPSHOT: [Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:4.2.0-SNAPSHOT] : mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/4.2.0-SNAPSHOT/xml/features
	at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:121) ~[?:?]
	at org.apache.karaf.features.internal.service.RepositoryImpl.<init>(RepositoryImpl.java:51) ~[?:?]
	at org.apache.karaf.features.internal.service.RepositoryCacheImpl.create(RepositoryCacheImpl.java:51) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeatureCache(FeaturesServiceImpl.java:611) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.ensureCacheLoaded(FeaturesServiceImpl.java:582) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.listRequiredRepositories(FeaturesServiceImpl.java:514) ~[?:?]
	at org.apache.karaf.deployer.features.FeatureDeploymentListener.bundleChanged(FeatureDeploymentListener.java:247) ~[?:?]
	at org.apache.karaf.deployer.features.FeatureDeploymentListener.init(FeatureDeploymentListener.java:90) ~[?:?]
	at org.apache.karaf.deployer.features.osgi.Activator$DeploymentFinishedListener.deploymentEvent(Activator.java:86) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.registerListener(FeaturesServiceImpl.java:296) ~[?:?]
	at org.apache.karaf.deployer.features.osgi.Activator.doStart(Activator.java:53) ~[?:?]
	at org.apache.karaf.util.tracker.BaseActivator.start(BaseActivator.java:92) ~[?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:818) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:1) ~[org.eclipse.osgi-3.18.0.jar:?]
	at java.security.AccessController.doPrivileged(AccessController.java:569) [?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:810) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:767) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1032) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:371) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.Module.doStart(Module.java:605) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.Module.start(Module.java:468) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1847) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1840) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1783) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1745) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1667) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.18.0.jar:?]
Caused by: java.io.IOException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:4.2.0-SNAPSHOT: [Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:4.2.0-SNAPSHOT]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.configureIOException(AetherBasedResolver.java:803) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:774) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
	at java.net.URL.openStream(URL.java:1161) ~[?:?]
	at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[?:?]
	... 29 more
	Suppressed: shaded.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:4.2.0-SNAPSHOT
		at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) ~[?:?]
		at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:235) ~[?:?]
		at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:212) ~[?:?]
		at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:272) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
		at java.net.URL.openStream(URL.java:1161) ~[?:?]
		at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[?:?]
		at org.apache.karaf.features.internal.service.RepositoryImpl.<init>(RepositoryImpl.java:51) ~[?:?]
		at org.apache.karaf.features.internal.service.RepositoryCacheImpl.create(RepositoryCacheImpl.java:51) ~[?:?]
		at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeatureCache(FeaturesServiceImpl.java:611) ~[?:?]
		at org.apache.karaf.features.internal.service.FeaturesServiceImpl.ensureCacheLoaded(FeaturesServiceImpl.java:582) ~[?:?]
		at org.apache.karaf.features.internal.service.FeaturesServiceImpl.listRequiredRepositories(FeaturesServiceImpl.java:514) ~[?:?]
		at org.apache.karaf.deployer.features.FeatureDeploymentListener.bundleChanged(FeatureDeploymentListener.java:247) ~[?:?]
		at org.apache.karaf.deployer.features.FeatureDeploymentListener.init(FeatureDeploymentListener.java:90) ~[?:?]
		at org.apache.karaf.deployer.features.osgi.Activator$DeploymentFinishedListener.deploymentEvent(Activator.java:86) ~[?:?]
		at org.apache.karaf.features.internal.service.FeaturesServiceImpl.registerListener(FeaturesServiceImpl.java:296) ~[?:?]
		at org.apache.karaf.deployer.features.osgi.Activator.doStart(Activator.java:53) ~[?:?]
		at org.apache.karaf.util.tracker.BaseActivator.start(BaseActivator.java:92) ~[?:?]
		at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:818) ~[org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:1) ~[org.eclipse.osgi-3.18.0.jar:?]
		at java.security.AccessController.doPrivileged(AccessController.java:569) [?:?]
		at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:810) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:767) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1032) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:371) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.container.Module.doStart(Module.java:605) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.container.Module.start(Module.java:468) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1847) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1840) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1783) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1745) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1667) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.18.0.jar:?]
		at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.18.0.jar:?]
Caused by: shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:4.2.0-SNAPSHOT
	at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:431) ~[?:?]
	at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:235) ~[?:?]
	at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:212) ~[?:?]
	at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:272) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:555) ~[?:?]
	at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
	at java.net.URL.openStream(URL.java:1161) ~[?:?]
	at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:114) ~[?:?]
	... 29 more

Is there another log I should check?

I’m realizing that’s I’m on OH 4.1.2, vs the installed regular insteon binding is showing as the latest release 4.2.0 Snapshot vs the stable 4.1.2. Is it possible there’s some incorrect dependency there? Either like your describing in the market place or in the beta itself? (if it is installing the original binding with it)

I noticed that too and is probably related to the issue I reported. As a matter of fact, if you try to uninstall the official version in that case, it won’t work but if you uninstall the beta version, both will show as uninstalled. Also the supported bundle version tag [4.1.0,5.0.0) shouldn’t appear in the MainUI marketplace. It is only used to filter a given marketplace add-on. This is most likely an indication that it is not currently being processed.

Something has changed with regards to how the marketplace addons are loaded in OH. Unfortunately, I don’t have enough knowledge to determine the root cause.

That’s just because the beta addon was compiled with the latest 4.2.0 code. However, it is fully backward compatible with OH 4.1.x.

Have you tried to load the kar file directly into your addons folder? There is a link to it in my original post above. Make sure to uninstall the marketplace version beforehand.

Ah, I did a fresh reboot and realized the uninstall log actually wasn’t triggered by me. It is automatically occuring durring boot. Seems like something odd is going on there. Once it finished booting it only showed the Beta installed, not the 4.2.0 Snapshot Insteon Add-on. After then removing and adding it again they were both back and worked.

I switched from using the broswer to installing via the .jar file, as you recommended and the problem is resolved. Insteon intializes just fine after a reboot. No more 4.2.0 xml feature error at boot either.

Thanks for the help!

1 Like

I am in the final stretch in getting these changes reviewed and included in the next OH release.

If anyone currently using the official Insteon binding, it would be much appreciate if you could test this beta version to confirm that the recently added backward compatibility support is working as intended.

Please do keep in mind that you should backup your existing environment before upgrading as legacy device things will be converted to the new device-legacy thing type in the background preventing the ability to go back to the current official binding without restoring your previous environment.

Hi, testing the Beta binding and getting stuck not been able to load/import all devices from the modem. I have about 60+ devices linked to the Hub and so far only 37 are been discovered (downloaded from the modem). I tried to manually create (via paperUI) one of the devices I am not seeing and it says:

Device not found in modem database.

I tried waiting to see if more data would be downloaded from the modem over time, but still shows only the 37 items. Restarted the container several times to see if it will fix, but after syncing with the hub, it always shows the same 37 devices.

All of my devices are manually linked on my oficial Binding THING definition with no issues.

Any ideas what might be causing the database download to not be complete?

Also, not that is problem per se, but notices that the THING parameter "modemDbRetryTimeoutSeconds’ is not included. I have seen in my posts that people don’t really use this, but in my set up (at least with the current binding) the database download hangs some times. During my original troubleshooting, setting this timeout was the only way I could eliminate the random hanging. Not sure if it is possible to add the parameter back (note: the Beta binding has not giving me any download hanging issues so far).

Setup:

  • Docker 24.0.5
  • Image openHAB 4.2.1.Clean install with no other bindings other than the Insteon Beta. Totally isolated from my main openHab instance and on a different port (Sandbox). Main instance is shutdown before starting the sandbox.
  • Insten Hub: Hub2. Fixed IP.
  • Insteon Devices: 2334-232 Keypad Dimmer 6-Button, 2475F FanLinc, 2477D SwitchLinc Dimmer, 2477D SwitchLinc Dimmer, 2477S SwitchLinc, 2634-222 On/Off Outdoor Module,

Can you confirm that you don’t have the official and beta binding installed at the same time? The official binding needs to be uninstall prior to installing the beta version. Using the console command below, the beta version would have an extra item related to the karaf wrapper.

bundle:list | grep -i insteon

Can you please confirm that your existing setup worked without any issue when you switched to the beta binding? There shouldn’t be any changes in the way the legacy binding is interacting with your devices.

Now related to the new implementation, are there any errors in your OH logs? I can’t see how partial modem database can happen unless there is a third party application interacting with your modem at the same time. Thus my earlier question about multiple binding versions running at the same time. Why type of modem are you using?

All data downloaded including the modem database is cached now. You would need to run the below console command to force a modem database reload:

insteon modem reloadDatabase

Before doing that, I would be interested to see the current content:

insteon modem listDatabase --records

That might have been in the binding version for OH 1. I don’t see this parameter in the current official binding. Anyway, there is no change in the way the beta version will retry downloading the modem database. Basically, it will restart the entire process if it didn’t receive a message from the modem after 30 seconds. The only way the binding would consider the download process complete is when it received a message from the modem that indicates all link records have been sent.

I have added a migration guide to the documentation. I would recommend that you use this guide to migrate your existing Insteon things to the new beta version.

Can you please confirm that your existing setup worked without any issue when you switched to the beta binding? There shouldn’t be any changes in the way the legacy binding is interacting with your devices.

Interesting… It did not cross my mind to check on this as I did a clean container install with no carry over, and then installed the Beta from the marketplace.

This is what the command shows

openhab> bundle:list | grep -i insteon                                                                                                                                                                                                                           
266 │ Active │  80 │ 4.3.0.202409202335    │ openHAB Add-ons :: Bundles :: Insteon Binding
269 │ Active │  80 │ 0                     │ wrap_file__openhab_userdata_tmp_kar_org.openhab.binding.insteon-4.3.0-SNAPSHOT_org_lastnpe_eea_eea-all_2.4.0_eea-all-2.4.0.jar

And on the UI it has:

Does that look the way it is supposed to?

Can you please confirm that your existing setup worked without any issue when you switched to the beta binding? There shouldn’t be any changes in the way the legacy binding is interacting with your devices.

I tried to start small and just wanted to add a couple of devices at a time to test out, then work from there until I could do a full migration. So no, I did not load my current set up into the new binding.

This is the result of the ListDatabase command:

openhab> insteon modem listDatabase --records                                                                                                                                                                                                                    
The all-link database for modem 4C.05.4B contains 70 records:
4C.3A.D7 RESP group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.3A.D7 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.3A.D7 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4A.F3.43 RESP group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4A.F3.43 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4A.F1.2E RESP group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4A.F1.2E RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.50.89 RESP group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.50.89 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.2C.59 CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.2C.59 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.41.53 RESP group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.41.53 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.E1.00 RESP group: 0x00 data1: 0x01 data2: 0x2A data3: 0x45
4C.E1.00 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4A.3A.E6 CTRL group: 0x00 data1: 0x01 data2: 0x2D data3: 0x44
4A.3A.E6 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
48.23.BE CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
48.23.BE RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
48.0F.CF CTRL group: 0x01 data1: 0x01 data2: 0x20 data3: 0x45
48.0F.CF RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
48.12.00 RESP group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
48.12.00 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4A.37.75 CTRL group: 0x00 data1: 0x01 data2: 0x2D data3: 0x44
4A.37.75 CTRL group: 0x01 data1: 0x01 data2: 0x2D data3: 0x44
4A.37.75 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
48.20.FC CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
48.20.FC RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.3B.45 CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.3B.45 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.F4.D4 RESP group: 0x00 data1: 0x01 data2: 0x2A data3: 0x45
4C.F4.D4 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
49.B9.EA CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
49.B9.EA RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.F1.6A RESP group: 0x00 data1: 0x01 data2: 0x2A data3: 0x45
4C.40.14 CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.40.14 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.24.B4 CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.24.B4 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.3C.09 CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.3C.09 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.3A.FA CTRL group: 0x00 data1: 0x01 data2: 0x20 data3: 0x45
4C.3A.FA RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.F1.6A RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
53.38.3E RESP group: 0x00 data1: 0x01 data2: 0x2E data3: 0x45
51.CE.77 RESP group: 0x00 data1: 0x01 data2: 0x2E data3: 0x45
49.CD.5C RESP group: 0x00 data1: 0x01 data2: 0x2A data3: 0x45
49.CD.5C RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
49.C6.07 RESP group: 0x00 data1: 0x01 data2: 0x2A data3: 0x45
49.C6.07 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
49.42.E7 CTRL group: 0x00 data1: 0x01 data2: 0x37 data3: 0x48
49.42.E7 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
49.40.68 CTRL group: 0x00 data1: 0x01 data2: 0x37 data3: 0x48
49.40.68 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
49.3E.F3 RESP group: 0x00 data1: 0x01 data2: 0x37 data3: 0x48
49.3E.F3 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
49.19.0D RESP group: 0x00 data1: 0x01 data2: 0x38 data3: 0x43
49.19.0D RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4B.59.74 CTRL group: 0x76 data1: 0x00 data2: 0x00 data3: 0x76
49.CF.D4 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
56.AA.C9 RESP group: 0x00 data1: 0x01 data2: 0x2C data3: 0x44
4C.A3.A1 RESP group: 0x00 data1: 0x01 data2: 0x37 data3: 0x48
4C.A3.A1 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
4C.A6.8F CTRL group: 0x00 data1: 0x01 data2: 0x37 data3: 0x48
4C.A6.8F CTRL group: 0x01 data1: 0x01 data2: 0x37 data3: 0x48
4C.A6.8F RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
2B.30.DE RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
45.DD.81 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
56.AA.C9 CTRL group: 0x01 data1: 0x01 data2: 0x2C data3: 0x44
4C.2C.59 CTRL group: 0x00 data1: 0x01 data2: 0x1A data3: 0x41

The specific device I am trying to manually add is: 50.57.9A, which is not showing on the list.

There was nothing on the logs that would indicate there were missing records/devices during the download. Below is the log from the time the container is started, it complains about device 50.57.9A, and then at 15:51:32 I ran the modem reload database command… which after a few minutes it got more records (discovery inbox now shows 100 items, which includes the scenes that I have)… after some more time, the device in question showed up YAY!!! . I trimmed the log, as it got really big after it added the additional records, but you can see on the last line that it came online.

openhab> log:tail
14:17:25.723 [INFO ] [org.openhab.core.Activator ] - **Starting openHAB 4.2.1 (Release Build)**
14:17:26.231 [INFO ] [b.core.internal.i18n.I18nProviderImpl] - **Locale set to 'en_US'.**
14:17:39.922 [INFO ] [b.core.model.lsp.internal.ModelServer] - **Started Language Server Protocol (LSP) service on port 5007**
14:17:41.537 [INFO ] [re.automation.internal.RuleEngineImpl] - **Rule engine started.**
14:18:36.622 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:hub2:77815006cc' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)**
14:18:36.623 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:device:77815006cc:3ea2a691d0' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)**
14:18:39.648 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:hub2:77815006cc' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING**
14:18:39.661 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:hub2:77815006cc' changed from INITIALIZING to UNKNOWN (CONFIGURATION_PENDING): Initializing modem.**
14:18:39.662 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:device:77815006cc:3ea2a691d0' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING**
14:18:39.666 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:device:77815006cc:3ea2a691d0' changed from INITIALIZING to UNKNOWN (CONFIGURATION_PENDING): Waiting for modem database.**
14:18:45.743 [WARN ] [insteon.internal.device.InsteonDevice] - **device 50.57.9A not found in the modem database. Did you forget to link?**
14:18:45.744 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:device:77815006cc:3ea2a691d0' changed from UNKNOWN (CONFIGURATION_PENDING): Waiting for modem database. to OFFLINE (CONFIGURATION_ERROR): Device not found in modem database.**
14:18:45.747 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:hub2:77815006cc' changed from UNKNOWN (CONFIGURATION_PENDING): Initializing modem. to ONLINE**
15:51:32.129 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:hub2:77815006cc' changed from ONLINE to OFFLINE (CONFIGURATION_PENDING): Resetting bridge.**
15:51:32.129 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - **Thing 'insteon:hub2:77815006cc' changed from OFFLINE (CONFIGURATION_PENDING): Resetting bridge. to UNKNOWN (CONFIGURATION_PENDING): Initializing modem.**
.
.
.
15:56:39.719 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'insteon:device:77815006cc:3ea2a691d0' changed from UNKNOWN (CONFIGURATION_PENDING): Waiting for link database. to OFFLINE (CONFIGURATION_ERROR): Unable to determine device.
15:56:39.723 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'insteon:device:77815006cc:3ea2a691d0' changed from OFFLINE (CONFIGURATION_ERROR): Unable to determine device. to UNKNOWN (CONFIGURATION_PENDING): Waiting for link database.
16:01:56.197 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'insteon:device:77815006cc:3ea2a691d0' changed from UNKNOWN (CONFIGURATION_PENDING): Waiting for link database. to ONLINE

That might have been in the binding version for OH 1. I don’t see this parameter in the current official binding. Anyway, there is no change in the way the beta version will retry downloading the modem database. Basically, it will restart the entire process if it didn’t receive a message from the modem after 30 seconds. The only way the binding would consider the download process complete is when it received a message from the modem that indicates all link records have been sent.

Thanks! as I said, I did not have an issue connecting to the modem, so hopefully it stays that way over time :slight_smile:

I will play around with some devices here and there to test things out, then work my up and eventual migrate my current set up based on your guide.

Why type of modem are you using?

I have the HUB2.

  • Bin Version: Hug2-V04-20140904
  • PLM Version: A5
  • Hub FW: 1019

Will let you know if I encounter any other issues.

Thanks!

1 Like

It does. The fact that both the official and beta versions are displayed as installed in MainUI, when only the latter is in reality, is a known issue. The only way to confirm it at this point is to run the console command.

Assuming you are running your main OH server in a container, you could copy the data volume and bind it to your test container. That way you could test the migration as well including the backward compatibility.

Also, since you are running a separate instance, is your main OH server up and the Insteon binding on that instance up as well? If so, you should disable the network bridge to disconnect it from your modem. Having multiple applications connected to the same modem produce unreliable results including the partial modem database you have experienced.

Glad to hear the database was downloaded properly this time. Related to the scene discovery, this is why it’s disabled by default :smile:

As far as the device you manually added, I can see its link database was downloaded. You can check its content to confirm if it’s correct:

insteon device listDatabase 50.57.9A

@funky28 were you able to test the backward compatibility? If so, can you confirm that your current setup ran without any issues?

Hi, sorry I have not posted my results, classic case of work life getting in the way of hobby life :wink:

I have successfully manually replicated my config (via UI and THING file) to make sure it all works ok and have had not issues whatsoever. Next on my todo was to do the automatic import… just haven’t had the time.

I do have a mount volume where I keep the following:
/openhab/conf
/openhab/userdata
/openhab/addons

So, for the automatic import to work will it suffice if I just copy the THING and ITEM files that I have … or should I just mount all three volumes (of course, a copy of them to not mess up with my formal set up)

Depends on how you configured your environment. userdata is required. If you configured your things and items via textual configuration files, conf is needed. As far as addons, unless you manually added this beta version into that directory, it is not needed.

However, ideally, you should aim at replicating your existing environment if you don’t want to use this beta version in your main environment. So I would recommend having all three volumes for your test.

It took me a while, but I finally was able to use the migration feature to import my existing config (under a new container). Initially it threw a bunch of errors and warnings because I didn’t quite notice that some channel name had changed (fanlinc, outlet, keypad) and even item type (From Number to String on the fanlinc)… but once I updated those, everything was recognized without issues.

I would say I felt the initial DB download and initialization of the things took quite a long time… not sure if this is normal. But once they were online, and after some restarts the initialization was very quick.

I also got random disconnection warnings from the hub/IP. But no functionality was lost. I think I might have that issue even with the current binding/hub as some times I get disconnections… but I think the beta binding just have better logging output and easier readability.

I have not gotten to play the scenes, it turns out I have quite a few and I got overwhelmed… specially since I have no way of knowing what is what, which means I have to test them one by one.

Thanks for the update.

Prior to the migration, could you confirm that your existing environment was working without any issue? As I mentioned previously, part of the test was to confirm that the backward compatibility is working as intended. This is an important step as users upgrading to the upcoming OH 4.3 may not migrate to the new implementation immediately.

This is expected as the modem and all devices databases are downloaded the first time the binding is initialized. All that information is then cached for subsequent restarts.

You can use the following console command to determine which device is controlled by a given scene.

insteon scene listDetails <thingId>

The changes have been merged and are now available in the latest OH 4.3 snapshot build as the next official Insteon binding.

If you are running the Insteon binding on the snapshot version, it would be much appreciated if you could report any issue with your current Insteon setup.

Prior to the migration, could you confirm that your existing environment was working without any issue? As I mentioned previously, part of the test was to confirm that the backward compatibility is working as intended. This is an important step as users upgrading to the upcoming OH 4.3 may not migrate to the new implementation immediately.

With the previous binding I do have connection issues on a low level (not enough to cause a problem, but have not been able to pin point the cause). When I migrated to the new binding, I left it as it was for a day or so and I would say it behaved the same, I did not see any issues and it worked as intended. No concerns there.

This is expected as the modem and all devices databases are downloaded the first time the binding is initialized. All that information is then cached for subsequent restarts.

I figured, and agree… after the initial DB download, the initialization was a breeze after forced restarts.

insteon scene listDetails

Game changer!!! will give this a try and hope to map all the scenes that I have effortlessly

Thanks for taking the time to updgrade the Binding. I think it is a step in the right direction and nice to see it is getting some love :slight_smile:

1 Like

These changes are now available in the OH 4.3 release.