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

Add-ons Bindings
242

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

243

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.

244

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.

245

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:

246

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.

247

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.

248

I finally got my MQTTv2 binding to work but the definition of my Thing is different. I am using the notation with spaces instead of colon.

In your case I would have written

Thing topic sonoff-sc01

instead of

Thing mqtt:topic:sonoff-sc01

Also your broker name is inconsistent mosquitto != mqttitude.

The third thing that is different in my working config is the channel of my Items which in your case should be:

mqtt:topic:mosquitto:sonoff-sc01:schalter
249

@David_Graeff @thaasoph

Thank you both! The Broker was online and the connection seemed to work! I could see a successfull connection log entry in the tail.

I’ll give it another try tomorrow :slight_smile:

250

Just for the record, I’m running the same way but I also let PaperUI manage my Things. Just mount the userdata folder into the container and you are good to go.

Everything you do in PaperUI IS saved in text files. They are just of a different format and in a different folder.

Starting down that path I can say it is a lot of work. There are a lot of topics that need to published to to enable automatic discovery. Personally, if you are working on something that you want to share with the wider world it is worth the effort. If it is something custom you’ve written just for yourself, it’s probably not worth the effort.

Here is a link to the 3.0.0 spec for Homie.

1 Like
251

Yeah I use a python version of homie as well. Which can make that look a little consistent.

My main trouble would be that all my devices aren’t at 3 yet, so I have to reflash them.

Also after getting over my broker name issue (trying to use dns name). I tried using a generic mqtt item, and while I can mosquitto_sub it no problems, the binding says java.lang.Exception: No MQTT client, not sure what that means

252

Do you know of a python implementation of 3.0.0 in work? I couldn’t see much going on on the “official” github project in that direction (I saw your comments there though :wink: ).

My plan is to implement just enough of it to get by as I don’t have time to build a fully capable library to release or submit as a PR anywhere.

253

No, but the owner was looking at things it could do, this might be a good starter. Or I could get my hands dirty and have a go.

1 Like
254

Have a look at the example: The Homie convention. It is not that much actually.

This is a resolved issue, either in OH 2.4 release or OH 2.5 snapshot, not sure rn.

1 Like
255

I just discovered profiles which are apparently new in 2.4. They support all the transforms and they work for incoming data (device to Item direction). Perhaps adding an outgoing flag to the profile would solve this problem. I don’t know if one can have more than one profile on an Item though, nor do I know yet if one can set profiles in PaperUI yet.

We might be closer to having a solution to this than I thought. But you know the code, am I off base?

256

Yes. They were not finished when I started the MQTT development. It could make sense to remove transformations for incoming values and use profiles instead, actually. For outgoing values I like to have a framework solution as well, but will be different to profiles.

1 Like
257

I probably have a special use case that makes it a lot more work for me. I can support N nodes and I don’t know until run time what they are or what they publish so I have to go through a loop or registration process to publish to $nodes and all the $ topics for each individual node. Indeed, something less dynamic would be much less work.

To make it more challenging is Homie will not be the only way the script can publish so I need to code it in a way where REST commands and plain old arbitrary MQTT are still options without blowing up my config files.

258

I started the migration to mqtt2 using this thing definition:

Bridge mqtt:broker:opusMQTT [ host=“myIP”, secure=false, username=“myUser”, password=“myPasssword” ]

Item:

Switch Stern “Stern” { channel=“mqtt:opusMQTT:topic:sonoff_1:Sonoff_1” }

Resulting in a:

17:28:21.341 [INFO ] [o.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to ‘myIP’ with clientid paho37883175964382 and file store ‘/var/lib/openhab2/mqtt/myIP’
17:28:21.384 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘mqtt:broker:opusMQTT’ has been updated.
17:28:21.397 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘mqtt:broker:opusMQTT’ changed from OFFLINE to ONLINE

So it seems to work for the broker.

My switch thing however doesn’t connect

{
Thing topic sonoff_1 {
Channels:
Type switch : Sonoff_1 “Test” [ stateTopic=“tele/sonoff_1/STATE” , transformationPattern=“JSONPATH:$.POWER” , commandTopic=“stat/sonoff_1/POWER”, on=“ON”, off=“OFF” ]
}
}

Resulting in:

17:23:44.170 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘mqtt:topic:opusMQTT:sonoff_1’ changed from OFFLINE (BRIDGE_OFFLINE) to OFFLINE (COMMUNICATION_ERROR): java.lang.Exception: No MQTT client

or

17:28:21.325 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘mqtt:topic:opusMQTT:sonoff_1’ changed from OFFLINE (COMMUNICATION_ERROR): java.lang.Exception: No MQTT client to OFFLINE (BRIDGE_OFFLINE)

259

You need OH 2.4 release or 2.5 snapshot for a fix, not sure rn. This happens only on textual configuration changes. Workaround: Put the broker definition in a separate thing file, restart OH and you should not encounter the error anymore.

1 Like
260

I’m on the new 2.4 stable.

Putting the bridge line in a separate file and restarting resulted in no change???
I’m using my (old) mosquitto broker, that shouldn’t be the problem (I think).

261

Hi there,

I’m in the process of migrating my MQTT1 stuff to the new binding. Most of my things work perfectly. I have only one issue. I had the following in my MQTT1 binding:

Number BLE_phone_EG {mqtt="<[mosquitto:monitor/eg/12\\:44\\:95\\:F2\\:B/\\:81:state:JSONPATH($.confidence)]"}

and have converted it to

Thing topic phoneBLE  "phoneBLE" {
        Channels:
             Type number : eg [ stateTopic="monitor/eg/12\\:44\\:95\\:F2\\:B/\\:81", transformationPattern="JSONPATH:$.confidence" ]

}

but I’m not getting any data. This is the only Channel where the topic contains colons, which I had to escape with \ in MQTT1 and a transformationPattern.

Any idea what might be wrong?

Thanks