Per homie protocol, set messages should not be sent as retained.
In the behavior above, the first message was generated by using the PaperUI to change the dimmer value. It is correct as retain is false.
The second message occurs after disconnecting a client (not OH) and then reconnecting the client to the broker. Notice the second message is now flagged retain true.
The problem is that everytime a client connected to the broker all the old set messages a sent and devices are changed even if that set value is no longer valid.
Once retained, always retained until cleared. Because there has been any retained message sent to the topic that message will remain on that topic even if there are later messages sent with the retained flag set to false.
openHAB is completely ignorant as to whether a subscriber subscribes or not so there is no way it can resend a message with the retained flag set to true when a client subscribes to the topic. So the most likely cause of the behavior is that at some point a retained message was published to that topic. That message remains because a retained message doesn’t get cleared out when non-retained messages are sent afterwords.
The first thing you need to do is clear out the retained message. You can do this by sending an empty message with the retained flag set to true. I think MQTT Explorer has a button you can use that will do this for you.
Until you clear out that old retained message, any client that subscribes to that topic will get that message every time they connect.
@rlkoshak, I have cleared out all messages - using MQTT Explorer as you mentioned. The Homie spec says that set messages are to be sent with retain false. This is exactly what OH does.
BUT, if a client (not OH) disconnects from the broker and then reconnects, there is a second set message being sent that has the retain flag true. This second message only happens if the set command comes from OH. I know the set message is from OH as it comes with the same value as the first message.
Ie. If I clear out all messages and send a set command using MQTT Explorer, disconnect the non OH client and reconnect, no second set message appears. So this second set message with retain true when a client reconnects has to be coming from OH…
The only way OH will know about this is if it sends this second message when the broker publishes the LWT message for that client. Do you see a correlation between the LWT message and OH republishing the message?
If not, there is no way that OH can know that the client disconnected so how can it resend the message with or without the retained flag set to true?
I’m not convinced that is strong enough evidence yet to definitely say that is where the message is coming from. I’m not arguing it’s not coming from OH either.
Put the binding into trace logging. If OH is in fact sending the message, you will see it doing so in the logs.
How are you observing this second retained message? Does MQTT Explorer receive the message independently or are you seeing the disconnected client receiving the message when it reconnects? What is the exact timing of the message? Immediately when the client disconnects, when the broker publishes the LWT, some other delay?
I’ll work on figuring out the log for the binding - have not used that before.
Openhab will know when the homie client reconnects as the homie client will republish itself. Its this reconnection that triggers OH to send the second set message.
The second set message does not appear if you reconnect a MQTT browser like MQTT Explorer or Lens
I see the errors below when I try and set a value using the PaperUI. The right value gets sent but there is this error dump.
02-Dec-2019 15:51:29.571 [DEBUG] [org.openhab.binding.mqtt.generic.ChannelState ] - Format pattern incorrect for mqtt:homie300:Queen:testdimmer:dimmer#dimmer
java.util.IllegalFormatConversionException: d != java.lang.String
at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4302) ~[?:1.8.0_222]
at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2793) ~[?:1.8.0_222]
at java.util.Formatter$FormatSpecifier.print(Formatter.java:2747) ~[?:1.8.0_222]
at java.util.Formatter.format(Formatter.java:2520) ~[?:1.8.0_222]
at java.util.Formatter.format(Formatter.java:2455) ~[?:1.8.0_222]
at org.openhab.binding.mqtt.generic.ChannelState.publishValue(ChannelState.java:366) [bundleFile:?]
at org.openhab.binding.mqtt.generic.AbstractMQTTThingHandler.handleCommand(AbstractMQTTThingHandler.java:128) [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_222]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_222]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy502.handleCommand(Unknown Source) [?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_222]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_222]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
02-Dec-2019 15:51:29.581 [DEBUG] [nhab.binding.mqtt.generic.AbstractMQTTThingHandler] - Successfully published value 0.21000000 to topic homie/testdimmer/dimmer/dimmer/set