SET_DOES_NOT_CHANGE_LAST_CHANGE does not work

[stefxx]

Hi Michael,

I just noticed that setting the "SET_DOES_NOT_CHANGE_LAST_CHANGE" on a device doesn't get saved. If I go back to the same device after setting this, it is disabled again.

And even when I set it on the feature directly ("Last Change Time Updates on Status Change Only") it doesn't work. It still updates the date/time on every update.

This is really a problem when working with events that rely on a device being on or off for a certain time.

Thanks!

[Michael McSharry]

I am not able to replicate the issue of the Edit tab setting of the MISC properties. The checkbox sticks and persists through plugin restarts. The setting in HS mirrors the setting on the Edit tab.

At the bottom of SetDeviceValueString function is where mcsMQTT decides to explicitly update LastChange property based upon logic earlier in the function that assesses if the value or string changed. It does not use the MISC property setting in this logic. Perhaps this logic should change, but I thought HS would only update lastchange based upon value change and not on string change.

The UI to manage the checkbox is part of MQTTASP with the postback case of SUB_SET_DOES_NOT_CHANGE_LAST_CHANGE that invokes the SetMisc procedure where both the plugin MISC and the HS MISC properties are managed.

I think the best way to proceed is with the debugger at your end. This logic has not changed in the past months.

[stefxx]

Hi Michael,

I must be going mad, I tested the Edit tab settings 3 times this morning with same results. Just tested it again, and now it does stick! So never mind that issue and call me crazy.

About the actual updating of devices; I had a quick look at the code and notice that you are using UpdateFeatureValueByRef and UpdateFeatureValueStringByRef. That will always update the device including LastUpdate. You either have to use UpdatePropertyByRef (but I have found that to be less reliable, maybe that has improved recently?) or simply compare old and new values and only update if they differ. In my plugins, i have chosen the latter.

Thanks again!

[Michael McSharry]

I noticed updating the value property had some issues and had previously changed them all to be what I have now with the FeatureValue. I was not aware that FeatureValue always updated the LastUpdate. In what situation does HS4 use the MISC property for LastChange?

The issue with conditionally updating the value is that there are user wants events triggered each time the message is received even if the value did not change. For example, doorbell rings.

[stefxx]

I doubt if HS4 is doing anything with that MISC property at all. It sounds logical that it shouldn't update lastupdate date/time if the value is unchanged. But if I remember correctly, this was not even the case in HS3.

So I wasn't complete in my statement that my plugins only check if the value actually changed. What I do is more like "if (dv.value <> newvalue) OR (NOT dvMisc.SET_DOES_NOT_CHANGE_LAST_CHANGE) then UpdateFeatureValueByRef". Same for device status.

[stefxx]

Hi Michael,

Any thoughts on this? Currently I can't use events that checks if a device is on or off for a certain time..

Thanks!

[Michael McSharry]

I think I provided a solution in 5.6.0.1 (http://mcsSprinklers.com/HSPI_mcsMQTT_5_6_0_1.zip). If that does not solve the problem then it can be revisited. mcsMQTT now does look at the LastChange MISC property as part of its decision process of changing the feature's LastChange property.

[stefxx]

HI!

I don't see a different behavior by using the 5.6.0.1 version, sorry. Device date/time is still being updated. It is a bit confusing as I noticed that setting SET_DOES_NOT_CHANGE_LAST_CHANGE prevents HS4 from refreshing the device page, but after manually refreshing the page you'll see that the feature's last date/time is still being updated.

Thanks!

[Michael McSharry]

I tried again with http://mcsSprinklers.com/HSPI_mcsMQTT_5_6_0_2.zip. The code now contains the logic to explicitly manage the feature's LastChange property based upon the MISC setting and if the updated Value or String changed. If MISC checkbox is checked and the Value or String did not change from the prior MQTT message then the LastChange feature property will show the time of when the feature's Value or String had changed. If the MISC property is unchecked then the LastChange property will always be updated.

[stefxx]

Thanks. Unfortunately, I still do not see any change in the behavior. Every update also updates the date/time of LastChange with 5.6.0.2.

[Michael McSharry]

Do you have the MISC flag set for the LastChange on the Edit tab? Is the value you are sending via MQTT constant or changing?

[stefxx]

I might have found the problem. When setting the MISC flag from the plugin, it also updates the HS4 feature with the "Last Change Time Updates on Status Change Only". But not the other way around. That is why I believed the MISC flag was set... If the flag is set from the Plugin it seems to work just fine.

I will do some more testing because this is weird. Unless you have a simple explanation?

[Michael McSharry]

The plugin is using its copy of LastChange MISC. If it is changed outside the plugin then it will now know about it. Access of the HS object is more resource expensive than use of local plugin memory so I elected to go this route rather than query HS each time.

In HS3 there was some device property that was write-only by plugins so the plugin was not able to know what a user may have changed via DeviceManagement. This is why the plugin updates the properties when an update is made to the Edit tab.

[stefxx]

Yes, I was just looking in the mcsMQTT database and found it. Understandable, but also confusing. And I configure my devices by scripts, but this is something I have to set manually I guess...

Thanks!

[stefxx]

Final thought: is this something that can be set by default (for new devices)? Or if you feel that this isn't what most users want, configurable? That would save me from ticking the box box every time (and forgetting most of the time) when I create a new device...