New MQTT 2.4 Binding

This should be the right one

1 Like

Thanks for your quick response, but I’m working with 2.4 version.

A quick search here for “MQTT 2.4” turns up several threads specific to your question. Maybe repost your question to the thread you think is most appropriate for your issue?

thanks. I missed that search as I looked for MQTT only.

No problem. Hope you get a resolution to your problem.

Basically you are trying to use the mqtt event-bus integration that is available with MQTTv1 in the v2 binding

See there:

Can this topic be solved? :slight_smile:

MQTTv2 allows to publish all events with a self written rule only at the moment.
What is missing is a new rule engine template that does this job and simulates the old mqtt-eventbus. But we are not yet there.

Cheers, David

1 Like

Can you give an example, please?
I have not seen any MQTTv2 rule examples, yet

1 Like

I cannot. I haven’t written a javascript rule yet and have no idea how to interact with a new rule engine action from within DSL rules. But the idea is simple:

When
  item_change
Do
  mqtt.publish("my/topic/"+item.getUID(), item.getState().toString())
1 Like

But the MQTT action remains the same after MQTTv2 is installed and V1 removed? In the DSL

No, as I said, I have no idea how to access a new-rule-engine action. The binding id is “mqtt” and the action-id is “publish”, that is all I know.

Not in the new rule engine. In the DSL, does the action remain the same?

I would assume you cannot use the MQTT v2 action in the DSL rules.

Well, I want to clear up the assumption, and understand how to use the equivalent of the V1 Action with the V2 binding.

I could live with the fact that “new” actions would only be accessible via “new” javascript/jython rules. But Kai said something along the lines of that new actions will be available for DSL rules as well, personally I just don’t know how.

Can someone explain me a little bit, how this MQTT Binding differs from the old (1.0) one?

I have tried installing it, but I couldn’t find later, how could I use it… I thought it follows the same procedure as other OH 2.X bindings, that you will have a bridge (MQTT broker) and then it will “auto-discover” the available topics and you can add each end-topic as a thing.
But I assume this is not how this works. Can someone explain that to me in a few sentences?
Will it worth switching to it from 1.0? I think sooner or later I will have to switch from my 1.X bindings and I have a few (I use MQTT very frequently, almost everything communicates through this protocol), so I would start with this…

Thanks in advance!

Yeah, this is at least what I like to make possible, potentially even only through some workaround/hack. But I see it as an important feature so that the new MQTT binding can really serve as a full replacement for the old one.
Getting the actions accessible from rules is one of my last todos for the 2.4 release - I’ll hurry up to come up with some suggestion :slight_smile: .

3 Likes

I’m just trying to migrate to MQTT 2.4.
So far I’ve been pulsing my EasyESP over mqtt1:

default.items:
Rollershutter Markise “Markise” {mqtt=">[broker:/Markise/cmd:command:UP:pulse,0,0,100], >[broker:/Markise/cmd:command:STOP:pulse,2,0,100], >[broker:/Markise/cmd:command:DOWN:pulse,1,0,100]"}

but how do I do that in the new version ?!

At the moment you can’t. You would need an outbound MAP transformation to convert UP to “pulse,0,0,100” and so on. OH 2.5 snapshot will support this soon.

Hi David,

are there plans for OH2.5 to support multiple nodes for one homie device as this is currently noted as a limitation and I’d like to use this?

  • This binding does not support Homie Node Instances.

Cheers, Michel