Not really, no. It doesn’t take long to realize that isn’t actually a great binding. To quote a recent comment from the developer of that binding:
He does not provide a hopeful outlook. My problems with the binding have been patched up with messy rules, added xml files, and a setup that is not very stable in the long term. If I have a device that needs to be replaced I’ll be stuck with a few weeks of reprogramming. It took me over a month the first time and didn’t get easier over time. Example: the method available in that binding to build a group scene (so each light turns on together) involves running a python CLI program with a steep learning curve and very little documentation…
I said “complicated” I should have said “complex” … the amount of stuff it does and features it has gets me going down far too many rabbit holes for my own good. Like I said, I’ve got a functional system in OH and am enjoying and using the automations daily.
Essentially I’m scared of messing with my OH deployment in the same way I wouldn’t poke a bear in the forest. It’s fine how it is, I’ll almost certainly break it if I try anything.
I’ve considered running insteon-mqtt linked to OH. But the complexity of the MQTT binding and having to manually link things/items/channels to a non-standard (non homie protocol) is not worth the effort to me. Especially since I’ve been moving over to node red slowly with my first move being HomeKit…
The node red developing environment works better for me. As I said in my first comment, there are arguments and fixes to everything I have problems with but I personally would rather invest the time into node red.
Another thing that has turned me “off” about OH is using new-ish bindings. My understanding of the milestone builds is they’re generally development/beta versions, not really recommended for full deployments or non-advanced users. Full disclosure: I do not understand the OH development process. I have tried and failed several times to load a binding from github using maven. Some specific examples:
- MQTT 2.4. This was released recently, generally works, but I ran into issues immediately. I tried to use the new built-in broker and was left with error logs. Then I tried to use the new MQTT discovery feature which was shipped with a breaking bug. No big issue here, each of these things are known and fixed in milestone 2.5.
- The active-development bindings are generally milestone-only. The Unifi binding is currently under development and to use the new version that works with fewer errors than the 2.4 add on - guess what you need to go to milestone 2.5.
- the apple tv binding is a new development. It has huge potential and is going to be very cool. Milestone 2.5.
- the new work on HomeKit I believe is also milestone 2.5.
So new development is happening but to get involved I either have to wait months for a 2.5 release (then maybe 2.6 if there were bugs!) or I have to run the potentially unstable 2.5 milestone.
In the case of Apple TV, I’ve been running PYATV for months inside of node-red as a command line program with great success. No milestone build necessary.
In the case of HomeKit, there has been a little progress in OH finally but I’ve had a great system up and running inside of node-red… Based on my homekit/nodered tutorial thread I think a lot of others here have been moving their homekit setup over, too.
In the end, I know OH could work - if I stuck with it I could have a good system eventually once development has progressed more. I’ve found fixes for my openhab deficiencies in node red - once I move away from the Insteon binding the only thing left in OH for me is basically timers. It doesn’t seem worth the effort to keep OH running just for Astro and Expire bindings…