Sending Data via MQTT is not working

I want to send an receive data via MQTT. Receiving works fine, but sending don’t work at all. My Sitemap Item gets changed if I send Data with another device to that channel, but changing it in openHAB doesn’t send new data back. There are no erros or warnings in the log.

things file:

Bridge mqtt:broker:mosquitto [ host="192.168.3.5" ]{
Thing topic findus {
        Channels:
            Type number : findusLight "Grab beleuchtung" [ commandTopic="/backyard/findusGrab/lightMode", stateTopic="/backyard/findusGrab/lightMode" ]
    }
}

items file:

Number iFindusGrabLicht "Grablicht" <light> (GF_BackYard) { channel="mqtt:topic:mosquitto:findus:findusLight" }

Sitemap

Selection item=iFindusGrabLicht mappings=[0="Aus", 1="An", 2="Gedenktag", 3="Weihnachtsbeleuchtung"]
  • Platform information:
    • Hardware: PC Engines APU2
    • OS: Debian 9
    • Java Runtime Environment: OpenJDK 1.8
    • openHAB version: 2.5.3 / binding-mqtt - 2.5.3
    • MQTT Broker: mosquitto 3.1

Two possible options:

  1. Have you tried restarting openHAB?
  2. Are you sure you want your topic to be /backyard/findusGrab/lightMode? Topics often don’t usually start with /, so I would also try backyard/findusGrab/lightMode

What is the other device that you have used to send data which worked, and can you show us the Mosquitto log when it works, and when it doesn’t?

That’s generally a nonsense set up, identical “send” and “receive” topics. It’ll be just as nonsense at your remote device too - perhaps you have misunderstood the topics it is using?

What is wrong with it? How would I otherwise display the current state?
The Topic is used by an ESP32

const char *mqttTopicLightMode = "/backyard/findusGrab/lightMode";
PubSubClient mqttClient(mqttServer, 1883, getMqttData, espClient);
mqttClient.subscribe(mqttTopicLightMode);


void getMqttData(char* topic, byte* payload, unsigned int length) {
    ...
    payloadString = (char*)payload;
    sscanf(payloadString, "%d", &nextLightMode);
    updateLights();
}

Topics are one-way communications. Someone publishes on a topic, someone else(s) listens to it. If you subscribe to the same topic that you publish to, you disappear up your own backside. It’s not a complete disaster, but no sensible setup does it that way.
More normal usage is like -
somedevice/sometopic/SwitchA/command
somedevice/sometopic/SwitchA/status
where a remote device listens for command, and sends out state. The openHAB end listens to state, and sends out command.

But even if I remove the stateTopic in the openHab configuration, the command is not send :frowning:

How do you know, are you using an MQTT monitor? May we see what you see? What command? Are you actually sending commands to your Item? (Your events.log will confirm that)

{ channel="mqtt:topic:mosquitto:findus:findusLight" }

If you use PaperUI to inspect your topic Thing and see what its channel(s) are called, you can find what should go in there.

Don’t forget when you are editing things files, changes are not always implemented immediately and you have to restart the bundle.

I use the Android App “MQTT Snooper”. There I can send Command to a Topic, and then I see that my ESP32 reacts to them with changing the LED Stripes. And I can also see there the Sensor Data I publish via MQTT. The Sensor Data is also visible in openHAB. And If I have the stateTopic configured, the Item in openHAB also changes when I send a command with the MQTT Snooper.
But if I try to send a command with openHAB, I see absolute nothing. No log entries, nothing in the MQTT Snooper and nothing on the ESP32.

None? If your UI sends a command to a non-existent Item, you will see an error in your openhab.log. If your UI sends a command to a valid Item, you will see an entry in your events.log. If you see neither of those, your UI is blocked off from openhab or talking to the wrong port or something.

Nothing MQTT related

18:48:03.895 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'iFindusGrabLicht' received command 2
18:48:03.908 [INFO ] [arthome.event.ItemStatePredictedEvent] - iFindusGrabLicht predicted to become 2
18:48:03.924 [INFO ] [smarthome.event.ItemStateChangedEvent] - iFindusGrabLicht changed from 0 to 2

Did you try to set the is Command to true for this thing?

Read This

Adding the postCommand option did not help :frowning:

That’s only about incoming messages, not related to outbound at all.

Have you restarted the MQTT package after doing these edits?

hmm, well it does show that a command arrives at your Item. This is an important step towards narrowing down where the problem lies; you want help, don’t make it difficult.

Have you looked in your openhab.log to see that get a successful broker connection?

I’ve replicated your configuration on my setup and, whilst it’s definitely unconventional to use the same state and command topics, it does of course work.

You are of course free to ignore my suggestions from #2, but I really would look at re-starting openHAB (as @rossko57 has suggested a couple of times now too, when stating to re-start the MQTT binding), and also double check your leading / on your topic: it’s also unconventional.

Here’s it working for me:
image

Result in MQTT Explorer:
image

Changing Grablicht in openHAB Sitemap

image

Result in MQTT Explorer:
image

Now going the other way, publishing from MQTT Explorer:

image

Result in sitemap:
image


For completeness, here is the configuration that I used to test, as I use a separate broker file:

bridge.things

Bridge mqtt:broker:MosquittoMqttBroker "Mosquitto MQTT Broker" [
	host="192.168.1.92",
	secure=false,
	port=1883,
	clientID="OpenHAB2",
	username="",
	password=""
]

test.things

Thing mqtt:topic:findus (mqtt:broker:MosquittoMqttBroker) {
    Channels:
        Type number : findusLight "Grab beleuchtung" [ 
            commandTopic="/backyard/findusGrab/lightMode", 
            stateTopic="/backyard/findusGrab/lightMode"
        ]
}

test.items

Number iFindusGrabLicht "Grablicht" { channel="mqtt:topic:findus:findusLight" }

sitemap

Selection item=iFindusGrabLicht mappings=[0="Aus", 1="An", 2="Gedenktag", 3="Weihnachtsbeleuchtung"]

I will try a restart tomorrow. Restarting is always a mess with the homematic binding. I have then to restart the CCU2 a couple of times until all homematic items will work again.
But I see in the log that it reloads the file if I modify it.

20:44:24.894 [INFO ] [del.core.internal.ModelRepositoryImpl] - Refreshing model ‘mqtt.things’

the log I showed 2h ago is everything that happens when I update the item state. Receiving Data is working fine, and never needed a restart.

removing the stateTopic has no effect

the / is part of the topic, to remove it i would need to disassemble my hardware an reflash the ESP.

You can restart the binding too (as Rossko mentioned), rather than the whole of openHAB:

Or, what I do - deliberately corrupt or malform your things file (remove a { for example), save it, watch as openHAB complains in the logs and unloads your thing, then fix the things file and resave.

1 Like

I made bundle:restart 293 and bundle:restart 296 (MQTT Things & MQTT Transport). But still not working.

That’s a shame. Seems mysterious, especially as it works for me.

Sorry to bang on about this, but I would personally fix this. See Best practices on this page:

Never use a leading forward slash
A leading forward slash is permitted in MQTT. For example, /myhome/groundfloor/livingroom. However, the leading forward slash introduces an unnecessary topic level with a zero character at the front. The zero does not provide any benefit and often leads to confusion.

I still wonder whether it’s confusing one or other MQTT library in your chain.

You’re also on an old-ish version of openHAB, and the MQTT binding. Definitely upgrade as part of your troubleshooting!

if it confuses anyone, then openhab, because it works with the android app I mentioned.

An older openHAB. As I said, it works for me, and I’m on 2.5.10 - it’d be worth upgrading.