Hey @aaugustf, I have just mentioned your bounty here and hope that with this post, such bounties become more visibility and hence hopefully a higher chance that some developer goes for it. Would be cool if that works out!
Thanks so much for the kind mention @Kai. I didn’t take the posting of the bounty lightly (it started much smaller), as the best efforts happen when the fundraising has a large base and everyone in the community sees a need for a feature.
Unfortunately, the division between OH1 and OH2 users has led to a situation where the great potential of OH2 is being undermined by obsolete OH1 addons with, at best, patchy levels of functionality.
Despite being a programmer myself, I’ve not felt even remotely qualified to undertake the vast project of getting Insteon support going in OH2 in some reasonably way. Appreciating the size of the task is a key reason for the bounty. It’s merely a small reward for what I would expect to be some long and extremely tricky development work. I do feel though, that if fulfilled, this and other bounties like it can make OpenHab competitive with many other commercial offerings and the open-source glue that holds the many ecosystems we’re all increasingly stuck with together.
2 Likes
I have a PLM with 60 Insteon devices and no issues with OH2. If anything the insteonplm binding works better on OH2 than OH1.
I’m using a V2 hub rather than the PLM and only have a couple devices, but the binding seems to work well for me also on OH2. There is a slight delay sometimes, but I’d be surprised if that is the fault of the binding or OH.
@ranielsen that’s fantastic. I do wish I’d gotten to message with someone like yourself for any configs/modifications you had made when all the threads surrounding this got started a year back. I do have the plm working under v1, but it’s a dinosaur. V2 has been a total non-starter for me, and most everyone in these threads.
To clarify, I assume by working you meaning functioning in OH2’s backward compatibility mode using .items files and such and not any v2 UI’s and functionality. One of the most frustrating things about the state of the OH documentation these days is the vagueness about which version is being used. Coming from the OH2 documentation, I found documentation using what I assume to be the OH1 model of doing things incomprehensible in the extreme.
Same here with USB PLM. It was actually much easier to make the transition than I thought it would be.
@aaugustf I am, of course, using the OH1 configuration methods (placed in the OH2 directory structure) and I didn’t expect much, if any, Paper UI support for the OH1 binding.
I’m relatively familiar with the OH1 Insteon source code. I estimate it would take 100+ person-hours to make an OH2 binding with device discovery (if effective discovery is even possible given there is no Insteon device identifier database AFAIK).
@Bernd_Pfrommer or @ranielsen , do you have any comments on the automatic device discovery topic?
@steve1, I think the 100 hours is very conservative estimate. I also did basically what you did. I’m pretty sure there is documentation that documents how to get a OH1 binding up and running on OH2. I know that’s where I started. Here’s the basic steps:
- created conf/services/insteonplm.cfg file with the Insteon config info from the OH1 config file. Since I use a PLM I have the line port_0=/dev/ttyUSB0
- create a file conf/items/default.items which contains the insteonplm items from the OH1 items file.
- create a file conf/sitemaps/default.sitemap which contains insteonplm items from the OH1 sitemap.
- install the OH1 insteonplm binding
I completely agree. Hence the “+” qualifier. 
With the technical issues and the OH2/ESH PR process overhead it could easily be double that or more to have a stable binding with the required features (auto discovery, support for both PLM and hub, etc.). It took over a year to merge the JSR223 PR and that was simple compared to this.
Seems like OH2 is reaching some level of maturity. I’m considering giving OH2 a try some time in the coming months.
Device discovery is possible somehow, after all the hub does something like that. I believe device category can be discovered for many devices, and maybe then it’s a couple of probing calls to see how the device responds. That’s the insteon side. No idea how convoluted it will be to deal with the OH2 aspects.
My guess is that the Insteon hub is using a Product Data Request and the Insteon Product Database mentioned in the Insteon Developer’s Guide:
All INSTEON devices are assigned a 3-byte (24-bit) number, called the INSTEON
Product Key (IPK), which functions as a lookup key to the INSTEON Product
Database (IPDB). The IPDB is currently under construction and will be maintained
by SmartLabs.
AFAIK, the product database is not available to the general public.Are you thinking that device category can be inferred from the device address or maybe from reverse-engineering the IPK (when available) for known devices?
I have not managed to get a single device respond to the product data request. Would be glad if somebody showed me what I’m doing wrong.
There is a category/subcategory that can be queried (forgot how), but that works. After that you can send some queries (mostly ext2 get status requests) and see if the device responds. Not very appealing to implement.
@Bernd_Pfrommer. I ran across GitHub - phareous/insteonlocal: Python library for controlling Insteon Hub locally today. One thing it appears to do is:
You can request a list of all linked devices. For each device, it will also return the type of device and the model. This is accomplished by using two files from this library, device_categories.json and device_models.json
Interesting. Have you investigated enough to know if this only works for the Insteon Hub? It doesn’t appear that the device model and category information corresponds to device identifiers for my devices.
I’d give it a try if I had a hub, if somebody gets it working for a PLM. I’d be happy to help fill out the device tables.
Wow, this thread really caught steam while I was away (I got a 7 week old, it’s amazing how things like OH get de-prioritized).
I MEANT to report back that during my troubleshooting I left the inconsistent OH2 installation on a RPi running for a few days while I changed diapers and didn’t sleep, and low and behold, all the 0x02 errors (and similar random errors) disappeared from the log and ALL my insteon devices started responding without delay!! I wish I had mentioned that before I had to report that now I can’t access OH2 at all from Android/browser inside or outside my LAN. I lost internet one weekend and after powercycling modem/router/AP I got the internet back, but OH never did. I can SSH in and it shows the OH2 service as running but i can’t seem to access it. That’s neither here nor there, most likely not related to Insteon, just another issue with OH2 I suppose. But I feel like before this current issue I could confidently say that I too had the insteon binding working in the OH2 backward compatibility mode.
The conversation has also gone way beyond what I can contribute intellectually, but I very much want to use OH going forward as the glue of my smart home (and hopefully with a much more involved installation). So I added 10% to your bounty @aaugustf seeing as its the only way I know how to contribute. Unfortunately, I can’t (yet) match your generosity, but hopefully this gets it a marginal amount of more attention.
@Tweedleburger Thanks for contributing to the bounty. It’s much appreciated. I put up for a bounty the value I placed on having all my disparate home automation gear working together – and with the sad state of Insteon in OH2, it’s money well-spent. But sadly, I imagine I’ll get it back in some months time, as there are no takers.
I genuinely hope that something comes of it, but based on the feedback I’ve gotten from those looking to work on it, the bounty would need to increase by an order of magnitude to even begin to compensate for the massive amounts of work that would be needed to get Insteon functioning under OH2. I’ve reached out to the Insteon folks in the hopes that they could perhaps provide some guidance or resources that would make the process seem less an uphill battle of hack-ish reverse engineering, but have not heard anything back.
I’ve been working as time permits to replicate the results of those who say they’ve gotten some non-hub Insteon functionality working, but am unable to do so. Whether there are differences with PLM’s, other configurations/mods I’m not aware of, or whether there is some miscommunication in terms of what is working, I don’t know. Perhaps if we keep plugging this work, someone with a Ph.D. in Insteon implementations will kindly volunteer themselves.
I couldn’t get the binding working with a hub (Model: 2245-222), but like most times for me it could be operator error.
I only had simple on off devices so I made python scripts to trigger them following this site:
http://www.richstevenson.com/2014/01/06/insteon-direct-commands/
and so far so good. I have not tried to get status or anything like that yet.
Mind posting some log files?
It’s not quite the binding you want, but I’ve made some good progress on an Insteon PLM<->MQTT bridge application (in Python). It allows control of Insteon devices and reports state changes via MQTT messages (and automatically understands scenes so every device updates correctly) so it can be used with any/most home automation systems. It’s still in development but it does work for the devices I own. I’m working on adding automatic linking so something like insteon-terminal isn’t needed to to get more complicated devices like the remotes, smoke bridge, thermostats, etc configured. Later this week I’ll be adding a nicer front end and a user’s guide so you might want to check it on in a week or so. If you like the idea and have any feature requests (I need to expand the list of devices and will need testers since I don’t own many of them), feel free to open an issue on github. Repo: https://github.com/TD22057/insteon-mqtt
Based on perusing all the recent inteonplm posts and failed pull requests, I’m ready to withdraw support from my OpenHab bounties. Some folks do appear to have some sort of Insteon Hub or PLM functionality working, but have not been able to clarify just what is working and how. From what I gather, the work to get the v1 plugin properly working with v2 is something that the very few developers capable of doing the work don’t wish to take on. It seems that writing a proper v2 add-on for the Insteon PLM is too high a political and technical challenge to overcome. I’ll leave the bounties active for a few days more before moving on to other projects.