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

Yup. For now. I’m sure there will be an easier way in OH 2.5.

Is there a known issue when trying to configure a MQTT thing via the .things file?
When I try to configure a MQTT thing and take a look at it in the Paper UI the channels looks like this:

mqtt:topic:mosquitto:xcontactString:contactString

which corresponds to:

mqtt:topic:<broker>:<thingId>:<channelId>

Isn’t that wrong? Shouldn’t it be:

mqtt:<broker>:topic:<thingId>:<channelId>

Could this be the reason why I cannot get any messages at all to my items?

Bindings do not need to explicitly support textual configuration. If Paper UI works, the textual configuration works as well. The example of the readme file is working, too.

Cheers, David

Hello,

I installed the new binding today, and am running into trouble that my eventbus stuff is not working any more (i.e., multiple OpenHAB instances talking to a main one).

My eventbus was configured like this:

broker=mosquitto
commandPublishTopic=/server/out/${item}/command
stateSubscribeTopic=/client/out/${item}/state

Now that’s not working any more. How do I configure a replacement in the new binding? I don’t get it from the UI (or the textual setup).

Or other question - can I go back to version 1 somehow? It’s not listed in bundles in PaperUI and I’m currently stuck in a totally non-working system (with 6 OpenHAB client instances and > 150 devices)… not good at all. :frowning: worst is that I installed it by accident, as the latest nightly 2.4 OpenHAB version reported me some issues with mqtt binding so I thought I’d go and reinstall it… and got stuck.

1 Like

Event bus is not supported in the 2.4 version binding. You can fairly easily recreate that capability though by adding all the items to a Group and using the MQTT Action in a Rule to publish updates and commands and changes to the proper topics.

Because there is now at.x Verizon of the binding the 1.x version is now considered “legacy”. By default Paper I will not show legacy bindings. You can change that in configuration system settings. There has an option labeled something like “show legacy bindings”.

Now that the 1.x and 2.x bindings can happily coexist on the same OH.

1 Like

@meingraham @vzorglub
Maybe check out “HABApp”? MQTT support is only available in the dev branch but I’ll merge it this week.
It would allow you to directly connect to your mqtt instance, trigger on value and then publish it again.
Also you can write rules in plain python which is very nice. :slight_smile:

Hello @rlkoshak

thanks for your reply. Hmmm… that’s a pity as the eventbus fairly easy enabled me to have such a complex system running without a bigger overhead on configuration, as everybody got notified properly. That puts a bigger hurdle in front of me. Sure I can put all devices into a group but that’s quite some effort (I’m not talking of an installation with 3 devices but perhaps not yet big but quite large installation) and I need to do it on all the instances I have running. And then I still need to figure out a proper rule for that. For somebody on full time work and who’s just become father a bit challenging. :wink:

Especially when considering that everything used to work really well with the 1.x binding and IMHO it would have been nice if features were not stripped out of the system with the new version as this possibility to run multiple instances was one of the main killer-features that let me chose OpenHAB (the nicest thing was that it used to work via VPN even for the home of my parents that I could take care of when they weren’t there).

If there’s anywhere a hint of how the rule(s) for this should look like, I would be really gracious to get some help on that.

Also I noticed that the documentation for the v2 binding seems not in place (when I click on the binding name in Paper UI, it gives me a 404 error page).

1 Like

MQTT v1 is still available.

As expected the openHAB 2 version works different, because it takes all the new concepts like Things and Channels and the new automation engine into account.

The sender side is actually not complicated, if Paper UI would support the new automation engine in all detail already, you could even do this graphically. You want a rule that triggers on any item update and push the item id and item value via the (new) MQTT action.

The receiver side is simple as well actually. You configure a trigger channel on your Broker Thing and in a second rule, react on that trigger, extract the item id and state and post it to the eventbus.

There will be a Rule Template, encapsulating those two rules for easier handling soon.

Cheers,
David

2 Likes

I am giving up on this binding!!!
Textual things throw warnings…
And the breaking point is that after a restart ALL items are in UNDEF state and because of the order in which things are done during restart the restoreOnStartUp doesn’t work. OH restores and then the binding puts everything on UNDEF.
Unworkable…

Hello @David_Graeff

thanks for your reply. It would really be helpful to have some kind of tutorial explaining how to mimic the old eventbus behavior. I get that it might make from a software engineering perspective make sense to have this overhaul of the binding, but it should be ensured that stuff that used to work still works (or can be achieved without too much of a hassle even on existing installations that have grown – I think that’s anyhow where MQTT makes sense, as for a one-system / 2 z-wave switches systems you won’t need MQTT).

I switched back to the 1.x binding (by rolling back my OpenHAB installation a version) but I am also aware that at some point in time the 1.x binding is going to be broken if there’s major architectural changes in OpenHAB so I want to switch to the new binding but of course all has to work as before (and not cost me days of reworking the setup).

Thanks again and I’m looking forward to a tutorial or templates for the rules.

1 Like

That looks like a nice addition to have this as a configuration option. You can use MQTT in different ways. If you fully go with retained topics, the binding is expected to put items to UNDEF if the retained topic vanished.

Could actually be made smart instead. If the channel is retained, the items are put to UNDEF, if the channel is not retained, the item state is not touched, or similar.

See https://github.com/openhab/openhab2-addons/issues/4393

I don’t use retained topics, I use restoreOnStartup.
So OH restarts, the items get restored from MAPdb, the binding kicks in and put all the items to NULL and then to UNDEF. restoreOnStartup out of the windows. How do I get my values back? WITHOUT using MQTT retain because it’s a pain in the neck.

2 Likes

You really don’t need to do that. The mqttv1 binding is still available for OH 2.4 and can even coexist with the new binding. You just need to enable the legacy addon repository

Hey there!

I tried using the MQTT 2.4 binding but could not get it to work with the documentation.
I’m not sure what I’m doing wrong, so probably somenone can point me in the right direction?

mqtt.things

Bridge mqtt:broker:mosquitto [ host="1.2.3.4",secure=false, username="User", password="Pass", clientID="ohmqtt"  ] 
{
    Thing mqtt:topic:sonoff-sc01 {
        Channels:
            Type switch : schalter "Test" [ stateTopic="tele/sonoff-sc201/STATE" , transformationPattern="JSONPATH:$.POWER" , commandTopic="stat/sonoff-sc201/POWER", on="ON", off="OFF" ]
    }
}

switch.items

Switch sonoff_sc201_test "Test"  { channel="mqtt:mqttitude:topic:sonoff-sc01:schalter" }

When I switch the item I get the following log entry and nothing happens:

2018-12-17 19:23:56.077 [ome.event.ItemCommandEvent] - Item 'sonoff_sc201_test' received command ON
2018-12-17 19:23:56.084 [nt.ItemStatePredictedEvent] - sonoff_sc201_test predicted to become NULL

Best regards,
Marcel

Great work on the binding…at the reading about it stage rather than trying yet. With a system that is about 90% mqtt, including event bus, I want to see what’s involved first before giving it a go.

Has anyone done a one pager, on migration from mqtt1 to v2? From what I can tell ,I need to grab all my items, and make then into things (which does imply double the amount of configuration work), and I really can’t seem be setting up a couple of hundred items in paperui…it’s just too slow.

String alarm_state "Alarm Zone State [%s]" (g_alarm) {mqtt="<[openhab:Paradox/State:state:default]"}
Switch alarm_state_arm_disarm "Alarm Arm State [%s]" <shield> (g_alarm, g_controlpersist) {mqtt="<[openhab:Paradox/Partition:state:default]"}
Contact alarm_exit_state "Alarm Exiting [%s]" <shield> (g_alarm) {mqtt="<[openhab:Paradox/Events/1:state:MAP(onoff.map)]"}
Contact alarm_connection_heartbeat "Alarm Connection [%s]" <shield> (g_alarm) {mqtt="<[openhab:Paradox/Heartbeat:state:MAP(onoff.map)]"}
Contact alarm_zone_familyrm "Family Room State [%s]" <motion> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Family room PIR:state:MAP(onoff.map)]"}
Contact alarm_zone_maindoor "Main Door State [%s]" <motion> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Main door PIR:state:MAP(onoff.map)]"}
Contact alarm_zone_study "Study State [%s]" <motion> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Study PIR:state:MAP(onoff.map)]"}
Contact alarm_zone_studyreed "Study Door State [%s]" <door> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Study Reed:state:MAP(onoff.map)]"}
Contact alarm_zone_frontdoor "Front Door State [%s]" <door> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Front Door Reed:state:MAP(onoff.map)]"}
Contact alarm_zone_ballroom "Ballroom State [%s]" <motion> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Lounge PIR:state:MAP(onoff.map)]"}
Contact alarm_zone_dining "Dining State [%s]" <motion> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Dining Room:state:MAP(onoff.map)]"}
Contact alarm_zone_laundry "Laundry [%s]" <door> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Mid toilet Reed:state:MAP(onoff.map)]"}
Contact alarm_zone_bedroom "Bedroom State [%s]" <motion> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Bed room PIR:state:MAP(onoff.map)]"}
Contact alarm_zone_garage "Garage State [%s]" <motion> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Garage:state:MAP(onoff.map)]"}
Contact alarm_zone_playroom "Playroom State [%s]" <motion> (g_alarm,g_motion_detection) {mqtt="<[openhab:Paradox/Zone/Play Room:state:MAP(onoff.map)]"}
String alarm_hb_state "Alarm Homebridge state [%s]" (g_alarm) {mqtt="<[openhab:Paradox/Partition/Status:state:default]"}
String alarm_alarm_status "Alarm [%s]" (g_alarm) {mqtt="<[openhab:Paradox/Partition/Alarm:state:default]"}

//Paradox/Status/1 {"battery": 13.4, "vdc": 16.9, "dc": 13.7, "paneldate": "2018-6-4 12:0"}
Number alarm_battery "Battery Voltage [%.1fv]" <battery> (g_alarm) {mqtt="<[openhab:Paradox/Status/1:state:JSONPATH($.battery)]"}
Number alarm_vdc "VDC [%.1fv]" <battery> (g_alarm) {mqtt="<[openhab:Paradox/Status/1:state:JSONPATH($.vdc)]"}
Number alarm_dc "DC [%.1fv]" <battery> (g_alarm) {mqtt="<[openhab:Paradox/Status/1:state:JSONPATH($.dc)]"}

//This shows the starts of arming for when it was a command, to that you could disarm it.  Doesn't currently work is IP150 script
Switch alarm_command_arm_disarm "Alarm Arm Command" <shield> (g_alarm_control) { mqtt=">[openhab:Paradox/C/P1:command:ON:arm],>[openhab:Paradox/C/P1:command:OFF:disarm]"}
Switch alarm_command_arm_disarm_sleep "Alarm Sleep Arm Command" <shield> (g_alarm_control) {mqtt=">[openhab:Paradox/C/P1:command:ON:sleep],>[openhab:Paradox/C/P1:command:OFF:disarm]"}

So for each of these I need to make a thing, and then just reference the thing as each item? Is that right?

I know mqttv1 is still possible, but that’s not a long term solution.

Yes, that is how it works. All the fiddly configuration stuff goes into the Thing. Then the Items link to one or more Channels on the Thing.

So all your Items can remain and don’t need to be recreated. Just replace the mqtt="... stuff with channel="channel:id:for:mqtt:thing"

It is possible to create MQTT Things in .things files so that might be a bit easier of a way to migrate then clicking in PaperUI. That would be a bit more copy and paste versus point and click.

I’ve not looked into migrating yet either, though I’ve started some of the base work. It’s really nice that we can run both versions of the binding in parallel so we can take our time migrating. Most of the stuff I use MQTT for are based on my sensorReporter script so I want to rewrite that to support Homie so I and others can take advantage of automatic discovery. Plus I’ve been wanting to rewrite much of it anyway.

This is the way I am going as my setup is basically a docker image that can be thrown away / restarted at any time. Basically, an IT appliance where you switch the power off, switch it on again, and things magically work, just like the fridge in the kitchen :smile:

On the other hand, this means that I have to put lots of effort into configuring my setup via text files, and test, and re-test, and re-re-rest again and again. Good thing that being a DevOps engineer is my primary professtion :grinning:

Hmm wonder if it easier for me to rewrite some of my stuff in homie convention (some of the bridges), or at least an items > thing conversion.

You are the first one, that uses a username and password for his broker, configured via a text file.
Could you please check if the Broker Thing is Online in Paper UI (which means that the user/pwd credentials are working).

Other than that your config looks ok. You could use an mqtt browser addon or mosquitto_sub to watch the mqtt traffic to find out if the item is indeed publishing something.

Oh: Your “channel” item config is wrong: mqtt:mqttitude:topic:sonoff but you have mosquitto as broker bridge.