Smart Meter: Problems with arithmetic calculation evaluation

[redm123]

Using =m arithmetic calculations I noticed some problems (bugs?) in evaluation of formulas.

First of, some examples that work as expected, with 3=144, 4=0:

3+4=144
3*#-1=-144
4*#-1+3=144
4*#-1+3=192 (with 3=0, 4=192)

1. problem: Operator precedence is not taken into account, ex. with 3=144, 4=0:

3+4*#-1=-144 !! -> should be 144

Here I'm not sure if that is maybe "expected"? I mean, on first look this is obviously wrong and should be fixed. But maybe evaluation intentionally happens strictly L->R, for simplicity? In that case it would helpful to note that in the documentation.

2. problem: I think this here is really a bug, ex. 4=192, 3=0:

#-1*4+3=4054 !! -> should be -192

Meter config:

>M 1
+1,3,s,16,9600,EFR-SGM
1,77070100010800ff@1000,Bezug Total,kWh,Total_in,4
1,77070100020800ff@1000,Einspeisung Total,kWh,Total_out,4
1,=d 1 60 @1,1-min-Leistung In ±6W,W,Pcurrent1_in,0
1,=d 2 60 @1,1-min-Leistung Out ±6W,W,Pcurrent1_out,0
1,=m 4*#-1+3 @1,1-min-Leistung ±6W,W,Pcurrent1,0
#

[gemu2015]

constant values must be preceded with '#' see docs

Perform arithmetic ( +,-,*,/ ) on the measured data. Use # before a number to designate a constant value

evaluation left to right no brackets supported (i will add that to the docs)

[redm123]

evaluation left to right no brackets supported (i will add that to the docs)

👍Thanks for the clarification.

constant values must be preceded with '#' see docs

yes, that's what I did.. 3 and 4 refer to other lines, and the only constant in the examples is #-1 ... Ok, I tried it again and I think this looks like smoking gun? :)
Pcurrent1_in is line 3, Pcurrent1_out is line 4 ... testcalc2 is fine, but testcalc1 not really.

1,=m #-1*3+4 @1,test calc 1,W,testcalc1,0
1,=m 3*#-1+4 @1,test calc 2,W,testcalc2,0

{"Time":"2025-02-25T15:26:22","EFR-SGM":{...,"Pcurrent1_in":184,"Pcurrent1_out":0,"testcalc1":12866,"testcalc2":-184}}

[gemu2015]

Ok, you can only reference decoder lines in math calculations not math lines.
In case this is missing in the docs I will clarify that

[redm123]

Hmm? I don't think that's the problem here. For me this rather looks like an issue with evaluation of the formula, if the constant comes first... I can reproduce the same with just the decoder lines. Also other variations of the formula work fine.

>M 1
+1,3,s,0,9600,EFR-SGM
1,77070100010800ff@1000,Bezug Total,kWh,Total_in,4
1,77070100020800ff@1000,Einspeisung Total,kWh,Total_out,4
1,=m #-1*1 @1,testcalc3,W,testcalc3,0
1,=m 1*#-1 @1,testcalc4,W,testcalc4,0
#

testcalc4 is the expected result, testcalc3 is .. whatever...:

22:58:52.169 MQT: tele/esp_hichi/SENSOR = {"Time":"2025-02-26T22:58:52","EFR-SGM":{"Total_in":77.0842,"Total_out":10.3941,"testcalc3":5942,"testcalc4":-77}}

[gemu2015]

you are right, as it is coded now, 1. parameter must be a decoder line. not a constant.
i will add this to the docs