[Gelöst] Huawei SDongleA-05: Modbus TCP "uneingeschränkt" aktiv, trotzdem EOF / connection reset bei jeder Anfrage — Ursache war der eigene Client

[shokk4]

Setup: SUN2000-12KTL-M2 (V100R001C00SPC174), SDongleA-05 (V200R022C10SPC210) per LAN, evcc 0.310.1 auf Windows.

Symptom

Der Dongle nimmt die TCP-Verbindung auf Port 502 an, aber jede Modbus-Anfrage endet mit connection reset / EOF (read failed: EOF, i/o timeout). Getestet mit Unit-ID 0, 1 und 100 — identisch. In FusionSolar war ModBus-TCP korrekt auf „Aktivieren (uneingeschränkt)" gesetzt, Dongle-Neustart brachte nichts. Sah aus wie eine fehlende IP-Whitelist oder ein Firmware-Bug — war es aber nicht.

Ursache

Der SDongle bedient nur eine Modbus-TCP-Verbindung gleichzeitig und ignoriert Anfragen, die sofort nach dem Connect kommen. Unsere evcc-Konfiguration (custom meter) hatte id: 0, connectdelay: 1s und unterschiedliche Verbindungsparameter in den power-/energy-Blöcken. Folge: Timeout → Reconnect → Dongle ignoriert die zu schnelle Anfrage → Timeout … Der Dienst öffnete alle 16 s eine neue Verbindung (im Log an wechselnden Quellports erkennbar) und hielt damit den einzigen Slot dauerhaft belegt. Dadurch schlugen auch alle manuellen Tests fehl (evcc CLI, rohe TCP-Frames) — man sucht dann fälschlich beim Dongle/Portal, dabei sperrt der eigene Client alles aus.

Lösung

1. Alle Modbus-Clients stoppen (evcc-Dienst!) und 2–3 Minuten warten — der Dongle gibt belegte Verbindungen nur langsam frei.
2. Konfiguration korrigieren: id: 1 (Modbus-ID des Wechselrichters, in FusionSolar unter Geräteinformationen), timeout: 15s, connectdelay: 5s — und zwar identisch in power und energy, damit evcc eine einzige Verbindung wiederverwendet:

meters:
  - name: pv
    type: custom
    power:
      source: modbus
      uri: 192.168.188.102:502
      id: 1
      timeout: 15s
      connectdelay: 5s
      register:
        address: 32080 # Active power
        type: holding
        decode: int32nan
    energy:
      source: modbus
      uri: 192.168.188.102:502
      id: 1
      timeout: 15s
      connectdelay: 5s
      register:
        address: 32106 # Accumulated energy yield
        type: holding
        decode: uint32nan
      scale: 0.01

Danach: erster Read ~5 s (connectdelay), alle weiteren im Millisekundenbereich, seither fehlerfrei.