Regex Mosquitto

Setup, Configuration and Use Items & Sitemaps
,
1

Hi All,

I’ve been directed here from the google Groups.

This might be a very newbie question but I’m struggling with the REGEX on Mosquitto Bindings.

Example:

Number temp1 “Wired Temperature 3 [%.1f C]” (MainSpace) {mqtt="<[mymosquitto:temp:state:REGEX(aTATMPA(.))] " }
Number temp2 “Wired Temperature 3 [%.1f C]” (MainSpace) {mqtt="<[mymosquitto:temp:state:REGEX(aTBTMPA(.))] " }

I’m sending a command similar to this aTBTMPA22.00 and aTATMPA21.00 where TB or TA is the address of the sensor and 22.00 or 21.00 is temp.

The transform works for sensor in question but also passes the other through. So for temp1 I get 21.00 and aTBTMPA22.00. I just want 21.00!!

This is driving me mad! :slight_smile:

T

2

My experience is primarily with JavaScript but I think the concept is the same. When you do REGEX matching like this, you actually get an array of two results, the entire line of text that matches the REGEX and the part in the parentheses. To reference just the 21.00 you would need to access just the desired result. In JavaScript your REGEX would read: REGEX(aTATMPA(.*)[1]).

You may need to experiment some but I hope this points you in the right direction.

Rich

3

Hi Richard,

Many thanks for your response. I’ve tried adding the [1] after the capture group but to no avail.

What seems to be happening is that the Regex is working on the first command it receives (aTATMPA21.00). Then when the second arrives it decides that it doesn’t meet the Regex command so simply passes the whole message through.

For example if I change the Regex command to REGEX(x) then this should only pass through a message with the letter z in it right? But in my case if I run that command then both messages pass through in their entirety.

Why is it that a message that doesn’t meet the Regex command is passing through to write to the item?

Thanks again for you help.

T

4

The REGEX Pattern implementation has an implied ^ at the beginning of the specified pattern, and a $ at the end.

So when you specify a pattern of:

aTBTMPA(.*)

it’s internally transformed to this pattern:

^aTBTMPA(.*)$

Depending upon line delimiters for the incoming data, this can cause problems. From the text above, I can’t tell if the values being sent are all on one line, or come in as separate, line delimited, values.

Can you clarify?

Also, depending upon how clean the data stream is you may need to change the (.*) capture to something tighter like (.+) or even ([0-9]+\.?[0-9]*) to avoid potential data corruptions entering the system.

5

Hi Mark,

Thanks for your help. I’ve been looking at the data coming in to OpenHab over mosquitto and it seems they are coming in as separate messages. As you can see in the following image. When subscribing to the topic I get these messages.

Then once it’s gone through this regex.

{mqtt="<[mymosquitto:temp:state:REGEX(aTBTMPA(.+))]" }

The TB message gets changed to 21.25 but the TA message comes through through. What am I doing wrong???

Thanks :smile:
T

6

Like this.

7

Can you provide the snippet of events.log so I can see what’s being put into the Item itself?

You can also switch to using the debug log config, logback_debug.xml, and that’ll give you a lot more detail about what the transformation is doing with your data (in your openhab.log file)

8

Hi,

Thanks for your response. I posted the event log in my second post from earlier. Can you see that image?

Also I’ve looked see if I can enable debug logging and there seems to be some issues.

According to this page. https://github.com/openhab/openhab/wiki/Configuring-the-openHAB-runtime

I should have the follow folders and files.

/etc/openhab/logback.xml 
/etc/openhab
/var/log/openhab/openhab.log
/var/lib/openhab

These are all missing! However, my OpenHab runtime seems to work fine… apart from this Regex problem…

T

9

Depending upon how you installed, the log files aren’t always in those directories.

You can do a “jumbo” find command to locate where they’re really at using something like:

    sudo find / -name logback.xml -print

I somehow missed the second image earlier. I was looking for something in text, not as an image, so must have glossed over the second image.

10

Ok, so I wrote a little test Rule to try out what the REGEX is doing behind the scenes.

The example looks like this, it’s performing the same basic REGEX Transform, but via a Rule instead of being attached directly to an Item.

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

rule "REGEX Test"
  when
    Time cron "0/10 * * * * ?"
  then
    val VAL1 = 'aTBTMPA21.25'
    val VAL2 = 'aTATMPA21.06'

    logInfo("regex", 'VAL1: ' + transform("REGEX", "aTBTMPA(.+)", VAL1))
    logInfo("regex", 'VAL2: ' + transform("REGEX", "aTBTMPA(.+)", VAL2))
end

and the DEBUG-enabled output in openhab.log is:

10:13:00.425 DEBUG o.o.m.r.i.e.ExecuteRuleJob[:53]- Executing scheduled rule 'REGEX Test'
10:13:00.429 DEBUG o.o.c.t.i.s.RegExTransformationService[:42]- about to transform 'aTBTMPA21.25' by the function 'aTBTMPA(.+)'
10:13:00.432 INFO  org.openhab.model.script.regex[:53]- VAL1: 21.25
10:13:00.436 DEBUG o.o.c.t.i.s.RegExTransformationService[:42]- about to transform 'aTATMPA21.06' by the function 'aTBTMPA(.+)'
10:13:00.438 DEBUG o.o.c.t.i.s.RegExTransformationService[:48]- the given regex '^aTBTMPA(.+)$' doesn't match the given content 'aTATMPA21.06' -> couldn't compute transformation
10:13:00.440 INFO  org.openhab.model.script.regex[:53]- VAL2: aTATMPA21.06

'now it becomes a little clearer… so I read the source code, so the observed behavior now makes a lot more sense.

Basically, if the REGEX Pattern doesn’t match anything form the incoming data, the return the original source string.

In your case, the pattern matches one of the values it’s presented, so it correctly extracts the Temperature. In the other case, it matches nothing, so the original/unmodified string is returned by the transform.

Probably not the behavior you’re looking for…

Technically, because you’ve declared your temp1 and temp2 Items as Number, the values shouldn’t make it much past the Transform, but your events.log will be full of crud, and your openhab.log probably has a bunch of failed conversion errors type in it when attempts to convert the bad String values to Number values occur.

If you want more control, you can write a Rule to do it. In this case, have a new Item that’s bound to the MQTT State, and then then parse it apart in a Rule instead (using conditional calls to place the value into the correct Item once parsed out)

11

Hi Mark,

Thanks for your help on this so far. I’ve managed to replicate this in my own debug log. I think you are right. Openhab’s transformation only strips out required value if it matches the required Regex, otherwise it just passes the full string.

I’m going to look more into separate transformation script as you mention although ideally I wanted to avoid this.

Thanks

T