MQTT v2.5.5 - how to publish values from openhab to other clients?

Setup, Configuration and Use Beginners
1

Hello everyone,

I’ve been using MQTT v2.5.5 for a while now to get data/values INTO openhab, which works perfectly. So the MQTT configuration itself (mosquitto as broker, binding, thing, channels) should not be the issue. I now want to get the state of an item OUT OF openhab, for which I want to publish the value to the broker (running on localhost) and have other clients subscribe to that topic.

For testing purposes I defined the channel as “read”, meaning in PaperUI I put the topic in the channel’s MQTT State Topic. Submitting a publish to that channel from the external client using mosquitto_pub shows up in openhab and the item gets updated. This is the item definition:

Number item1 {channel="mqtt:topic:344c69dc:item1"}

So far, so good. Now I tried entering the topic in the channel’s MQTT Command Topic, checking the “Is Command” box, and update the item’s state from within openhab with a rule. My expectation is that this should then push the value out to the MQTT channel, but it doesn’t.

My (rather simple rule) is:

when
Item item2 received update
then
item1.sendCommand(item2.state)

Item2 is an openhab item that gets updated from within openhab, and item1 is linked to the MQTT channel as above. Now when item2 receives an update, the state of item1 changes accordingly, but nothing else happens.

I found actions from (presumably) the older v1 MQTT binding:

val mqttActions = getActions("mqtt","mqtt:broker:87c4e9b7")
mqttActions.publishMQTT("/broker/topic", "message")

but that only works with “message” verbatim, if I try to replace that with item2.state, I get a javascript error, so that is probably not the way to go. BTW, 87c4e9b7 is the MQTT bridge, and 344c69dc is the generic MQTT thing that contains the channels.

Any insights?

Thanks!

2

Yeah, pretty sure v1 commands are not going to work with v2.

Looking briefly at (v2 / current) MQTT binding sure doesn’t look like it says anything about sending out, either. Interesting.

I use MQTT also, but have not needed to push anything out yet, either.

There is probably a better (built-in?) way, however in the meantime you could maybe do it on the command line with exec binding and mosquitto-sub or similar?

3

The publishMQTT action is not V1 specific, and should work fine for this case.

It expects a string, so item2.state won’t work as that isn’t a string. Try item2.state.toString instead of “message” in publishMQTT.

4

Thanks, everyone!

Using a string, the publishMQTT action works, I’ll go see if I can get it to string and retain it at the same time. The “remote” party will call mosquitto_sub from a script at different times, so the value needs to be retained in the broker.

Still, I really would have thought that the v2 binding would be able to be configured to send to a topic on a state change. I don’t have any of those, but I know there are all kinds of smart devices out there talking MQTT who would need commands/values posted to them this way. So it would be very convenient to just act on an updated item instead of needing a rule with actions.

5

IMHO, the way you made it work so far is the intended way. Use a rule that triggers on a change and send the desired message.

6

Yes, that’s how I’ll try it tonight:

mqttActions.publishMQTT("/broker/topic", item2.state.toString, "true")

That should work with retention, I hope.

7

If Item 1 is linked to an MQTT channel with commandTopic specified … it will publish the command (after transformation, if you wish)

Beware in rules that state object is not always acceptable as command object. That trips everyone up -
someSwitch.sendCommand(otherSwitch.state)
WILL fail.
Circumvention, a string is always parsed
someSwitch.sendCommand(otherSwitch.state.toString)

8

Thanks!

I have linked the item1 to a MQTT channel with the command topic specified (via PaperUI). I will try to use “state.toString” and see if it works then. I didn’t expect “state” to fail as that MQTT channel is defined as “Number”, and not “String”.
But as that channel is send-only, with the mqttAction I should be able to avoid using the proxy item1 at all.

9

It’s up to you. Managing in future may be easier if all your topics are defined in Things instead of scattered amongst rules. Items are free of charge, and also give a convenient store for “what the heck did I last send?”.

10

As many probably do, I use the database/PaperUI for Things (mainly because of autodetection) but manually assign Items to those Things using configuration files. I’d rather struggle having all the items in the GUI. Items are grouped in separate item files, with the corresponding rule files having the same name.

As it is now, having the proxy item linked to the MQTT-Channel with the command topic defined is not helping as the command does not get sent out. The alternative to my mqtt.Action would be using the exec binding to run the publisher externally, but I don’t see the benefit here.

11

Then there is something wrong. Fix it, or not. If you want help with fixing it, we can help.

12

I just found the problem after fiddling around with the debug logs.

Sending “state” or even “state.toString” contained the item’s value and unit, and with the unit it did not qualify as a number for MQTT.

So as a solution I defined a variable stripping the unit from the value and updated the proxy item with that. And that worked (but took me a while to figure out):

var Number temp = (item2.state as QuantityType<Number>).doubleValue
item1.sendCommand(tempwind2)

Maybe this thread helps someone in the future trying the same thing.
One might be able to configure this in the “Outgoing Value Format” or “Outgoing Value Transformations” in PaperUI, but I’m not sure.