I’m new to OpenHAB. I’ve been investigating using it to replace the Homeseer system I’ve got at my house, mostly because HS3 is such a cobbled together mess of badly-designed VB code, with a worse UI and even worse mobile apps.
I’ve got a half dozen custom plugins I’ve written for HS3, either for 3rd party hardware there weren’t plugins for, or custom hardware for various uses around the house.
So far I had pretty good luck in converting one of them to hand-crafted rules, items and a sitemap. That one was an interface to the Monoprice six-zone whole-house audio amplifier. I found an example someone had for it on here, and while it was a bit of a learning curve in Xtend, I was able to refactor the example to run more efficiently and reliably. What I found, though, was that there was a really shocking amount of manual code needed to make it work. On the “receive” side of things, where the ASCII data from the receiver (in this case, over TCP) has the context of what its talking about, I was able to use groups, the group member list and a structured naming for the items to find where to stuff current state for the amplifier. (Its six zones, and about a dozen items per, so it was a lot of items to create, but was manageable, if oddly inefficient.) On the “send” side of things, though, it ended up being almost a thousand lines of rules for something that should’ve been maybe five or six. Every one of those items needed its own rule to handle state change, because the Xtend code for the rule doesn’t seem to be given the actual item that generated the event. (Its literally the only event-driven system I’ve ever seen that doesn’t provide it!?) So it was a lot of cut-n-paste-n-change, but it works. I think its at the tattered edge of what is “sane” to maintain by hand, though.
In looking at how bindings work, one big benefit is the fact that they have channels, and items can route commands back to them. So even if you have to manually create your items (yuck), at least you don’t need thousands of lines of repetitive rules for them.
One of the plugins I need to replace is a good bit more complicated. It provides a linkage to a combination IR blaster and environmental sensor suite. IR interactivity (because its time-sensitive) happens over TCP sockets. Environmental data, general device metadata and things like that are via a REST API. They’re published onto the network via SSDP/uPNP, so autodiscovery would work fine to find them. In theory, the IR interface could work exactly the same as the Monoprice stuff. The underlying protocol is pretty similar. (Actually, it’d probably work as-is with the GlobalCache binding.) These would be two pretty simple items per device on the network. Losing auto-discovery wouldn’t be ideal, but it’d be easy to manage.
The second piece the existing plugin provides is state management and both encoding and decoding of IR messages to and from a bunch of HVAC units. This starts to get a lot more complicated to do as rules – it’d be quite a few items per unit, all that need to respond and generate encoded IR from the other i/o items, as well as polled data from the HTTP endpoints, per unit. Even with liberal use of lambdas, I think I’d end up with quite a few thousand lines of rules to manage it all, even though the actual logic for what to do with almost everything is identical. Managing it long-term would be a nightmare.
It seems, from reading the forum and the docs, that there’s a pretty hardcore “bindings are for physical interfaces” mindset with OpenHAB and ESH, but the fact that you can’t (unless I’ve totally missed it) define, and implement, the thing->channel->item pattern with text-file based config and .rules files means for anything but the simplest of integrations, a custom Binding is essentially a requirement. (I’m guessing that’s why 75% of the OH2 bindings are simple TCP interfaces, and aren’t written as rules!)
Is there some detail I’m missing here? I don’t want to write a full binding if I don’t need to, particularly given its not the simplest of things to properly write a thread-safe, properly reliable bidirectional TCP client in Java. But I’m just not seeing a practical way to do this without a massive amount of manual work without one. (I’d probably write an abstract TCP binding, or at least generic connection, that I can extend and reuse with other devices. Half the OH2 plugins have the same thing implemented over, and over, and over again.)