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
Hi
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.
e.g.
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.
Wahh!
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 defaultState 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.
You can’t blindly destroy anything in the docs so don’t worry too much about that. All changes need to be reviewed by and accepted by a maintainer including changes to doc. You’d need to create a PR on the openhab/openhab-addons GitHub repo. The docs for each binding comes from that binding’s README.MD file. Clicking on the link at the very bottom of the page in the docs “Edit this page in GitHub” (or something like that) will take you right to the file that needs to be changed.
See How to file an Issue and [Wiki] How to contribute to the openHAB Documentation for lots of details on creating such a PR.
Also take note that MQTT is one of the examples used in the OH 3 Getting Started tutorial. Adding Things - Advanced | openHAB
But it’s also worth noting that how the parts of MQTT “fit together” are not unique to MQTT. The whole bridge Thing with sub-Things that communicate through the bridge is a standard approach for many/most OH 2/3 bindings. So you might consider that if any changes are to be made, they be made in the Concepts section of the main docs and not buried inside the docs for only one binding.
1 Like