I’m the developer behind the version 2 of the binding. Thanks for the comments, really appreciate it.
A bit of background
The work started with an open design process (taking months in calendar time, it’s a hobby project after all), and early prototypes (original thread). @rossko57 and active power users were truly helpful in this process and providing feedback based on their long experience with various devices and typical issues users are struggling with.
The design was discussed quite much in github with the maintainers but the topic of dynamic channels actually never came up.
When I was developing the binding, the KNX & MQTT adaptations were quite much in flux. Later on I have observed the same thing as you that some new bindings (that are “general” protocol bindings, similar to modbus) have opted for the dynamic channel approach. This is shame since user has to “learn” two ways of thinking things & channels (similar to different configuration syntaxes in openHAB1).
I remember considering it but do not remember exactly why I opted for static channels… perhaps I thought that there is no PaperUI support for the dynamic channels (I think this is not the case, at least any more, and you can configure dynamic channels in UI) and it’s advanced feature best left for advanced use cases.
Anyways, yeah there are many sides to this. It’s true that current design has more things compared to dynamic-channel approach but in the end is the goal to minimize number of things? Both design approaches have same number of active channels after all.
However, it’s not all bad – there certain symmetry/semantic benefits that I see with the current design:
- each data thing (and the associated configuration which brings quite much flexibility) can now be one-to-one something physical, e.g. “rollershutter position” is represented by one thing. In my mind it’s a bit similar to Hue for example – we shouldn’t have one thing only: hue bridge with channels for each lamp. Instead, the philosophy of openHAB2 is more towards having one thing for each light bulb, having hue bridge as parent thing.
- thing status can communicate configuration errors more locally (each data thing is independent of other data things). As you know, in modbus you can have 100+ things easily under same poller, and with dynamic channels, we would be forced to communicate all (configuration and other) errors of these channels in the same thing
- With dynamic channels, one would have to have the same dynamic channels for
serial/tcpthings to support write-only use case. However, it turned out thatserial&tcpthings can be reused in external, device specific modbus-bindings. Having the “messy/raw” modbus details (as exposed bydataandpollerthing) separate makes sense. Device specific binding can almost hide the “complexity” of the protocol.
As @rossko57 also pointed out, what I am really looking for active user-developers building device specific bindings on top of the general architecture. First one is binding for sunspec: https://github.com/openhab/openhab2-addons/pull/4220 which is reusing the tcp and serial things. It’s just so time consuming for the user to figure out the register indexes, endianness details etc. especially when you are not familiar with modbus terminology (and you shouldn’t be when you just want to get your device data in!).
From my personal perspective I consider architecture fixed now since there’s little gains (but definitely more pains, being backwards incompatible) to change it at this stage…