MQTT Item update and MQTT things file

openHAB 2.5.0~S1556-1 (Build #1556)
Raspberry PI
Bindings: MQTT 2.5, Zwave, Astro, mapdb, influxdb, network, NTP

Don’t have a particular problem, so this is just wondering notes.

As noted above, I’m running an OH2.5 snapshot. Ever since I updated to the new MQTT binding, when I save changes to the MQTT .things file, I need to restart OH to have them take effect.

Also, updates to MQTT things (i.e the thing has received a publish from the ether, updates with changed values are logged, but, if the values are identical there is no log of the received event. Further, a rule containing:

        Item blabla received update

The ‘then’ is triggered even thought the value is identical. (i.e. blabla update has happened but no value changed or nor has the receipt of the mqtt message been logged.)

Not a problem, just curious if this is by design.

Jep, known bug. There is an open issue in github.

Afaik normal behavior.

But that’s intended. This is the meaning of “received update”. If you want to trigger the rule only when the state changed, simply use “changed” as trigger.

1 Like

Ok, I thought I’d read that it was thought to be corrected shortly after the 2.x release.

I understand. But, since there is nothing logged when an unchanged update is received, short of having an update rule or monitoring the MQTT traffic external to OH, there is no indication that the MQTT topic was indeed received. Is this correct?

(Of course, a simple rule that just logs the receipt on update could be used, so it’s not a big deal. As well as, mosquitto_sub or wireshark could be used.)

I don’t know enough about the inner processes of openHAB and MQTT2, but I doubt that MQTT2 will update channels without receiving messages at the associated topics. Please remember, openHAB as well as all Bindings is stateless, so the binding itself does not know which state to write.

Sorry, I’m lost…nothing new. :blush:

If I write a rule that says:

        Item mqtt_thingy received update
        logInfo("test it4", White_Puck_10.state.toString)

It makes a log entry, but, no other log entry, with no change in the payload of the MQTT message.

But, if the payload changes, then a log entry is made:

Event.ItemStateChangedEvent mqtt_thingy changed from 42.6 to 42.9

In both cases a MQTT message was received and something in OH (or the binding) has decided to log only when a change in payload is noticed.

Yes, but afaik this is how it works. only changes are logged, but the event bus gets all updates.


So, the update (that an MQTT message was received) is on the bus and can trigger rules. And, some subsequent processing of the update may note a change in the message payload and chooses to log that change.

Does the “subsequent processing” then actually put a change event on the event bus as well? Which in turn can be used in rules “when item changed”.

Item rule triggers are

  1. received command
  2. received update
  3. changed

The third will only trigger when the state was changed (therefor there is a previousState var when the rule was triggered)
The second will trigger whether the state was changed or not, but openHAB received a status update.
The first will trigger if openHAB received a command (therefor there is a receivedCommand var when the rule was triggered)

All of the three triggers can be narrowed down (received update ON, received command OFF, changed from ON to OFF)

the bug is still present in version 2.5.11 (openHABian)
In this version restarting openHAB is not enough. You have to reboot the machine.

Can you post the link to the github open issue? Maybe there is a workaround posted.

I can’t confirm that the whole machine needs to be restarted. In fact, restarting all bundles in question should suffice.

Please be aware that this issue won’t be fixed for openHAB2, since this is a core problem. It is true for all version 2 Bindings (the “thing” bindings).

And openHAB3 also. At worst you will have to restart openHAB - you shouldn’t need to restart the whole machine. But I find that annoying, so I do this.

Quite a serious bug, then.
Can you point me to the link in github?

That is a very clever workaround…

There may be few or many;it is up to to each individual binding how it finds out someone has been editing Things, and what to do about it. “What to do” is very binding specific.

Hi @rossko57
I am not sure I understand. It’s a core bug or a binding bug?
According to @Udo_Hartmann it’s a core bug affecting all v2 bindngs, but you are saying a different thing… that it’s a binding bug only.
Can you help me understand?

@Udo_Hartmann : can you send the link of the github issue for this bug?

It’s a multipart issue.
Core has to report when a Thing is edited.
Binding is in sole charge of what to do about it, because it may involve anything from closing and reopening connection to other services (password changed?), amending a channel (added a transform?), tidily closing and recreating scheduled jobs (changed a poll period?) or in your MQTT case unsubscribe/resubscribe to changed topic etc. etc.

There’s a hundred odd bindings could probably bear improvement in handling Thing edits, help wanted!
Meantime it’s a minor irritant once you aware, because people don’t generally change Things on a daily basis once their home system is established.

Thanks for the clarification.
If I understood correctly, in this case, the core is working fine, but the problem resides with the MQTT binding. I wonder if there is already an issue on github. I searched for it but couldn’t find any.

I am already involved in a couple of open source projects, but I am not familiar with Java. Anyway will try to get in touch with the maintainer of this binding and see if I can help.

One such issue I opened:

If you just rename the .things file that will trigger the refresh - so I have a script doing that as a workaround.