Publish Smart Meter values every second

[julKali]

I have an ESP32 running Tasmota and the sensor53 driver that measures data from a smart meter every second.
As I would like to take full advantage of the second-granularity, I would like to receive a JSON MQTT message every second.
I know that teleperiod is limited to >= 10s, so reducing this won't work.
Instead, I wrote a script that should do it:

>D
p:yr=0
p:mon=0
p:day=0
p:hr=0
p:min=0
p:sec=0
p:ts=""
t:tmr=1 ; in sec
>B
=>sensor53 r
smlj=0 ; disable automatic reporting of the measurements
>M 1
+1,3,r,0,9600,HHStrom
1,=so3,256
1,=so4,0CEF85D96E4012C1F2D7C084C6689FA0
1,0209090cUUuu@1,year,,year,0
1,0209090cx2ss@1,month,,month,0
1,0209090cx3ss@1,day,,day,0
1,0209090cx5ss@1,hh,,hh,0
1,0209090cx6ss@1,mm,,mm,0
1,0209090cx7ss@1,ss,,ss,0
1,0209090cx13UUuuUUuu@1000,Zählerstand,kWh,Zaehlerstand,3
1,0209090cx18UUuuUUuu@1000,Einspeisung,kWh,Einspeisung,3
1,0209090cx23UUuuUUuu@1000,Blindenergie,varh,Blindenergie,3
1,0209090cx28UUuuUUuu@1000,Blindenergie einsp,varh,Blindenergie einsp,3
; Letzter Paramater (Precision) = add 16 to send data immediately 0 + 16 = 16
1,0209090cx33UUuuUUuu@1,Momentanleistung,W,Momentanleistung,0
1,0209090cx38UUuuUUuu@1,Einspeiseleistung,W,Einspeiseleistung,0
1,0209090cx43UUuuUUuu@1,Blindleistung,var,Blindleistung,0
1,0209090cx48UUuuUUuu@1,Blindleistung einsp,var,Blindleistung einsp,0
>F ; execs every 100ms
if tmr==0
then
yr=sml[1]
mon=sml[2]
day=sml[3]
hr=sml[4]
min=sml[5]
sec=sml[6]
act_pwr_in=sml[11]
ts=s(4.0yr)+"-"+s(2.0mon)+"-"+s(2.0day)+"T"+s(2.0hr)+":"+s(2.0min)+":"+s(2.0sec)+"02:00"
=>Publish iot/power {"time": "%ts%", "+A [kWh]": %sml[7]%, "-A [kWh]": %sml[8]%, "+R [kvarh]": %sml[9]%, "-R [kvarh]": %sml[10]%, "+P [W]": %sml[11]%, "-P [W]": %sml[12]%, "+Q [var]": %sml[13]%, "-Q [var]": %sml[14]%}
tmr=1
endif
#

I am using the >F directive, as the >S directive is supposedly not reliable. However, writing it like this seems too much work, such then every couple seconds, some messages get lost. Is there any better possibility? I specifically do not want to set all metric precisions to 16, as this results in 14 separate messages that ought to be correlated. I am also interested in all metrics, not just power, so PowerDelta is not sufficient either.

I already tried to compute ts every >F and compare it with the last value but this is obviously more workload. Could I reduce this with a RULE? Will a Berry script be more performant?

Thanks!

[sfromis]

I don't think that you have to worry about workload and performance of the code, until you have specific issues; only "costly" thing is doing the publish. And using the scripter means that you cannot have rules too. What Berry would give you would be better programming features, not better performance.

Are you aware that the meter metrics has a flag in precision to publish data immediately, instead of only at TelePeriod?
https://tasmota.github.io/docs/Smart-Meter-Interface/#meter-metrics

[julKali]

Yes, I am aware. I mentioned the precision field in my post. The problem is that this results in 16 individual messages to the MQTT broker, which I then have to correlate at the subscription side. I would like to have them all in one.

This is really a matter of performance, I believe, as the script works, it just doesn't work reliably enough.

I have also tried using >S (which then allows me to not do the if/then condition). This works better, but also skips an entry every once in a while (every couple tens of seconds).

[sfromis]

Well, what is the specifics behind your guess of performance being the issue? What are you seeing in the Tasmota log when you did not get what you expected.

[julKali]

This is an excerpt from the console:

04:39:49.787 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:39", "+A [kWh]": 10858.73, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 260.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 116.00}"
04:39:49.791 MQT: iot/power = {"time": "2025-06-28T20:06:39", "+A [kWh]": 10858.73, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 260.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 116.00}
04:39:50.786 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:40", "+A [kWh]": 10858.73, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 249.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 113.00}"
04:39:50.793 MQT: iot/power = {"time": "2025-06-28T20:06:40", "+A [kWh]": 10858.73, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 249.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 113.00}
04:39:51.792 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:41", "+A [kWh]": 10858.73, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 253.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 114.00}"
04:39:51.799 MQT: iot/power = {"time": "2025-06-28T20:06:41", "+A [kWh]": 10858.73, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 253.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 114.00}
04:39:52.748 MQT: iot/tele/tasmota_8E2DEC/STATE = {"Time":"1970-01-01T04:39:52","Uptime":"0T04:39:53","UptimeSec":16793,"Heap":164,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":4,"Objects":42},"Wifi":{"AP":1,"SSId":"iot","BSSId":"28:C6:8E:85:8B:68","Channel":1,"Mode":"HT40","RSSI":52,"Signal":-74,"LinkCount":1,"Downtime":"0T00:00:04"}}
04:39:52.792 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:42", "+A [kWh]": 10858.73, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 256.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 115.00}"
04:39:52.797 MQT: iot/power = {"time": "2025-06-28T20:06:42", "+A [kWh]": 10858.73, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 256.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 115.00}
04:39:54.799 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:44", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 259.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 114.00}"
04:39:54.804 MQT: iot/power = {"time": "2025-06-28T20:06:44", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 259.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 114.00}
04:39:56.786 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:46", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 255.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 114.00}"
04:39:56.791 MQT: iot/power = {"time": "2025-06-28T20:06:46", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 255.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 114.00}
04:39:57.791 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:47", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 259.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 115.00}"
04:39:57.796 MQT: iot/power = {"time": "2025-06-28T20:06:47", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 259.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 115.00}
04:39:59.820 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:49", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 256.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 114.00}"
04:39:59.825 MQT: iot/power = {"time": "2025-06-28T20:06:49", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 256.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 114.00}
04:40:00.823 SCR: performs "Publish iot/power {"time": "2025-06-28T20:06:50", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 255.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 113.00}"
04:40:00.830 MQT: iot/power = {"time": "2025-06-28T20:06:50", "+A [kWh]": 10858.74, "-A [kWh]": 0.00, "+R [kvarh]": 336.39, "-R [kvarh]": 1433.51, "+P [W]": 255.00, "-P [W]": 0.00, "+Q [var]": 0.00, "-Q [var]": 113.00}

Note how the timestamp for "2025-06-28T20:06:48" is skipped. I presume this happens because the chip occasionally cannot keep up with processing and sending the MQTT request in time for the next second.

Btw, I just saw there is a Discord server. We can move the discussion there if that is the preferred channel for such questions.

[julKali]

Okay, after some experimentation I modified my script like so:

>D
ts=""
sec_prev=0
>B
=>sensor53 r
smlj=0 ; disable automatic reporting of the measurements
>M 1
+1,3,r,0,9600,power
1,=so3,256
1,=so4,0CEF85D96E4012C1F2D7C084C6689FA0
1,=so6,500
1,0209090cUUuu@1,year,,year,0
1,0209090cx2ss@1,month,,month,0
1,0209090cx3ss@1,day,,day,0
1,0209090cx5ss@1,hh,,hh,0
1,0209090cx6ss@1,mm,,mm,0
1,0209090cx7ss@1,ss,,ss,0
1,0209090cx13UUuuUUuu@1000,Zählerstand,kWh,Zaehlerstand,3
1,0209090cx18UUuuUUuu@1000,Einspeisung,kWh,Einspeisung,3
1,0209090cx23UUuuUUuu@1000,Blindenergie,varh,Blindenergie,3
1,0209090cx28UUuuUUuu@1000,Blindenergie einsp,varh,Blindenergie einsp,3
; Letzter Paramater (Precision) = add 16 to send data immediately 0 + 16 = 16
1,0209090cx33UUuuUUuu@1,Momentanleistung,W,Momentanleistung,0
1,0209090cx38UUuuUUuu@1,Einspeiseleistung,W,Einspeiseleistung,0
1,0209090cx43UUuuUUuu@1,Blindleistung,var,Blindleistung,0
1,0209090cx48UUuuUUuu@1,Blindleistung einsp,var,Blindleistung einsp,0
>F ; >F execs every 100ms
if sec_prev!=sml[6]
then
sec_prev=sml[6]
ts=s(4.0sml[1])+"-"+s(2.0sml[2])+"-"+s(2.0sml[3])+"T"+s(2.0sml[4])+":"+s(2.0sml[5])+":"+s(2.0sml[6])+"02:00"
=>Publish iot/power {"time": "%ts%", "+A [kWh]": %sml[7]%, "-A [kWh]": %sml[8]%, "+R [kvarh]": %sml[9]%, "-R [kvarh]": %sml[10]%, "+P [W]": %sml[11]%, "-P [W]": %sml[12]%, "+Q [var]": %sml[13]%, "-Q [var]": %sml[14]%}
endif
#

Two key changes: Firstly, I simplified the script, getting rid of many variables. I think making them persistent had a big impact on performance. Second, I set the =so6 option of serial sync time to 500ms (default is 1s). This, if I understand correctly, will now sample the serial connection twice a second and not once.

Secondly, I used >F to be sure to have a good granularity, but then determined the 1s interval by looking at whether the current second value reported by the meter has changed.

Together, those changes make it report every second exactly (from an empirical test over a couple of minutes).

I will close this.