This is a lightweight, dependency-free BACnet/IP binding for openHAB 4.3.x.
Discovers BACnet devices (Who-Is / I-Am), reads and writes present values,
receives live updates via COV subscriptions, and forwards intrinsic alarms as
trigger channels. No external BACnet library — pure Java, EPL-2.0.
Experimental / work in progress. Not yet tested against real hardware.
Features
Discovery via Who-Is / I-Am broadcast
Read/write: Analog, Binary, Multi-State objects
COV subscriptions (live updates)
Intrinsic alarm forwarding
Schedule & Calendar (read-only)
Known limitations
No segmentation — large object lists may fail
COV and read/write share one UDP socket — may race under load
I have authored openhab 1.x bacnet binding a while ago and eventually wrote one which @stamate_viorel linked above targeting OH 3+. I do not like bacnet4j dependency, but at the same time I know that writing protocol library from scratch is a large effort. With or without LLM, there are many edge cases to cover which make not only binding, but library part complex in configuration and parsing.
Having said above - having an alternative approach in OH itself is better than no alternative.
I’m not sure that I agree with that on a general basis, of things are broken enough, I think it’s better if they aren’t there (because they will never actually be useful, only a source of frustration).
That said, I don’t know if this is the case here, but all the slop floating around these days makes for some really terrible experiences, so I’m naturally skeptical, and think that at the very least, people should be made aware if that’s what it is.
I don’t have any hardware using this protocol, so I have no way to test or evaluate any of it.
I think in terms of providing additional functionality to OH community. I am trying not to judge anything beyond this, because BACnet is a big thing in large installations an OH can benefit from having support for it. AI slope or not, it may at some point produce a valuable result, if there is enough patience pushing things forward.
My advice is - make sure that you have a feedback loop (a reference environment to test), which will let agent iterate independently and fix own mistakes. Without this quality will depend on a dice roll.
I don’t necessarily have a problem with such a method, if it’s just made to match some defined standard. It’s not that easy to read, but the level of nesting as a measurement of “code quality” has always been questionable to me. Splitting everything up into smaller methods just to satisfy some idea that “code shouldn’t have deep expressions” only makes it less readable, and much less effective. That said, this method might be completely crazy if I knew what it did/the structure of the data it tries to represent.
People have been writing crappy code all along, that’s nothing new. What is new with LLMs is that they basically don’t understand what they are doing, and are basically trying to “guess their way” to the intended result. To me, that can never end well, because the idea that you can test anything that thoroughly is naive. There must be some logic/planning when you make the logic, not just “tinkering until it seems to work”.
Experimental / work in progress. Not yet tested against real hardware.
