Smart Meter Interface / Scripting - how to decode multiple values from string

[nagyrobi]

Trying to set up my P1 Smart Meter with OBIS ascii interface. (based on docs here)

Having nice progress:

Two questions:

• the meter sends an OBIS string very long, like this:
  0-0:98.1.0(210201000000W)(000000.000*kWh)(000000.000*kWh)(000000.000*kWh)(000000.000*kWh)(000000.000*kWh)(000000.000*kWh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kWh)(00.000*kW)(00.000*kW)(00.000*kW)(00.000*kW)(00.000*kW)(00.000*kW)
  It contains monthly values. I'd like to extract each field between parentheses separately (separate command for each field would be ok). Or at least get them all in a big string. Can't figure it out from the docs. 1,0:98.1.0(@#),Havi adat,,havi,0 only extracts the first field. 1,0:98.1.0(@#,Havi adat,,havi,0 only extracts the first and half of the second field.
• the values extracted as string have quotes around them on the web interface. How to remove these?

[kugelkopf123]

Have a look on this: issue 10644

[nagyrobi]

I've seen that but it's no help.

[gemu2015]

there is definitely no support for very large strings in scripts. (max string size is 48)
i can think of a more general approach to select the nth entry of an obis value in sml
i will tune in again if i have looked at that.

[gemu2015]

ok tried a solution. since i do not have such a meter you may try this version.

you must define this serial buffer size, it is default to 48
#define SML_BSIZ 48
since your obis strings are very large you may choose e.g. 512

since this is times meters and meter is preset to
#define MAX_METERS 5

you would loose 2,5k of RAM or else decrease the MAX_METERS

then in the obis decoder try this:

1,0:98.1.0(@(0:1,Havi adat, KWh,havi1,3
1,0:98.1.0(@(1:1,Havi adat, KWh,havi2,3
1,0:98.1.0(@(2:1,Havi adat, KWh,havi3,3

e.g. the xpression (1: selects to skip one open bracket

if it works ill do a pr

EDIT:
MQTT issue solved by pr

new version in issues

[nagyrobi]

MAX meters means how many devices I have connected to the same Tasmota and want to read them separately with Smart Meter driver? I have just one, so is it safe to set #define MAX_METERS 1?

[nagyrobi]

Seems to work! How can I read the first field as a string?

[nagyrobi]

I was able to read a few, but as soon as I add all the fields to the script, almost everything will be zero:

And what's more strange, is that the MQTT is truncated. Not even all the fields will be present:
21:22:17.376 MQT: tele/elmu_bal/SENSOR = {"Time":"2021-02-20T21:22:17","telj_imp":1.378,"telj_exp":0.000,"fesz_l2":0.0,"havi_adat1":0.000,"havi_adat2":0.000,"havi_adat3":0.000,"havi_adat4":0.000,"havi_adat5":0.000,"havi_adat6":0.000,"havi_adat7":0.000,"havi_adat8":0.000,"havi_adat9":0.000,"havi_adat10":0.000,"havi_adat11":0.000,"havi_adat12":0.000,"havi_adat13":0.000,"havi_adat14":0.000,"havi_adat15":0.000,"havi_adat16":0.000,"havi_adat17":0.000,"havi_adat18":0.000,"havi_adat19":0.000}}

The script:

>D  
>B  
->sensor53 r
>M 1  
+1,3,o,16,115200,N,1
1,1-0:1.8.0(@1,Energia import,kWh,enrg_imp,3
1,1-0:2.8.1(@1,Energia export,kWh,enrg_exp,3
;1,=h—————————————
1,0:1.7.0(@1,Teljesítmény import,kW,telj_imp,3
1,0:2.7.0(@1,Teljesítmény export,kW,telj_exp,3
;1,13.7.0(@1,Teljesítmény tényez,,factor,3
1,32.7.0(@1,L1 Feszültség,V,fesz_l1,1
1,52.7.0(@1,L2 Feszültség,V,fesz_l2,1
1,72.7.0(@1,L3 Feszültség,V,fesz_l3,1
1,0:14.7.0(@1,Frekvencia,Hz,freq,2
;1,31.7.0(@1,L1 Áram,A,aram_l1,2
;1,51.7.0(@1,L2 Áram,A,aram_l2,2
;1,71.7.0(@1,L3 Áram,A,aram_l3,2
1,0:3.8.0(@1,Energia meddő import,kvarh,enrg_imp_med,3
1,0:4.8.0(@1,Energia meddő export,kvarh,enrg_imp_med,3
;1,0:98.1.0(@(0:#,Havi dátum,,havi_datum,3
1,=h—————————————
1,0:98.1.0(@(1:1,Havi adat1,kWh,havi_adat1,3
1,0:98.1.0(@(2:1,Havi adat2,kWh,havi_adat2,3
1,0:98.1.0(@(3:1,Havi adat3,kWh,havi_adat3,3
1,0:98.1.0(@(4:1,Havi adat4,kWh,havi_adat4,3
1,0:98.1.0(@(5:1,Havi adat5,kWh,havi_adat5,3
1,0:98.1.0(@(6:1,Havi adat6,kWh,havi_adat6,3
1,0:98.1.0(@(7:1,Havi adat7,kvarh,havi_adat7,3
1,0:98.1.0(@(8:1,Havi adat8,kvarh,havi_adat8,3
1,0:98.1.0(@(9:1,Havi adat9,kvarh,havi_adat9,3
1,0:98.1.0(@(10:1,Havi adat10,kvarh,havi_adat10,3
1,0:98.1.0(@(11:1,Havi adat11,kvarh,havi_adat11,3
1,0:98.1.0(@(12:1,Havi adat12,kvarh,havi_adat12,3
1,0:98.1.0(@(13:1,Havi adat13,kvarh,havi_adat13,3
1,0:98.1.0(@(14:1,Havi adat14,kW,havi_adat14,3
1,0:98.1.0(@(15:1,Havi adat15,kW,havi_adat15,3
1,0:98.1.0(@(16:1,Havi adat16,kW,havi_adat16,3
1,0:98.1.0(@(17:1,Havi adat17,kW,havi_adat17,3
1,0:98.1.0(@(18:1,Havi adat18,kW,havi_adat18,3
1,0:98.1.0(@(19:1,Havi adat19,kW,havi_adat19,3

;1,0:96.13.0(@#),Üzenet,,msg,0
;1,0-0:96.1.0(@#),Gyári szám,,sn,0
#

[nagyrobi]

Seems that when I try to read more than 10 or 12 values, errorneous values start appearing. I start getting values like 2 for voltage (which sould be around 230V) etc.

[gemu2015]

the max. Number of decode lines is set to 20
you must expand it by setting a higher value
#define SML_MAX_VARS xx

To start sml Mqtt after e.g. 10 seconds
in script you set additional to other things
>B

smlj=0

>S
If upsecs>10
then
smlj=1
endif

[nagyrobi]

SML_MAX_VARS was set to 40.

[nagyrobi]

And yes! The smlj method is excellent to avoid first tele message with zeros!!!
To make 100% sure that it will not happen, I use upsecs>22, as the meter transmits data every 10 seconds, and if Tasmota boots in the same moment as a bunch of data is coming, I might want to skip that. And the next one. Teleperiod is set to 60 for me (300 default) so I am well inside the first teleperiod timeframe anyway.
Thank you!

[gemu2015]

Probably your total string length is to high?
How many bracket values do you have in one line? How many chars is the line
Will simulate this tomorrow

[nagyrobi]

The entire OBIS is:

0-0:98.1.0(210201000000W)(000000.000kWh)(000000.000kWh)(000000.000kWh)(000000.000kWh)(000000.000kWh)(000000.000kWh)(000000.000kvarh)(000000.000kvarh)(000000.000kvarh)(000000.000kvarh)(000000.000kvarh)(000000.000kvarh)(000000.000kWh)(00.000kW)(00.000kW)(00.000kW)(00.000kW)(00.000kW)(00.000*kW)

[gemu2015]

Check the number of chars and ensure that the serial buffer length is large enough SML_BSIZ

will simulate this tomorrow

[nagyrobi]

The full OBIS is 316 characters. An ASCII character = 1 byte so that should be 316 bytes. I've set my SML_BSIZ to 512 so it should fit in. However might this be for the entire data package???? Or just this row?

[nagyrobi]

FYI this is how the entire data package looks like

/AUX1234567890

0-0:1.0.0(1234567890W)
0-0:42.0.0(AUX1234567890)
0-0:96.1.0(123456779876)
0-0:96.14.0(0002)
0-0:96.50.68(ON)
0-0:17.0.0(90.000*kW)
1-0:1.8.0(000071.318*kWh)
1-0:1.8.1(000030.104*kWh)
1-0:1.8.2(000041.214*kWh)
1-0:1.8.3(000000.000*kWh)
1-0:1.8.4(000000.000*kWh)
1-0:2.8.0(000003.762*kWh)
1-0:2.8.1(000003.762*kWh)
1-0:2.8.2(000000.000*kWh)
1-0:2.8.3(000000.000*kWh)
1-0:2.8.4(000000.000*kWh)
1-0:3.8.0(000000.569*kvarh)
1-0:4.8.0(000032.521*kvarh)
1-0:5.8.0(000000.568*kvarh)
1-0:6.8.0(000000.001*kvarh)
1-0:7.8.0(000001.988*kvarh)
1-0:8.8.0(000030.533*kvarh)
1-0:15.8.0(000075.081*kWh)
1-0:32.7.0(228.7*V)
1-0:52.7.0(229.1*V)
1-0:72.7.0(226.6*V)
1-0:31.7.0(003*A)
1-0:51.7.0(002*A)
1-0:71.7.0(001*A)
1-0:13.7.0(0.921)
1-0:33.7.0(0.933)
1-0:53.7.0(0.829)
1-0:73.7.0(0.988)
1-0:14.7.0(50.01*Hz)
1-0:1.7.0(01.418*kW)
1-0:2.7.0(00.000*kW)
1-0:5.7.0(00.000*kvar)
1-0:6.7.0(00.000*kvar)
1-0:7.7.0(00.000*kvar)
1-0:8.7.0(00.599*kvar)
0-0:98.1.0(210201000000W)(000000.000*kWh)(000000.000*kWh)(000000.000*kWh)(000000.000*kWh)(000000.000*kWh)(000000.000*kWh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kvarh)(000000.000*kWh)(00.000*kW)(00.000*kW)(00.000*kW)(00.000*kW)(00.000*kW)(00.000*kW)
0-0:96.13.0(��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������)
!FB50

The last telegram is called "textual message from the electricity provider" but I have no clue what could it be. Don't know exactly what those characters are, but they count exactly 512. I guess they must be some placeholders for an actual message.

[nagyrobi]

Is it important to keep the order of the decoding in the script with the order the OBISes come in the data package?
Because if I enable this line 1,13.7.0(@1,Teljesítmény tényez,,factor,3, voltages are not decoded correcly anymore.

[gemu2015]

ok testest your script. strange things happen and it took some time to find why.
there were additional spaces at the end of some lines. currently don't know why but that causes this behavior.
when i deleted these spaces it worked without problems.

but i found a bug in the dump function that is now fixed, so dont rely on dump on the current version

according to the serial buffer you need it as small as possible and as large as needed and it is meant per line (terminated with CRLF)

and the order of decode lines does not need to follow the order of telegrams

[nagyrobi]

Ok so the last line 0-0:96.13.0 is the longest, has 526 characters, +CR LF, it means the serial buffer should be at least 528, right? Is it safe to set it to 530?

Also, for the line with many fields in brackets 0-0:98.1.0 can you give me a hint how to get the value as a string, not number?
Can you share the fixes with me so I can test?

[nagyrobi]

there were additional spaces at the end of some lines

Which lines were with spaces? I only found spaces ocassionally after >D and >M 1, I think the web based text editor has something to do with them as I remember cleaning them from there and they re-appear after a while.

[gemu2015]

yes 530 is OK.

only 1 String per meter is supported with # decode key

this script worked with all the bracket values
obis_script.txt

you need no new tasmota version as long as you dont rely on dump mode sensor53 d1

[nagyrobi]

only 1 String per meter is supported with # decode key

OK so is it possible to get only this first bracket value 1,0:98.1.0(@(0:1,Havi adat0,kWh,havi_adat0,3 as string? This is the only string I need.

[gemu2015]

yes but not with bracket option but text option and only the 1. value in line

example
-1,1-0:0.0.0*255(@#),Zähler Nr,,Meter_number,0

[nagyrobi]

Ah :(
Because from all the brackets the first is text (date), the rest are numeric values :(

[nagyrobi]

Still not working. Can you please check this for me? What am I doing wrong? I recompiled with buffer set to 530.
script_robi.txt

Result is that the MQTT has missing values:
13:26:45.445 MQT: tele/elmu_bal/SENSOR = {"Time":"2021-02-21T13:26:45","telj_imp":1.633,"telj_exp":0.347,"havi_adat1":0.000,"havi_adat2":0.000,"havi_adat3":0.000,"havi_adat4":0.000,"havi_adat5":0.000,"havi_adat6":0.000,"havi_adat7":0.000,"havi_adat8":0.000,"havi_adat9":0.000,"havi_adat10":0.000,"havi_adat11":0.000,"havi_adat12":0.000,"havi_adat13":0.000,"havi_adat14":0.000,"havi_adat15":0.000,"havi_adat16":0.000,"havi_adat17":0.000,"havi_adat18":0.000,"havi_adat19":0.000}}

See? It only contains telj_imp and telj_exp, and all the havi_* while the script defines others too.
This reflects in the web interface too:

[nagyrobi]

And while in this state, clicking on Edit script in the web interface doesn't load the script, it's empty.

[gemu2015]

this is very strange i can't explain.

[gemu2015]

meanwhile i found the reason why it is unstable. I testet with 115200 and 9600 and with 115200 a lot of bytes are skipped because the system is not fast enough with 9600 no errors

can you configure your meter to 9600 ? i am sure the esp8266 will not be able to handle 115200 with this driver without loosing characters.
if not the serial irq buffer has to be largely increased. this would need extra configuration.

[nagyrobi]

No unfortunately the meter is hardcoded to 115200 by the electricity provider, and t it's all double sealed in a distribution box etc. they only allowed me to plug in a cable which is data output only (it's a TX port, has no physical RX connection).

Actually I was considering for the same thing last evening but unfortunately wasn't able to find where to configure the serial IRQ buffer.
Characters get lost for sure sometimes because if you disable the script and just watch for the strings with SerialSend 1 that can be noticed.
The borderline seems to be at 10 lines in the script, if i configure more, data starts to be corrupted.

[gemu2015]

ok i made the serial IRQ buffer size configurable
#define TMSBSIZ 1024
now it seems to work with 115200 if the gaps between the bursts are not too short.

xsns_53_sml.ino.zip

[nagyrobi]

testing, hold on

[nagyrobi]

What's your suggestion for SML_MAX_VARS? Is 120 enough for my case?

[gemu2015]

maxvars 50 should be enough even with your meter

[nagyrobi]

Whooaa! Now much better, sir!

[nagyrobi]

What I also did meanwhile was to remove all unneeded drivers from the build. Much like a tasmota-lite config, now the whole thing is small and snappy.

I think this is ready to be pushed in to main code. I volunteer to complete documentation and samples at https://tasmota.github.io/docs/Smart-Meter-Interface/ if that's OK with you.

[nagyrobi]

for sure adding this to the documentation would be great!

now please test it for a while and when it is really stable i will do a pr tomorrow

Let me know when you submitted the pr, so I can start writing the doc

[gemu2015]

here is the final version to test. i made a few additional tweaks. your ugly string value overflowed the text variable. this is now also fixed.

also if you define too many decode lines these are ignored now (with debug message), and don't overflow the descriptor.

here is a hint for that large meter descriptors that you have.
#ifdef SML_REPLACE_VARS
allows for replacing repeated parts of the descriptor with text variables

in >D
define a text variable
r="1,0-0:98.1.0(@("

then in the descriptor

%r%1:1,Havi import,kWh,havi_import,3
%r%2:1,Havi export,kWh,havi_export,3
%r%3:1,Havi adat3,kWh,havi_adat3,3

%r% inserts the text variable and saves some space (3 instead of 15 chars)

xsns_53_sml.ino.zip

[nagyrobi]

OK testing, hold on.

[nagyrobi]

SML_REPLACE_VARS and text variable replacement works, thank you. The ugly string still causes an invalid JSON on MQTT here, but as I said I don't see how you could reproduce it in your environment as I suspect those are not some standard encoded characters and I don't know (yet) what they are.

[gemu2015]

found another bug, now even your ugly string is also put to MQTT (truncated)
will do a pr now

[nagyrobi]

Another question: do you think it's possible to decode VBus data with this method? Could you have a look at this topic?
#10988

[gemu2015]

the sml driver uses several methods to access serial data.
e.g. in obis the serial data stream is processed in a shift register and on EVERY char compared to the decoder array searching for patterns, same is true for sml with binary data.

another method is predefined pattern like ebus. data is not shifted but sampled in the buffer until end of telegram and then compared.

third method is MODBUS bidirectional mode where a demand string is send and a response is decoded.

i am not familiar with VBUS but it is probably similar to EBUS.
feel free to add the code to this driver as long as you dont disturb the functionality of the existing modes.

you may simply introduce a new 'v' mode and isolate the code by checking for this mode. you may probably use the existing decoder syntax for decoding.

i can assist you if you have questions

[gemu2015]

after a closer look at the VBUS i think it will be very easy to implement this in the sml driver.
a special decoder is needed for the septet format because the payload must have bit 7 cleared but that is a trivial task
if you provide a couple of sample packets i will check how to implement this. i can easily test then with my simulator setup.

[nagyrobi]

For the documentation, can you please write a few describing words for each of the below, and what's their default value:

#define SML_MAX_VARS N
#define USE_SML_SCRIPT_CMD
#define SML_BSIZ N
#define MAX_METERS N
#define TMSBSIZ N
#define SML_REPLACE_VARS

[gemu2015]

SML_MAX_VARS (default 20)
max number of decode lines (html lines not counted)

SML_BSIZ (default 48)
max number of chars in serial input buffer. complete chunk of serial data must fit into this size

MAX_METERS (default 5)
max number of meters

TMSBSIZ (default 256)
max number of chars in serial IRQ buffer
(should always be larger than SML_BSIZ and even larger on high baud rates)

#define USE_SML_SCRIPT_CMD
this allows access to sml vars in scripts

#define SML_REPLACE_VARS
this allows replacement of any text in descriptor by script text variables.
only useful if several occurrences of a text occupies a lot of space and you get short of script buffer
because readability gets worse only makes sense on large descriptors

[gemu2015]

pr is done

[nagyrobi]

Doc updated with all extras appeared here, pr sent in.

[nikito7]

Just read this.

There is a limit with raw
Can only decode 10 registers
Like this r0104006C0009
After 09 will not decode

Not tested the stuff talked above yet!

[nagyrobi]

I think you should start a new discussion topic as this was about ASCII and it was solved, works.

[nagyrobi]

@gemu2015 , Looks like dump mode has problems now (latest git pull from tasmota repo):
Some string parts are repeated in the next lines, and some are truncated (see 0-0:98.1.0):
Values decoding by script is OK, only dump is affected imho.

09:40:31.385 : /AUX59902722892�������������������������������������������������������������������������������������������������������������
09:40:31.389 : 0-0:1.0.0(210301094030W)����������������������������������������������������������������������������������������������������
09:40:31.392 : 0-0:42.0.0(AUX1030302722892)������������������������������������������������������������������������������������������������
09:40:31.395 : 0-0:96.1.0(9902722892)22892)
09:40:31.397 : 0-0:96.14.0(0001)2892)
09:40:31.399 : 0-0:96.50.68(ON))
09:40:31.402 : 0-0:17.0.0(90.000*kW))
09:40:31.405 : 1-0:1.8.0(000258.053*kWh)92)
09:40:31.407 : 1-0:1.8.1(000103.763*kWh)
09:40:31.410 : 1-0:1.8.2(000154.290*kWh)
09:40:31.412 : 1-0:1.8.3(000000.000*kWh)
09:40:31.415 : 1-0:1.8.4(000000.000*kWh)
09:40:31.417 : 1-0:2.8.0(000048.019*kWh)
09:40:31.420 : 1-0:2.8.1(000032.465*kWh)
09:40:31.422 : 1-0:2.8.2(000015.554*kWh)
09:40:31.425 : 1-0:2.8.3(000000.000*kWh)
09:40:31.427 : 1-0:2.8.4(000000.000*kWh)
09:40:31.430 : 1-0:3.8.0(000003.513*kvarh))
09:40:31.433 : 1-0:4.8.0(000156.519*kvarh)
09:40:31.436 : 1-0:5.8.0(000003.498*kvarh)
09:40:31.439 : 1-0:6.8.0(000000.015*kvarh)
09:40:31.442 : 1-0:7.8.0(000027.396*kvarh)
09:40:31.445 : 1-0:8.8.0(000129.123*kvarh)
09:40:31.447 : 1-0:15.8.0(000306.073*kWh))
09:40:31.450 : 1-0:32.7.0(227.0*V)73*kWh)
09:40:31.453 : 1-0:52.7.0(226.4*V)
09:40:31.456 : 1-0:72.7.0(230.5*V)
09:40:31.458 : 1-0:31.7.0(002*A)V)
09:40:31.461 : 1-0:51.7.0(001*A)
09:40:31.463 : 1-0:71.7.0(001*A)
09:40:31.466 : 1-0:13.7.0(0.447)
09:40:31.469 : 1-0:33.7.0(0.116)
09:40:31.472 : 1-0:53.7.0(0.603)
09:40:31.474 : 1-0:73.7.0(0.883)
09:40:31.477 : 1-0:14.7.0(49.99*Hz)3*kWh)
09:40:31.480 : 1-0:1.7.0(00.037*kW)
09:40:31.482 : 1-0:2.7.0(00.394*kW)
09:40:31.485 : 1-0:5.7.0(00.000*kvar)kWh)
09:40:31.488 : 1-0:6.7.0(00.000*kvar)
09:40:31.491 : 1-0:7.7.0(00.398*kvar)
09:40:31.493 : 1-0:8.7.0(00.316*kvar)
09:40:31.644 : 0-0:98.1.0(210301000000W)(000249.070*kWh)(000100.816*kWh)(000148.254*kWh)(000047.903*kWh)(000032.349*kWh)(000015.554*kWh)(00)
09:40:31.872 : 0-0:96.13.0(����������������������������������������������������������������������������������������������������������������)
09:40:31.876 : !B8D86.13.0(����������������������������������������������������������������������������������������������������������������

Compiled with:

#define SML_MAX_VARS 60
#define USE_SML_SCRIPT_CMD
#define SML_BSIZ 1060
#define MAX_METERS 1
#define TMSBSIZ 2048
#define SML_REPLACE_VARS

[nagyrobi]

Tried with SML_DUMP_SIZE 1060 (so it's equal to SML_BSIZ) but now it truncates the begginnings of the lines???

12:45:31.278 : /AUX59902722892
12:45:31.281 : 0-0:1.0.0(210301124530W)
12:45:31.284 : 0-0:42.0.0(AUX1030302722892)
12:45:31.287 : 0-0:96.1.0(9902722892)
12:45:31.290 : 0-0:96.14.0(0001)
12:45:31.292 : 0-0:96.50.68(ON)
12:45:31.295 : 0-0:17.0.0(90.000*kW)
12:45:31.298 : 1-0:1.8.0(000258.337*kWh)
12:45:31.301 : 1-0:1.8.1(000104.047*kWh)
12:45:31.303 : 1-0:1.8.2(000154.290*kWh)
12:45:31.306 : 1-0:1.8.3(000000.000*kWh)
12:45:31.309 : 1-0:1.8.4(000000.000*kWh)
12:45:31.312 : 1-0:2.8.0(000051.019*kWh)
12:45:31.315 : 1-0:2.8.1(000035.465*kWh)
12:45:31.317 : 1-0:2.8.2(000015.554*kWh)
12:45:31.320 : 1-0:2.8.3(000000.000*kWh)
12:45:31.323 : 1-0:2.8.4(000000.000*kWh)
12:45:31.326 : 1-0:3.8.0(000003.513*kvarh)
12:45:31.329 : 1-0:4.8.0(000158.614*kvarh)
12:45:31.332 : 1-0:5.8.0(000003.498*kvarh)
12:45:31.335 : 1-0:6.8.0(000000.015*kvarh)
12:45:31.338 : 1-0:7.8.0(000029.212*kvarh)
12:45:31.341 : 1-0:8.8.0(000129.402*kvarh)
12:45:31.343 : 1-0:15.8.0(000309.356*kWh)
12:45:31.346 : 1-0:32.7.0(233.9*V)
12:45:31.349 : 1-0:52.7.0(229.1*V)
12:45:31.352 : 1-0:72.7.0(229.1*V)
12:45:31.354 : 1-0:31.7.0(002*A)
12:45:31.357 : 1-0:51.7.0(003*A)
12:45:31.360 : 1-0:71.7.0(002*A)
12:45:31.362 : 1-0:13.7.0(0.908)
12:45:31.365 : 1-0:33.7.0(0.755)
12:45:31.368 : 1-0:53.7.0(0.903)
12:45:31.371 : 1-0:73.7.0(0.988)
12:45:31.373 : 1-0:14.7.0(50.00*Hz)
12:45:31.376 : 1-0:1.7.0(00.000*kW)
12:45:31.379 : 1-0:2.7.0(01.688*kW)
12:45:31.382 : 1-0:5.7.0(00.000*kvar)
12:45:31.384 : 1-0:6.7.0(00.000*kvar)
12:45:31.387 : 1-0:7.7.0(00.776*kvar)
12:45:31.390 : 1-0:8.7.0(00.000*kvar)
12:45:31.543 W)(04.872*kW)(04.072*kW)(01.844*kW)(01.672*kW)(01.844*kW)
12:45:31.773 ��������������)
12:45:31.776 : !8FBF

[gemu2015]

ok, next try (index variable to small uint8)

[nagyrobi]

Much better now, thanks!!!
For the docs, anything special note about SML_DUMP_SIZE ? Max possible value etc?

[nagyrobi]

@gemu2015 ?

[gemu2015]

no special limit but reduces heap ram size on esp8266