So where are people getting the old example config file from? Is there another file for OH2?
Is the USB drive full?
Could also be the OS not flushing to disk (but in this case I would not expect the time stamp on the file to update).
Maybe try another USB stick?
I assume the above logs are all generated with OH1, since OH2 doesn’t work and gives the 0x02 errors, right?
That file is the one used by OH2
I seriously doubt it but I will check (seems unlikely given the updated update time).
I’m not 100% sure what this means but seems possible possible. maybe something is amiss with my move to an external USB, but yes updated times are confusing.
I’ll try but this feels like it would take a while and I didn’t really notice any performance improvements even in reliability. I may just roll back that one and still do everything on the sd card…for now.
So no, at least I don’t think so. I re-enabled OH2 in order to test the CPU load like you asked for. Lights SEEM to be working more consistently for some reason (though they degenerated in reliability over time last time, though it happened MUCH faster than if it started now). Outlets still don’t work. The errors, if you look at the part of the log that did print, seem like more than just 0x02 errors. But to answer you’re question these logs, I believe are generated with OH2. At least I"m finding them in /var/log/openhab2 as oh2 is running…
Having started this thread around a year ago, it’s become clear to me that the insteonplm module as written is a total non-starter in OH2. It’s never worked for me at all, and I’m not sure I could reasonably have expected that, considering what a different animal OH1 is. I’ve put up a $500 bounty (https://www.bountysource.com/issues/47277806-insteonplm-feature-request-oh2-insteon-plm-hub-support) to make a proper insteonplm add-on happen, but so far, no takers. For many of us with large Insteon installs, OpenHab is useless without a proper add-on, so here’s hoping someone takes it up.
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.