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 
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 2Adding the postCommand option did not help
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:
Result in MQTT Explorer:
Changing Grablicht in openHAB Sitemap
Result in MQTT Explorer:
Now going the other way, publishing from MQTT Explorer:
Result in sitemap:
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.
I stopped upgrading, because with every update something new broke. The need to reboot the CCU came with an openHAB update, also that the say command doesn’t work anymore with special chars, and that mails only get send random. I’m more interested in getting it reliable, thought already about a downgrade.
I can understand that. But it comes with the consequence that you don’t receive bug fixes. What you’re experiencing might be a bug which has been fixed in a later release.
A complete restart has fixed the Problem. Data is now send. Its not complete nice, because it sends the integer as a float. But my device is at this point fault tolerant and converts it back to int.
When it Stopsley working again (possibly when you edit something) set the log to debug for mqtt and transport. When you change the item state do you see it in the debug (says something like successfully published message blah) but it’s not appearing at mosquito?
It’s an issue I’m struggling with.