[SOLVED] Yet another MQTT 2.4 binding question - am I close?

Setup, Configuration and Use Items & Sitemaps
1

I’m getting mentally prepared to upgrade my openhabian to version 2.4 - I think I understand everything that needs to be adjusted except the new MQTT binding.

I’d like to start by making a couple of points:
1- I’ve been reading all of the threads about the pre-release binding, it looks like a lot of work has gone into this! I appreciate it and I want to fully embrace the new and improved 2.4 powers

2- I’m confused about the attitude of the new binding - essentially the comment seems to be “use homie or home-assistant standards or may as well just keep the old binding”. Correct me if I’m wrong but isn’t that exactly opposite of what OpenHAB is all about? I understood the point of OH was to make everything work with everything, I thought OH was the software that tries to work with everything instead of us as users going and asking others to support OH…

Ok, on to my most troubling item. In the future I plan to replace Tasmota on this device (esp8266) with a custom Arduino sketch and Homie, but I have go in baby steps or things break in the house and my wife makes me unplug my automation toys.

I have this Item from the 1.x binding:

Switch MicroLight "Microwave Light"   { mqtt=">[mybroker:cmnd/wemos2/POWER1:command:ON:ON], >[mybroker:cmnd/wemos2/POWER1:command:OFF:ON], <[mybroker:cmnd/relayState/POWER1:state:default], <[mybroker:tele/wemos2/SENSOR:state:JSONPATH($.Switch1)]"}

A little different but works great. The command for “on” and “off” are both “ON” because it toggles a relay on my wemos that “pushes the button” on the microwave for the light. Next we have the state coming back. This is a “switch” in tasmota or a GPIO high/low on the wemos. The tele/wemos2/SENSOR coming back is for reinitializing after openhab reboots.

And now my attempt at the 2.4 binding. Please be kind it’s my first try.

My attempted new Things:

Bridge mqtt:broker:myUnsecureBroker [ host="localhost", secure=false ]
{
    Thing mqtt:topic:microwave {
    Channels:
        Type switch : highLight1 "Microwave Lamp 1" [ commandTopic="cmnd/wemos2/POWER1", on="ON", off="ON"]
        Type switch : highLight2 "Microwave Lamp 2" [ stateTopic="cmnd/relayState/POWER1"]
        Type switch : highLight3 "Microwave Lamp 3" [ stateTopic="tele/wemos2/SENSOR", transformationPattern="JSONPATH($.Switch1)"]
}

My attempted new Item:

Switch MicroLight "Microwave Light" {channel="mqtt:myUnsecureBroker:topic:microwave:highLight1", channel="mqtt:myUnsecureBroker:topic:microwave:highLight2", channel="mqtt:myUnsecureBroker:topic:microwave:highLight3"}

Am I close? Will this even work? Is it just me or is this much more complicated than the “old way” for this item?

I’ve read through the documentation and tried to adjust examples to my item. I also read David’s blog post from a couple of days ago about the new system and grabbed some helpful information there. Finally, this is just step 1 for this “thing” - I have the “low” light, “high” vent fan, “low” vent fan, and a temp/humidity sensor connected to the same ESP…

2

Do you have another machine to play with? Even if it just another instance of openHAB. One great thing about mqtt, is more than one broker can consume a message.

3

Once I have time (probably January) I’ll be setting up a test OH 2.4 at work with the same topics and messages as these items so I’m sure it’s sorted before taking it home.

In the meantime I’m hoping for a bit of wisdom so I don’t get stuck somewhere that doesn’t have a fix.

4

According my humble experience as of last night I would say the commandTopic would be the one starting with “cmnd” together with the two …on="ON, off=“ON”…
I’m not sure which stateTopic would work/be needed, however I think only one would be enough. The one needed for reinitialize after restart could IMHO be handled by persistence (mapdb with restoreonstartup). Or I misunderstood this use case.
Both the commandTopic and stateTpoic should be in one channel and the item only be linked to that one.

Look at_my post_

5

Ah yes. I mistyped this - I’ve edited the original post.

As for persistence- you’re probably right but last time I tried persistence it did not go well. Instead I just wrote a “system started” rule to initialize 2 or 3 things then made sure everything else would be updated within about 10 minutes of startup… I suppose the retain option on the new embedded mqtt broker could help in this. I may try that.

I still like the idea of the tele command coming in every 5 minutes just to make sure OH really always knows the state of things gs.

I guess my final question is two things before I go and try it -
1- can I have multiple channels on one item like this?
2- are my state and command topics formatted correctly?

6

transformationPattern uses the pattern NAME:TRANSFORMATION not NAME(TRANSFORMATION).

yes

It seems so.

Cheers, David

7 
Type switch : highLight3 "Microwave Lamp 3" [ stateTopic="tele/wemos2/SENSOR", transformationPattern="JSONPATH:$.Switch1"]

I copied that part from my old item then missed the changes you noted on your blog post - I think this is correct.

Thanks for the response! I will be trying it out just as soon as I get some free time.

8

I don’t think this is a correct assessment.

In order to support automatic discovery it requires the devices to publish certain information to certain well known topics.

EVERY MQTT firmware and devices out there seems to have their own standards and almost none of them are suitable for automatic discovery. So the developer settled on two standards, the platform independent Homie standard and the Home Assistant standard. Having looked into it a bit, these are the only two that are generic enough and robust enough to truly support automatic discovery. So despite my initial objections, I think this is a reasonable line to draw.

Note that we are only talking about automatic discovery of MQTT Things.

For the rest of the firm wares out there, while automatic discovery won’t be supported, they can and are still usable with the new binding. You just have to define the Things and topics yourselves, which is no different really than the MQTT 1.x version binding.

1 Like
9

This is helpful Rich. I think I’m starting to get it.

For DISCOVERY to work there obviously has to be a standard. The available standards are homie and home assistant.

For DIY we are free to configure things and channels however we feel like.

Awesome!