Generic MQTT thing - multivalue topic with optional values

Setup, Configuration and Use Items & Sitemaps
1

OH 3.4.5 / Debian

I have a Generic MQTT Thing (configured via text due to the number of channels) that has a common topic (/weather-east/loop) that is published with a JSON object containing the individual values (i.e., “JSONPATH:$.windDir”).

/weather-east/loop {"monthET": "0.0", "barometer_inHg": "29.608",  ... }

		Type number : windDirection  "Wind Direction" [
			stateTopic = "/weather-east/loop",
			transformationPattern = "JSONPATH:$.windDir",
			unit = "Degree"

If some of the values are missing (i.e., wind direction is omitted if the wind speed is zero), a message is logged.

 [WARN ] [t.generic.ChannelStateTransformation] - Executing the JSONPATH-transformation failed: Invalid path '$.windDir' in {JSON object}

I realize these messages aren’t a functional problem … the channels with values in the message get updated, but the “not there” messages clutter up the log, especially like tonight when most of the values are missing because of a battery failure…
I’d love to have a way to make these silently ignored. I could probably write a regex that returns NULL if the value isn’t there, but I don’t want to post NULL to the channel – I’d prefer that updated only happen when the value is present.

I’ve been putting off upgrading to 4.x; if there’s a better solution there, it would add some incentive.

2

You can solve this issue by combining two transformation services:

Type number : windDirection  "Wind Direction" [
			stateTopic = "/weather-east/loop",
			transformationPattern = "REGEX:(.*windDir.*)∩JSONPATH:$.windDir",
			unit = "Degree"

So the first transformation, REGEX will let pass only strings (the JSON object) if it contains “windDir” as part of the string. The ∩ sign is “Intersection”.

2 Likes
3

I am running OH version 4.x and I use mqtt to read data from my anemometer. I have set up a generic mqtt thing and have added a channel (linked to an item) for each specific data field from the anemometer.

For example, my anemometer mqtt topic is: “sensors/anemometer/” with data fields as follows:

battery: “sensors/anemometer/battery”
wind speed: “sensors/anemometer/windspeed”
wind direction: “sensors/anemometer/windspeed”

…and so on.

I add a channel to the generic thing for each of the data fields using the data field sub-topics; for example the channel for battery has the following entered as the MQTT State Topic in channel configuration: “sensors/anemometer/battery”

I have done this from the Main GUI.

If one of the data fields is missing as per your example, OpenHab wouldn’t know about it and there would be no error as each channel update works independently.

The mqtt / OH interface works really well for my needs. Data is acquired every 5 seconds for the anemometer, 24 x 7. I am also acquiring data using this same method for many other weather sensors. It is very reliable.

Hope this helps.

4

Now that @Udo_Hartmann 's approach has been around since OH 2 so this alone is not a reason to or not to upgrade.

1 Like
5

I have this option with my weather station, but was hoping to stay with the all-in-one message to reduce mqtt clutter; there are about 40 values reported every minute and it’s a lot to scroll thru when debugging mqtt reports from some other sensor that reports less frequently.

6

Thanks, I’ll give this a try. It’s windy today, so it may take a while to find out how it works.

1 Like