mqtt-Binding: Possible bug

Add-ons Bindings
1

Just in case someone experiences the same:
When I add a mqtt-thing (I do this via .things file), the mqtt-binding receives updates from this device as expected, but only from that new device. Any other defined mqtt-things stop receiving updates.

The solution here is to temporarily disable and re-enable the mqtt-bridge-thing (The thing that connects openhab to your mqtt-broker) in PaperUI. After that all mqtt-devices are updated in openhab. So not a big deal, but worth noting.

I’m currently running 2.5.10, but the same but existed in 2.5.9.

2

What binding version are you running (you can see that in the PaperUI)?
Also, can you share your things and items files?

3

Same binding version as openhab2-version: 2.5.10

But here are excerpts from the configuration files:
(Temperature transmitted from a Raspberry Pi)

thing:

Bridge mqtt:broker:home "MQTT Bridge Home" [ host="127.0.0.1", port=1883, secure=false ]
{
Thing topic Raspi1 "MQTT Raspi1" {
Channels:
Type number : temperature1 "Temperature1" [ stateTopic="raspi1/temperature1" ]
}
}

item:

Number:Temperature weather_raspi1_temperature1 "Outside Temperature [%.1f °F]" <temperature> (temperature) {channel="mqtt:topic:home:Raspi1:temperature1"}

4

Strange,

Here’s mine:

Bridge mqtt:broker:mosquitto [ host="192.168.0.11", clientID="openhab2", port=1883,secure=false,retainMessages=false, retain=false ]
{
  Thing topic shellyht-58F8A4 "shellyht-58F8A4"  {
    Channels:          
      Type number : temperature "shellyht-58f8a4 temperature" [ stateTopic="shellies/shellyht-58F8A4/sensor/temperature"] 
  }
}

And the corresponding item:

Number Entrance_TempSensor_Temperature "Entrance Temperature [%.1f °C]"                                        <temperature>          {channel="mqtt:topic:mosquitto:shellyht-58F8A4:temperature"}

I don’t think the additional configuration options make any difference. but try adding the clientID="something"

5

Without the explicit clientID the system created an unique one, so that shouldn’t be the cause.

1 Like
6

Have you tried adding a new “thing” to your things file and see what happens?
I’ve only had that on this occasion, on a restart of the mqtt-broker-thing everything works again.

7

@Tron

I’ve noted that changes to the Things configuration don’t always go through until I restart the server. But adding new things always go through.

8

Hello,

I might be wrong, but can it be related to the way the bridge is defined/used?

Could you try to define the MQTT bridge/thing from PaperUI or in a text file (.things) like in the below example (adjust the parameters to match your environment):

mqtt:broker:mqtt_broker [ host="brokerIP", secure=false, username="brokerUsername", password="brokerPass" , clientID="openhab2", enableDiscovery=false ]

Then define your things like this, by referencing the bridge instead of (maybe) defining a bridge for each item:

Thing mqtt:topic:sonoff_1 "Sonoff 1" (mqtt:broker:mqtt_broker) {
Channels:
    Type switch     : Power  [ stateTopic="...", commandTopic="...", on="ON", off="OFF" ]
    ...
}

Thing mqtt:topic:sonoff_2 "Sonoff 2" (mqtt:broker:mqtt_broker) {
Channels:
    Type switch     : Power  [ stateTopic="...", commandTopic="...", on="ON", off="OFF" ]
    ...
}
9

Hmm, I have one file with all the mqtt-things in it, which is why I only need to define the bridge once and do not need to reference it again (or defining multiple bridges). But I fail to see the real difference here.

That’s also the reason I did it in files (instead of PaperUI) as I have several identical devices and in a file can easily copy text and create multiple things. I think openhab3 offers that in the GUI…

10

That’s fine, just be sure to nest all a Bridge’s children in curly braces { }

You’re on something of a goose-chase here; it is not unexpected that many OH2 bindings do not play nicely with Things & channels editing in files. It’s very common to find that edits are not correctly picked up until the binding is reinitialized. That’s always been the case, some bindings are better at it than others, some have been improved over time.

I think you have discovered that for MQTT sometimes you only need reinitialize the broker Thing, which sounds useful. Makes sense, it will resubscribe everything.

Configuring Things and channels via GUI fares better in this regard, somewhere behind the scenes it pushes different buttons.

11

You may be right there. Maybe I’m just more of an old-school console guy.
But yes, OH is now such a complex structure that some incompatibilities are to be expected. Interestingly enough, after every update of OH I always need to restart the service twice for it to run well, first time around always gives me lots of errors on the console.

This post was not to complain about the glitches, but more to give someone else a hint who might run into the same issue (which in this case is easily fixed).

12

Again, yes. There is some kind of system cache that update (rightly) clears, and first boot with empty cache is pants.

1 Like
13

Got exact same issue here.
Spent 2 days migrating hundreds (241) of items across to mqtt2.5 binding

have around 7 thing files like such;


Bridge mqtt:broker:blindsBroker [ host="mqtt.home", secure=false, port=1883]
{
    Thing topic FrontRoomRight
    {
        Channels:
            Type number     : Position      "Position"         [stateTopic =    "home/blinds/rpiserver01/f4:21:18:4c:58:1b/position", commandTopic = "home/blinds/rpiserver01/f4:21:18:4c:58:1b/position/set"]
            Type number     : Battery       "Battery"          [stateTopic =    "home/blinds/rpiserver01/f4:21:18:4c:58:1b/battery"]
            Type datetime   : LastUpdate    "Last Update"      [stateTopic =    "home/blinds/rpiserver01/f4:21:18:4c:58:1b/time"]
            Type string     : Move          "Move"             [commandTopic =  "home/blinds/rpiserver01/f4:21:18:4c:58:1b/move/set"]
            Type switch     : MoveUp        "Move Up"          [commandTopic =  "home/blinds/rpiserver01/f4:21:18:4c:58:1b/moveup/set"]
            Type switch     : MoveDown      "Move Down"        [commandTopic =  "home/blinds/rpiserver01/f4:21:18:4c:58:1b/movedown/set"]
            Type contact    : Working       "Working"          [stateTopic  =   "home/blinds/rpiserver01/f4:21:18:4c:58:1b/working"]
            Type switch     : Refresh       "Refresh"          [commandTopic =  "home/blinds/rpiserver01/f4:21:18:4c:58:1b/refresh/set"]
    }

    Thing topic FrontRoomLeft
    {
        Channels:
            Type number     : Position      "Position"         [stateTopic =    "home/blinds/rpiserver01/fd:9b:70:91:33:ba/position", commandTopic = "home/blinds/rpiserver01/fd:9b:70:91:33:ba/position/set"]
            Type number     : Battery       "Battery"          [stateTopic =    "home/blinds/rpiserver01/fd:9b:70:91:33:ba/battery"]
            Type datetime   : LastUpdate    "Last Update"      [stateTopic =    "home/blinds/rpiserver01/fd:9b:70:91:33:ba/time"]
            Type string     : Move          "Move"             [commandTopic =  "home/blinds/rpiserver01/fd:9b:70:91:33:ba/move/set"]
            Type switch     : MoveUp        "Move Up"          [commandTopic =  "home/blinds/rpiserver01/fd:9b:70:91:33:ba/moveup/set"]
            Type switch     : MoveDown      "Move Down"        [commandTopic =  "home/blinds/rpiserver01/fd:9b:70:91:33:ba/movedown/set"]
            Type contact    : Working       "Working"          [stateTopic  =   "home/blinds/rpiserver01/fd:9b:70:91:33:ba/working"]
            Type switch     : Refresh       "Refresh"          [commandTopic =  "home/blinds/rpiserver01/fd:9b:70:91:33:ba/refresh/set"]
    }
...snipped
}

They stop working randomly and the other solution is to either touch the file (rare that it works) or rename the broker or the faulty channel and then name it back again.

Updating the topic also has more misses that hits. log set to trace and you can see it saying successfully published message to new topic but using mqtt spy, the message never arrives. Rename and back again and the message arrives.

There certainly seems to be something wrong with the binding with this. The 1.x binding never missed a beat (same mqtt instance in a container on rpi)

14

If that is spontaneous, and not the result of editing, it is not the same issue at all. You’d be wise to start a new thread.

15

I would agree that there’s some other cause to this. Are you using zigbee2mqtt, by any chance? That occasionally dies on me, rarely, but it does. Even though I only have like a dozen zigbee devices in total.
To monitor that I log and track the link quality. That fluctuates rather frequently, especially with mains-powered devices. When those lines start flatlining, I know that zigbee is down.

16

I do but those topics I have not noticed. They only update thermometers so I don’t notice failures.
I do notice the blinds not opening :laughing:

17

Understandably. How do the mqtt-messages reach the broker? Wifi?

18

Hi,

same problem here. Got a RPi with Deconz dongle and zigbee2mqtt running. MQTT gets published over wifi.

Best regards,
Daniel

19

Nope. Eithernet, same vlan.
Been rocks solid until the about 2 upgrades ago. On 2.5.9 nowhere as I’m no comfortable moving to the 2.5.10 or 3.0 :sleepy:

20

Hi,

I did an update to 2.5.10 yesterday, but this behavior didn’t changed :-/

Best regards,
Daniel