Deadband for Publish on Value change

[vasrc]

I looked through the doc and didn't see this functionality..

Would it be possible to add a deadband to the value change publish function? By value change, percent, roundup, etc would be great.
I publish values to remote MQTT devices for display and control, and sending .01 changes really isn't necessary.

Thanks

[Michael McSharry]

Implemented with new expression function "IfChange" with three parameters. The first two are the numbers being compared and the third is the hysteresis threshold which can be a number or can be a numeric string suffixed with "%". A new replacement variable was also added $$PREVIOUS: which is the value provided by HS at the time the value change event is raised.



Assume that the plugin installed is at least current with updater. The attached (HS3 or HS4) goes in the \bin\mcsMQTT folder.

A couple usage notes
1. The publish template has literal text. Use double lessthan and greaterthan brackets so the plugin knows a an expression needs to be evaluated
2. The $$PREVIOUS: replacement variable is set as a result of an event callback. Using it for something like a received MQTT message will not give expected results
3. The percentage change syntax is based upon a change in HS device value and not in a change from the last time a message was published. It is likely that a percentage change will be small in two consecutive updates of a HS device.
4. The numbers being used are Double so decimal values should be able to be included.

[vasrc]

What took you so long
I'll give it a spin shortly..

Thanks!

[vasrc]

I'm not seeing the effect I'm expecting.
I have a well depth monitor that typically runs between 96 and 110 feet. If I set the "hysterisis" to 0.1 I get changes. 0.2 does not change when I expect it to. Tried with and without "" "". Percentage acts in a similar manner (ie larger changes required that I expected).

For example I have it set to 0.5 now and the last Published value was 107.45. It wasn't until it got to 106.11 that I saw a new value sent. 106.11 didn't change even when it went to 108.5. I finally got a new value sent at 105.6 ft. (the delta for Value/Previous is +/-, correct?)

What's the actual calc being used between $$VALUE and $$PREVIOUS?? I'm wondering if the HS4 VALUE/PREVIOUS values aren't accurate representations of what's occurring in real-time..

Thanks

[Michael McSharry]

[vasrc]

It works when I manually enter values into a device, so it's not the plugin. IFchange code is pretty straight-forward, so sure it's not that. May just be it dealing with non-linear values, or even the MQTT browser I'm using to check what's published. I'll look at it more closely tomorrow.

Thanks again.

[Michael McSharry]

I added another replacement variable $$PUBLISHED: that retains the Payload of the Topic when published. It may be more useful with the IfChange function as small incremental changes in HS DeviceValue may never reach the $$PREVIOUS: threshold, but will reach the $$PUBLLISHED: threshold. I also make IfChange function more generic to handle the case of String rather than Numeric inputs. For Strings the threshold is ignored so it is only an equality comparison. The $$PUBLISHED: value does not persist restarts of the plugin.

[vasrc]

Thanks for looking at it.
Something's still not correct. If I enter 0 (numeric) for the delta, I of course get realtime publishing.. 0.1, stops publishing until I get an larger delta than 0.1 (something like 2 or 3 delta)
If I put in something like 0.02 it does start to publish again, but in small increments like 0 (or just $$VALUE does. I've tried using just $$PREVIOUS or $$PUBLISHED, and when I publish those values, they "seem" to be valid..

Your compare code works fine (I used it in a script to check), so without seeing what the actual inputs are and the resulting calc (nDelta, nBy), I'm at a loss..
The value I'm using is an HS3 device and it is populated from a Plugin. The value is also being archived by the Device History plugin, but if I remember correctly, EventChange is a one way mechanism..

Thanks

[Michael McSharry]

For $$Value: and $$Previous: the values are in the plugin debug for HSEvent lines. I think the 3rd is $$Value: and the 2nd or 4th is $$Previous:

I think there is also debug in ApplyExpression of which IfChange is part.

could it be fractional delta causing issue? I did not try it. I could also give you debug in this function.

[vasrc]

Ahh... I see the light now...

c:\Program Files (x86)\HomeSeer HS3\Data\mcsMQTT>tail -f "mcsMQTT Debug.txt"|grep IFCHANGE
5/21/2021 9:58:53 AM 62168743 | ApplyExpression IFCHANGE(100.87,100.94,0.1) Result=
5/21/2021 9:58:58 AM 62173777 | ApplyExpression IFCHANGE(100.85,100.87,0.1) Result=
5/21/2021 9:59:04 AM 62179514 | ApplyExpression IFCHANGE(100.82,100.85,0.1) Result=
5/21/2021 9:59:09 AM 62184651 | ApplyExpression IFCHANGE(100.75,100.82,0.1) Result=
5/21/2021 9:59:14 AM 62189786 | ApplyExpression IFCHANGE(100.74,100.75,0.1) Result=
5/21/2021 9:59:19 AM 62194840 | ApplyExpression IFCHANGE(100.69,100.74,0.1) Result=
5/21/2021 9:59:25 AM 62200575 | ApplyExpression IFCHANGE(100.66,100.69,0.1) Result=
5/21/2021 9:59:30 AM 62205694 | ApplyExpression IFCHANGE(100.64,100.66,0.1) Result=
5/21/2021 9:59:35 AM 62210829 | ApplyExpression IFCHANGE(100.61,100.64,0.1) Result=
5/21/2021 9:59:40 AM 62215965 | ApplyExpression IFCHANGE(100.6,100.61,0.1) Result=
5/21/2021 9:59:46 AM 62221702 | ApplyExpression IFCHANGE(100.55,100.6,0.1) Result=
5/21/2021 9:59:51 AM 62226739 | ApplyExpression IFCHANGE(100.52,100.55,0.1) Result=
5/21/2021 9:59:56 AM 62231872 | ApplyExpression IFCHANGE(100.47,100.52,0.1) Result=
5/21/2021 10:00:01 AM 62237007 | ApplyExpression IFCHANGE(100.46,100.47,0.1) Result=
5/21/2021 10:00:07 AM 62242738 | ApplyExpression IFCHANGE(100.46,100.46,0.1) Result=
5/21/2021 10:00:12 AM 62247780 | ApplyExpression IFCHANGE(100.44,100.46,0.1) Result=
5/21/2021 10:00:17 AM 62252915 | ApplyExpression IFCHANGE(100.4,100.44,0.1) Result=
5/21/2021 10:00:23 AM 62258051 | ApplyExpression IFCHANGE(100.39,100.4,0.1) Result=
5/21/2021 10:00:28 AM 62263788 | ApplyExpression IFCHANGE(100.35,100.39,0.1) Result=

If the delta is within the deadband, it allows it to "creep" up/down without publishing.. $$PUBLISHED: is changing to the last VALUE, not the last PUBLISHED..

Z

[Michael McSharry]

Cut/Paste issue when $$PUBLISHED: was added. Should be fixed in the attached.

[vasrc]

That got it... Was a bit concerned, until I figured out the Debug log runs about 1-2 mins behind realtime I'm assuming you give it low priority..
As you figured out, $$PREVIOUS won't work.. $$PUBLISHED is the key..

Thanks again... Off to give Dishy a permanent home on the roof...
Z

[Michael McSharry]

Glad this works now. There is no intentional scheduling of the debug log. IT uses TextWriterTraceListener to avoid concurrency issues of writes to the same stream, but I have never observed such a large lag. It may be appropriate to disable the debug when not actually using the debug output.

[vasrc]

I always turn it off when I don't need it. Timestamps are spot on, just their display in the debug.txt file is off.
Probably slow because I use Unix commands on Windows 10

Thanks