OH3 Reading MQTT values

  • Platform information:
    • Hardware: RPi4
    • OS: OpenHabian
    • Java Runtime Environment:
    • openHAB version: 3
  • Issue of the topic: Reading MQTT Values

Once upon a time (OH2 but using the MQTT binding from OH1) I would read MQTT items with an item config like this

Number Boiler_Flow "Flow [%.1f]" {mqtt="<[mosq:sensor/multi:state:REGEX(.*FLOW (.{1}\\d*\\.\\d*)):.*840d8e10bdb4.*]" }

Which gave me an item ‘Boiler_Flow’ that read the value from an MQTT message that looked like this

1620074237 840d8e10bdb4 : FLOW 27.18

And set the Boiler_Flow to 27.18

The question is… How do I do this in OH3? The docs are… less than clear…

Converting a v1 MQTT to a V2/3 config:

Or use the new UI in OH3.

Yeah. I have the UI… but the docs on how to configure a REGEX in it appear to be missing… The ‘examples’ for translating OH1 to OH3 when you’re using REGEX don’t appear to exist either

That’s because the use of REGEX is independent of the MQTT Binding - the REGEX Transformation Service is generic and can be used by many bindings (and rules). No specific examples exist because there’s quite a few Transformation Services.

Why not show us how far you’ve got, and we can help fill in the blanks? Might also be worth showing what the full MQTT message is that you’re trying to parse with REGEX.

1 Like


That was a full message…

Maybe an explanation of the setup. I have a scattering of esp16’s and esp32’s with various temperature/humidity/pressure sensors on them. Some BME280’s, some 1 wire temp probes. Some with multiple sensors, some with just one.

Most of them log messages such as this

-273338341 000336da : humid 57.60 temp 13.90 heat_ind 12.84
244975 3c71bfa94cc0 : humid    88.94 temp     8.34 press   990.80
3175264 cc50e381bf8c : humid 66.19 temp 13.90 heat_ind 13.07
-243120438 000336da : humid 57.70 temp 13.90 heat_ind 12.85

A message per line. And sensors log all their value son one line. The values are

<timestamp> <esp_id> : humid <humidity> temp <temperature> heat_ind <heat_indicator from sensor>

What I need to do there is identify the sensor by the esp_id, then parse out the humidity and temperature and save them in an item. Oh, and persist the reading (Which used to be in a mariadb database, but that killed the SD card - hence my struggle to resurrect this as OH3 instead of OH2 with OH1 mqtt plug-in)

Then there’s the multi sensor esp’s… They log messages like this

1620106218 840d8e10bdb4 : FLOW 16.81
1620106218 840d8e10bdb4 : RTRN 14.18
1620106279 840d8e10bdb4 : FLOW 16.81
1620106279 840d8e10bdb4 : RTRN 14.18
1620106339 840d8e10bdb4 : FLOW 16.75

Similar but the same sensor logs multiple lines (One per sensor).

On the OH1 mqtt plug-in I could do the filter and regex all in one as an item. e.g.

Number Boiler_Flow "Flow [%.1f]" {mqtt="<[mosq:sensor/multi:state:REGEX(.*FLOW (.{1}\\d*\\.\\d*)):.*840d8e10bdb4.*]" }
Number Boiler_Rtrn "Rtrn [%.1f]" {mqtt="<[mosq:sensor/multi:state:REGEX(.*RTRN (.{1}\\d*\\.\\d*)):.*840d8e10bdb4.*]" }

So, now I need to do the same on OH3… I can configure the mqtt to get the messages. but the transform from raw messages to items is currently escaping me.

Please show us this - I’m still not clear how you’re configuring in OH3.

I haven’t yet worked out how to configure OH3 in the same way. But from the GUI I can configure an mqtt ‘thing’ that connects to my mqtt server.


And it finds updates… And logs a trigger

events.log:2021-05-04 08:14:14.792 [INFO ] [openhab.event.ChannelTriggeredEvent ] - mqtt:broker:f5e7d39686:mqtt_sensor_temp triggered -1576735667 000336da : humid 57.20 temp 13.50 heat_ind 12.39
events.log:2021-05-04 08:14:18.419 [INFO ] [openhab.event.ChannelTriggeredEvent ] - mqtt:broker:f5e7d39686:mqtt_sensor_temp triggered 3178234 cc50e381bf8c : humid 64.60 temp 14.00 heat_ind 13.14
events.log:2021-05-04 08:14:44.999 [INFO ] [openhab.event.ChannelTriggeredEvent ] - mqtt:broker:f5e7d39686:mqtt_sensor_temp triggered -1546519731 000336da : humid 57.10 temp 13.50 heat_ind 12.39

The channel config on the mqtt binding states that I need to do something in a ‘rule’ (?) to massage these into items. But that’s pretty much where I got lost. As there was nothing obvious about taking an mqtt message and pulling the values from it to update an item…

You’ve shown the configuration for your Broker Thing. Can you show it for your Generic MQTT Thing?

Sounds like it might be worth going over the basics of Thing - Item interaction. There’s now a Getting Started tutorial which might help.

Otherwise, this tutorial goes through the steps of adding an MQTT relay into openHAB 3 using the UI and processing some data from that relay using a Transformation Service - it may help you. If you’re confident that your Broker Thing is setup correctly you could start from step 4.

The conventional approach is to build a Thing & channel hierarchy like -

MQTT Bridge Thing  [details of your broker] {
      // hardly ever use channels directly on Bridge
     generic MQTT Thing {
             // represents some device, say an ESP32 
         channel switch [ mqtt topic , transformation, details ]
         channel number [ mqtt topic , transformation, details ]

     generic MQTT Thing {
              // represents some other device 
         channel number [ mqtt topic , transformation, details ]

I didn’t have a Generic MQTT thing… Now I do…

Question. In the transformation for the Generic MQTT thing… Is the REGEX syntax the same as the OH1 REGEX syntax? e.g.

I’m guessing not, because although the mqtt broker logs the inbound message

2021-05-04 11:38:46.491 [INFO ] [openhab.event.ChannelTriggeredEvent ] - mqtt:broker:f5e7d39686:mqtt_sensor_temp triggered 296 cc50e381b620 : humid 50.55 temp 13.89 press 996.24

There is no update to the item connected to the channel

I’m missing something here… I noticed a comment about the broker not having channels configured. And so removed them. Relying instead on the channels of the MQTT generic thing.

But it would appear that although the broker will subscribe to messages in sensor/temperature and sensor/multi, the Generic MQTT thing does not… I no longer get mqtt messages logged. (This is of course assuming that the Generic MQTT thing will log channel updates in a similar manner to the mqtt broker thing).

If you’ve set it up in the usual way, you won’t. The message you previously saw was about trigger events - something introduced back in OH2 bindings and not generally used a great deal.

A regular non-trigger channel will be linked to an Item. The Item will get updates (which you can monitor by rule if you wanted) and may change (which will appear in your events.log)

Got it…

The syntax for transforms in the GUI is not the same as the syntax used in the items files… Sigh…

Whereas the items takes a syntax such as

mosq:sensor/temperature:state:REGEX(.*temp (.{1}\\d*.\\d*).*):.*cc50e381b620.*

To take that regex and place it into the transform in the GUI it becomes

REGEX:.*cc50e381b620 : .*temp (.{1}\d*.\d*).*

I’m not sure whether the GUI has a separate filter… So I moved that into the REGEX itself. But in addition there’s the REGEX() changing to REGEX: and of course the \d no longer needs to be escaped as \d

Annoyingly the regex still has to match the whole string. Something that the docs imply differently. Because the docs specifically mention the ^ anchor, but if the whole string HAS to match then an explicit ^ isn’t required because it’s implied.

Might I mention the profiles as an aside… Having a profile called ‘default’ that isn’t the default would tend to be somewhat obscure too…

It does not. Nothing to do with GUI or REGEX directly, the OH1 binding offered separate parameters for ‘transformation’ and for ‘filtering’. OH2 binding (as carried forward to OH3) only has transformation.
That’s okay, the OH2/3 binding offers chained transformations to pull off exactly the same trick (and be more flexible in other uses).
Typically users might use a REGEX to select messages containing a magic serial number, then if found chain on another transform to select a data field -usually by JSONPATH, but if want to use another REGEX of course you can.

Yes, REGEX transformation service is unchanged.

Profile ID Type Supported Item Types Description
default State All If you don’t specify any Profile, this Profile will be used. For State Channels, this means that states and commands are just propagated from the Channel to the Item and vice versa without any changes. For Trigger Channels, the Default Profile won’t change anything on the Item.

(Emphasis added by me) That sure sounds like the default Profile is in fact the default. What gives you the impression that it isn’t the default?

Beyond that, what rossko57 said. REGEX hasn’t changed it’s behavior since OH 1 and now if I recall correctly and definitely hasn’t changed since OH 2.5.0 to now.

I think the GUI offers both ‘none’ and ‘default’ as profiles.

1 Like

Issued filed.

You’re right. It does… but it then defaults to ‘none’ instead of ‘default’. It caught me for a while there as the updates don’t appear to happen when it’s ‘none’.

FWIW, a diagram of how the MQTT support fits together would be nice… I admit I’m a bit of a visual person. And I need to understand something end-2-end before I can be confident of what I’m doing.

Now that I know how it’s supposed to be configured, I went back and tried to read the MQTT binding doc again and see if it made sense. It didn’t…

Reading MQTT - Bindings | openHAB gave me no sense that what I now know to configure matched the doc. And following MQTT Things and Channels - Bindings | openHAB didn’t raise much recognition either.

I’d type in some docs myself, but I think I’ll ask where it should go first. Rather than just blindly destroying someone else’s work that I don’t fully understand.