Do you think that the “data” Things could become channels of the poller thing instead of the poller thing acting as a Bridge?
@ssalonen is the code owner, he might be able to provide some insights in the design of the binding.
I explored this in some time ago in my backwards-incompatible thing hierarchy:
README shows few examples how the configuration would look like openhab2-addons/bundles/org.openhab.binding.modbus at modbus-14058 · ssalonen/openhab2-addons · GitHub
(the branch is relatively feature complete, and even the tests were ported to a degree)
The thinking was to have separate channels in order to easily parse the data, to make the binding more easy to use. For example, turning ON/OFF commands into 0/1 numbers in modbus.
In the end, the design still was quite odd, and did not match any other binding, see notes in the issue.
In addition, the Web UI (at least the time) was very much making it hard to build a “generic” binding like modbus, since the UI is enforcing channel type to match the item type [1]. This leads to explosion of channels as you have to duplicate the same channel for each item type (example: write coil from ON/OFF with Color item, write coil from ON/OFF with Dimmer item, write coil from ON/OFF with Switch item). See comments in the issue.
Later I have also learned that with 4.x a openhab-core change lead to a situation where a non-UoM Number channel is somewhat challenging for user to use with UoM items, see comment Modbus thermostat : stepper don't work ( - #20 by ssalonen . The bidirectional unit conversion/scaling profile provided by the modbus binding (gain-offset) broke as a result in 4.x, and has been broken since. In other words, openhab-core discourages use of plain Number channels with UoM channels. Unfortunately, in a generic binding like modbus, I don’t find it too nice to have channels for each QuantityType (consider e.g. writeRegisterFromNumber
channel permutated for Power, Energy, …)
All this above lead to a situation where the “simplified” thing structure was not actually simple anymore. There were too many channels and “odd” design choices remained. Overall I ran out of energy, as I noticed the changes are quite invasive, and the design is not so obvious for the user.
As a summary, I felt that the openhab core and WebUI is making it very hard to build a binding like this one where we have low level data (essentially collection bits stuffed into registers), and want to facilitate transformation typical encodings of data (e.g. 0/1 to ON/OFF, or 0…255 into percentage, or 0…1000 into 0…100 Celsius) into openHAB items. Vast majority of bindings are “specific”, and can provide the data in processed format, such as “room temperature in celsius” etc - obviously this is not the case with modbus.
It is likely that I might be missing some key design angle here, but this is as far as I could get.
I guess alternative would have been to provide the raw data as hex or numbers, but leave even the simplest of data conversions for the user to figure out. Even then, due to the WebUI issues, we would have to have multiple channels for the items types and possibly for different quantity types.
The best approach from a users point of view would be to create pollers completely behind the scenes by configuring polling settings per register instead. This would allow getting rid of pollers altogether so that I could only have my inverter thing with individual channels for every required register. I think this should be doable but I also understand that this is not trivial.
This is has come up sometimes in the forum. Respectfully, I do not think this works very well in the generic binding, as
- some devices refuse to answer to read queries unless the registers is set just right. For example, reading 2 registers is allowed but not reading them in pieces.
- we have many users with high polling frequency and flooding the modbus server with requests is unlikely to work in practice (we have had many cases where the server refuses to respond to queries).
- Finally, sometimes registers are connected (e.g. 32 bit number spread into two registers), and it’s important to read them together as one to get the right value out.
Many of these points have come up in the forum in one way or another over the years.
So the my preference with a low level protocol as modbus has been to enable maximum flexibility, as there is no strict compliance from the devices point of view, and in order to stay efficient.
For certain use cases (longer poll interval, not so many registers, server more lenient on the way the registers are called) I do agree it would make the configuration easier for the user. We could even offer this kind of “auto mode” as an alternative.
–
- [1] Later, there were some spot-adjustment in WebUI (thanks @florian-h05 !) to allow linking Number to Switch item, Number channel cannot be linked to Switch Item (with profile) · Issue #1478 · openhab/openhab-webui · GitHub, but the general issue remains, it was only addressing Number channel<>Switch item, but not e.g. Number<>Dimmer.