Insteon PLM recognized but not available as a Binding

I’m at a place in setting up Openhab2 where my Insteon modem is being recognized but is unavailable as a Binding when going to add a new device, leaving me unable to proceed. I started by installing the insteonplm Binding via the Paper UI. Unlike the other bindings, the progress spinner on this never stopped spinning, but the logfile indicated it was installed and the config file was right where it was supposed to be.

I then modified it to look at /dev/ttyUSB0 for the PLM and restarted openhab. I then got the following log output:

2016-08-25 17:20:31.768 [INFO ] [g.insteonplm.InsteonPLMActiveBinding] - config: port_0 -> /dev/ttyUSB0
2016-08-25 17:20:31.784 [INFO ] [b.core.service.AbstractActiveService] - InsteonPLM has been started
2016-08-25 17:20:31.809 [INFO ] [g.insteonplm.InsteonPLMActiveBinding] - devices:   0 configured,   0 polling, msgs received:     0
2016-08-25 17:20:31.838 [INFO ] [g.insteonplm.InsteonPLMActiveBinding] - config: service.pid -> org.openhab.insteonplm
2016-08-25 17:20:32.201 [INFO ] [onplm.internal.driver.SerialIOStream] - successfully opened port /dev/ttyUSB0
2016-08-25 17:20:32.232 [INFO ] [assic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app
2016-08-25 17:20:32.293 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2016-08-25 17:20:33.118 [INFO ] [g.insteonplm.InsteonPLMActiveBinding] - modem database has 11 entries!
...

But when I went to add devices, I got the following screen:

So, it’s clear to me the PLM binding is working on some basic level, since it’s seeing my Insteon network’s device ID’s in the logfile. But the fact that its installation via the Paper UI didn’t complete is making me wonder if somehow its installation isn’t properly complete. I’ve had no trouble adding Hue, Pioneer, and other devices, so whatever the issue is, it would seem to be unique to the Insteon PLM binding. I read through this Github issue (https://github.com/openhab/openhab/issues/3922), but I’m unsure whether it’s applicable to this situation. I assume not, since I got much further than the folks reporting the issue. Anyone else running into this issue?

I was able to get InsteonPLM to work with a USB PLM using the OH1 style config files a few months ago, just to make sure it worked. The referenced defect only affects hubs, not PLMs.

@ranielsen, that was my reading of it as well. But there’s not much mention of Insteon anywhere, and that was the only possible reason I could see it not working. I’m just starting to go through the code in question (this sort of Java is far from what I’m familiar with), but it may just be that a great deal of the functionality of the insteonplm binding is not manifested in the v2 UI. I’ve noticed that about a bunch of the bindings, such as the MyQ one. They can be installed and properly configured, but just do not manifest themselves in the UI in any way. Perhaps a UI for these bindings is still on the post-beta3 todo list?

I asked this question in a different way and got a much better response: How should bindings appear in the Paper UI?

Basically, the InsteonPLM binding isn’t going to be recognized by Paper. If it’s working properly, setting up the proper configs, device lists/sitemaps, and such will do something. I’ll post back if I actually get OH turning anything on/off.

The latest OpenHab2 beta4 in some ways answered my main question. It includes HabMin, which correctly shows the insteonplm binding as being from v1 (something Paper is unhelpfully opaque about). As mentioned in the replies to my other post on this topic, this requires the use of the v1 files. I’ve not yet been able to get them working under v2, so hopefully a v2-compatible insteonplm binding is in the works.

Would any other folks using Insteon gear be interested in putting together a bounty for a v2 implementation of the insteonplm binding? Based on my reading of the development guidelines, putting together a native v2 binding will be a non-trivial amount of work.

Services like Bounty Source are pretty good at setting up something like that. I’m not sure how much of a difference a bounty might make in terms of folks with the necessary skillset to do this, but it might be worth a try.

I’d be interested (in the bounty that is) provided that new binding also worked better with X10 signals as well. I have the insteonplm binding from OH1 (version 1.9) working to some degree in OH2 (insteon motion sensor works, and X10 devices at A.2 and A.3 work), but even though I’ve added many X10 items to my .items file, the binding does not seem to see the power line codes for X10 devices other than A.2 and A.3. The strange part is I can control the X10 devices A.1 through A.15 using the binding, but if I use my local X10 controllers (to trigger a light ON code for example) , the binding does not see it (except A.2 and A.3 it sees those two addresses fine).

You’ve gotten further than I have getting the OH1 plugin for Insteon to work under OH2; it’s totally non-functional for me despite the controller being seen in the logfile (hence the bounty). But if I read you correctly, you’re saying is that OH/InsteonPLM are actually controlling all your X10 devices, but not getting status updates when you use another controller.

Others who know more can chime in, but I think that’s actually expected behavior. I’ve used other automation packages and whether they get the status update seems to be, as you say, coincidental. With the exception of the unusual X10 2-way gear, status updates like you’re describing aren’t really a thing X10 does well or at all. In the past, I’ve had a few X10 devices to use with alternative HA packages with largely this result. So I don’t think a new plugin (or any programming work) can change the physical reality of what the Insteon PLM is/isn’t receiving. But have you have a different experience with other software?

Yes, basically the modem sees all commands which are sent over the powerline, so although your correct that X10 devices do not provide feedback or confirmation that they have received a signal, the modem (plm) still sees the original command that is sent to the device(s). I have actually verified that the modem does in fact see these commands using another software tool. It seems odd to me that it all works as expected for the X10 addresses A.2 and A.3, but none others.

You are correct that the Paper UI or HABmin do not really help much with the configuration of the insteonplm. I had to create an insteonplm.cfg file in the services folder (it sounds like that has been done for you already), then I added items (using the old OH1 items structure as described in the insteonplm binding docs).

Switch FF_Hall_Tracklight “Ceiling Track Light” (FF_Hall, Lights) {insteonplm="A.2:X00.00.01#switch}

One thing that took me a bit to find was that in the insteonplm.cfg file you must remove the comments in brackets that appear after the port designation. But again, it sounds like your plm is recognized so this is not likely your issue.

Also, the dimming does not work cleanly with this binding. I’ve read a few other threads on this issue and basically it doesn’t sound like it will be fixed anytime soon. So I think a rewrite of the binding specifically for OH2 would be in order, but as you have indicated that may not happen without a bounty of sorts to raise its priority.

Did you try this? This was my problem using OH2 Beta4.

Device Permissions / Linux Device Locks

When OpenHAB is running as a non-root user (Linux/OSX) it is important to ensure it has write access not just to the PLM device, but to the os lock directory. Under openSUSE this is /run/lock and is managed by the lock group.

Example commands to grant OpenHAB access (adjust for your distribution):

usermod -a -G dialout openhab
usermod -a -G lock openhab
Insufficient access to the lock directory will result in OpenHAB failing to access the device, even if the device itself is writable.

What you are describing with your X10 commands not being seen by the binding could actually be a limitation of X10 itself. Switch the insteonplm binding into debug logging (see wiki) and observe the log file. If there are no messages incoming when you flip your switches, it’s not a problem with the binding. If messages come in and are not processed correctly, that could be fixed.

I will try that once I get my items file loading properly again. With the last upgrade (beta 4 I believe the one with Habmin) my item file no longer loads the items bound to the insteonplm. At least my hue bound items are now working, It was loading the insteonplm bound items fine prior to this build. I think I’ll try another build as this one is a week old now, then if I’m still having X10 issues I’ll try the debug mode as suggested.

Thanks

@Bernd_Pfrommer Okay, I’ve finally got my Beta 4 working again with Habmin and I’ve istalled the insteonplm binding and once again the motion sensor works, and A.2 and A.3 still work (modem sees the commands from my external controllers and OH2 recognizes the commands as well). Higher Addresses do not work (A.4- A.15). So now I would like to try the debug mode you suggested which is described on the WIKI, but I cannot find where the logback.xml file resides or if I have to create one, where to create it.

I have no idea how openhab 2 works, sorry!

@speedmax I know this is a bit old but I’m having issues getting the 1.9 version of the binding working on my newly migrated OH2. I’m on a RPi3 and there doesn’t appear to be a lock group. I created one and added openhab to it, but, somewhat obviously, that didn’t work.

For more color, toggling my items in sitemaps gives the expected output in openhab.log and events.log but none of my devices actually turn on/off. As in, there are no errors in the log that I can find, just none of my devices respond to the openhab commands that worked in 1.8.3…

Take a look at the bindings wiki page and fire up extra logging then post
any errors you see.

Thanks for taking the time @tommycw10

The weirdest thing happened. I went to ssh into the RPi running openhab2 and was prompted with a password. That’s odd because I’ve had SSH keys set up for months now seamlessly offering passwordless entry. I remember this request for password happened yesterday but I powered through it in the quest to solve my insteon problem. Today, annoyed, I attempted to fix this first. I re-ran ssh-copy-id from my Mac, still it asked for a password. I deleted the duplicate entry and the original entry for my mac in the RPi’s authorized_keys file and reran ssh-copy-id and still the RPi was requesting a password. some light googling told me to check the /etc/ssh/sshd_cofig file that StrictModes is NOT enabled and it was (i.e. StrictModes yes, when it should’ve been StrictModes no). I rebooted and was able to log in without password prompt. Did something in Openhab2 change this setting (that I just learned about, so maybe it wasn’t changed)? I felt this was important to document in case its related.

Anyways, after i logged in I WAS able to actually toggle some of my insteon products. 2 of the light switches did go on and on but they were very inconsistent sometimes taking upwards of 15 seconds to respond to an off command (if at all) and none of my outlets were responding to commands. Honestly it seems more like noise on the powerline than something with openhab but it happened DIRECTLY after upgrading to openhab2. Here’s the debug log if it has any clues…https://pastebin.com/pgy4JRN5

Thanks again!

Are you using the hub or a PLM connected to the RPI?

I am using an USB PLM