Rounding %value% and %pvalue% to two decimal places befrore caclucating formula

[revyakin]

In

ESPEasy/src/src/ESPEasyCore/Controller.cpp

Line 633 in 0e8f533

formula.replace(F("%pvalue%"), String(preValue[varNr]));

%value% and %pvalue% get truncated to two decimal places before substitution. Is it a desired behavior or a bug? Should I send PR?

[TD-er]

Looks like a bug indeed.
We do have functions like doFormatUserVar (and all variations that call it)
But not sure how to use it on the preValue.

[revyakin]

doFormatUserVar would also round before calculating the formula. But it seems not right for me as we should round calculation results, not input.

Maybe as an ugly but simple fix, we should pass something like 10 into decimal Places param?

[TD-er]

I get your point and I'm not yet sure whether I agree or disagree.

Normally you always use the number of decimals available and round at the end.
But here the nr of decimals may also be a property of the sensor or at least the unit of measure.
For example what to do with 0 decimals?

Or what if you need to use a specific nr of decimals to get stable readings from an ADC?
If you multiply it, you may also introduce noise which was first deliberately suppressed by setting a specific nr of decimals.
The calculations done in the rules also uses the nr of decimals set to create a string to parse/process and it always uses the set nr of decimals of the source of the value.
The same in events.

So normally I would totally agree with you to only round at the end, but for use in ESPEasy I'm not sure if that's what the (often inexperienced) user will expect.

In generating the numerical values, there is also another trick being used to round numbers to a bit more expected values.
For example 3 * 0.333333 should equal 0.999999.
But if its value is computed like this (1 / 3) * 3 one would expect 1 to be the answer.
So there is some rounding trick in generating the string representation of a floating point value, where the result is more to what the user would expect.
Otherwise a user would get unexpected results if comparing a value with 1.
Mathematically and scientific this is debatable, but from a user standpoint it makes things a lot more usable and less frustrating.

I would even go as far that we should not copy the floating point value, but maybe even take the string representation from it and store that as previous value.

[TD-er]

@revyakin Can you test PR: #3745

It does store the %pvalue% as a string and for both %pvalue% and %value% the function formatUserVarNoCheck is used.

The reason I chose to use this format function is that it's also used in the rules parsing.

[revyakin]

Sorry, I missed your previous message.

Thank you for such a clear explanation. Now I completely agree with you.

I'll try to test the PR this weekend.

[TD-er]

Also added a number of examples to the documentation and fixed the formula parsing so you can now also use standard conversions and refer to other task values using [taskname#taskvalue]

See documentation: Appendix/System Variables/Task Formulas

By the way, another argument for using the formatUserVarNoCheck is that it does allow for task specific formatting.
There is a call to let a plugin generate a specific formatting, but that's currently only used by the "cron" plugin, but it may be used by others later.
Another example is to fetch the "LONG" int values like generated by plugins like RF-ID readers.