OH2.5 Some MQTT Topics never get a valid value though they are updated regularly in the broker

Setup, Configuration and Use Beginners
1

Hi everyone,

Iam running OH2.5.12 on a raspi Pi3 with mosquitto installed on the same device.

Connected to mosquitto is also a lawn mower (Robonect).

  • OH is successfully connected to mosquitto as well as robonect.
  • via MQTT Explorer I can verify that all topics of robonect are available with valid values and updated frequently.

In OH I configured the following thing:

Thing mqtt:topic:greenkeeper "Aussen_Garten_Maehroboter" (mqtt:broker:mqtt_ob) {
        Channels:
                // ### Battery
                Type number : battery   "Batterieladezustand"   [ stateTopic="greenkeeper/mower/battery/charge"]
                // ### WLAN
                Type string : wlan      "WLAN Signal"   [ stateTopic="greenkeeper/wlan/rssi"]
}

The items are configured as following:

String  Aussen_Garten_Maehroboter_WlanSignal      "WLAN Signal [%d dB ]" <qualityofservice>     {channel="mqtt:topic:greenkeeper:wlan"}
Number  Aussen_Garten_Maehroboter_Battery         "Batterie [%d %%]" <battery>                {channel="mqtt:topic:greenkeeper:battery"}

For some reason “Battery” gets updated without problems but “Wlan” never ever got any value though the topic is updated regularly.
This is just an excerpt, I have about 15 more channels where I can see the same issue. 10 show correct values the other 5 just stay undefined for ever.

OH and Mosquitto logs show no errors at all.

Any ideas on that ?

Thx for the help in advance.

2

None of the Things you have shown us are called greenkeeper

3

Yes, you are right, my bad. It wanted at first to anonymize this post here but did decide otherwise in the middle.
I corrected that - in the original thing config be assured the thing is called greenkeeper :wink:

4

hmm, “I will hide any typos and maybe introduce some new ones” is not helping yourself.

To flesh out a bit, you have multiple brokers?
There’s more than one way to refer to a channel.
{channel="mqtt:topic:greenkeeper:wlan"}
Your topic Thing greenkeeper may or may not be unique. I think use of xxx.things files may let you create another one linked to a different broker (pretty sure UI would object, but files are less rigidly validated). You may not have done that deliberately, but funny ghosts can get left over from editing.

The point is that you can be more specific
{channel="mqtt:topic:mqtt_ob:greenkeeper:wlan"}
which I would be inclined to do for my own sanity in a multi-broker setup.
Remembering that file edits are not always neatly picked up by bindings, advise a binding restart too.

May we see an MQTT message that is being ignored?

5

To flesh out a bit, you have multiple brokers?

No, I have only one broker called mqtt_ob which was created through the UI.

Your topic Thing greenkeeper may or may not be unique. I think use of xxx.things files may let you create another one linked to a different broker (pretty sure UI would object, but files are less rigidly validated). You may not have done that deliberately, but funny ghosts can get left over from editing.

Except bridges all objects (things, items) are only created by files never through the UI.

The point is that you can be more specific
{channel="mqtt:topic:mqtt_ob:greenkeeper:wlan"}
which I would be inclined to do for my own sanity in a multi-broker setup.

I do not have an multibroker setup, however you gave me an idea… I just created a new generic thing through the UI, added the wlan channel by the UI and linked a newly created thing also by the UI with it.
Result is that the item still shows “NaN”.

So by setting up everything through the UI I ruled out any typos or miss configuration in files.

May we see an MQTT message that is being ignored?

You may.
This is taken from the initial subscription after a OH restart where home.ob is the client id used by OH:

25679869: Received SUBSCRIBE from home.ob
1625679869: greenkeeper/wlan/rssi (QoS 1)
1625679869: home.ob 1 greenkeeper/wlan/rssi
1625679869: Sending SUBACK to home.ob
1625679869: Sending PUBLISH to home.ob (d0, q0, r1, m0, ‘greenkeeper/wlan/rssi’, … (7 bytes))
1625679869: Received SUBSCRIBE from home.ob

And here is the received update of the topic:

1625680223: Received PUBLISH from ROBONECT8BC15F (d0, q0, r1, m0, ‘greenkeeper/wlan/rssi’, … (7 bytes))
1625680223: Sending PUBLISH to home.ob (d0, q0, r0, m0, ‘greenkeeper/wlan/rssi’, … (7 bytes))

6

Perhaps if you use some other tool, we can see the payload too?

7

Sure. By subscribing with mosquitto_sub it shows the payload with “-80 dBm”.

8

I wonder if it is struggling with the leading hyphen, would not expect that to be an issue with a string type channel though.

Put the binding in DEBUG log mode, see if it is (a) getting the topic (b) what it does with the payload.
Reminder that after editing Things, be sure to restart the binding package at least.

9

Can you share your entire Things file, and tell us which of the Channels remain undefined?

10

@rossko57
@hafniumzinc

Thank you. Both of you gave me the right clues for the solution.

First of all looking at the working channels I saw that they almost all are of type string.
Looking into the MQTT client config of the mower I saw that there is an option enabled by default to add units with all published values.
e.g. -80 dBm, 30.0°C, 40%, 3.3V.

Well, obviously openhab does not want to convert 30.0°C or 3.3V into a number.
After changing all relevant channels to type string the values showed up.
The other way round, after disabling the feature to add units automatically, the values also showed up as number.

However, there is one exception:
The humidity value of 40% got converted to a number WITH unit just fine.

11

But … the wlan channel you said failed was of type string, the battery channel that works was of type number?

Number:Dimensionless types (as used with %) are a bit special, where absence of unit is uniquely considered to be a valid unit.

12

Correct, the wlan channel is of type string and failed to display the mqtt message with “-80 dBm”. However when I put away the unit it suddenly displayed the “-80” correctly; After turning units on again it somehow showed “-80 dBm” as well.

In fact, that I cannot explain…