Smart meter on esp32c3

[FransOv]

I'm trying to read my SageCom T211 meter by means of the Tasmota Smart Meter script on a Lolin esp32C3 Mini. The reason for using this module is that this meter sends a datagram of over 800 bytes every second and the esp8266 simply could not cope with that.

I receive a valid datagram each second from the meter and can see it on the console, but I cannot get the Smart Meter script to work. The sensors are created, but the values are never updated and remain at zero.

I compiled Tasmota with the following options:

#ifndef USE_SML_M

#define USE_SML_M

#endif

#define SML_MAX_VARS 60

#define SML_BSIZ 1060

#define MAX_METERS 1

#define TMSBSIZ 2048

#define USE_SML_SCRIPT_CMD

#define SML_REPLACE_VARS

The script is as follows (I adapted it from the example in the Tasmota Smart Meter  documentation):

>D
>B
smlj=0
->sensor53 r
>R
smlj=0
>S
if upsecs>22
then
smlj=1
endif
>M 1
+1,20,oN1,16,115200,,1
1,=h SageCom T211 3 phase ESMR-5
1,=h<hr/>
1,0-0:96.14.0(@1,Current tariff,,tariff,0
1,=h<hr/>
1,1-0:1.8.1(@1,Energy import T1,kWh,enrg_imp_t1,3
1,1-0:1.8.2(@1,Energy import T2,kWh,enrg_imp_t2,3
1,1-0:2.8.1(@1,Energy export T1,kWh,enrg_exp_t1,3
1,1-0:2.8.2(@1,Energy export T2,kWh,enrg_exp_t2,3
1,1-0:1.7.0(@1,Power import,kW,pwr_imp,3
1,1-0:2.7.0(@1,Power export,kW,pwr_exp,3
1,=h<hr/>
1,1-0:21.7.0(@1,L1 Power import,Kw,l1_pwr_imp,3
1,1-0:41.7.0(@1,L2 Power import,Kw,l2_pwr_imp,3
1,1-0:61.7.0(@1,L3 Power import,Kw,l3_pwr_imp,3
1,1-0:22.7.0(@1,L1 Power import,Kw,l1_pwr_exp,3
1,1-0:42.7.0(@1,L2 Power import,Kw,l2_pwr_exp,3
1,1-0:62.7.0(@1,L3 Power import,Kw,l3_pwr_exp,3
1,=h<hr/>
1,1-0:32.7.0(@1,L1 Voltage,V,volts_l1,1
1,1-0:52.7.0(@1,L2 Voltage,V,volts_l2,1
1,1-0:72.7.0(@1,L3 Voltage,V,volts_l3,1
1,=h<hr/>
1,1-0:31.7.0(@1,L1 Current,A,current_l1,1
1,1-0:51.7.0(@1,L2 Current,A,current_l2,1
1,1-0:71.7.0(@1,L3 Current,A,current_l3,1
1,=h<hr/>
#

Any hints to point me in the right direction?

[Philip Knowles]

You don’t seem to have enabled scripting (but you just have missed it from the list). Not sure if that’s the issue.

 

Sent from Mail for Windows

--
You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/8586c285-a8ee-4566-8784-6199f53b2a82n%40googlegroups.com.

 

[FransOv]

The #define USE_SCRIPT line is also in my user_config_overide.ini. That is not the cause, it looks like the driver gets no input at all. The only thing not completely in line with the example is that the hardware RX of the esp32c3 is on GPIO 20. I'll check the xsns_53_sml.ino but it is a big file so will take some time.

Op donderdag 30 juni 2022 om 23:03:04 UTC+2 schreef knowles...@gmail.com:

[Philip Knowles]

When you say that you see the input on the console, can you upload what you see?

 

The meter definition looks incorrect

+1,20,oN1,16,115200,,1

 

I think the N1 only applies to MODBus. None of the OBIS examples seem to use the 16 counter flag so,  assuming GPIO20 and baud rate of 115200 I would try

+1,20,o,0,115200

 

Regards

 

Phil K

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/5166644d-aa43-4f14-afdd-3833a68a0cf2n%40googlegroups.com.

 

[FransOv]

I just fried my esp32c3. That's my punishment for using 5v and 12v adapters with the same size plug. 

I therefore tried again with an esp8266 D1 mini. Surprisingly that worked to a certain extent. There are a fair number of errors and/or overruns in the serial communication. That is why I need the median filter (16) in the definition. Without it the sensors will get intermittent strange values. The N1 dies not seem to make a difference.

I will solder the pins to a new esp32c3 and try again with that processor. To be continued.

Op vrijdag 1 juli 2022 om 14:49:47 UTC+2 schreef knowles...@gmail.com:

[Philip Knowles]

Oops. Not sure what the final 1 in your definition is for too.

 

Phil K

 

Sent from Mail for Windows

 

From: FransOv
Sent: 01 July 2022 14:44
To: TasmotaUsers
Subject: Re: Smart meter on esp32c3

 

I just fried my esp32c3. That's my punishment for using 5v and 12v adapters with the same size plug. 

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/cd930589-f6f3-4817-999d-4923105d9b77n%40googlegroups.com.

 

[FransOv]

That is a result of copying the example from the documentation, it is the TX gpio, but nothing is transmitted to the meter, and for the esp32c3 it is not the correct port. I'll delete it.

Op vrijdag 1 juli 2022 om 15:54:48 UTC+2 schreef knowles...@gmail.com:

[FransOv]

Stranger and stranger!

After a reset the esp8266 did not receive any information any more. 

I used a fresh esp32c3 mini from Wemos (https://www.wemos.cc/en/latest/c3/c3_mini.html). It looks like the input from the serial interface is intercepted by the command process. See the console output below. The smart meter driver does not receive any information whatsoever. 

19:45:01.839 CMD: /Ene5\T211 ESMR 5.0

19:45:01.844 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:01.854 CMD: 

19:45:01.858 CMD: 1-3:0.2.8(50)

19:45:01.863 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:01.878 CMD: 0-0:1.0.0(220701194500S)

19:45:01.886 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:01.898 CMD: 0-0:96.1.1(4530303632303030303034363439373231)

19:45:01.904 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:01.914 CMD: 1-0:1.8.1(000033.469*kWh)

19:45:01.919 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:01.933 CMD: 1-0:1.8.2(000019.549*kWh)

19:45:01.938 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:01.948 CMD: 1-0:2.8.1(000000.167*kWh)

19:45:01.953 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:01.966 CMD: 1-0:2.8.2(000000.000*kWh)

19:45:01.971 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:01.987 CMD: 0-0:96.14.0(0002)

19:45:01.991 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:02.001 CMD: 1-0:1.7.0(00.540*kW)

19:45:02.006 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:02.016 CMD: 1-0:2.7.0(00.000*kW)

19:45:02.021 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:02.034 CMD: 0-0:96.7.21(00006)

19:45:02.039 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:02.049 CMD: 0-0:96.7.9(00003)

19:45:02.056 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:02.068 CMD: 1-0:99.97.0(0)(0-0:96.7.19)

19:45:02.073 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

19:45:02.085 CMD: 1-0:32.32AD

19:45:02.090 MQT: stat/tasmota_3699D4/RESULT = {"Command":"Unknown"}

Op vrijdag 1 juli 2022 om 16:04:42 UTC+2 schreef FransOv:

[Philip Knowles]

It looks like the script isn’t running. The serial input is being read as commands

 

Are you sure that you have

#ifndef USE_SCRIPT

#define USE_SCRIPT

#endif

#ifndef USE_SML_M

#define USE_SML_M

#endif

#ifdef USE_RULES

#undef USE_RULES

#endif

in user_config_override.h

I therefore tried again with an esp8266 D1 mini. Surprisingly that worked to a certain extent. There are a fair number of errors and/or overruns in the serial communication. That is why I need the median filter (16) in the definition. Without it the sensors will get intermittent strange values. The N1 dies not seem to make a difference.

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/d4cccd41-00da-4f9b-910b-fe767846c13cn%40googlegroups.com.

 

[FransOv]

It looks like the hardware rx port of the esp32c3 being on port 20 is the culprit. I compiled Tasmota with USE_ESP32_SW_SERIAL and used this meter definition: +1,-20,o,16,115200,ESMR5, the minus sign on the port indicating to use software serial.

The smart meter driver now receives the data although with numerous communication errors so I need to use the median filter. An outlier filter would have been even better.

Op vrijdag 1 juli 2022 om 21:09:29 UTC+2 schreef knowles...@gmail.com:

[Philip Knowles]

I wonder if the C3 variant might be an issue. It’s only single core and not as fast as the other ESP32.

 

Would you not be better allocating another GPIO as SerialRx rather than using the hardware port? It would then automatically use SW Serial

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/77893bcd-5c24-42bf-9a9a-d612b4e7a901n%40googlegroups.com.

 

[FransOv]

Hi Phil,

I found the problem. The ESP32C3 has two UART's while the ESP32 has three. The xsns_53 driver assigns the uart's to the meters starting with the highest number, line 2870: uint32_t uart_index = 2; First meter gets index 2, second meter gets index 1 and the third gets index zero. I changed that line to: uint32_t uart_index = 1; and I can now use the hardware serial on the ESP32C3. It can also keep up quite well with the speed with which the meter sends out information. Hardly any corrupted datagrams any more.

Is there a way to check for the subtype of the ESP32 in the coding?  I know about the #ifdef ESP32, but that only indicates a generic ESP32. I found this CONFIG_IDF_TARGET_ESP32C3 . Will it be OK to use that or should I use the value of ESP32_ARCH, that is set to esp32c3 in the module support_esp.ino when CONFIG_IDF_TARGET_ESP32C3  is defined?

Op zaterdag 2 juli 2022 om 09:04:02 UTC+2 schreef knowles...@gmail.com:

[FransOv]

I submitted a problem report and a solution has already been made. Should be resolved in the next release. Quite a neat solution too. Turns out there is a variable that has the number of UART's of the processor used: SOC_UART_NUM.

Op zondag 3 juli 2022 om 14:10:34 UTC+2 schreef FransOv: