TasmotaSerial: RS485/ModBus broken @115200bps?

[corbolais]

Hey guys,

I'd appreciate your input here: got an esp8266 with Tasmota 12 flashed, built locally with modbus support.

Once the esp is running, querying and displaying battery voltage is working. Adding a query for, say, battery current, the battery voltage is displayed as 0V and current as 0A. Whereas battery voltage beforehand showed like 26.61V. Reverting the query of battery current will however not bring back battery voltage display.

Script:

>D
>B
->sensor53 r
;disable publishing at MQTT teleperiod, on boot
smlj=0
>S
;re-enable publishing at MQTT teleperiod, after 10 seconds of uptime
if upsecs>10
then
smlj=1
endif
>M 1
+1,1,m,0,115200,T4215BN,3,10,r010431040001;,r010431050001
1,=hBattery
1,010402UUuuxxxx@i0:100,Vb,V,Vb,2
;01 04 02 0a 6d 7e 7d
;1,010402UUuuxxxx@i1:100,Ib,A,Ib,2
;01 04 02 00 00 b9 30 
#

I inserted comments with the response to the queries, as shown when debugging is enabled via sensor53 d1. So the esp <-> Tracer communication via modbus is working correctly. The values are sensible and the right ones as measured by DM.

Any ideas why this might happen? This behaviour seems rather non-deterministic to me.

Thanks for your feedback.

[corbolais]

Update:
I get the battery voltage display back if the query string does end after the 3104 query:

+1,1,m,0,115200,T4215BN,3,10,r010431040001

Line end and the display is good.
But I'd like to display more than just battery voltage.
How is this possible?

[corbolais]

Now, when I change the order of the queried registers like so: current first (r010431050001), voltage last (r010431040001).
And I also change the order of indexes (i1: vs. i0:), things start getting ... funny:

+1,1,m,0,115200,T4215BN,3,10,r010431050001,r010431040001
1,=hBattery
1,010402UUuuxxxx@i1:100,Vb,V,Vb,2
1,010402UUuuxxxx@i0:100,Ib,A,Ib,2

The web UI shows:

Battery
T4215BN Vb	0.00 V
T4215BN Ib	26.61 A

Well, that's the correct number for the battery voltage. But it is displayed as the current's value. It's supposed to display Vb 26.61V and Ib 0 A.

So there's some serious issue regarding indexing it appears. Unless I'm messing something up which might happen sometimes.

Please, could anyone explain to me what is happening and why?

[corbolais]

+1,1,mN1,0,115200,T4215BN,3,10,r010431040002
1,=hBattery
1,010404UUuu@i0:100,Vb,V,Vb,2
1,010404xxxxUUuu@i0:100,Ib,A,Ib,2

Not working as such
Values displayed: all 0.0
Dump:

10:07:24.188 transmit index >> 0
10:07:24.190 > 01 04 31 04 00 02 3e f6 
10:07:25.187 transmit index >> 0
10:07:25.189 > 01 04 31 04 00 02 3e f6 
10:07:26.158 transmit index >> 0
10:07:26.160 > 01 04 31 04 00 02 3e f6 
10:07:27.187 transmit index >> 0
10:07:27.189 > 01 04 31 04 00 02 3e f6 
10:07:28.188 transmit index >> 0
10:07:28.190 > 01 04 31 04 00 02 3e f6

tx only. no rx.

Actually, now it stopped working altogether. Tx only. No matter what.
Yikes.

[nikito7]

+1,1,mN1,0,115200,T4215BN,3,10,r010431040002

I dont know the correct order

But I use gpio 3 and gpio 1 in esp8266.

And gpio 19 and gpio 18 in esp32.

Its esp8266 or esp32 ?

You feed ttl with 3.3v or 5V ?

[nikito7]

About serial. You could test with TCP BRIDGE.

Tcp brigde is "rtuovertcp" in modbus softwares

https://github.com/nikito7/edpbox/blob/dev/tasmota/BRIDGE-TCP.js

And change gpios in templates to TCP RX and TCP TX

[corbolais]

About serial. You could test with TCP BRIDGE.

Tcp brigde is "rtuovertcp" in modbus softwares

https://github.com/nikito7/edpbox/blob/dev/tasmota/BRIDGE-TCP.js

And change gpios in templates to TCP RX and TCP TX

EPever Solar Station software does not support TCP Bridge.

[corbolais]

+1,1,mN1,0,115200,T4215BN,3,10,r010431040002

I dont know the correct order

But I use gpio 3 and gpio 1 in esp8266.

Yes, the same here. 1->RX, 3->TX.

And gpio 19 and gpio 18 in esp32.

Its esp8266 or esp32 ?

ESP8266 and ESP32.

You feed ttl with 3.3v or 5V ?

3.3V UART connection.

[corbolais]

Using this:

+1,1,m,0,115200,T4215BN,3,10,r0104311b0001,r010431060001,r010431050001,r010431040001
1,=hBattery
1,010402UUuuxxxx@i1:100,Tb,C,Tb,2
1,010402UUuuxxxx@i2:100,Pb,W,Pb,2
1,010402UUuuxxxx@i3:100,Ib,A,Ib,2
1,010402UUuuxxxx@i0:100,Vb,V,Vb,2 
#

Yields:

Battery
T4215BN Tb	0.00 C
T4215BN Pb	0.00 W
T4215BN Ib	0.00 A
T4215BN Vb	26.60 V

That is, everything is zeroed except the battery voltage (which is queried last, gets index 0).
If the last query (battery voltage) is omitted, the rest of the queries is displayed correctly:

Battery
T4215BN Tb	17.78 C
T4215BN Pb	0.00 W
T4215BN Ib	0.00 A
T4215BN Vb	0.0 V

Correct Temperature (and presumably also P and I as it is dark outside). V is zero as there's no data queried. And debugging shows all values are received correctly, just not displayed as it should be.
One could say, well, ignore the web UI data if responses are valid and transmitted as such to MQTT. Fair enough. Trouble is: the values transmitted via MQTT correspond to those displayed in the web UI:

MQT: tele/gt_AEDF5B/SENSOR = {"Time":"2022-09-02T23:54:00","T4215BN":{"Tb":0.00,"Pb":0.00,"Ib":0.00,"Vb":26.60}}

[gemu2015]

this is strange behavior. modbus scripts are used by a lot of users without issues. i myself use 3 different devices. what Tasmota version are you using ? you should use the most recent dev version
at least some users seems to have success with Epever
(#12800)

[corbolais]

this is strange behavior.

It sure is. I'll recheck the modbus responses. IIRC, the responses are spot on, only the conversion fails somehow.

modbus scripts are used by a lot of users without issues. i myself use 3 different devices. what Tasmota version are you using ? you should use the most recent dev version at least some users seems to have success with Epever (#12800)

Yes, I found that ticket prior. It is a Tracer A, though. I have yet to get the A series' register specification. Basically, that oughta be the same principle. Not sure where the devil's hiding.

One thing to notice in #12800 is the index starting at 1:

[...]
+1,1,m,16,115200,,3,10,r010431100001,r0104311A0001,r0104331A0001,r0104331B0001,r010431000001,r010431010001,r010431020001,r0104310C0001,r0104310D0001,r0104310E0001,r010433040001,r0104330A0001,r0104330C0001,r010433120001,r010433030001
;
1,=h Batterie
1,010402SSssxxxx@i1:100,Temp,°C,Batt Temperature,2
[...]

There's no index 0 to be found and neither a requested block "0" in the the transmit section of the meter definition whereas the documentation states:

- in case of MODBus, ix: designates the index (x = 0..n) referring to the requested block in the transmit section of the meter definition

It is 15 request blocks indexed i1..i15. When trying to reproduce exactly this, all values are pinned to 0.0 .

Thanks for replying anyways. :)

[corbolais]

Daily dose of testing:

Register addresses according to a document titled "B-Series MODBUS Specification
EPEVER Corporation", filename "ControllerProtocolV2.3.pdf".

Battery capacity query via r0104311a0001 yields 01 04 02 00 64 b8 db (0064h -> 100). Above document states "Times 100", however it is in fact times "1". Result is "100%".

Battery voltage query via r0104331A0001 yields 01 04 02 0a 64 be 7b (0a64h -> 2660). Above document states "Times 100", which is correct and results in "26.60V". However the doc states register address 331Ah is "Battery voltage" but filed under "Statistical Parameters". Section "Examples" states: "Read real-time battery voltage" from "Register Address: 0x3104", this address is not listed in the "Realtime Datum" table, though. Buggers.

Battery temperature (external sensor) query via 01 04 31 1b 00 01 4f 31 yields 01 04 02 05 92 3b cd (0592h -> 1426). This correctly results in "14.26°C", which is a fresh late summers night's outside temperature.

There's a catch: the order of queries above is only displayed in the corresponding line in the attached image if the indices "ix:" are given as shown below. The indices are all over the place if indices start at 0. They seem fine if indices start at 1. In the latter case the last query, the one for the battery temperature (Tb) is sent last (would be index 3) but needs to be accessed via index 0 (i0:).

+1,1,m,0,115200,T4215BN,3,10,r0104311a0001,r0104331A0001,r0104311b0001
1,=hBattery
1,010402UUuuxxxx@i1:1,Capb,%,Capb,2 ; r0104311a0001
1,010402UUuuxxxx@i2:100,Vbstat,V,Vbstat,2 ; r0104331A0001
1,010402UUuuxxxx@i0:100,Tb,°C,Tb,2 ; r0104311b0001
; sensor53 d1
;00:34:32.738 > 01 04 31 1a 00 01 1e f1 
;00:34:32.784 : 01 04 02 00 64 b8 db 
;00:34:33.706 > 01 04 33 1a 00 01 1f 49 
;00:34:33.751 : 01 04 02 0a 64 be 7b 
;00:34:34.680 > 01 04 31 1b 00 01 4f 31 
;00:34:34.729 : 01 04 02 05 92 3b cd

Displayed as:

Given all this, one might think the decoding algo is defunct. According to the internet no other (EPever Tracer BN?) owner/user experiences the same issue. Or is it that none use EPever Tracer BN series devices and for other SML/modbus decoders this is working out ok?

Consequently, I'd rather like to assume there's a fault on my part, wiring or whatever.
But: The values sent back from the Tracer BN are all good. It's just the decoding going haywire. Doh. Time to delve into "xdrv_10_scripter.ino", "xsns_53_sml.ino", maybe "xdrv_63_modbus_bridge.ino"?

Ideas anyone?

Thanks.

[gemu2015]

beging the author of this driver i checked the modbus code again and could not find any reason for this behavior.
(the involved code is only in "xsns_53_sml.ino")
Indices always start with index 0. the example in #12800 starts with index 1, but the registers given are also offset by 1, so they are displayed correctly and only index 15 should be invalid in this example.
since your dump is correct your hardware is not involved in this error.

i have just 2 remarks:

1. there is no support for comments at the end of a line, only a whole line can be commented out.
2. you do not need xx decoding entry at the end of decoding, only in front if you want to skip an entry.

+1,1,m,0,115200,T4215BN,3,10,r0104311a0001,r0104331a0001,r0104311b0001
1,=hBattery
; cap = r0104311a0001
1,010402UUuu@i0:1,Capb,%,Capb,2
; volt = r0104331a0001
1,010402UUuu@i1:100,Vbstat,V,Vbstat,2
; tmp = r0104311b0001
1,010402UUuu@i2:100,Tb,°C,Tb,2

just to be sure use the latest code that i use for testing. if we can't track i will provide a version with additional debugging.

xsns_53_sml.ino.zip

[corbolais]

beging the author of this driver i checked the modbus code again and could not find any reason for this behavior.

Thank you for taking the time to check this out. Very much appreciated.

(the involved code is only in "xsns_53_sml.ino") Indices always start with index 0. the example in #12800 starts with index 1, but the registers given are also offset by 1, so they are displayed correctly and only index 15 should be invalid in this example.

Not sure, I'm getting this. Just correct me if I'm wrong:
The values given in the example reference "i1:" so the first query to be decoded for "i1:" is "r0104311A0001", correct? That way, "i15:" is out of bounds. Last valid index should be "i14:" with query "r010433030001" and "i0:" isn't used at all.

since your dump is correct your hardware is not involved in this error.

That is what was reassuring and troubling at the same time. ;-) But no, it's a relief that the data coming back is at least OK. We'll see what the cause of all this is..

i have just 2 remarks:

1. there is no support for comments at the end of a line, only a whole line can be commented out.

Oh, nice. Thank you for pointing that out. I suspected so at one point but neglected to verify the fact.

2. you do not need xx decoding entry at the end of decoding, only in front if you want to skip an entry.

Very valuable input. I don't think this is documented anywhere, I might be wrong though.

+1,1,m,0,115200,T4215BN,3,10,r0104311a0001,r0104331a0001,r0104311b0001
1,=hBattery
; cap = r0104311a0001
1,010402UUuu@i0:1,Capb,%,Capb,2
; volt = r0104331a0001
1,010402UUuu@i1:100,Vbstat,V,Vbstat,2
; tmp = r0104311b0001
1,010402UUuu@i2:100,Tb,°C,Tb,2

Will check this.

Any idea about the discrepancy of the correction factor "Times 100" regarding the cap response? The EPever documentation can be found here: ControllerProtocolV2.3.pdf

The other thing is: battery voltage ought to be 331a or 3104? Very strangely the latter is only referenced in the example of the above doc pdf but also found in examples all over the net, IIRC.

just to be sure use the latest code that i use for testing. if we can't track i will provide a version with additional debugging.

xsns_53_sml.ino.zip
I'll certainly have a look and let you know my results.

Thank you!

[corbolais]

Using your sample like this:

>D
>B
->sensor53 r
;disable publishing at MQTT teleperiod, on boot
smlj=0
>S
;re-enable publishing at MQTT teleperiod, after 10 seconds of uptime
if upsecs>10
then
smlj=1
endif
>M 1
+1,1,m,0,115200,T4215BN,3,10,r0104311a0001,r0104331a0001,r0104311b0001
1,=hBattery
; cap = r0104311a0001
1,010402UUuu@i0:1,Capb,%,Capb,2
; volt = r0104331a0001
1,010402UUuu@i1:100,Vbstat,V,Vbstat,2
; tmp = r0104311b0001
1,010402UUuu@i2:100,Tb,°C,Tb,2
#

results in this

I'll check the code in your attachement.

[corbolais]

Hm. The source is differing:

sha1sums:

c55dfa71b213d55e487d9d88aeae0db91ad2e43c  tasmota_xsns_sensor/xsns_53_sml.ino
4cc4d6b7a611e332335b5dcc0d411714634d96c3  xsns_53_sml.ino

Just did a rebase on master: up-to-date. Master had 3 more commits, none regarding SML stuff.

Latest git hash for "tasmota_xsns_sensor/xsns_53_sml.ino" is de52580a18f5034fcaae69f045ce6509c108e003 (commit msg "sml special options descriptor") in my codebase.

development branch has a file "tasmota_xsns_sensor/xsns_53_sml.ino" with 5525395d1ee6c269796089a7b15d295c7b384449. So far I just followed the master branch.

[gemu2015]

the code is different because i implemented a new meter type (KAMSTRUP)

[corbolais]

the code is different because i implemented a new meter type (KAMSTRUP)

With respect to master or development branch?

I have no clue so far as to why the values are mangled in the web ui display.

[gemu2015]

this is a debug version that prints out the transmit and receive index with dump data in normal (not dump mode)

xsns_53_sml.ino.zip

[corbolais]

can you lower the baud rate or it the tracer fixed to115200 ?

Uh. Good question. Should be feasible. I'm not eager to go this route right now, though. It'd mean to disassemble the PV unit to get hold of the Tracer, hook it up to a pc and change the values using the proprietary software. No fun in that.
Edit: tried setting baudrate via the EPever Tracer Software. It is not working. Baudrate remains at 115200bps no matter what setting is selected. (See also below)

I'd focus on the queue/slot issue, if you will. That's the pressing issue for me and that hickup is likely to be independent of the baudrate setting. The frequency of missing responses is one thing, the disturbing thing is that responses get bubbled up to the wrong tx-rx-slot.

[corbolais]

can you lower the baud rate or is the tracer fixed to115200 ?

others are using 9600

Noted. To-Be-Done.
Tried and failed. See prior post or below.

[gemu2015]

strange thing is that many responses are missing at all. if there were a checksum error at least an error response would be sent (if supported by this tracer ?)
you probably may try to set the time slot higher. currently 1 second
---------------------------- 10 = tenth of seconds time slot e.g to 20 = 2 seconds
+1,1,m,0,115200,T4215BN,3,10,r0104311a0001,r0104331a0001,r0104311b0001

[corbolais]

+1,1,m,0,115200,T4215BN,3,30,r0104311a0001,r0104331a0001,r0104311b0001

log:

16:28:11.030 transmit index >> 2
16:28:11.033 > 01 04 31 1b 00 01 4f 31 
16:28:14.209 transmit index >> 0
16:28:14.211 > 01 04 31 1a 00 01 1e f1 
16:28:14.255 receive index >> 0
16:28:14.257 > 01 04 02 07 00 bb 00 01 00 00 
16:28:17.419 transmit index >> 1
16:28:17.421 > 01 04 33 1a 00 01 1f 49 
16:28:20.828 transmit index >> 2
16:28:20.831 > 01 04 31 1b 00 01 4f 31 
16:28:20.877 receive index >> 2
16:28:20.879 > 01 04 02 0a 8e 3f f4 01 00 00 
16:28:24.130 transmit index >> 0
16:28:24.133 > 01 04 31 1a 00 01 1e f1 
16:28:27.262 transmit index >> 1
16:28:27.265 > 01 04 33 1a 00 01 1f 49 
16:28:27.312 receive index >> 1
16:28:27.314 > 01 04 02 00 64 b8 db 01 00 00 
16:28:30.597 transmit index >> 2
16:28:30.600 > 01 04 31 1b 00 01 4f 31 
16:28:33.839 transmit index >> 0
16:28:33.842 > 01 04 31 1a 00 01 1e f1 
16:28:33.888 receive index >> 0
16:28:33.890 > 01 04 02 07 00 bb 00 01 00 00 
16:28:37.077 transmit index >> 1
16:28:37.080 > 01 04 33 1a 00 01 1f 49 
16:28:40.367 transmit index >> 2
16:28:40.370 > 01 04 31 1b 00 01 4f 31 
16:28:40.416 receive index >> 2
16:28:40.418 > 01 04 02 0a 8e 3f f4 01 00 00 
16:28:43.650 transmit index >> 0
16:28:43.652 > 01 04 31 1a 00 01 1e f1 
16:28:46.737 transmit index >> 1
16:28:46.740 > 01 04 33 1a 00 01 1f 49 
16:28:46.786 receive index >> 1
16:28:46.789 > 01 04 02 00 64 b8 db 01 00 00 
16:28:49.942 transmit index >> 2
16:28:49.944 > 01 04 31 1b 00 01 4f 31 
16:28:53.297 transmit index >> 0
16:28:53.300 > 01 04 31 1a 00 01 1e f1 
16:28:53.575 receive index >> 0
16:28:53.577 > 01 04 02 07 00 bb 00 01 00 00 
16:28:56.489 transmit index >> 1
16:28:56.492 > 01 04 33 1a 00 01 1f 49 
16:28:59.634 transmit index >> 2
16:28:59.636 > 01 04 31 1b 00 01 4f 31 
16:28:59.682 receive index >> 2

This excerpt looks to me like there's one successfull tx-rx cycle then a missing rx, then again a successfull trx-cycle. One could argue this being an improvement. So, next try: 6s delay.

[corbolais]

+1,1,m,0,115200,T4215BN,3,30,r0104311a0001,r0104331a0001,r0104311b0001

log:

16:28:11.030 transmit index >> 2
16:28:11.033 > 01 04 31 1b 00 01 4f 31 
16:28:14.209 transmit index >> 0
16:28:14.211 > 01 04 31 1a 00 01 1e f1 
16:28:14.255 receive index >> 0
16:28:14.257 > 01 04 02 07 00 bb 00 01 00 00 
16:28:17.419 transmit index >> 1
16:28:17.421 > 01 04 33 1a 00 01 1f 49 
16:28:20.828 transmit index >> 2
16:28:20.831 > 01 04 31 1b 00 01 4f 31 
16:28:20.877 receive index >> 2
16:28:20.879 > 01 04 02 0a 8e 3f f4 01 00 00 
16:28:24.130 transmit index >> 0
16:28:24.133 > 01 04 31 1a 00 01 1e f1 
16:28:27.262 transmit index >> 1
16:28:27.265 > 01 04 33 1a 00 01 1f 49 
16:28:27.312 receive index >> 1
16:28:27.314 > 01 04 02 00 64 b8 db 01 00 00 
16:28:30.597 transmit index >> 2
16:28:30.600 > 01 04 31 1b 00 01 4f 31 
16:28:33.839 transmit index >> 0
16:28:33.842 > 01 04 31 1a 00 01 1e f1 
16:28:33.888 receive index >> 0
16:28:33.890 > 01 04 02 07 00 bb 00 01 00 00 
16:28:37.077 transmit index >> 1
16:28:37.080 > 01 04 33 1a 00 01 1f 49 
16:28:40.367 transmit index >> 2
16:28:40.370 > 01 04 31 1b 00 01 4f 31 
16:28:40.416 receive index >> 2
16:28:40.418 > 01 04 02 0a 8e 3f f4 01 00 00 
16:28:43.650 transmit index >> 0
16:28:43.652 > 01 04 31 1a 00 01 1e f1 
16:28:46.737 transmit index >> 1
16:28:46.740 > 01 04 33 1a 00 01 1f 49 
16:28:46.786 receive index >> 1
16:28:46.789 > 01 04 02 00 64 b8 db 01 00 00 
16:28:49.942 transmit index >> 2
16:28:49.944 > 01 04 31 1b 00 01 4f 31 
16:28:53.297 transmit index >> 0
16:28:53.300 > 01 04 31 1a 00 01 1e f1 
16:28:53.575 receive index >> 0
16:28:53.577 > 01 04 02 07 00 bb 00 01 00 00 
16:28:56.489 transmit index >> 1
16:28:56.492 > 01 04 33 1a 00 01 1f 49 
16:28:59.634 transmit index >> 2
16:28:59.636 > 01 04 31 1b 00 01 4f 31 
16:28:59.682 receive index >> 2

This excerpt looks to me like there's one successfull tx-rx cycle then a missing rx, then again a successfull trx-cycle. One could argue this being an improvement. So, next try: 6s delay.

Nope, not happening:

16:31:43.433 transmit index >> 1
16:31:43.436 > 01 04 33 1a 00 01 1f 49 
16:31:50.527 transmit index >> 2
16:31:50.529 > 01 04 31 1b 00 01 4f 31 
16:31:50.575 receive index >> 2
16:31:50.577 > 01 04 02 0a 8f fe 34 01 00 00 
16:31:57.389 transmit index >> 0
16:31:57.391 > 01 04 31 1a 00 01 1e f1 
16:32:03.693 transmit index >> 1
16:32:03.695 > 01 04 33 1a 00 01 1f 49 
16:32:03.742 receive index >> 1
16:32:03.744 > 01 04 02 00 64 b8 db 01 00 00 
16:32:10.116 transmit index >> 2
16:32:10.119 > 01 04 31 1b 00 01 4f 31 
16:32:16.516 transmit index >> 0
16:32:16.518 > 01 04 31 1a 00 01 1e f1 
16:32:16.563 receive index >> 0
16:32:16.565 > 01 04 02 07 01 7a c0 01 00 00 
16:32:23.185 transmit index >> 1
16:32:23.188 > 01 04 33 1a 00 01 1f 49 
16:32:29.908 transmit index >> 2
16:32:29.910 > 01 04 31 1b 00 01 4f 31 
16:32:29.956 receive index >> 2
16:32:29.958 > 01 04 02 0a 8f fe 34 01 00 00

Back to 3s delay.

[gemu2015]

probably yet a hardware issue. what rs485 converter are you using ?

[corbolais]

probably yet a hardware issue. what rs485 converter are you using ?

Using the one marked "XY-017" on the back side silkscreen.

Well, I spent my time trying to change the default baudrate from 115200 to 9600 to no avail.

After the fact, I checked and realised I should've checked first: Recommendation is not to change the baudrate.. Bummer. Their proprietary software (Solar Station Monitor V1.95) isn't working in all aspects presented (at all): You cannot change the baudrate, it's there and then nothing. But that's another chapter.

So, back to square one: 115200bps.

How to debug TasmotaSerial, again? ;-)

[corbolais]

I changed BAUDRATE 9600 to 115200 in xsns_53_sml.ino before realizing that I'm using a script_meter. Compile, flash and run shows there's no rx at all after this change. This shouldn't happen, IMO, as SML_BAUDRATE is only used in METER_DESC of predefined meters. This change must not introduce changes in behaviour when using scripted meters, or must it?

[gemu2015]

#define SML_BAUDRATE in sml driver has no effect since it is only used when scripting is NOT used which is normally no longer the case with this driver,
it will definitely not change anything in script defined meters since the static descriptors are not used at all in this case.

[corbolais]

#define SML_BAUDRATE in sml driver has no effect since it is only used when scripting is NOT used which is normally no longer the case with this driver, it will definitely not change anything in script defined meters since the static descriptors are not used at all in this case.

Correct. My bad. Again. But rx aren't back either.

[corbolais]

Using SML_SetBaud via sml(1 0 115200) it is clear, no hardware serial is at play here. What's max baudrate with software serial? Most likely less than 115200bps. So, question is, why no hw serial when GPIO01 and GPIO03 are set:

+1,1,m,0,115200,T4215BN,3,30,r0104311a0001,r0104331a0001,r0104311b0001

Is it for the swapped RX/TX pins? Then I'd need to get the hot iron out. But why aren't all rx's lost then..

[gemu2015]

i overlooked that you swapped tx,rx in the descriptor. on an esp8266 this leads to not using hardwareserial but software serial. this is not really recommended at 115200 baud.
if possible always use hardware serial for serial io.

on an ESP32 the pins are multiplexed and the first 3 defined serial ports are always hardware serial.

[corbolais]

This gets more and more interesting.

I've got an esp32 with the same firmware settings and script as the esp8266, for easy comparison equally with swapped rx/tx pins. Now, they're correctly crossed over and the script meter description is:

+1,1,m,0,115200,T4215BN,3,30,r0104311a0001,r0104331a0001,r0104311b0001

After bootup at the very first moment, Vbstat briefly was correctly displayed as 28.33V. A couple of seconds later, the display shuffled and it ended up displaying the same mixed up mess as usual (as with the esp8266).

I managed to grab the log and it shows what was happening:

13:45:44.089 transmit index >> 1
13:45:44.093 > 01 04 33 1a 00 01 1f 49 
13:45:44.134 receive index >> 1
13:45:44.138 > 01 04 02 0b 11 7e 0c 0b 00 00 
13:45:45.223 transmit index >> 2
13:45:45.227 > 01 04 31 1b 00 01 4f 31 
13:45:46.178 transmit index >> 0
13:45:46.181 > 01 04 31 1a 00 01 1e f1 
13:45:46.219 receive index >> 0
13:45:46.223 > 01 04 02 04 15 7a 3f 01 00 00 
13:45:47.175 transmit index >> 1
13:45:47.179 > 01 04 33 1a 00 01 1f 49 
13:45:48.194 transmit index >> 2
13:45:48.198 > 01 04 31 1b 00 01 4f 31 
13:45:48.238 receive index >> 2
13:45:48.242 > 01 04 02 0b 11 7e 0c 01 00 00 
13:45:49.195 transmit index >> 0
13:45:49.199 > 01 04 31 1a 00 01 1e f1 
13:45:50.194 transmit index >> 1
13:45:50.198 > 01 04 33 1a 00 01 1f 49 
13:45:50.238 receive index >> 1
13:45:50.242 > 01 04 02 00 61 78 d8 01 00 00 
13:45:51.207 transmit index >> 2
13:45:51.211 > 01 04 31 1b 00 01 4f 31 
13:45:52.207 transmit index >> 0
13:45:52.211 > 01 04 31 1a 00 01 1e f1 
13:45:52.251 receive index >> 0
13:45:52.255 > 01 04 02 04 15 7a 3f 01 00 00 
13:45:53.209 transmit index >> 1
13:45:53.213 > 01 04 33 1a 00 01 1f 49 
13:45:54.210 transmit index >> 2
13:45:54.214 > 01 04 31 1b 00 01 4f 31 
13:45:54.254 receive index >> 2
13:45:54.258 > 01 04 02 0b 11 7e 0c 01 00 00 

33 1a (tx index 1) is Vbstat with a value of 0b 11 (2833d -> 28.33V).

Next time tx index 1 is sent, there's no response but on the subsequent tx index 1 being sent the response is 00 61 (97d -> 97% capacity charged). So it seems to get it right the first time but not any more after that.

With the esp32, hw serial should be employed. This I have not yet verified, though.

Next up: correctly crossing over rx/tx on the esp8266.
Done. Now positively using hardware serial on the esp8266. Good thing.
Data still messed up, though.

[s-hadinger]

Esp32 only support hw serial. Sw serial was never implemented on Tasmota for esp32

[gemu2015]

the SML driver supports software serial on the ESP32 as it uses its own serial driver (not Tasmota serial).

[corbolais]

the SML driver supports software serial on the ESP32 as it uses its own serial driver (not Tasmota serial).

I noticed the esp32 SS implementation, yes.

[nikito7]

Tasmota cannot decode 2 bytes responses.

Use count 2 in raw at least

[corbolais]

Tasmota cannot decode 2 bytes responses.

In what respect should this be valid? And if so, why cannot Tasmote decode 2 byte responses?

Use count 2 in raw at least

My guess is you're referring to the meter description and raw queries.

Using

+1,3,m,0,115200,T4215BN,1,30,r0104311a0002,r0104331a0002,r0104311b0002

yields

11:34:19.942 transmit index >> 1
11:34:19.944 > 01 04 33 1a 00 02 5f 48 
11:34:19.947 receive index >> 1
11:34:19.949 > f0 01 04 04 0a 9e 00 16 18 00 
11:34:23.025 transmit index >> 2
11:34:23.027 > 01 04 31 1b 00 02 0f 30 
11:34:25.999 transmit index >> 0
11:34:25.001 > 01 04 31 1a 00 02 5e f0 
11:34:26.001 receive index >> 0
11:34:26.003 > 01 84 02 c2 c1 01 04 04 18 00 
11:34:29.009 transmit index >> 1
11:34:29.011 > 01 04 33 1a 00 02 5f 48 
11:34:29.014 receive index >> 1
11:34:29.016 > 01 04 04 0a 9e 00 13 d8 7f 00 
11:34:32.019 transmit index >> 2
11:34:32.021 > 01 04 31 1b 00 02 0f 30 
11:34:35.001 transmit index >> 0
11:34:35.003 > 01 04 31 1a 00 02 5e f0 
11:34:35.009 receive index >> 0
11:34:35.011 > 01 84 02 c2 c1 01 04 04 7f 00

Which is remarkable for the rx idx 2 response of 01 84 02 c2 c1 01 04 04 18 00 but a bad response nevertheless.

The web ui displays 0.0 only on every occasion, so decoding is not happening. Responses are still intermittent.

Can you clarify your statements, please?

[nikito7]

Ok maybe its not your case.

About this 01 84 02 c2 c1 01 04 04 18 00

01 84 02 c2 c1 error
01 04 04 18 00 incomplete response

Have you change this?

#define SML_MAX_VARS 50
#define MAX_METERS 1

[corbolais]

01 84 02 c2 c1 error
01 04 04 18 00 incomplete response

Thanks.

#define SML_MAX_VARS 50

Left this untouched. It's unclear to me why SML_MAX_VARS should be increased, I'm using three registers, so even 20 should provide ample space for extension.

#define MAX_METERS 1

This is left at the default value of 5.

Is there any reason to know of to change the defaults?

[nikito7]

Memory or buffer issues

[nikito7]

If you have time, compile 12.1.1 stable with this:

// ### ### ###
// user_config_override.h
// sml configs

#undef USE_RULES
#define USE_SCRIPT
#define USE_SML_M
#define USE_SML_SCRIPT_CMD
#define SML_MAX_VARS 50
#define SML_REPLACE_VARS

// tcp

#define USE_TCP_BRIDGE

// misc

#define USE_SCRIPT_WEB_DISPLAY
#define USE_SCRIPT_JSON_EXPORT
#define MAX_METERS 1
#define MAXSVARS 10

// eof

(This is what I use in my devices, all its not needed, but is for compare)

and paste here sensor53 d1 logs

My modbus devices are working fine.

Above posts you have 00 00 after crc, it's not normal.
It will break modbus checksum check

[corbolais]

Do your devices talk via modbus @115200bps? It's (was so far) suspected this issue is related to speed as usually the devices communicate @ 9600bps . Also, the meter is an EPever Tracer4215BN series PV ctrl, this might also have a play at this game. Changing bps is not an option, though (see above).

Above posts you have 00 00 after crc, it's not normal.
It will break modbus checksum check

Mh, interesting. The response values are sensible/correct however. Only the rx index is off. That's why the values are displayed in the wrong place in the web display.

My tasmota/user_config_override.h config is similar to yours, only the following are not changed from defaults:

#define SML_MAX_VARS 50
#define SML_REPLACE_VARS
#define MAX_METERS 1
#define MAXSVARS 10
#define USE_TCP_BRIDGE

Will try your setup for the sake of it. Keep you posted.

Thanks.

[nikito7]

With high speed is easy to get errors.

Maybe wiring issues.

Use an utp pair wires for A/B. (same color)

[nikito7]

If your device is sending 00 00 at the end.

There is not fix....

[corbolais]

With high speed is easy to get errors.

Maybe wiring issues.

Use an utp pair wires for A/B. (same color)

I'm using an SSTP CAT7 cable. I'm inclined to believe the cable is alright.

[corbolais]

If your device is sending 00 00 at the end.

There is not fix....

I'm ignoring how a response can be sensible and valid but fail a CRC check. The error had to be in the CRC itself, which is hard to believe. Or it is a multiple error miraculously resulting in a sensible and valid value. IDK, am I missing something?

[corbolais]

OK, back to square one. Once more.

Looks like the RS485 adapter got fried at some point, now it's only Txing, no Rx. After replacement, Rx is functional.

That is not to say, the Rx indexing is miraculously fixed. Rx indexing is still off.

[nikito7]

Maybe is to fast for adapter.

You could try to feed rs485 with 5V

[gemu2015]

i am quite sure it must be a hardware issue.
you may check this article:
https://electrical-engineering-portal.com/correct-cabling-modbus-rs485

[corbolais]

Maybe is to fast for adapter.

Possibly. Sad thing is, I cannot reduce (or change at all, for that matter) the Tracer's baudrate.

You could try to feed rs485 with 5V

Yes, this is a good point. I already pondered over it but did not try so far.

[corbolais]

i am quite sure it must be a hardware issue. you may check this article: https://electrical-engineering-portal.com/correct-cabling-modbus-rs485

I'd be happy to find the issue, for sure! ;) I'll have a look at the link you provided. Thanks.

Edit: well, the only thing different to the correct cabling according to above link is a missing termination of 120ohm. The distance however is only 15 meters, shielded twisted pair cabling. OTOH, using the MT50 with 3 meters unshielded cabling is working well (termination status unknown).

It is equally unclear from a hardware point of view why of three Tx two successive ones succeed while after the third Tx no Rx is happening.

Are mailboxes in use for hw-serial in a esp8266? What are the conditions a mb gets a msg appended and how does hw-serial in a esp8266 dequeue mb msgs? Is there a chance the missing Rx isn't queued for some (probably hw-related) reason? Or is it rather discarded after dequeueing for a unmet software condition? I hadn't had a look at the hw-serial code in a esp8266 yet.

[corbolais]

Hi there,

Working on this I am.
There must be something going (horribly) wrong in Tasmota regarding EPever Tracer4215BN Tx/Rx/en-/decoding.

I'm asking for the battery realtime voltage register before asking for battery SOC, yet the value I get back for SOC is actually that of the battery. And Tx for query no. 3 (tx index 2) is never getting any Rx at all. Subsequent Txs get their (or any, as in the bat voltage/SOC confusion) Rx.

+1,3,m,0,115200,T4215BN,1,50,r010431020002,r0104330C0002,r010431040001,r0104311a0001
1,=hBattery
; PV pwr = r010431020002
1,010404uuuuUUUU@i0:100,PVpwr,W,PVpwr,2
; PVpwday = r0104330C0002
1,010404uuuuUUUU@i1:100,PVpwday,kWh,PVpwday,3
; volt_real = r010431040001
1,010402UUuu@i2:100,Vbreal,V,Vbreal,2
; cap = r0104311a0001
1,010402UUuu@i3:1,Capb,pc,Capb,2
#

Console log:

17:49:40.554 transmit index >> 0
17:49:40.556 > 01 04 31 02 00 02 de f7 
17:49:40.559 receive index >> 0
17:49:40.560 > 01 04 04 00 00 00 00 fb 84 00 
17:49:45.567 transmit index >> 1
17:49:45.569 > 01 04 33 0c 00 02 be 8c 
17:49:45.571 receive index >> 1
17:49:45.572 > 01 04 04 00 02 00 00 5a 44 00 
17:49:50.659 transmit index >> 2
17:49:50.661 > 01 04 31 04 00 01 7e f7 
17:49:55.672 transmit index >> 3
17:49:55.674 > 01 04 31 1a 00 01 1e f1 
17:49:55.676 receive index >> 3
17:49:55.678 > 01 04 02 0a 32 3e 45 01 44 00

Web display:

Bat voltage gets no Rx, hence no voltage display (0.00V).
Bat SOC percentage however gets the register content of bat voltage. I'm wondering where the bat SOC registers' content has gone then. As a note aside, once the script's saved, bat SOC briefly has values displayed in the range of "13800.00" before switching to the bat voltage value.

The values that are displayed are sensible and OK. So communication in itself is believed to be good. There's no difference in behaviour wether 3.3V or 5V supplied to the RS485 module. Tested with an esp8266 with 3.3V for the RS485 module and an esp32 with 5V for the RS485 module. Results are identical. Both using hardware serial @115200bps. This setting cannot be changed, AFAIK. I tried but failed and documentation either states, changing baudrate is not possible or should not be done. Either way, it's not going to happen. Cabling is a non-brainer, too. I'm also using this USB dongle with twin screw terminal for A/B input available online. Using this dongle and identical cabling etc., I can successfully start the EPever solar station monitor on windows. This proprietary software is working fine with regards to the values displayed. So up to the physical point of contact where the RS485 adapters access the low level data everything in the setup remains unchanged. The adapter used to fish out the data is of no concern (to me anyways ATM) as there's the correct data Tx/Rx happening. The only variable left over is Tasmota itself, the ESPs (be it esp8266 or esp32) have been swapped and multiple devices have been tested. It's all invariant. The remaining DUT is Tasmota/the RS485/serial code.

Communication sniffed per logic-analyser shows nothing unusual or missing. Tx no. 3 in particular gets transmitted fine and has a corresponding Rx. This is corroborating with the fact that the correct bat voltage value is displayed. It just happens to be displayed in the wrong place.

All in all, this points to some off-by-one error in Tasmota. So the Rx's get shifted by one and the last one (bat SOC in this case) gets lost.

Judging by the scarcity of complaint about this situation to be found online, this is supposedly tightly tied to the EPever Tracer4215BN series, notably the "BN" series, in particular.

Happy weekend!

[corbolais]

Addendum: I just had the urge to see where the Rx value for the bat SOC has gone. I added the same bat SOC query again and again:

+1,3,m,0,115200,T4215BN,1,50,r010431020002,r0104330C0002,r010431040001,r0104311a0001,r0104311a0001,r0104311a0001,r0104311a0001
1,=hBattery
; PV pwr = r010431020002
1,010404uuuuUUUU@i0:100,PVpwr,W,PVpwr,2
; PVpwday = r0104330C0002
1,010404uuuuUUUU@i1:100,PVpwday,kWh,PVpwday,3
; volt_real = r010431040001
1,010402UUuu@i2:100,Vbreal,V,Vbreal,2
; SOC = r0104311a0001
1,010402UUuu@i3:1,SOC,pc,SOC,2
; SOC = r0104311a0001
1,010402UUuu@i4:1,SOC,pc,SOC,2
; SOC = r0104311a0001
1,010402UUuu@i5:1,SOC,pc,SOC,2
; SOC = r0104311a0001
1,010402UUuu@i6:1,SOC,pc,SOC,2
#

The console log, lo and behold:

18:32:12.255 transmit index >> 1
18:32:12.257 > 01 04 33 0c 00 02 be 8c 
18:32:12.261 receive index >> 1
18:32:12.263 > fc 01 04 04 00 02 00 00 5a 00 
18:32:17.272 transmit index >> 2
18:32:17.275 > 01 04 31 04 00 01 7e f7 
18:32:22.234 transmit index >> 3
18:32:22.236 > 01 04 31 1a 00 01 1e f1 
18:32:22.238 receive index >> 3
18:32:22.240 > 01 04 02 0a 09 7f 96 01 5a 00 
18:32:27.255 transmit index >> 4
18:32:27.257 > 01 04 31 1a 00 01 1e f1 
18:32:32.262 transmit index >> 5
18:32:32.264 > 01 04 31 1a 00 01 1e f1 
18:32:32.266 receive index >> 5
18:32:32.268 > 01 04 02 00 40 b8 c0 01 5a 00 
18:32:37.268 transmit index >> 6
18:32:37.270 > 01 04 31 1a 00 01 1e f1 
18:32:42.280 transmit index >> 0
[...]

The console output was:

18:32:36.489 MQT: tele/dead_beef/SENSOR = {"Time":"2022-10-15T18:32:36","T4215BN":{"PVpwr":0.00,"PVpwday":0.000,"Vbreal":0.00,"SOC":2569.00,"SOC":0.00,"SOC":64.00,"SOC":0.00}}

So Rx indices 2, 4 and 6 are missing. Would anyone like to have a guess about what the next Rx index missing would be like? Looks like an index mod 3 condition to me. Nota bene: the 3rd occurrence of SOC is "SOC":64.00. (Yay, it's always been there.)

Now, someone show me this isn't the code to blame.

Cheers

[nikito7]

+1,3,m,0,115200,T4215BN,1,50,r010431020002,r0104330C0002,r010431040001,r0104311a0001,r0104311a0001,r0104311a0001,r0104311a0001

mN2

[corbolais]

Hi @nikito7

Thanks for your reply.

Your device definition specifies "m".

What is your intention by stating "mN2"? Do you mean the T4215BN is using 2 stopbits? Where did you get this information from?

Edit: driving the T4215BN with "mN2" leads to Tx-only. No Rx whatsoever. Not that the T4215BN would really use "N2". BTW, as explicitely stated, the values returned on the wire are correct.

Thanks.

[corbolais]

Using @radiergimmy's script from #12800 there's no answer every other query. So using the following script it's not a mod 3 but a mod 2 sigh

>D
SOCmin=50
SOC=0
lON="r01050002FF00"
lOFF="r010500020000"
lSwitch=0
lState=0
>B
smlj=0
->sensor53 r
>R
smlj=0
>S
if upsecs>30
then
smlj=1
endif
>W
bu(lSwitch "Load ON" "Load OFF")
nm(0 100 1 SOCmin "SOC (min)")
>T
SOC=EP#bSOC
lState=EP#lStatus

if ((chg[lState]>0) and (lSwitch!=lState))
then
lSwitch=lState
endif

if (((chg[SOC]>0) or (chg[SOCmin]>0)) and (SOC>0) and (SOC<SOCmin))
then
if lState>0
then
print EPEVER OFF - SOC %SOC% < %SOCmin%
sml(1 3 lOFF)
lSwitch=0
else
if lSwitch>0
then
lSwitch=0
endif
endif
endif

if chg[lSwitch]>0
then
if lSwitch>0
then
if ((SOC==0) or (SOC>=SOCmin))
then
print EPEVER ON - SOC %SOC%
sml(1 3 lON)
else
print EPEVER ON prevented - SOC %SOC% < %SOCmin%
lSwitch=0
endif
else
print EPEVER OFF - SOC %SOC%
sml(1 3 lOFF)
endif
endif

>M 1
+1,3,m,16,115200,EP,1,,r010432020001,r010432000001,r0104311A0001,r010431100001,r0104331B0001,r0104331A0001,r010433020001,r010433030001,r010431010001,r010431000001,r010431020001,r010433040001,r0104330A0001,r0104330C0001,r010433120001
1,=hLast
1,010402SSssxxxx@i1:1,Status,,lStatus,0
1,=h<hr/>Batterie
1,010402SSssxxxx@i2:1,Status,,bStatus,0
1,010402SSssxxxx@i3:1,SOC,%%,bSOC,0
1,010402SSssxxxx@i4:100,Temp,°C,bTemperature,2
1,010402SSssxxxx@i5:100,Strom,A,bCurrent,2
1,010402SSssxxxx@i6:100,Spannung,V,bVoltage,2
1,010402SSssxxxx@i7:100,Spannung (max),V,bVoltageMax,2
1,010402SSssxxxx@i8:100,Spannung (min),V,bVoltageMin,2
1,=h<hr/>PV-Modul
1,010402SSssxxxx@i9:100,Strom,A,pCurrent,2
1,010402SSssxxxx@i10:100,Spannung,V,pVoltage,2
1,010402SSssxxxx@i11:100,Power,W,pPower,2
1,=h<hr/>Energie
1,010402SSssxxxx@i12:100,Verbrauch (Tag),kWh,dConsumption,2
1,010402SSssxxxx@i13:100,Verbrauch (Total),kWh,tConsumption,2
1,010402SSssxxxx@i14:100,Ertrag (Tag),kWh,dProd,2
1,010402SSssxxxx@i15:100,Ertrag (Total),kWh,tProd,2
#

[corbolais]

There is a corresponding issue #12205 and discussion #12418 (superseded by this one).

[corbolais]

Gosh, possibly related/possible cause: #17106

[barbudor]

@corbolais #17106 has been solved 1 month ago. Be sure to use latest version to get it
There should be no reason for MODBUS to not work at 115200 as far as you are using hardware serial
Software serial at 115200 is prone to errors
As you are using GPIO3 as RX pin that should be ok

I see your meter definition is

+1,3,m,16,115200,EP,1,,r010432020001,r010432000001,r0104311A0001,r010431100001,r0104331B0001,r0104331A0001,r010433020001,r010433030001,r010431010001,r010431000001,r010431020001,r010433040001,r0104330A0001,r0104330C0001,r010433120001

I think you are missing a parameter that was introduced recently : The TX enable pin
Check the doc at https://tasmota.github.io/docs/Smart-Meter-Interface/#meter-definition

[gemu2015]

sml uses its own serial driver and did not have that 115kb overflow.
however looking again a @corbolais descriptor i realized that the meter description misses the transmission interval (it is ,,) and will evaluate to zero meaning that the meter will be overrun, insert a 10 here to give the meter at least 1 second between requests.

+1,3,m,16,115200,EP,1,10,r010432020001,r010432000001,r0104311A0001,r010431100001,r0104331B0001,r0104331A0001,r010433020001,r010433030001,r010431010001,r010431000001,r010431020001,r010433040001,r0104330A0001,r0104330C0001,r010433120001

[barbudor]

@gemu2015 but from the doc there should also be the txpin enable after the txpin ans before the transmission period

[gemu2015]

this is optional, only meant for max485, if after the transmit pin follows a bracket the direction pin can be given,

[corbolais]

Well, after upgrading to 12.5.0 there is an Rx for every Tx sent. Some code change seems to have fixed this long-lasting issue.
Now on to the shifted values issue.

[corbolais]

This looks promising. I still have to look up the correct registers for the Tracer as I am testing with a later model right now as opposed to the production unit manufactured a couple of years ago. Register addresses might differ. This would be kinda strange but not surprising.

Anyway, the one(s) who changed the code did good. Kudos. The missing Rx msgs are not happening any more, the % sign is now working as documented (need to escape via %%), this was not working as of the previously used Tasmota version.

I wonder what code change fixed this issue and whether others have been staring at mixed up columns of data for years which I somehow doubt. So what was the reason this issue crept up in this setting here. Between the tests today only lay a couple of hours and the update to Tasmota 12.5 after which everything started working as expected.

Will check register addresses soon(er or later) and report back, hopefully being able to close this issue.
Thanks again for all your support and the code changers.

cheers

[corbolais]

It is clear now that a missing level shifting is not at the origin of this issue.

As of Tasmota 12.5 data is queried and displayed correctly with or without level shifter in the loop.

[corbolais]

Why is it that in the SML meter description the meter name must not exceed 7 chars? It's defined as char name[24];.

When using 12345678 as meter name the web UI displays garbage and the MQTT message gets truncated after 1234567.

I've got two solar controllers I want to monitor. To be able to distinguish them in Grafana and Home Assistant and to know which data is sent by which controller, I'd like to have meaningful names indicating the controller and an indexed suffix like T4215BN01.

According to the name string definition in xsns_53_sml.ino:2289:void SML_Show(boolean json) it should be possible.

Where and why does truncating happen?

[gemu2015]

the meter prefix is defined as char prefix[8]; thus the documentation is correct max 7 chars and will not be changed

[gemu2015]

@corbolais

just did a pr
the default will remain at 7 chars but you may redefine the size in your own compile with
#define SML_PREFIX_SIZE

[corbolais]

Thank you @gemu2015 . That's great! :)

Cannot find the PR though.