Solarman LSE-3 writes to Deye inverter but returns an invalid FC16 response

[mmatuska]

Describe the bug

EVCC tries to issue write commands via my Solarman LSE-3.

FC16 request:
00 01 00 00 00 09 01 10 00 7F 00 01 02 00 19

LSE-03 response:
00 01 00 00 00 03 01 10 00

Expected FC16 response would be:
00 01 00 00 00 06 01 10 00 7F 00 01

But the register value is written and this can be verified via mbpoll and local Deye UI.

Evcc treats this as an error, and that is correct.
LSE-3 firmware is ME_0E_5406_4.0E

All reads work fine.

I have already contacted Deye support.
Is this a known issue? Could a workaround be made?

Steps to reproduce

1. Configure evcc to trace logging

Configuration details

meter
---
db:2 {Type:template Title:Inverter Icon: Product:Deye 3p hybrid inverter} map[batterytype:lv baudrate:9600 comset:8N1 firmware1098:false gridchargecurrent:160 host:A.B.C.D id:1 includegenport:false maxacpower:10000 maxdischargecurrent:200 modbus:tcpip port:8899 storageunit:1 template:deye-hybrid-3p usage:pv]
db:3 {Type:template Title:Battery Icon: Product:Deye 3p hybrid inverter} map[batterytype:lv baudrate:9600 capacity:16 comset:8N1 firmware1098:false gridchargecurrent:160 host:A.B.C.D id:1 includegenport:false maxacpower:0 maxdischargecurrent:200 maxsoc:100 minsoc:25 modbus:tcpip port:8899 storageunit:1 template:deye-hybrid-3p usage:battery]

Log details

[db:3-Battery] TRACE 2026/08/20 08:50:40 modbus: send 00 1e 00 00 00 09 01 10 00 7f 00 01 02 00 19
[db:3-Battery] TRACE 2026/08/20 08:50:40 modbus: recv 00 1e 00 00 00 03 01 10 00
[site  ] ERROR 2026/08/20 08:50:40 battery mode: modbus: response data size '1' does not match count '4'

My LSE-3 firmware is

What type of operating system or environment does evcc run on?

other

External automation

• I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

evcc version 0.313.3 (ec8c5ec)

[github-actions[bot]]

Thanks for the detailed trace. This matches the write path in templates/definition/meter/deye-hybrid-3p.yaml for batterymode, which writes register 127 via writemultiple (FC16) — exactly the request/address seen in the log.

Looking at the byte trace:

• Request: ... 00 09 01 10 00 7f 00 01 02 00 19 (MBAP length 9, unit 1, function 0x10, start addr 0x7F, quantity 1, byte count 2, value 0x19)
• Response: ... 00 03 01 10 00 (MBAP length 3, unit 1, function 0x10, then only one more byte)

A conformant Modbus FC16 response echoes unit + function + start address (2 bytes) + quantity (2 bytes), i.e. MBAP length 6. Your LSE-3 sends a response declaring length 3 and only including a single trailing byte — the response itself is truncated/malformed at the protocol level, even though the write is actually applied (as you confirmed via mbpoll/local UI). evcc (via the underlying Modbus client) correctly rejects this as an invalid response.

This looks like a firmware-level protocol violation in the LSE-3, not a bug in evcc's Modbus handling. Relaxing evcc's response validation to tolerate truncated FC16 responses would be a design change to the shared Modbus client used by all devices, with a real risk of masking genuine errors for other users/devices — not something to change without further discussion, and not a small self-contained fix.

Given this, I'm not applying the bug label and won't attempt an automated fix. If you'd like to pursue a device-specific workaround, it would help to know:

• whether other write registers on this same LSE-3 exhibit the same truncated-response behavior, or only register 127
• whether Deye support confirms this is expected/fixed-in-a-future-firmware behavior

🤖 Generated with Claude Code

[andig]

This needs be fixed on the device side.