[CLOSED] MQTT binding version 2.4 (Pre-release !)

Add-ons Bindings
1

THIS THREAD IS NOW CLOSED AS IT WAS RELATED TO THE PRE-RELEASE VERSION OF THE MQTT BINDING v2.4

IF YOU HAVE AN ISSUE WITH THE CONFIGURATION OF THINGS AND ITEMS WITH THE NEW BINDING PLEASE OPEN A NEW THREAD FOR YOUR ISSUE

PLEASE REFER TO:

and

BEFORE OPENING A NEW THREAD

THANK YOU

It appears that there is a new 2.4 MQTT binding:

image
image1251×213 9.58 KB

Has anyone got info about it. Clicking on the binding gives me a 404 error…

2

@David_Graeff
I would be willing to test the binding

3

Hey @vzorglub,
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 :slight_smile:

Cheers, David

6 Likes
4

Something to look forward to indeed!

5

@David_Graeff
I am beside myself in anticipation
I have one question, if you don’t mind.
How does the binding affect the use of the MQTT action?

6

hey @vzorglub,
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.

Cheers David

7

There are interferences in my experience. I have tried the MySensors binding which makes use of:
feature:install esh-io-transport-mqtt

And that causes the mqtt action to be disabled. I then have to uninstall the action, restart OH and re-install the action.

I use the action for several reasons. I could use items but that would be a lot of items…
I generate the topic of the fly with a rule and fire a message

8

Let’s try and merge your use-case into the binding.

The new MQTT binding allows to bind specific topics to Thing Channels.
A Channel is then linked to an Item, as usual and can be used in rules etc.

What you need for your use-case is to bind a Channel to a wildcard topic,
like “sensors/+/event”, if I understand you correctly?

1 Like
9

I think that could be the solution. Cool

10

I just checked if the new binding can do this out of the box. I almost succeeded.
There is one line of code that need to be changed.
But I can’t promise to get this in before the OH 2.4 release.

Cheers, David

11

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.

12

That’s a great progress. I migrated all my mqtt items to new binding and it works so far. Is there any documentation on it? What is A Homie (version 3.x) device?

13

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.

Cheers, David

14

But I don’t know anything about the new binding.
Now I am curious what homie has to do with it :thinking:

15

I think that the new binding will allow autodiscovery according to some “standards” like homie, tasmotta, espeasy…

16

Is the previous beta MQTT Broker also working. It would be great to have an all in one solution that did autodiscovery.

17

The MQTT Action can only publish to topics.

  • 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.

18

I agree. I misunderstood the previous proposition. I want to be able to publish any arbitrary topic anytime in a rule. Or any algorithm generated topic and payload for that matter.

19

+1. I also use MQTT action to publish messages where the topic is generated by rule code. This feature allow to integrate virtually any MQTT device in a simple way.

20

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 :smiley: .)

Cheers,
David