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.)
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.
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”.
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)
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.