Issues with difference calculations

[redm123]

Hi! I'm having some issues with difference calculations in smart meter scripts I don't understand. Not sure, if I'm maybe missing something here or if there is some bug(s) somewhere... It seems to work overall, but going closer something looks fishy.

First of, I wonder how the difference calculation actually works... documentation of =d says:

Calculate difference between metric values decoded at time intervals (up to 10 =d lines possible)
e.g. 1,=d 3 10 calculate 10 second interval difference of decoder entry 3

I read this as: it takes the input values at interval time apart and simply calculates the difference. So in my case: one value of Total_in, after 60s another value of Total_in, and the difference thereof. But it also seems to convert the kWh to W... or something. At least the resulting values are not even close to the pure diff, but rather match the momentary W values directly from the meter... So how does this really work?

Then the observations:

• the values of =d are delayed by about 4 minutes (compared to source values Total_in, and momentary values of Pcurrent), while the interval is only 60s
• even several minute long energy spikes are completely lost, even though the source values Total_in react immediately and are sampled at about 2s intervals (at least thats how it updates in the web UI). A manual calculation of a 60s diff of Total_in comes pretty close to the 4kW, so the information is there, in the data.

An image to illustrate observations. The green line is delayed over the yellow and orange, and the 2-3min 4kW peak in the yellow line is completely lost.

I have the following Smart Meter Definition (slightly shortened):

>M 1
+1,3,s,16,9600,EFR-SGM
1,77070100010800ff@1000,Bezug Total,kWh,Total_in,4
1,=d 1 60 @1,1-min-Leistung In ±6W,W,Pcurrent1_in,0
1,77070100100700ff@1,Leistung Aktuell,W,Pcurrent,0
#

[gemu2015]

yes you are right, i will clarify this in the documentation. =D is meant for meters that do not have a momentary power but only total kWh.
it calculates the consumed kW for the defined Period from kWh and thus per hour
but you can do every math you desire e.g. in >S section of script

>D
delta=0
last=0
>S
; calculate difference every 10 seconds
if upsecs%10==0 {
delta=sml[1]-last
last=sml1[1]
}
>W
Delta{m}%delta%

[redm123]

Ah, good catch ... I wanted to try that out, but forgot about it 😬

But if you say "5 point" that would mean 5 updates from the meter? As this seems to update every 2s or so, that should be no more than 10s...? But I'll try removing nonetheless.

[gemu2015]

if you query a delta every 60 seconds delay would be up to 4 times 60 seconds = 4 minutes

[redm123]

Ah ok, yea that makes sense. I guess that should explain both observations then.

I was under the impression that median works on the raw data. Which comes in every 2s. Wouldn't that make more sense, if the goal is just to catch outliers in the measured data? For my old meter I had a 3-min delta, to keep the result somewhat accurate, and that creates a lag of 12min or something like that, which is pretty long...

[gemu2015]

as said before, don't use SML math for your special requests. with scripting math you have much more options and time resolutions.

[redm123]

Well, yea... It was just a thought for improvement, as the lag could get pretty long with several minutes deltas.

I'm fine for now with the median flag removed. And don't want to go down that rabbit hole with scripting ;) Just wanted to understand what's going on.