@rlkoshak, wow your panties are in a bunch! Your exact response and attitude is what has pushed developers away and not want to contribute. I never asked or expected @Kai to continue to maintain the OH1 compatibility layer.
Again, all I stated is support was going away in a future release of OH to make InsteonPLM users aware of it.
Well, you accused me of having an attitude that repells contributors for pointing out that OH 1.x bindings still have away to be used with OH 3. Somehow supporting a compromise between enslaving Kai to forever support the compat layer (since no one else is willing to do it) and completely dropping any interoperability with OH 3 and 1.x bindings is driving away developers.
Those are the two choices. Since neither are acceptable, they came up with a compromise. Yes, the attitude is shocking (sarcasm).
I advertise that the compromise exists. Wow, what an attitude (sarcasm).
Forgive me when I get upset when my attempts to help point out that all is not lost is accused thusly. It was a personal accusation and I responded.
Please note that no decision has been taken wrt to the compat layer whatsoever. I was only suggesting that its removal could help a lot to simplify openHAB both from a (new) user perspective as well as ensuring the maintainability of the code base on the long run (meaning that we must avoid me being the only person to be able to fix/adapt certain parts of the core code).
Hey all I just saw this thread and I want to sign up as a +1 for a user who REALLY wants a good Insteon binding.
There are several good efforts going on around github for various Insteon projects and I’m constantly watching them pondering whether I want to ditch openhab for one of the more mature Insteon setups. Currently I’ve got my eye on Insteon-mqtt which would be easily compatible with openhab.
BUT a new binding would be awesome. If someone has the knowledge of how to do this but needs a spare PLM - hit me up on a private message and I’ll order you one! Looking at you - @Laufeyjarson…
If I were a programmer I’d be all over this but, alas, I went a different direction in college. Let’s get this ball rolling!
I’ve got a second PLM with a dead power supply. The replacement capacitors arrived for it last weekend, and I’ll be replacing them soon. Once I have that, I should have all the hardware I need. I have several extra switches and stuff I can work with.
Hopefully the Eclipse framework is stable enough now for me to start developing and seeing what I can get working. I had thought I’d do a quick proof of concept to make sure I knew enough to finish things, and then I’d create a PR on the Github site and ask a bunch of specific questions there.
I’d really like to add a bunch of configuration tools, similar to how the zwave stuff has, but I haven’t seen anything about how that’s done and if it’s a direct Habmin extension or what. Being able to trigger links between devices from the UI, and being able to save the modem config and stuff would be really handy. I’d love to be able to also allow the configuration of things like LED brightness and ramp rate, without having to just make those channels. I fear if they’re channels someone will write a rule that updates it frequently and cook the eeprom on the device. (Although, with a 100,000 write eprom that’s one update an hour for eleven years, so maybe it’s okay.) A UI changes like this would be awesome, and a way to say “make all my dimmers use a 3.5 second ramp rate” would be neat.
A way to export the modem database and reimport it, possibly onto a new modem, possibly updating the entries in the other devices, would also be a really useful feature, especially since the PLMs seem to die.
I know all these things are doable by hand with insteon-terminal, so the Insteon part isn’t that much of a mystery - how to get it all fit into OpenHAB is the part I don’t know yet.
In the comments for the v1 InsteonPLM binding, the author warns that the Insteon network is easily overloaded and that a bunch of the devices don’t support the “describe yourself” function. If you’ve linked the device with your modem, it should be “discoverable”, but you might have to pick the device type manually. You might not, if the device will tell you.
I’ve been doing some homework! 
Yes! I’ll add one thing to this list: make groups (modem scenes)
It seems like these should be channels along with the “on level” which is a feature I copied from elsewhere and put into my OpenHAB deployment.
Indeed. I’ll be watching to see what you come up with. The most compelling features that have me considering other things are 2-way linking without touching the devices and modem scene configuration through software. These two things seem like they would effectively back up the modem.
I haven’t ever looked at the z-wave setup in habmin but that sounds like an interesting idea to add for insteon. Way over my head. I’m good at brainstorming (and testing eventually, I’ll buy a dev PLM) but not so much good at actual programming.
Finally - I think there was some work done for an OH 2 binding a while ago … search “insteon bounty” in the forums and you’ll see some interesting old threads.
I started working on a 2.0 Insteon binding a while ago but didn’t get much past logging in a getting the hub version.
I just received my new hub (the usual capacitor issue) and I plan to start back up again. I was using a modeling tool called Papyrus to generate the code from a model. In the time since I stopped, both Papyrus and openHAB have gone through fairly extensive changes and it appears that openHAB is now transitioning from 2.0 to 3.0.
BTW, for those of us in the USA, Smarthome is replacing dead hubs free of charge. If anyone is interested, I’ll dig up the link to their e-mail about this.
Dead hubs or dead PLMs? Both are interesting to know, but they’re different. I’ve stayed away from the hub because of the dependency on their site.
With respect to the linking issue, you do want your links to be complete. Ie. you need the proper links on both the controller and the responder device. If not, you actually end up with more Insteon traffic on the powerline as the the controller sends “clean up” messages to responders after a broadcast event. The controller will try upto 3 times for a response from each device. Some of this behavior is configurable (with the right software) on newer Insteon devices.
Keeping an Insteon network intact, ie with correct links on all devices can be a PIA without a controller that can do that automatically, especially on large installations. I have over 120 devices in my home with a failure rate of 2-5%/year. I have switched over to the ISY99 and have had very good success using this device to manage the network. The latest version of the OH binding is available for download in the ISY forum. Unfortunately, its not being actively maintained and does have some bugs.
The hub. Specifically the 2245-222.
I wouldn’t say that the network is overwhelmed, just that the bandwidth is very low. I have not seen any Insteon device that does not respond appropriate to the get device info request.
I have not heard that this is a concern.
If you can imagine someone writing a Rule like this, someone WILL write a Rule like this. I’m not sure there is anything you can do in the binding to prevent that though. If this is a concern though, I think it could be addressed using a warning in the binding docs.
This is what I found in the internal docs for the v1.0 Insteon binding. I haven’t tested the network overload myself, but I have got at least one device here that ignore the “get info” request entirely, so it seems plausible to me. I’ve been testing sending messages to devices with insteon-terminal.
All this means is that we’ll have to have a way for people to manually select device types if discovery is wrong or missing. I don’t know how to do that yet, but hope I will find out soon.
It’s the nature of any device that uses an eeprom. I’m pretty sure it applies to the Insteon devices. I haven’t heard it mentioned, but I suspect that’s because the usual set of data stored changes rarely and 100k is plenty of updates.
As I said, with a change an hour it’s still over a decade’s worth and given how quickly some of the devices die, that’s probably a safe number.
Yeah, after I did the math and came to “over eleven years” I kind of decided the same thing. If someone really wants to do something that will wear their device, they can. But it’s a good idea to let them know there is a limit, even if it is really big.
And… if you only adjust the brightness a couple of times a day you get indicators you can read during the day but don’t keep you awake at night. Which is kind of neat!
Yeah, this is something I’m noticing as my network gets bigger. I’ve managed it by hand with a lot of attention to detail, but that’s no fun.
The current Insteon binding for Openhab doesn’t try to do anything like this for you… should it? If it polled every device and found missing connections or connections that were only one-way, would a report or a tool to fix those be useful? Would a “link this new device” command be useful?
These aren’t things I’d expect to see in PaperUI, but more in Habmin, and I don’t know what the planned future for that is, or if it’s the right place to do these things. Should OpenHAB be able to replace their discontiued software or the ISY, at least for Insteon? (And, is it worth the trouble, as the ISY is good at it and not that expensive. Instead of fixing the PLM driver, should we just fix the ISY driver?)
For another HA system, I wrote the Insteon plugin - over 10K lines of code in Lua. It managed the entire network and healed broken/missing links and allowed for device replacement etc. Its a massive undertaking. I now use the ISY - it works very well. I would propose maintaining and improving that binding vs trying to develop a full OH solution. Or writing a standalone PLM piece of software that supports Homie MQTT would be great and would work with other HA solutions.
Forgot to mention, this will happen with the second generation of Insteon 2 devices IF the device is not linked to the PLM first. What device doe this?
I am not surprised at the amount of work it took; it’s a big task. I think the more minimal “just allow interacting with the device” path that the v1 interface took has some advantages - it certainly lets you get a binding out more quickly.
But on other forums, the question always asked is, “But how do you configure the groups and set up the network?” On the Smarthome forum, the idea of actually doing all that with the push-buttons seems unacceptable. They’re big fans of the ISY over there, too.
A standalone tool for maintenance might be interesting, but I don’t know about the MQTT interface.
I expected just a NAK to any request if it’s not linked to the PLM. I fear I was doing all sorts of messing about that night and didn’t keep good notes. It was probably something stupid like a lamp module. I’ll do more experiments when I get a working dev PLM. Monday, according to Amazon…
