MQTT device question

[vasrc]

I have some MQTT based devices that have their Last Changed dates reset to the latest HS4 restart time. I don't see that behavior with other MQTT devices nor HS devices (zwave, etc)..
The MQTT devices that reset, have JSON payloads, such that /Value:xxx is a number and String:abcde is Text. (yeah I know, not great key choices )...
Can you think of any MQTT settings that might cause this to occur?


Tnx

[Michael McSharry]

Most like candidate is the original source of the MQTT message. If it has the Retain property set when published then the MQTT Broker will send it to mcsMQTT each time mcsMQTT reconnects to the Broker. The MISC setting you have in the screenshot shows that Last Change should be updated even if the DeviceValue does not change.

Two ways to change the behavior. One to have the original publisher of the Topic to not use Retain. The other is to have the Last Change MISC setting checked.

[vasrc]

I show both screenshots as Set does NOT change Last Change (screenshots are "fuzzy" to me). I've confirmed it on all the devices as well. I also don't publish with the retain flag set (PubSubClient defaults to false). I also don't see any of the other MQTT devices change dates, but to be fair, most of them change every 30 secs or so, and the problematic ones change daily/weekly, so it's easier to notice. The other difference is these are multi-topic devices (value & status), all the others are single-topic.

I'll poke around some more and see if can find anymore clues, just thought I'd ask in case it rang a bell with you.

Thanks

[Michael McSharry]

If you have mcsMQTT receiving a topic, then mcsMQTT has no effect on this topic's Retain property. It is the client that publishes the topic that sets the Retain property.

mcsMQTT uses this MISC setting to determine if it should store something in the HS Device Feature as well as knowing if the LastChange property of the Device Feature should be updated. If the MISC property is checked then both DeviceValue and LastChange properties do not change unless the payload is different than DeviceValue.

[vasrc]

Understood.
All the affected clients are using PubSubClient and I'm pretty confident they're not sending Retain to the broker. I'm also very confident the client is not sending it again, so that would seem to point to HSevent value change?
I'll do some more detailed testing to see if I can establish where it's being triggered from (eg MQTT, HS, plugin).

mcsMQTT debug shows the HSevents if I remember correctly...
Is the debug flag carried over on a HS restart?

I'm assuming, on single HS devices that have multi-topics assigned, any (OR) of the values/status/etc topics will trigger a device Last Change update, correct?

Thanks

[Michael McSharry]

HSEvents are in the mcsMQTT debug log and the debug log setting persists restarts. The muti-topic mappings are handled individually when each topic is received so Last Change change would be like OR.

On startup, mcsMQTT looks for MQTT device associations that have Control/Status UI set anything expect Text and Jpg and will clear the Status/String property using method hs.UpdatePropertyByRef. This should not result in a Last Change being affected, but just wanted to make you aware. I did not see any other startup initializations that update Device Feature properties.