Fix ESP8266 Exception crash-loop on PZEM/Modbus energy monitors (regression from 15.5.0)

[gionag]

Description

Since v15.5.0, ESP8266 devices with a PZEM (PZEM-004T v3 / PZEM-016) or any Modbus energy monitor crash-loop a few seconds after boot with Exception (9) (load/store alignment) once the driver starts transmitting. It reboots roughly every ~10s (right at the end of the PZEM stabilize window), BootCount keeps climbing, and it never reads. 15.4.0 is fine.

Bisected to #24726 ("Add RX Enable GPIO support for Modbus", commit 0c85dbc) in TasmotaModbus.cpp. That change added an RX-enable block to Send(). The digitalWrites are guarded by if (mb_rx_enable_pin > -1), but the delay(10) was left outside the guard:

  write(frame, framepointer);
#ifdef TASMOTA_MODBUS_RX_ENABLE
  delay(10); // runs on every Modbus Send, for every device
  if (mb_rx_enable_pin > -1) {
    digitalWrite(mb_rx_enable_pin, LOW);
  }
#endif

So every Modbus transmit now hits an unconditional delay(10), even though almost nobody has an RX-enable pin configured. On ESP8266 that delay() yields into the SDK mid-send and faults — the crash EPC (0x40105f68) is in IRAM. It's ESP8266-only (ESP32 is unaffected) and reproduces with no PZEM even attached, just by assigning a PZEM0XX Tx pin (confirmed by a second user in #24883).

Fix

Move the delay(10) inside the existing mb_rx_enable_pin > -1 guard. For any setup without an RX-enable pin — i.e. every current PZEM/Modbus user — this makes Send() byte-for-byte identical to 15.4.0. RX-enable timing for people who do set that pin is unchanged.

Verified

Built the standard tasmota env (ESP8266 core 2.7.8) with this change and OTA-flashed it to two boards that crash-loop on stock 15.5.0:

• PZEM-004T v3 (hardware serial)
• PZEM-016 (software serial)

Both went from Exception crash-loops (uptime never past ~10s) to fully stable — uptime climbing for minutes, RestartReason "Software/System restart", reading voltage/current/power normally (~232 V / ~900 W / addr 1). No change to RX-enable behaviour for setups that use it.

Related issue: fixes #24883

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.8
• The code change is tested and works with Tasmota core ESP32 V.3.3.8 from Platform 2026.05.50 (bug is ESP8266-only; the change is a trivial guard that compiles for ESP32 but I did not flash ESP32 hardware)
• I accept the CLA.

[s-hadinger]

Thanks, good for me. @arendst ok to merge?