This is my .items: Switch doorbell "Switch 1" (all) {mqtt=">[octopus:openhab/doorbell:command:on:default],>octopus:openhab/doorbell:state:*:default],>octopus:openhab/doorbell:command:off:default]"}
This is my .cfg:
mqtt:octopus.url=tcp://:1883
Now, if I well understood, the item should publish outbound MQTT packet when state change. So, if a merely did: curl --header "Content-Type: text/plain" --request PUT --data "ON" http://localhost:8080/rest/items/doorbell/state
the item doorbel shall publish an outbound message, shouldn’t it?
I see the state change in openhab logs
2016-07-25 16:12:22.383 [INFO ] [runtime.busevents ] - doorbell state updated to ON
2016-07-25 16:12:24.527 [INFO ] [runtime.busevents ] - doorbell state updated to OFF
but no mqtt message has been receiving at the broker. By using another chanell (e.g. mosquitto), If I subscribe to the openhab/doorbel channel nothing is reveived.
As broker, I used mosca with username/password authentication.
In the examples on the binding wiki page, the “on” and “off” should be uppercase (i.e. ON, and OFF).
I also notice you are missing the “[” on the second and third bindings.
Did you intend the “state:*:default” to be incoming (i.e. messages published on openhab/doorbell changes the state of the doorbell Switch)? If so the direction is wrong, it should be “<”.
Finally, you might need to use “autoupdate=false” to prevent the incoming messages from causing a new command being published back to the topic resulting in a loop.
There likely were some errors printed to the logs complaining about not being able to parse the binding configuration string with the errors described above.
You will have to do that in a rule. A message will only be published to MQTT when the Item receives a command. That is actually the key distinction between an update and a command, updates do not trigger the binding.