New Insteon 2.5+ binding

@tommyc210 thank you for your reply.

I still must not have it right since it didn’t work. I added this to my thing file

Thing insteon:device:476856 "Insteon - Living Room Keypad" (insteon:network:8d75e6ef) [address="47.68.56", productKey="F00.00.15"] {
  Channels:
    Type switch : keypadButtonA "Fan High"   [ group="0x05" ]
    Type switch : keypadButtonB "Fan Medium" [ group="0x06" ]
    Type switch : keypadButtonC "Fan Low"    [ group="0x07" ]
    Type switch : keypadButtonD "Fan Off"    [ group="0x08" ]
}

My Items file did not change.

Do I need to put the bridge in the thing file also? Do I need to remove the device from paper ui?

Ok, after some more testing I found that I need to have the bridge statement in the thing file and I do need to remove the thing from the paper ui. after doing that, it all works now.

1 Like

Does anyone have a leak sensor working with openhab/insteon binding?

I had trouble getting the linking correct before, and curious if anyone else has had success.

thanks,
Craig

I have several working well. My things are defined in PaperUI and .items look like this:

Contact  dwLeak     "Dishwasher Leak Sensor [MAP(leak.map):%s]"	         <water>		(Leak_Chart, gSensors)	{channel="insteon:device:AABBCC:contact"}
DateTime dwLeakLHF  "DishwasherLeakLHF [%1$tm/%1$td %1$tl:%1$tM %1$tp]"  <calendar>								{channel="insteon:device:AABBCC:lastHeardFrom"}
1 Like

@tommycw10 did you set up linking within insteon-terminal?

I had issues with the fact that the sensor has separate wet and dry contacts. If I triggered a wet condition, the sensor would not reset appropriately. I would have to manually hit the reset button on the device.

If you trigger a wet condition how long does it take to switch back to dry if you take the sensor from the wet?

thanks

@tommycw10 I figured out what is going on. the leak sensors changed sometime in the past and I was expecting it to automatically switch from wet to dry after some time. but apparently I have to go and hit the set button for an update.

Finally updated my OH2 and using the new 2.5+ binding. Can someone confirm that in the bridge connection string, we HAVE to use an IP address and not a hostname?

So
Bridge insteon:network:home [port="/hub2/xxx:xxx@192.168.1.99:25105,poll_time=1000"] is OK
but
Bridge insteon:network:home port="/hub2/xxx:xxx@insteonhub:25105,poll_time=1000"]
will fail.

I thought I would use the second form in my config file but when I do, I get errors in the log file about the OH2 not being able to download the modem db. When I go back to the first form, all is good. And yes, I can ping insteonhub from the command line and I get the correct response back.

You shouldn’t have to, are you getting the same ip address when you ping it? Can you turn on debug logging and share the results? Also what version of OH and Java are you using?

I am running OH2 2.5.6-2 (Release Build) and java -version shows:
openjdk version “1.8.0_222”
OpenJDK Runtime Environment (Zulu8.40.0.178-CA-linux_aarch32hf) (build 1.8.0_222-b178)
OpenJDK Client VM (Zulu8.40.0.178-CA-linux_aarch32hf) (build 25.222-b178, mixed mode, Evaluation)

When I ping insteonhub I get back 192.168.1.99 same thing for insteonhub.localdomain so the address is correctly resolved. What happened is that I changed the IP address for the name, save the config file, restarted OH2 and got errors about the binding not able to download the modem DB. If I undid my change and go back to the IP, the problem goes away.

The broader issue here is for OH2 to be able to deal with the hub getting a change of IP address. All of the above was as a result of me moving from my router DHCP server to the server in the new Pi-Hole 5.0. The Pi-Hole gave the hub a new address which of course did not match what was hard coded in the config file, leading me trying to use the host name instead. What happens if the hub gets a new IP address after OH2 is started?

This is probably more of an OS question, the insteon binding connects to the hub using http://host:port/ which in your case is http://insteonhub:25105/ or http://192.168.1.99:25105/. The binding uses URL (Java Platform SE 8 ) to open the connection to the hub.

The code for /hub2/ is at: openhab-addons/bundles/org.openhab.binding.insteon/src/main/java/org/openhab/binding/insteon/internal/driver/hub/HubIOStream.java at 2.5.x · openhab/openhab-addons · GitHub

Thanks. Will continue to investigate.

Hi folks. I just upgraded from InsteonPLM to Insteon, having some issues that other people have noted. My binding stops working after a day or so, and I think it may be related to when it sends a message which fails to get acknowledged by a device (either it’s unplugged or gets interrupted by “signal noise”, since I have devices in my garage on the same outlet as a refrigerator). Sometimes it will still work, but it can take like 30 seconds to activate a device.

And just to get clarification, if I’ve got my bridge and devices defined in a .things file and then set up in my .items files, should I or should I not delete them out of Paper UI?

The items will show up in the paper UI and should be left as is. What version of the binding are you using? Do you see any sort of errors in the openhab.log file? I’ve ran mine for weeks at a time with no issues.

I’m using version 2.5.9. No errors show up in the console, usually I’ll just see something like

2020-10-28 07:53:59.024 [ome.event.ItemCommandEvent] - Item 'OU_Backyard_SideYardLight' received command OFF
2020-10-28 07:53:59.026 [nt.ItemStatePredictedEvent] - OU_Backyard_SideYardLight predicted to become OFF
2020-10-28 07:53:59.035 [vent.ItemStateChangedEvent] - OU_Backyard_SideYardLight changed from ON to OFF

… in the case where it works, and if it doesn’t, I simply won’t see the first line with the “received command”.

The main issue I have is with my Motion Sensor II, its state gets reported to Openhab infrequently at best. I use a newer Insteon Hub, and I can see the motion events in the Insteon companion app (which I assume means it’s been linked correctly?), but Openhab only occasionally receives those updates. I’m not sure how to diagnose that though.

Check out the Insteon known limitations and issues, specifically:

  • Using the Insteon Hub 2014 in conjunction with other applications (such as the InsteonApp) is not supported. Concretely, openHAB will not learn when a switch is flipped via the Insteon App until the next poll, which could take minutes.

The insteon app could be consuming the events that are sent by the sensor and other devices. Motion Sensors do not support polling, so these events will be completely missed.

Ah, that could explain a lot. Could you clarify whether this means I simply shouldn’t have the InsteonApp open and running on my phone or if I should log out/uninstall completely?

I use a PLM so I can’t give you an answer. Maybe somebody else who uses a hub can give you a answer. You could try first keeping the app closed, and if that doesn’t help, then log out and uninstall.

@Dennis_Pelham - just to clarify what Rob said:

If you defined your bridge and devices in PaperUI BEFORE you put them into your .things and .items files then you will have them defined 2x (once in PaperUI and once in files) and you should delete the ones you defined in PaperUI.

If you defined your bridge and devices in your .things and .items files only, those definitions will then show up in PaperUI and there is no need to delete them. (In fact I believe if you delete them, they will just come back since they are defined in the .things and .items files anyway).

I didn’t add the bridge or devices in Paper UI, everything was configured manually in the files, so I assume then all the Insteon devices that are now showing up in my Inbox in Paper UI are redundant duplicates of the ones already displayed in the Things section and should be Ignored?

The ones in the inbox can be deleted, currently the binding doesn’t clean up the inbox if they are manually defined.