How to transform multiple values read from Modbus into a single value for an item?

I think I have a pretty basic questions but seem to lack the knowledge how it’s done correctly in Openhab.
I have boiler where I just started to pull in various data using the Modbus binding. The boiler is providing the software version in 3 successive registers which are all uint16 (length=3).
From these register I’d like to create a single version string like “21.0.14” and provide this as Thing.

The examples in the modbus binding seem to transform only single register values. I could probably. So what would be the best way to transform this?


That’s right, transformations operate under the basic “one data point in, one data point out” principle.


Use a rule to assemble three Items into whatever, its very easy.

There is one pitfall.
Traditionally you might trigger such a rule to run when one of the Items updates. The snag is that if you read poll your registers together, you can’t tell which one updates first or last - they will not update their individual Items at the same microsecond. So when assembling three Items there is risk of using a mix of elements from this-poll and previous-poll.
That might not be a problem for your data - presuming “software version” will not be changing very often…
If it is a problem, a suggested solution.

You might question why you want to read the software version at all … is it going to change very often?

Hi Rossko,

thanks for your comments. I think I’ll go with the rules, that seems to solve my need. Slightly unconvenient that that I need an additional rule and items, but it solves the problem. The problem with the updates of the different items is okay to handle, but good you mentioned it.

Why do I need it? Because I want to ,-) No, honestly, it’s just that I’m currently working on some Modbus based binding for KWB boilers and just want to provide as much information as I’m able to pull from the boiler control.

Thanks for your comment!

They are totally cost-free to users. I’m often puzzled by resistence to using rules - its just code, same as a transformation is.

Meantime, I have thought of a possible single-transformation approach.
The Modbus binding includes 64-bit unsigned integer data type - that’s four “standard” registers.
If your read poller is able to read a larger block that includes the three regs that you want, you might make a data Thing that includes your target three plus an unwanted register X.

It is of course possible to link that to a Number Item as a 64-bit value and process that in a rule, but frankly that is likely to end up as clumsier code than starting with three 16-bit Items. And of course you would still need the extra ‘results’ Item.

The advantage is that you could construct a JS transform to extract your three data chunks and output a single string from the data Thing to an Item. It’ll need fancy coding to mask out the unwanted register, and split out the three wanted 16-bits worth. Probably easiest as byte-level manipulation.
A possible pitfall - I’ve no idea if standard javascript can actually deal with 64-bit integer.

Ha ha, I’m not afraid of code (or rules ,-)) I also throught about that 64-bit reading and bit-manipulation afterwards, but I agree, that would be just over the top to get a version number - and likely almost unreadable code for the bit-manipulation.

Maybe it’s just because I’m still relativly new to openhab in general, but I just expected that reading out some values, transforming and displaying would involve less, well, components. E.g. in openhab it’s not even possible just to peek what a thing receives, one has to put the whole chain of item/transformation/thing into place to visualize the values. This is uncommon to me (coming from a old-school developer background, where debugging on machine level was/is quite standard, so one doesn’t has to pass the all layers to get out some information), but one has to accept it with openhab; that’s okay for me ,-))

For the moment I’ll stick with the rules approach, this is a an easy to manage und understand approach and fits good into openhab’s concepts - thanks for your thoughts!