MQTT binding and update from old MQTT rules

Setup, Configuration and Use Installation
,
1

Running Openhabian 2.4.0

I have just upgraded to the latest and planning on checking out the new MQTT binding.

I have working MQTT rules that use a broker on my network. I skimmed through the blog post about the new MQTT binding (read: I will go read it in detail…but haven’t yet).

So, can I install the new binding and create new MQTT OH rules for other MQTT topics from my broker and not effect the working ones?

Ultimately I’ll switch them all to the new binding, just wanted to avoid messing up working stuff for the moment.

Also, the blog mentions setting generic Things to standards like Homie. (I need to read up on what homie is…)
Since all of my topic senders are Raspberry Pi and ESP32 nodes of of my own design, I would need to update a bunch of code, so, that might be a while… :roll_eyes:

2

Ok, so I was wrong, the old binding was apparently tossed when I upgraded.

So, I installed the new binding and set up a thing with a broker connected to my broker in Paperui.

I have these items in my items file:

Number mqtt_drive_motion "Motion sense in driveway! [%.1f]" {mqtt="<[redpi_mqtt_broker:driveway/motion:state:default]"}

String mqtt_test "Mqtt test [%s]" {mqtt="<[redpi_mqtt_broker:driveway/stringtest:state:default]"}

I’m not sure if the broker connection is set right.

But, the broker says online, does this indicate it found the broker?

Should it see the items in the item file?

Is the red_pi_broker in the above items the Thing broker name or location field

The rules that work with items are not being triggered.

3

The mqtt1 binding is indeed removed at install time, but you can add it again (mqtt1) and run them alongside each other.

The new MQTT binding uses channels defined at the Thing level, and not mqtt=. I’m afraid you’ll have to read the documentation for this… :grin:

1 Like
4

Yeah, I need to find out how to add mqtt1, I didn’t see it.
But, I read the docs on mqtt2, and got a Thing connected to my broker, but I don’t grok the channels. The first channel I attempted to add didn’t have any receive types, only one send type.

I need to read it again. :roll_eyes:

5

I have no access to my system right now but I will post an example tomorrow.

6

I just read the blog post again. In the part about configuring by text it shows an example a broker.thing file that defines brokers. And a mqtt.thing file that defines a bridge that defines a broker with the same info as in the broker file (ip address, etc.)

Are both files needed? Seems like redundant information.:thinking:

7

You should have read the blog as opposed to scan for “copy and pastable parts”!

The (black and white) examples for the broker are multiple examples on how to configure a broker in a .things file, each of which is talked about in the following lines. Below that the colured example shows a complete example with a broker and a generic thing. In other words you only need top define a single broker like it is done in the coloered example.

8

This is a stripped example from my setup for processing MQTT messages from the utility ‘smart meter’ device. The .things file:

Bridge mqtt:broker:mosquitto [ host="192.168.1.2", secure="AUTO", username="xxxxxx", password="xxxxxx" ]
{
    Thing topic dsmr "DSMR reader" {
    Channels:
        Type number : P_Use         "Current consumption"   [ stateTopic="sensor/dsmr", transformationPattern="JSONPATH:$.power.use.actual.total" ]
        Type number : P_UseL1       "L1 consumption"        [ stateTopic="sensor/dsmr", transformationPattern="JSONPATH:$.power.use.actual.L1" ]
        Type number : P_UseL2       "L2 consumption"        [ stateTopic="sensor/dsmr", transformationPattern="JSONPATH:$.power.use.actual.L2" ]
        Type number : P_UseL3       "L3 consumption"        [ stateTopic="sensor/dsmr", transformationPattern="JSONPATH:$.power.use.actual.L3" ]
        Type number : P_Ret         "Current return"        [ stateTopic="sensor/dsmr", transformationPattern="JSONPATH:$.power.return.actual.total" ]
        Type number : P_RetL1       "L1 return"             [ stateTopic="sensor/dsmr", transformationPattern="JSONPATH:$.power.return.actual.L1" ]
 ... etc
    }
}

Key points:

  • mosquitto is the broker id referenced in the item channel links below. If you have more than one broker you need to create another bridge and use a unique host:port combination.
  • A Thing definition represents a device (most scenarios), in my example a ‘smart meter’,
  • topic is for generic MQTT things (as opposed to auto-discovered based on the Homie standard). Not sure if this must always be named ‘topic’ though…
  • dsmr is my topic/device name.
  • I only have stateTopics as it is just reading the data but there could also be a commandTopic to send something.
  • sensor/dsmr is the actuel MQTT topic to subscribe to,
  • The MQTT message is in JSON format in my example, hence the transformationPattern,
  • ‘Labels’ like P_Use are referenced in the Items channel definitions, see below,

The corresponding .items file:

Number Pwr_Use      "Huidig verbruik [%.3f kW]" {channel="mqtt:topic:mosquitto:dsmr:P_Use"}
Number Pwr_UseL1    "Verbruik L1 [%.3f kW]"     {channel="mqtt:topic:mosquitto:dsmr:P_UseL1"}
Number Pwr_UseL2    "Verbruik L2 [%.3f kW]"     {channel="mqtt:topic:mosquitto:dsmr:P_UseL2"}
Number Pwr_UseL3    "Verbruik L3 [%.3f kW]"     {channel="mqtt:topic:mosquitto:dsmr:P_UseL3"}
Number Pwr_Ret      "Huidig retour [%.3f kW]"   {channel="mqtt:topic:mosquitto:dsmr:P_Ret"}
Number Pwr_RetL1    "Retour L1 [%.3f kW]"       {channel="mqtt:topic:mosquitto:dsmr:P_RetL1"}
 ... etc

Hope this helps.

9

This is very helpful.

Questions.

If I understand correctly; the keyword Bridge is used when the broker and Thing is being defined together (as in your example), as opposed to just a line (as shown in the blog) mqtt:broker:myAuthentificatedBroker [ host="192.168.0.43",secure=true, username="user", password="password" ]

(Since I’ve been burned before…) is the prefix of the .thing file “special”? The blog mentions mqtt.thing and broker.thing or is anyname.thing ok?

10

In PaperUI you need to turn on legacy bindings, do a refresh, then you’ll see the 1.x mqtt binding and can install it.

11

I have a broker on my net I have a generic broker and another device that publishes a topic “driveway/stringtest” with one of two states Motion and No Motion.

I created the following mqtt.things file:

Bridge mqtt:broker:redpi_mqtt_broker [ host="192.168.53.105", secure="AUTO", username="xxx", password="xxx" ]
{
    Thing topic drivesensor "Driveway Motion Detector" {
    Channels:
        Type number : DrvMotNum     "Drive Motion Num Channel"   [ stateTopic="driveway/motion" ]
        Type string : DrvMotStr     "Drive Motion Str Channel"   [ stateTopic="driveway/stringtest"]
    }
}

And I changed my item file to:

Number mqtt_drive_motion "Motion sense in driveway! [%.1f]"  {channel="mqtt:topic:redpi_mqtt_broker:drivesensor:DrvMotNum"}
String mqtt_test "Mqtt test [%s]"  {channel="mqtt:topic:redpi_mqtt_broker:drivesensor:DrvMotStr"}

PaperUI shows the broker online, the thing/channels online.

But the log file shows no indication of receiving when the topic is published. (other receivers do see the topic, so it is being sent.)

I assume I’ve got something wrong in the mqtt.things file, but, what?

Update: I shutdown OH and rebooted and the publish is seen now. Must have been something stale from the mqtt 1.x binding.

12

Nope. I named it mqtt.things but it could be named anything, like mosquitto.things for instance. OH looks for the file extension and doesn’t care about the name.

13

Normally, OH sould pick up configuration changes. But in my experience some times a reboot is needed to activate changes, especially for Bridge and Things.

Glad it works! :grin:

14

This is especially true for the MQTT binding, because I do not use text files and of course there was a bug in the OH 2.4 release where you need to restart OH after every file change. Is fixed since day one of OH 2.5 snapshots though :slight_smile: