I am using MQTT 2.4, and I have strange behaviour and probably I am missing something.
I have an item which is connected to an MQTT topic. All works fine. When the topic change, the item is updated.
The strange is that when I send the item a command (via Karaf console), the item is changed but then goes back to the value it was before. The only thing that can explain it, is that the MQTT binding somehow “retain” the item value.
BTW, when I remove the link to the MQTT channel (item is not connected to any channel), the item works as expected, that means, when I send the command from Karaf, it keep the value (this was just to check that the item is not changed from other source).
Here is log example when it happens (I don’t understand why Motion_Entrance change back from OFF to ON):
2019-01-20 10:50:17.357 [ome.event.ItemCommandEvent] - Item 'Motion_Entrance' received command OFF
2019-01-20 10:50:17.371 [nt.ItemStatePredictedEvent] - Motion_Entrance predicted to become OFF
2019-01-20 10:50:17.400 [vent.ItemStateChangedEvent] - Motion_Entrance changed from ON to OFF
2019-01-20 10:50:17.404 [GroupItemStateChangedEvent] - Motion changed from ON to OFF through Motion_Entrance
2019-01-20 10:50:17.408 [vent.ItemStateChangedEvent] - Motion_Entrance changed from OFF to ON
2019-01-20 10:50:17.412 [GroupItemStateChangedEvent] - Motion changed from OFF to ON through Motion_Entrance
Yes, but the MQTT topic did not change, therefore it had to flip back. If you want to debug, you should publish to the topic, not sending comand to the item.
If I understand you correctly, the binding makes sure that the item value will match the last topic state. Is this the case? (this is what I am seeing but I must say that it is strange behaviour)
Not sure why you think this is strange? Sending OPEN to most doors, they’ll stay shut in reality and I would expect their OH status to stay shut as well.
The ‘predicted’ part in your log comes about from autoupdate guessing what might happen after a command. Autoupdate is not smart enough to understand that there won’t be an affect here.
The strange thing is that using Karaf, I’ve sent a command to the item, not to the binding. That means that the mqtt binding monitors the state of the item all the time and makes sure that the state of the item will match the state the binding have.
“Someone” has decided to return the state of the item to ON (in the above snapshot). The end device didn’t send it, so the only one that can do it is the binding and this is strange.
Okay, so you would prefer the MQTT binding to only update your Item when there is an external event. I think what you want is a stateless channel, inbound, i.e. an event channel. I don’t think MQTT supports that? though it easy to simulate with a proxy Item.
Actually, I just want to know the behaviour. If the binding stores the last state he got from the device and it always sync this state ti the item, that is fine, for me it was a surprise. I just want a confirmation that this is how it works so I know it is not an issue with my system.
I don’t even know what that means, but so far as I see the generalized openHAB logic:
It’s down to a debate about whether sending a command to a read-only channel should cause a binding to do nothing at all, or to instead give the reasonable response of affirming that the ‘target’ device state will remain unchanged.
Maaaaybe. Bear in mind it would be legitimate to send a REFRESH command to a read-only channel, for example, and to get an update in response. “Do nothing” definitely not a blanket expectation.
The binding is the real arbiter of what is a sensible response or not, this might depend on the underlying technology.
We’re second-guessing what the binding developer had in mind now.
Is your problem that it changed at all? See autoupdate.
The Mqtt binding keeps its channel in sync with their state topics. Linked items are therefore set to the bindings cached state and will reset to that state if the framework sends a “command”.
The binding will not be informed if the user overwrites an item state via “update”.
