New Insteon 2.5+ binding

ranielsen · January 13, 2020, 3:11pm

I’m in the process of porting over the 1.x InsteonPLM binding to a new 2.5+ Insteon binding. My goal is to use as much of the InsteonPLM code as possible, with little or no modification. The new binding can send updates to channels and receive commands from channels. There’s more work to do, but wanted to share the progress I’ve made so far. I only have a plm, and will need eventually work with somebody to test with Insteon hubs, along with other supported Insteon devices that I don’t own.

To show how the new binding works. Here’s an 1.x InsteonPLM example of an items file with two Insteon devices that are using the feature dimmer:

Dimmer dining "Dining Room Lights" {insteonplm="23.9F.82:F00.00.11#dimmer}
Dimmer living "Living Room Lights" {insteonplm="23.9F.F0:F00.00.11#dimmer}

The new Insteon binding uses a bridge to define the Insteon PLM or hub. Things are used to describe the Insteon devices. Using the above example, here’s how the Insteon devices it’s described in the things file:

Bridge insteon:plm:2413U [port="/dev/ttyUSB0"] {
    Thing device 239F82 [address="23.9F.82", productKey="F00.00.11"]
    Thing device 239FF0 [address="23.9F.F0", productKey="F00.00.11"]
}

Features for a Insteon device are represented as channels. Using the above example, here’s the updated items file:

Dimmer dining "Dining Room Lights" {channel="insteon:device:2413U:239F82:dimmer"}
Dimmer living "Living Room Lights" {channel="insteon:device:2413U:239FF0:dimmer"}

Currently the binding can send updates for channels and receive commands from a plm. Here’s an example from events.log:

2020-01-12 20:57:46.833 [vent.ItemStateChangedEvent] - dining changed from NULL to 100
2020-01-12 20:58:06.340 [vent.ItemStateChangedEvent] - living changed from NULL to 100
2020-01-12 20:58:21.953 [ome.event.ItemCommandEvent] - Item 'living' received command 0
2020-01-12 20:58:22.083 [nt.ItemStatePredictedEvent] - living predicted to become 0
2020-01-12 20:58:22.116 [vent.ItemStateChangedEvent] - living changed from 100 to 0
2020-01-12 20:58:28.765 [ome.event.ItemCommandEvent] - Item 'living' received command 100
2020-01-12 20:58:28.782 [nt.ItemStatePredictedEvent] - living predicted to become 100
2020-01-12 20:58:28.817 [vent.ItemStateChangedEvent] - living changed from 0 to 100
2020-01-12 20:58:33.453 [ome.event.ItemCommandEvent] - Item 'dining' received command 0
2020-01-12 20:58:33.483 [nt.ItemStatePredictedEvent] - dining predicted to become 0
2020-01-12 20:58:33.528 [vent.ItemStateChangedEvent] - dining changed from 100 to 0
2020-01-12 20:58:36.061 [ome.event.ItemCommandEvent] - Item 'dining' received command 100
2020-01-12 20:58:36.088 [nt.ItemStatePredictedEvent] - dining predicted to become 100
2020-01-12 20:58:36.182 [vent.ItemStateChangedEvent] - dining changed from 0 to 100
2020-01-12 21:13:36.470 [ome.event.ItemCommandEvent] - Item 'dining' received command 46
2020-01-12 21:13:36.582 [nt.ItemStatePredictedEvent] - dining predicted to become 46
2020-01-12 21:13:36.619 [vent.ItemStateChangedEvent] - dining changed from 100 to 46

And here’s an example of whats logged to openhab.log:

2020-01-12 20:57:36.434 [INFO ] [nsteon.internal.InsteonBridgeHandler] - device 23.9F.82 found in the modem database and the modem controls groups [0xFE] and responds to groups [0x01].
2020-01-12 20:57:36.455 [INFO ] [nsteon.internal.InsteonBridgeHandler] - device 23.9F.F0 found in the modem database and the modem controls groups [0xFE] and responds to groups [0x01].
2020-01-12 20:57:46.659 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9F.82 to level 100
2020-01-12 20:58:06.324 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9F.F0 to level 100
2020-01-12 20:58:22.010 [INFO ] [nsteon.internal.InsteonDeviceHandler] - Channel dimmer for device insteon:device:2413U:239FF0 triggered with command 0
2020-01-12 20:58:22.037 [INFO ] [steon.internal.device.CommandHandler] - PercentHandler: sent msg to set 23.9F.F0 to zero by switching off
2020-01-12 20:58:22.042 [INFO ] [nsteon.internal.InsteonBridgeHandler] - found binding config for channel insteon:device:2413U:239FF0:dimmer
2020-01-12 20:58:22.381 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9F.F0 to level 0
2020-01-12 20:58:28.815 [INFO ] [nsteon.internal.InsteonDeviceHandler] - Channel dimmer for device insteon:device:2413U:239FF0 triggered with command 100
2020-01-12 20:58:28.823 [INFO ] [steon.internal.device.CommandHandler] - PercentHandler: sent msg to set 23.9F.F0 to 255
2020-01-12 20:58:28.827 [INFO ] [nsteon.internal.InsteonBridgeHandler] - found binding config for channel insteon:device:2413U:239FF0:dimmer
2020-01-12 20:58:29.161 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9F.F0 to level 100
2020-01-12 20:58:33.488 [INFO ] [nsteon.internal.InsteonDeviceHandler] - Channel dimmer for device insteon:device:2413U:239F82 triggered with command 0
2020-01-12 20:58:33.499 [INFO ] [steon.internal.device.CommandHandler] - PercentHandler: sent msg to set 23.9F.82 to zero by switching off
2020-01-12 20:58:33.502 [INFO ] [nsteon.internal.InsteonBridgeHandler] - found binding config for channel insteon:device:2413U:239F82:dimmer
2020-01-12 20:58:33.827 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9F.82 to level 0
2020-01-12 20:58:36.118 [INFO ] [nsteon.internal.InsteonDeviceHandler] - Channel dimmer for device insteon:device:2413U:239F82 triggered with command 100
2020-01-12 20:58:36.126 [INFO ] [steon.internal.device.CommandHandler] - PercentHandler: sent msg to set 23.9F.82 to 255
2020-01-12 20:58:36.144 [INFO ] [nsteon.internal.InsteonBridgeHandler] - found binding config for channel insteon:device:2413U:239F82:dimmer
2020-01-12 20:58:36.454 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9F.82 to level 100
2020-01-12 21:02:46.616 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9F.82 to level 100
2020-01-12 21:03:06.299 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9F.F0 to level 100
2020-01-12 21:05:04.600 [INFO ] [steon.internal.device.MessageHandler] - LightOnDimmerHandler: device 23.9E.9D was turned on REGULAR. Sending poll request to get actual level
2020-01-12 21:05:05.948 [INFO ] [steon.internal.device.MessageHandler] - DimmerRequestReplyHandler: set device 23.9E.9D to level 100
2020-01-12 21:06:12.634 [INFO ] [steon.internal.device.MessageHandler] - LightOffDimmerHandler: device 23.9E.9D was turned off REGULAR.
2020-01-12 21:07:29.396 [INFO ] [nsteon.internal.InsteonBridgeHandler] - devices:  60 configured,  60 polling, msgs received:   158

More to come later…

Thedannymullen · January 13, 2020, 9:01pm

Awesome!!

tommycw10 · January 14, 2020, 7:44am

Exciting stuff! I suspect you’ll add lots of different channels to these for things like faston/off LED brightness, beep, local on-level, local RR, etc, etc?

Also, Not sure if you’ve ever used any Insteon Hidden Door Sensors before, but the code in the 1.x InsteonPLM binding to handle them is basically broken, so i fyou are reusing code, be on the lookout for this. The basic functionality is there. You can open a door and catch that, you can close a door and catch that, just don’t do either too quickly after another or you’ll miss the state change. I found that opening my door, talking inside and closing it, frequently results in the door thinking it was still open forever.

I dug through the code and I guess I’m not smart enough to figure out the issue but I think it is related to how the binding is trying to filter out duplicates. Since it recently saw an open it thinks the close is a duplicate command (or something like this). After lots of trial, I ditched my Insteon hidden door sensors and installed Z-Wave hidden door sensors (which conveniently fit into the same hole in my door frame) and they work perfectly. Since mine are sitting around, I’d be willing to send you one to borrow if you need hardware to test. I also have a smoke bridge I can send you if you want to test that as well.

ranielsen · January 14, 2020, 1:55pm

At this point, all I plan on doing is porting over existing code with minimal modification.

ranielsen · January 15, 2020, 11:38pm

I’ve been running the new binding for a few days now. I should have something ready this weekend for people to help test.

If you are interested in helping, please message me with your contact info.

ranielsen · January 18, 2020, 10:02pm

For the most part, I have the binding done and is ready for testing. I still need to clean up warnings from the code analysis tools. If anybody is interested in helping out please PM me.

ranielsen · January 26, 2020, 4:43pm

The binding is pretty much complete, including device discovery. Still looking for more volunteers to help test it. If you are interested, please message me.

mladams922 · January 28, 2020, 1:16pm

If you’d like someone to help test let me know. I’d love to help. I have a plm, some fanlinc modules, keypad dimmers, standard dimmers, standard switches, dimmer outlets, and switch outlets. If yo share source code I can help add channels to the devices as well.

jeshab · January 28, 2020, 3:16pm

@ranielsen thanks for making this happen! Any chance you could make your source code available?

zephod · January 31, 2020, 12:23pm

Well done. you beat me to it. I just got the IDE set up 2 weeks ago.
I only have one device, a sprinkler controller that I don’t think was supported in the 1.x branch. I had to write a Python module in insteon-terminal to get it to work. I’d be happy to help test.

Thedannymullen · January 31, 2020, 12:30pm

@zephod check your messages.
Welcome aboard!!

EdwardV · February 1, 2020, 7:18am

Great!! One question . . I have an ‘old’ 2242-422 Hub still doing his job. Obviously integrated into OpenHab 2.5.1 (sometimes with mixed feelings). Will this version also be supported in your binding? If so I’m happy to do testing and troubleshooting of your binding

ranielsen · February 1, 2020, 12:25pm

Yes, it will.

zephod · February 4, 2020, 11:03pm

So I’ve grabbed the binding and dropped it in the addons directory. I have a 2245-222 hub but the configuration seems to want a serial port and not a IP address. I assume I’m missing something.

lsurhett · February 7, 2020, 5:27pm

Edward,

I have the 2245-422 hub. I used the same line that I used to have in the Insteon.cfg but changed “port_0=” to “port=”. Also, did not use the insteon.cfg anymore but added a bridge line in the things file.

See if that helps.

Rhett

zephod · February 8, 2020, 7:45pm

I tried with port= and port_0= in the insteon.cfg file and got the same response, below. I tried a wrong UserName and got a different response so I’m fairly sure that the credentials are correct.

14:36:26.320 [INFO ] [inding.insteonplm.InsteonPLMActivator] - Insteon PLM binding has been started.
14:36:26.412 [INFO ] [ng.insteonplm.InsteonPLMActiveBinding] - dead device timeout set to 3000s
14:36:26.417 [INFO ] [ng.insteonplm.InsteonPLMActiveBinding] - config: port_0 -> /hub2/MYUSERNAME:MYPASSWORD@MYIPADDRESS:25105,poll_time=1000
14:36:26.431 [INFO ] [ab.core.service.AbstractActiveService] - InsteonPLM has been started
14:36:26.441 [INFO ] [ng.insteonplm.InsteonPLMActiveBinding] - config: port -> /hub2/MYUSERNAME:MYPASSWORD@MYIPADDRESS:25105,poll_time=1000
14:36:26.456 [INFO ] [ng.insteonplm.InsteonPLMActiveBinding] - config: service.pid -> org.openhab.insteonplm
14:36:26.462 [INFO ] [ng.insteonplm.InsteonPLMActiveBinding] - devices: 0 configured, 0 polling, msgs received: 0
…
14:36:30.801 [INFO ] [ng.insteonplm.InsteonPLMActiveBinding] - modem database has 3 entries!
14:36:30.803 [INFO ] [ng.insteonplm.InsteonPLMActiveBinding] - device FF.FF.FF found in the modem database, but is not configured as an item and the modem controls groups [0x01].
14:36:30.804 [INFO ] [ng.insteonplm.InsteonPLMActiveBinding] - device 88.88.88 found in the modem database, but is not configured as an item and the modem controls groups [0x01].
14:36:30.981 [WARN ] [nsteon.internal.driver.SerialIOStream] - got no such port for MYIPADDRESS:25105
14:36:30.982 [WARN ] [nsteon.internal.driver.SerialIOStream] - got no such port for MYIPADDRESS:25105
14:36:30.982 [WARN ] [nding.insteon.internal.InsteonBinding] - initialization complete, but found no ports!
14:36:30.982 [WARN ] [nding.insteon.internal.InsteonBinding] - initialization complete, but found no ports!
14:36:30.983 [WARN ] [nternal.handler.InsteonNetworkHandler] - Initialization failed, unable to start the Insteon bridge with the port ‘MYIPADDRESS:25105’.
14:36:30.983 [WARN ] [nternal.handler.InsteonNetworkHandler] - Initialization failed, unable to start the Insteon bridge with the port ‘MYIPADDRESS:25105’.

ranielsen · February 9, 2020, 1:54pm

It looks like you still have the insteon plm binding running and it is starting up before the insteon binding. You’ll need to either uninstall insteonplm, or put in some invalid config info for it. For example"

port_0=“foo”

For the new binding it uses port instead of port_0 and should be the same string you used before with insteonplm. There is no need to use a thngs file unless you want to, the Insteon bridge will show up in the paper ui inbox, along with all your devices once the bridge is configured correctly.

zephod · February 9, 2020, 4:01pm

If I uninstall the insteonplm1 binding I get an unresolved module error:

10:06:34.630 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.insteon-2.5.2-20200131.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.insteon [228]
Unresolved requirement: Import-Package: org.apache.commons.codec.binary; version="[1.4.0,2.0.0)"

at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

So I reinstalled the insteonplm binding and set the port_0 to junk in the insteon.cfg file, deleted my insteon.thing and insteon.item file then I get this:

10:54:22.240 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘insteon:device:e0582850’ changed from UNINITIALIZED to UNINITIALIZED (BRIDGE_UNINITIALIZED)
10:54:22.274 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘insteon:network:local’ changed from UNINITIALIZED to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING)

which is logged before insteonplm reports about the port which seems OK and port_0 which generates an exception as you would expect. There is no mention of the Bridge initializing.

Steve

notanatheist · February 19, 2020, 9:01pm

Can test soon. Will I be able to add new devices without having to unload the binding and putting the PLM in linking mode? I already have 18 devices in my *.items file. Guessing I’ll need to reconfigure them all? Got a couple more to add. Bit of an Insteon fanboy. Zwave has not impressed me and Wifi can suck it.

ranielsen · February 19, 2020, 9:03pm

No you won’t need to link the devices again. Just reconfigure to use channels and things. I’ll add you to the private testing group.