[SOLVED] New MQTT 2.4 - incoming State works, incoming Command does not

[mcqwerty]

I have a switch type channel defined on a MQTT thing. I have both stateTopic and commandTopic defined. When I use an MQTT client (MQTT.fx) to post a message on the state topic, the item bound to the channel on the thing reacts appropriately. When I post a message to the command topic it does not react at all.

.things file:

Bridge mqtt:broker:mqttBroker [ host="192.168.x.x", secure=false ]
{
	Thing topic mqttTest "mqttTest" {
		Channels:
			Type switch : mqttSwitch "MQTTSwitch" [ stateTopic="MQTTSwitch/State", commandTopic="MQTTSwitch/Command" ]
	}
}

.items file:

Switch mqttSwitch "switch" {channel='mqtt:topic:mqttBroker:mqttTest:mqttSwitch'}

When publishing 1 to topic MQTTSwitch/State events.log shows

[vent.ItemStateChangedEvent] - mqttSwitch changed from OFF to ON

When publishing 1 to topic MQTTSwitch/Command
Nothing appears in the logs.

When commanding the switch item via Basic UI I see a message in MQTT.fx of 0 or 1 under the topic MQTTSwitch/Command

I have tried this on version 2.4 release and also on the latest 2.5 snapshot, same behaviors in both.
I have tried restarting multiple times but nothing seems to work.

This seems like a pretty fundamental problem so I’m assuming I have done something wrong, but what?

[David_Graeff]

@mcqwerty

This seems like a pretty fundamental problem so I’m assuming I have done something wrong, but what?

Not reading the documentation and not being familiar with MQTT conventions.

It might help if I use other words instead (although the current ones are standard within the MQTT community):

stateTopic = incomingTopic
commandTopic = outgoingTopic.

Hopefully that helps.

Cheers, David

[mcqwerty]

Ok, so if I understand you correctly, only state updates are communicated TO the MQTT server and only command updates are read FROM the MQTT server?

If this is that case, how do I link two instances of OH via MQTT if I wish to be able to command a remote item when the local item is commanded?
Actually, then this means that it is not possible to link two instances using MQTT at all since the source will only publish to the state topic and the consumer will only listen to the command topic…

[David_Graeff]

@mcqwerty

Ok, so if I understand you correctly, only state updates are communicated TO the MQTT server and only command updates are read FROM the MQTT server?

Other way round. See documentation. I have written from the perspective of openHAB of course, not the MQTT broker.

@mcqwerty

If this is that case, how do I link two instances of OH via MQTT

Use mqtt1 and the eventbus binding. That is for now the fastest way. There will be a modern OH-link-service available at some time, it’s on my agenda.

[mcqwerty]

@David_Graeff

Use mqtt1 and the eventbus binding. That is for now the fastest way. There will be a modern OH-link-service available at some time,

I should have asked this question a few days earlier before I got so deep into it but thanks for letting me know.
Any rough ETA? I would really like to dump the v1 binding and go all on you new binding.

[David_Graeff]

@mcqwerty

I would really like to dump the v1 binding and go all on you new binding.

I appreciate that. There should be no need for OH1 bindings anymore at some point hopefully.

I mean, you can go with MQTT2 as well (see: https://github.com/openhab/openhab2-addons/tree/master/addons/binding/org.openhab.binding.mqtt.generic#synchronise-two-instances), it is just a bit more work and will not work reliable in OH 2.4 (you must be on OH 2.5M1 at least).

@mcqwerty

ETA

I’m a bit busy with the new Paper UI design study (https://davidgraeff.github.io/paperui-ng/) and all related missing core features. On my personal agenda it has a very low priority so ETA is about half a year to a year. Maybe someone else jumps in in the mean time.

[mcqwerty]

@David_Graeff

you can go with MQTT2 as well

This makes sense and it’s the route I will probably take. May wait for 2.5 to mature a bit first though before I install it on my main system.

p.s. The Paper UI update looks slick. Nice!

[metin]

@David_Graeff

I mean, you can go with MQTT2 as well (see: https://github.com/openhab/openhab2-addons/tree/master/addons/binding/org.openhab.binding.mqtt.generic#synchronise-two-instances ), it is just a bit more work and will not work reliable in OH 2.4 (you must be on OH 2.5M1 at least).

I’ve taken a closer look at the proposed solution, and I have a questions regarding this rule:

rule "Publish all"
when 
      Channel "mqtt:broker:myUnsecureBroker:myTriggerChannel" triggered
then
   // TODO
end

Your docs say

The event payload will be the received MQTT topic value.

How can I access the event payload from within the above rule? Does “MQTT topic value” mean the published topic (like /generic/itemname/status/value) or just the value of the topic?

[metin]

@metin

How can I access the event payload from within the above rule? Does “MQTT topic value” mean the published topic (like /generic/itemname/status/value) or just the value of the topic?

@David_Graeff, never mind, I’ve found that receivedItem contains both, topic and value (like so: /generic/itemname/status#VALUE).

While this may be considered obvious, I’d propose to add this info to the docs.

[David_Graeff]

@metin

While this may be considered obvious, I’d propose to add this info to the docs.

It is part of the channel description (xml file).

This is at the moment only rendered by Paper UI, but there is an open Issue on the website/docs repository to automatically generate available Things / Channel descriptions via those xml files. A developer has to repeat himself 3 times right now and often the documentation is not in sync with the xml files or the java code.

[metin]

@David_Graeff

A developer has to repeat himself 3 times right now and often the documentation is not in sync with the xml files or the java code.

I understand the problem. However, I’ve proposed a small change on the doc page for the time being.

I’d also like to see some of the details there that have posted in the forum and are very helpful (like those from this thread). Does it make sense to add them to the docs page? I must admit, I sometimes feel a bit lost in the docs, not finding infos in the binding docs, then later discovering that they are somewhere else.

[David_Graeff]

@metin

I sometimes feel a bit lost in the docs, not finding infos in the binding docs, then later discovering that they are somewhere else.

That’s also part of the discussion on the mentioned Issue (Generate add-on installation instructions · Issue #152 · openhab/website · GitHub). The question is how much should be added to individual binding docs, because many people only ever go the binding docs and not the general ones.

Rule of thumb: If you feel that the information is mostly relevant for MQTT, then please go ahead and create a PR. Consider this note though: People complained that the MQTT doc doesn’t provide enough information. The MQTT Generic doc has now dozen of examples, migration sections etc pp and is about 10 printed pages long. People now complain that it is not concise enough. Keeping this balance is really hard.