Gelöst: E3/DC reagiert nicht auf MODBUS-Anfragen aus fremden Subnetzen

[BEV-OPTIGEM]

Bei mir läuft EVCC auf einem RaspBerry im WLAN. Ein Sungrow Wechselrichter der über LAN verbunden ist, liefert per ModBus Daten. Das E3/DC Kraftwerk, das im gleichen LAN erreichbar ist, liefert RaspBerry-IP:WechselndePorts -> E3/DC-IP:502 connection reset by peer.

Verwende ich den gleichen Versionsstand (0.125.0) von EVCC mit einer identischen Kopie der evcc.yaml auf einem Windowsrechner, der sich im gleichen LAN wie das E3/DC Hauskraftwerk befindet, funktioniert die Kommunikation ohne Probleme, auch mit dem Sungrow Wechselrichter.

Schalte ich beim E3/DC ModBus ab, erhalte ich erwartungsgemäß den Fehler: connection refused.

Trace auf dem RaspBerry;

[modbus] TRACE 2024/04/24 10:15:17 modbus: send 00 01 00 00 00 06 00 03 9c 89 00 02
[modbus] TRACE 2024/04/24 10:15:17 modbus: close connection and retry, because of EOF
[modbus] TRACE 2024/04/24 10:15:32 modbus: send 00 01 00 00 00 06 00 03 9c 89 00 02
Power: read failed: read tcp 10.20.31.160:55146->10.20.30.55:502: read: connection reset by peer

Trace unter Windows:

[modbus] TRACE 2024/04/24 11:13:05 modbus: send 00 01 00 00 00 06 00 03 9c 89 00 02
[modbus] TRACE 2024/04/24 11:13:05 modbus: recv 00 01 00 00 00 07 00 03 04 00 1c 00 00
Power: 28W

Kann mir jemand einen Tipp geben, wo ich weitersuchen kann?

[EnErWeh]

Mal so in die Luft geschossen:

Vielleicht mal mit netstat schauen, welche und wieviele tcp-Verbindungen Windows und der RASPI jeweils zum E3/DC halten.

Modbus (RTU) kennt eigentlich nur genau einen abfragenden Master. Mehr werden durch den TCP-Adapter gehandelt. Da gibt es auf der Slave/Geräteseite unterschiedliche Implementierungen, wie viele Verbindungen zugelassen werden. Es könnte sein, dass beim RASPI / WLAN die Verbindungen länger stehen bleiben.

[icke-pp]

Grundsätzlich sollte nur 1 Modbus Verbindung aktiv sein. Um zu verhindern das mehrere Verbindungen zur gleichen Zeit stattfinden solltest du einen Modbus Proxy nutzen. Dieser kann dann von dir zentral abgefragt werden und übernimmt alle Abfragen.
Der Modbus Proxy kann auch auf der evcc eingerichtet werden.
https://docs.evcc.io/docs/reference/configuration/modbusproxy

Alles andere funktioniert nicht.

[BEV-OPTIGEM]

Vielen Dank für die Antworten.
Der Grund für das Problem: E3/DC beantwortet keine MODBUS-Anfragen aus fremden Subnetzen!
Die Lösung: Über einen passenden NAT (Network Address Translation) Eintrag in der Firewall wird E3/DC nun vorgegaukelt, der Raspi befände sich im gleichen Subnetz. Mit den Details bin ich leider überfragt, aber wer sein Netzwerk sicher macht, sollte auch wissen was er tut, oder jemanden kennen, der das weiß.