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

Correct. Is there a need for directly interacting with the event bus?

Same problem as here?

Not really… sometimes I am just too lazy to define a focused MQTT Item so I use the Bus integration :slight_smile:

There was a scenario that you could use this integration to “link” 2 OH2 installations together but this is rare and can be also done with focused items.

Homie looks really interesting and should allow for much easier use of MQTT devices with OH. Awesome.

Does this MQTT binding enables autodiscovery? I mean I was able to add the broker but after what should I do? Where can I define my MQTT items?
I haven’t found it in the posted readme, it only defines in textual files (which is not really a way it should be in OH2, right?)

The MQTT 1.x binding had an event bus configuration that is useful for integrating OH with other systems and for integrating multiple OH instances together.

Used cases include:

  • vacation house remote monitoring and interaction
  • remote elder monitoring (I use it for this)
  • alternative UIs

I’m sure I’ve seen others mentioned.

The configuration automatically publishes events and sincerity to events in a standardized way with minimal configuration.

I didn’t even think of this. It’s going to be a whole lot of work to redo this by hand. It’s going to be quite some time before I can adopt this new binding without the event bus because it basically means recreating two new complete OH configs. :tired_face:

You can publish all item changes to mqtt via the new rule engine.

To convert an incoming stream of published item changes back to item state updates you would use a script and the trigger channel of the mqtt broker.

I think you can satisfy all mentioned use cases with what is there already if I’m not mistaken.

It is at least not necessarily to touch the event bus directly anymore.

I rebuild the thning from scratch, this should not the problem

I don’t see an easy way to do this without something like the MQTT publish Action.

If have to create a rule two rules (one in the remote OH and one in the “master” for each and every item that needs to be mirrored.

I don’t think anyone is arguing that it can’t be done. But right now I mirror 50+ items with three lines of config code. I’m going to have to generate 100+ rules to replace that with MQTT 2.x. It’s going to be a whole lot of work and a nightmare to maintain.

If I had the publish Action, I could just write one rule and use the event.topic variable as the topic to publish to. I’m not sure how to replicate the behavior of the subscribe part. I know if no way to subscribe to the using * and get both the message and what topic the message was posted to do I need manually configure 100 items with MQTT publish and subscribe.

So at best I’m going from three lines of config to 100 painfully point and click created Rules, or 100 manually configured MQTT Items.

The loss of the event bus doesn’t break this per se, but it generates a massive amount of work to maintain just what I have working now.

What if you just use the clustering capacities of the MQTT-Broker? I use VerneMQ, with this one it’s dead simple.

the “problem” is more related to the OH2 configs and the ease of configuration using the existing MQTT<->Event Bus integration.

The alternative is a big pain (it works but it takes much more time to setup and debug) = define multiple Items in both OH2 instances and configure them in a way to exchange info between them (using MQTT). The Broker setup doesn’t affect this (or at least, I don’t see how it will help).

It is coming :wink:
And it will allow to publish to a topic based on the rule action inputs (for example item name, item value).
In your case you would setup a new-rule-engine rule that triggers on an item change and perform the mqtt action to publish for example to “myfirstinstance/{item_name}”->{item_value}

You can. Create a trigger channel on the MQTT broker, subscribed to “myfirstinstance/#”.
The trigger payload at the moment is the value only, but I will extend the payload to contain the topic name as well separated with a custom character.

You only need one new-rule-engine rule that fires on the mentioned trigger channel and executes a script that does a postCommand or so.

So all in all: You are right it is not possible right now, because I’m waiting for another framework feature to arrive, but it will be. There should be no reason to need the mqtt-eventbus binding anymore or did I overlook a use-case?

Cheers,
David

2 Likes

OK, then this isn’t so bad. A couple of Rules that I can later distribute as a library or a template isn’t so bad at all.

:+1:

Nothing I can think of. I think as long as we can subscribe to a tree of topics using # and get the topic as well as the message itself and we have a way to publish to arbitrary topics from a Rule (using event.topic as the MQTT topic will probably be the most natural) I think we have all the bases covered.

1 Like

@David_Graeff, in the documentation on GitHub there are some limitations:

  • The following HomeAssistant MQTT Components are not implemented: Camera, Climate, Fan, Cover. The light component only supports a on/off switch and no color or brightness changes.

When I try to add a light component, the only found channel is a color channel.
That’s not correct, because my config payload is:

{
    "name":"test light",
    "state_topic":"homeassistant/light/testlight/onoff/state",
    "command_topic":"homeassistant/light/testlight/onoff/command"
}

It would be great if you can support also the brightness, color and color temperature(as a dimmer) channels for light components.

I do not intend to advance the homeassistant support at the moment. But the mentioned bug will be fixed.

@David_Graeff maybe a trivial question, but after reading some comments (here and in github): Is there a reason for all this urgency with regards to bringing this MQTT v2 binding to the next release?

No not at all. It is available in Eclipse framework and collide with the old mqtt binding. It is shining through to openHAB here and there, so it either needs to be hidden from openHAB in one way or another or be rock solid to really replace the old binding.

3 Likes

Can someone answer me some questions about mqtt?

I´m on oh2.4 snapshot and now i will starting my first work with mqtt. I bought some esp8266 modules and want to integrate them now.

Which version is recommended to start with? I didn´t use mqtt. This is my first start with it.

Should i still use mqtt 1 or should i use mqtt 2?

All what i did so far: i installed mosquitto (with apt-get install mosquitto) on my debian server…

Try the Homie-Implementation, but take the fork from bodiroga, he implemented Homie V3.


This implementation is as I said a fork, pull request to the original is pending I think

Was this answer for me?

I need help with the server side mqtt (on my debian server running openhab), not with my esp-devices.

The question was about mqtt binding version 1 or version 2.