Have you had anymore thoughts on adding trigger channels as part of the Generic MQTT Things?
A trigger channel cannot be of any specific type (string, number, etc) because it doesn’t have a state (it can carry a string payload though). So there is really just one trigger channel. The question you are asking is if it should be available on a Thing or on the broker Bridge Thing.
@Kai convinced me to have the trigger channel on the Broker Thing. But I have to admit it is quite hidden there, especially because the MQTT Generic documentation doesn’t mention its existence.
I assume the right action to take is to add a reference of the trigger channel to the readme of MQTT Generic.
Kai just added the possibility to use the MQTT publish action from DSL rules:
rule "Send startup message"
when
System started
then
val actions = getActions("mqtt","mqtt:broker:myUnsecureBroker")
actions.publishMQTT("system/started","true")
end
The next snapshot distro #1460 should include the action (and also the other latest MQTT fixes), so please go and test it!
I just tested the new MQTT binding and it works very well. It’s a bit more time consuming since I can’t easily clone a generic MQTT thing in Paper UI but it’s much more clean by configuring through PaperUI.
One thing I can’t get to work though is applying transformations for outgoing values. I will have to send JSON code to my MQTT broker. For simple data sets the current solution to “format” the outgoing value using %s or %.4f is working but I need to run a transformation for my RGB LED strip. The outgoing value will have to be something like { “color”: { “r”: 120, “g”: 10, “b”: 230}}. Before I used a JS transformation that JSON formatted those 3 values for me.
Would it be possible to also allow transformations for outgoing values? Or maybe I’m missing something. I see that I can define transformation when linking the channel to an item but I don’t understand how that works as I can’t enter parameters like which JS script to use.
Yes please, I noticed that too.
There are some examples in the readme.md file of the binding (which will become the website docu once 2.4 is released).
My first iteration of the binding actually did had an outgoing transformation option as well. But yeah, I’m a c++ efficiency guy and I was afraid of heavy abuse, exactly this scenario actually: applying a js transformation. This is soo costly, because I was not allowed to cache the transformation/js context. So it is recreated again… and again on every publish. I really couldn’t do that.
There are ways around this of course, involving rules. But personally I think the target device should be fixed to not expect JSON.
My personal opinion.
Cheers, David
Hmm, understood but why then allow transformation for incoming values? Isn’t that as costly as for outgoing values? Also one could argue that devices should be fixed to neither expect nor send JSON… but then again I can transform incoming JSON 
Another issue I have is I would need to re-create an old MQTT 1.x channel link that looked like this:
mqtt="<[local:hermes/asr/startListening:state:ON], <[local:hermes/asr/stopListening:state:OFF]"
Is there a way to do that with the new binding?
Nope unfortunately not directly. The binding design would be insanely more complex so I decided not to provide this feature. (I mean, it is a broken topic design on the client device, isn’t it)
But: you can create two switch channels and bind them to the same item. Problem solved.
The majority of people will use the map, regex, jsonpath or xpath transformation here. That is alright. If you really perform a js transformation, then yes that is not performing well and any leak in the js engine (not unlikely as it is complex) will eat up your ram on many topic changes.
I really can’t tell as I haven’t had the time to check the specs for MQTT about allowed payload formats. I can work around those 2 issues like you mentioned and I see your concerns but then again: it’s always sad to lose functionality with an update.
My only complaint with this attitude is that many or most of us do not have the ability or the control necessary to forever the end device to change. I’ve seen you respond severally times with "tell Shelly/Tasmota/ESP Easy to use Homie. That’s all well and good if they do that but in the mean time is as oh users are screwed and if they never adopt homie we are permanently screwed.
This is a similar situation. If we can’t change the end device we are screwed. There is no help from oh. Conform to OH items or remain incompatible. Why support transforms at all? Just change the end device, right?
I seriously doubt it is more efficient to call a transform from a rule and it is a significantly more amount of work for the end OH user. This really feels like letting the beauty of the coffee take precedence over the users.
Over all it really comes across as antithetical to what OH stands for. We are an adapter that lets different technologies interoperate. We are not a system that imposes requirements on third parties before we deign to work with them.
Personally, if it were up to me I’d pull transformations out of the bindings entirely and implement a service that lets us use transformations with ANY binding.
So the stance for the MQTT binding is force the end device to conform to OH and if you can’t do that go pound sand. Not very user friendly.
It is really just the js transformation that concerns me, which is relatively new. The framework and they way how to resolve a transformation within bindings does not feel prepared for this. If I would at least be allowed to cache the transformation as a binding developer.
And no this is not against users this is to prevent heavy abuse because there are more and more OutOfMemoryExceptions happening.
I think with the formatter for outgoing messages you can already do a lot. The only thing not possible is split a complex type into its components and convert a state to something completely different.
Personals I think this can only be solved efficiency within the core. As you suggested. Generic bindings like mqtt,http,coap should not offer transformation options at all, but the framework should bring support for it.
Cheers, David
How heavy? This for the user to decide.
A warning in the docs should inform the user.
The new binding should strive to have ALL the functionality and flexibility of the old one.
I agree. In the mid-run a solution in the ESH core can be found, I’m sure. Just before the release of 2.4 the binding and core cannot be changed that fundamental anymore though.
User case for outbound transformations.
I really think this important despite your reservations about performance issues.
See:
Where the user is using a MAP transform outbound
I have my own case where, when I started in HA, I mage my own arduino device to control 433MHz devices.
I made some design “errors”. The value for of is 0 and for ON is 9
The reason for this was htat I could have settings it between.
I still have two of these legacy devices, they are hard to access AND I have lost the original code.
I don’t want to write that code again. I don’t want to spend hours accessing those devices. They are very reliable.
What I want is being able to send 0 for OFF and 9 for ON. To do that I currently use the MAP transform.
Switch LivingRoom_WallLights "Wall Lights" (LivingRoom, MaghribLights, SunsetLights) [ "Lighting" ] { mqtt=">[mybroker:ESP8266/LivingRoom/WallLights:command:*:MAP(off0on9.map)]" }
How can I achieve that with the NEW binding?
You can’t. Use mqttv1.
Cheers, David
That is very helpful. Thanks for listening to users needs. You did for the mqtt action. Why not this?
I have responded already. Just two post above.
I have tried to use one of my contact sensors over the new MQTT binding but for some reason I can’t get it to work at all.
My mosquitto is working fine and the state changes get published properly on the configured topic but for some reason I cannot get any state change of my Items whatsoever.
I have boiled down my configuration as much as possible in order to eliminate possible causes of errors.
mqtt.things:
Bridge mqtt:broker:mosquitto "local mosquitto" [ host="localhost", secure="OFF" ]{
Thing mqtt:topic:xcontact {
Channels:
Type contact : contact "Xiaomi Contact" [mqttstate="deconz/contact/16"]
}
Thing mqtt:topic:xcontactString {
Channels:
Type string : contactString "Xiaomi Contact String" [mqttstate="deconz/contact/16"]
}
}
It doesn’t seem to make a difference whether I use this notation or “Thing topic xcontact”.
mqtt.items:
String ContactString "[%s]" { channel="mqtt:topic:xcontactString:contactString" }
Contact XContact "Contact" { channel="mqtt:topic:xcontact:contact" }
sitemap:
Text item=ContactString label="Buttonevent [%s]"
Default item=XContact label="Contact" icon="door"
Is there anything I can do to debug this issue further? According to the log the binding does connect to the broker but after that I cannot achieve any state change.