Including Smart Meter Interface breaks hardware serial bridge (at least receiving).

[TheChatty]

PROBLEM DESCRIPTION

Compiling SMI into the build breaks hardware serial bridge (cannot receive data).

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in the docs
• Searched the problem in the forum
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): ESP01 1M
• Tasmota binary firmware version number used: 9a21dc8 (9.0.0.2 from 20.10.2020)
  • Pre-compiled
  • Self-compiled
    • IDE / Compiler used: gitpod
• Flashing tools used: esptool.py 2.8
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:

{"NAME":"Generic","GPIO":[1,1,1,1,1,1,1,1,1,1,1,1,1,1],"FLAG":0,"BASE":18}
{"Module":{"1":"Sonoff Basic"}}
{"GPIO0":{"32":"Button1"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},...

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:

• Provide the output of the Console log output when you experience your issue; if applicable:
  (Please use weblog 4 for more debug information)

  Console output here:

There is no output even though the device connected to GPIO3 sends diligently.

TO REPRODUCE

Compile build with no changes to source to find SerialReceived working.
Compile build with SMI included to find SerialReceived NOT working.

Prior configuration just includes connecting to WiFi, set baudrate and initial serialsend5 00.

EXPECTED BEHAVIOUR

Hardware SerialReceived to be working, e.g. receiving the data which is sent from the other device.

[gemu2015]

did you read the sml documentation ?

https://tasmota.github.io/docs/Smart-Meter-Interface/

this driver defines all used GPIO in the driver or script.

when not using a script the default descriptor is used which occupies pin3 for serial input thus conflicting with serial bridge. (if enabled on pin 3)

when using an sml script you can define the GPIO you want to use for serial meters in the script and choosing another pin would free GPIO3 for serial bridge.

[TheChatty]

I read the docs. Now again. Nowhere does it talk about default GPIOs. Instead it says if a configured smart meter inteferes with an otherwise configured PIN it will produce a "duplicate GPIO defined" error in the log and the meter descriptor will be ignored.

But I said to reproduce the above mentioned problem you just need to compile SMI into Tasmota and don't configure any meter. And the problem is not sending messages, it only block receiving messages.

[gemu2015]

ok, it has to be clarified in the docs that the checking of duplicate GPIOs is only true for the script driven driver. the "old" hardcoded interface should normally no longer be used. it is left over for special purposes.
(e.g. if someone for some reason must use rules)

[gemu2015]

docs updated!

[TheChatty]

I find the whole SML doc to be quite unstructured but at least my case is now documented which explains why this issue is not a bug.

[meingraham]

@TheChatty

The firmware and the documentation both open source and are maintained by volunteers, i.e., unpaid. We encourage users like you to enhance the documentation.

[TheChatty]

@meingraham: Once I fully understood what is what I might contribute.

@gemu2015: I need to reopen because when I reconfigure my meter to use GPIO2 (means don't touch 1+3) I still can't see a response (SerialReceived log) until I reboot with GPIO2-config.

[gemu2015]

@TheChatty
i assume you used an ESP8266
i tested with a Wemos ESP8266 and it works like expected (sml input at gpio4, serial bridge works)
i forgot to mention and it is still missing in the docs that on an ESP32 the serial port behaves different.
i will update the docs.

by the way you should not use GPIO2 for input. dig the net about pins better not to use for input on an ESP

if you still have problems you need to describe more in detail what you are doing (post descriptor, logs etc)

[TheChatty]

I'm using this board.

I just retested it to be sure. I have Tasmota 9.0.0.2 with SML installed, no GPIO configured.

• boot without any script
  • SerialSend works, SerialReceived does not work --> correct, explained by gemu
• reconfigure script to use GPIO4 (no reboot)
  • SerialSend works, SerialReceived does not work
• boot with script configured to GPIO1+3
  • SerialSend works, SerialReceived does not work --> correct, script occupies GPIOs
• reconfigure script to use GPIO4 (no reboot)
  • SerialSend works, SerialReceived does not work
• boot with script configured to GPIO4
  • SerialSend works, SerialReceived works --> correct, GPIOs are usable

After the no-script situation has been clarified by gemu, I think the reconfiguration of script GPIOs needs to free unused GPIOs.

Also as a new user I'd rather prefer to have "the old behavior" removed.

My real intention is to be able to use TCP bridge (see #9586) and SMI simultaneously on the same modbus device.

[gemu2015]

exactly that is the normal behavior

i made a note in docs about a required restart

[TheChatty]

Not handled in my desired direction but nevertheless handled thus closed.

@gemu2015: Is there any documentation (besides the code itself) about the

"old" hardcoded interface [...] left over for special purposes

?

[gemu2015]

as already said the old interface makes only sense in case you want to use rules and not scripts together with sml

from the source code see below
select a meter from the predefined ones.
or create a new descriptor and edit the entries.
the descriptor is the same as in a script with slightly different separators
and some new options are not supported like MODBUS.

// this descriptor method is no longer supported
// but still functional for simple meters
// use scripting method instead
// meter list , enter new meters here
//=====================================================
#define EHZ161_0 1
#define EHZ161_1 2
#define EHZ363 3
#define EHZH 4
#define EDL300 5
#define Q3B 6
#define COMBO3 7
#define COMBO2 8
#define COMBO3a 9
#define Q3B_V1 10
#define EHZ363_2 11
#define COMBO3b 12
#define WGS_COMBO 13
#define EBZD_G 14

// select this meter
#define METER EHZ161_1

[TheChatty]

@gemu2015: Initializing all belonging consts with empty values leads to my expected behavior: no undocumented feature is enabled by default and claims the rxd GPIO. And having TCP bridge and SMI in one image with one active at a time works.

In my opinion this should be condition in git.

[gemu2015]

now there is a hardcoded Meter NO_OP in the meter list
that leads to an empty meter that does nothing at all
#define METER SML_NO_OP

ill do a pull request soon