Very kind of you. The binding got tested extensively internally and will straight go into the next release (just a few days ahead).
But I’m happy about any defects you find and report after the release
Actions are still openHAB 1.x technology. What exactly are you using Mqtt Actions for? You would need to have the old and new binding being installed side by side, I can imagine there are interferences.
Would that be enough I wonder? The MQTT Action publishes arbitrary messages to arbitrary topics.
How can I publish “ON” to “sensors/bedroom/cmd” one call and “ON” to “sensors/livingroom/cmd” on another call. I’m no expert on MQTT so I don’t understand how I can do that with “sensors/+/cmd”.
I would imagine needing to do something similar to Exec 2 where you have an input channel and using $1 (e.g sensors/$1/cmd) to replace the $1 with the topic. I can’t say I’m in love with this approach but it works OK for Exec 2.
The MQTT Actions binding can subscribe to specific topics and wildcard topics.
-> Those can now be mapped to Thing Channels.
The Action binding can also publish to arbitrary topics. That is correct and this cannot be done with the “modern” Thing/Channel approach.
But I wonder why you just don’t create the required Thing Channels for each of the topics
and set the Channel values in your rule or in the new automation engine.
publish(String brokerName, String topic, String message) : Publish the message to topic using the specified MQTT broker.
You must use the MQTT Binding and Items to subscribe to topics. And that makes sense. How would one write a Rule that subscribes to a topic?
It isn’t that we can’t just create the Thing Channels (and Items to link to them), but that in many situations it can be significantly more work.
There are situations where one can write 2-3 lines of Rules code to handle ten or more topics verses still needing at least one line of Rules code plus all the work to create ten or more Things/Channel.
I don’t actually use the MQTT Action myself so I may not be the best person to drive this discussion, but I know that Vincent and many others do to create code like I described. And this feature will be something that will be lost in the move to MQTT 2.0.
I understand that a shift of thinking is required here. In OH1 a lot was done with rules because there was no choice.
But the idea with OH2 is that the framework has a representation of the outside world, modeled with Things for devices, Channel Groups and Channels for the inner functionality of a device.
Those elements can interact with each other ideally via a If-Then-That relation (E.g. by building on the new Eclipse Smarthome rule engine).
So yes, it is a in the spirit of OH2 to have a few Things and Channels configured for static devices (topics in this case).
But I need the exact use cases in which the MQTT Action binding is still useful to enhance the new binding.
(Avoiding to create 10 Things once is not considered a use-case though .)