Is it possible to create a Modbus 'bundle', to avoid having loads of individual Things?

ssalonen · January 21, 2025, 4:27pm

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:

github.com/openhab/openhab-addons

[modbus] openHAB 4.0 refactoring: turn things into channels similar to mqtt.generic

opened 10:31AM - 24 Dec 22 UTC

ssalonen

enhancement

Prototyping in https://github.com/ssalonen/openhab-core/tree/modbus-14058 h…ttps://github.com/ssalonen/openhab2-addons/tree/modbus-14058 [README](https://github.com/ssalonen/openhab2-addons/tree/modbus-14058/bundles/org.openhab.binding.modbus#read-channels) openHAB ~4.0~ x.0 (30.5.2023: **this is not going to make openHAB 4.0**, we would need much more testing and user feedback) is in the works and this is the right time to consider breaking changes. I create this issue to bring visibility and open up discussion. cc @Rossko57 as FYI ### Background Modbus binding was one of the first bindings with complex thing hierarchy...and that shows. At the time, I decided to go for the following thing hierarchy Read/write `data` things: ``` endpoint (tcp or serial) -> poller (reading block of data, every x milliseconds) ---> data (referring to one piece of data from poller, optionally how to write data) ``` Write-only `data` things: ``` endpoint (tcp or serial) --> data (how to write data) ``` This setup introduces lot of things which is cumbersome to edit in MainUI. For example, MainUI YAML view is optimized to edit single thing, not multiple things. Often with Modbus, many of the `data` things are very similar, just the "address" is different. It would be much more convenient to edit the channels of a single thing in UI. There's other negative downsides with several things, for example a lot of thing status spamming in logs when poller goes OFFLINE. ### Proposal (WIP) We can take example of mqtt.generic binding where one can configure channels. The exact same approach is applicable to modbus. Instead of data things, we could have configurable channels for `poller` (read/write behaviour) and `tcp`/`serial` (write-only behaviour). Channels could be specialized for the item type, allowing ease of use, for example `Switch` channel could have `on_value` and `off_value` to encode/decode raw bit pattern from/to modbus (similar to [mqtt](https://www.openhab.org/addons/bindings/mqtt.generic/#channel-type-contact-switch)). **update: ** this is implemented in proto, as `readIntoOnOff` channel At the same time, we probably should look into initiliazation logic, starting with `UNKNOWN` `tcp`/`serial`/`poller` until we have a successful read/write **(update: this is implemented in the proto)**. Currently endpoint thing starts with ONLINE, even when no single TCP packet has been communicated with the device ### read channels https://github.com/ssalonen/openhab2-addons/tree/modbus-14058/bundles/org.openhab.binding.modbus#read-channels ### Write channels: [Note: writing "json" would not be supported anymore. One would have thing actions for endpoint thing instead. https://github.com/ssalonen/openhab2-addons/tree/modbus-14058/bundles/org.openhab.binding.modbus#write-channels ### Notes from prototyping - the current design in the prototype is designed such that multiple items are to be linked to different channels. Is this pattern used in other bindings? Is there better way to do this? Example of read and write channel linked to same item: https://github.com/ssalonen/openhab2-addons/tree/modbus-14058/bundles/org.openhab.binding.modbus#valve-example-writing-to-different-address-and-type-than-read Example of one read channel and two write channels linked to Dimmer item: https://github.com/ssalonen/openhab2-addons/tree/modbus-14058/bundles/org.openhab.binding.modbus#dimmer-example Downside: This approach might be hard to understand for users as this is not a model used by other bindings. I have also noted that due to https://github.com/openhab/openhab-webui/issues/1478 linking via UI is hard and clunky. Upside: However, with this separation-of-concerns, separating e.g. writing of ON/OFF from writing of PercentType with different channels, neatly divides the configuration task into "orthogonal" sub-problems. ### Some considerations 1. Many modbus users might have tens if not hundreds of `data` things. We probably should consider if it is possible to create a tool to assist with migration? This might get complicated though. Can we use core migration capability? 2. We need to ensure no breakages with `modbux.xxx` device bindings. I think this is not an issue, they do not rely on `poller` and `data` things. 3. Data things had channels for erroring/successfull read/write. Emulate same by propagating channel write errors to poller (if parent for channel) and endpoint (always) thing status? Badly configured read channels should make poller go offline 4. Can we provide suitable ready-to-use transformations with the binding distribution? Eg number-to-switch and vice versa? Similar how persistence addons bring their config https://github.com/openhab/openhab-addons/blob/4d6d6443ef38a5799e8913e9f04edbbf245c7f06/bundles/org.openhab.persistence.dynamodb/src/main/feature/feature.xml#L9

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.