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.
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.
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
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.
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…
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)
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.
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.
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.
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…
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.
