ModBus-Connection failed: read failed: read tcp i/o timeout

[Pogofant]

Hallo Community,

Leider kann mein RaspberryPi (mit installiertem evcc) nicht über mein ModBus-Gateway auf meinen Hybridwechselrichter zugreifen.
Ich erhalte für die meter "pv1", "pv2" und "battery" immer die Fehlermeldung "read failed: read tcp 10.0.0.123:xxxxx -> 10.0.0.99:502: i/o timeout". Das xxxxx steht für eine 5 stellige Portnummer, die der RaspberryPi/evcc verwendet. Scheinbar wird jeden Verbinungsversuch ein neuer random-Port verwendet (z.B. habe ich mitgeschrieben: 54968, 54980, 54068, 35028, 35042, 44902, 42944, 42952, etc...)

Die IP Adressen sind:
RaspberryPi: 10.0.0.123
ModBus-Gateway: 10.0.0.99

Das komische ist, wenn ich manuell (per PC-Software Modbus-Tester.exe) ebenso über LAN(ModBus-Gateway) auf den Hybridwechselrichter zugreife, funktioniert das ohne Probleme und ich kriege plausible Registereinträge.
Lediglich der RaspberryPi scheint das nicht auf die Kette zu bekommen...

Ich habe bereits die Option "rtu: true" in evcc.yaml ausprobiert (ohne Erfolg).
Ebenso habe ich bei meinem Netzwerk-Router, über dem die Verbindung in beiden Fällen läuft, eine Port-Forwarding für Port 502 konfiguriert um die Kommunikation zu ermöglichen.

Ich denke, dass hier irgendwo der Port o.Ä. Blockiert wird...
Hat jemand eine Idee woran es liegen könnte?

Hier Screenshots des ModBus-Gateway Config und des funktionierenden MosBus-Testers auf meine lokalen PC:

Hier die Definition der Meters in der verwendeten evcc.yaml Config Datei:
meters:

• name: grid
  type: template
  template: shelly-pro-3em
  usage: grid
  host: 10.0.0.250 # IP-Adresse oder Hostname
• name: pv1 # PV-Kreis 1
  type: custom
  power:
  source: modbus
  id: 1
  uri: 10.0.0.99:502 #IP-Adress of ModBus-Gateway
  timeout: 4s
  register:
  address: 228
  type: input # Read an input register
  decode: int16
• name: pv2 # PV-Kreis 2
  type: custom
  power:
  source: modbus
  id: 1
  uri: 10.0.0.99:502 #IP-Adress of ModBus-Gateway
  timeout: 4s
  register:
  address: 232
  type: input # Read an input register
  decode: int16
• name: battery
  type: custom
  power:
  source: modbus
  id: 1
  uri: 10.0.0.99:502 #IP-Adress of ModBus-Gateway
  timeout: 4s
  register:
  address: 1196
  type: input # Read an input register
  decode: int16
  scale: -1.0
  soc:
  source: modbus
  id: 1
  uri: 10.0.0.99:502 #IP-Adress of ModBus-Gateway
  timeout: 4s
  register:
  address: 226
  type: input # Read an input register
  decode: int16

[andig]

Ich habe bereits die Option "rtu: true" in evcc.yaml ausprobiert (ohne Erfolg).

Was heisst denn probieren? Du musst doch wissen, was Dein WR spricht? Und wozu ein Modbus Gateway? Was tut das? Mit oder ohne Protokollkonvertierung?

Schau Dir bitte auch mal die diversen anderen Threads zu Modbus an...

[Pogofant]

Ok... Wo pappe ich das -log trace Kommando ran? An ein Linux-Shell Kommando oder irgendwo in evcc.yaml?

Sorry, aber da musst du leider etwas weiter ausholen, weil so fachlich tief bin ich leider dann doch nicht drin um das aus dem Kontext heraus zu verstehen.

[VolkerK62]

Einfach auf der Kommandozeile evcc meter --log trace

[Pogofant]

Ich habe nun evcc meter --log trace in die RasPi-Kommandozeile reingetippt und bekomme folgendes Ergebnis:

pv1

[modbus] TRACE 2024/08/24 13:50:38 modbus: send 00 01 00 00 00 06 02 04 00 e5 00 01
Power: read failed: read tcp 10.0.0.123:46732->10.0.0.99:502: i/o timeout

pv2

[modbus] TRACE 2024/08/24 13:50:43 modbus: send 00 02 00 00 00 06 02 04 00 e9 00 01
Power: read failed: read tcp 10.0.0.123:46740->10.0.0.99:502: i/o timeout

Hier nochmal die Erklärung wie eine ModBus-TCP Botschaft aufgebaut ist / wie die o.A. Botschaftsrequest zu interpretieren sind.

Anhand vom Request von pv2:
00 02 => Transaction ID (Random Nummer vom Modbus-Master um Slaveantwort eindeutig zuordnen zu können)
00 00 => Protocol ID (eigentlich immer 00 00 bei Modbut-TCP, soweit ich verstanden habe)
00 06 => Nachrichtenlänge: 6byte (02, 04, 00, e9, 00, 01) -> In Summe 6 Stück, passt soweit
02 => Slave-ID (2 passt soweit für meinen FSP-Wechselrichter)
04 => Modbus Funktionscode (=Read Register)
00 e9 =>Adresse des ersten Registers: e9 (hex) entspricht 233 dezimal. Passt also soweit
00 01 => Anzahl der zu lesenden Register: 1 (nur 233). Passt soweit

Hmmm... Auf den ersten Blick sehe ich jetzt nichts falsches...

[andig]

Prima. Und was machen die andern Tools im Vergleich?

[Pogofant]

Wie finde ich das denn raus? Gibt es ein -log trace Pendant für die Windows-Konsole auch, damit ich sehe was das Modbus-Tester Tool auf meinem Laptop so an Datenstream fabriziert?

[osulivanDE]

Ich will mich mal dranhängen und berichten, dass meine 130.2 EVCC Instanz seit dem letzen Update auch Modbus Probleme mit meinem SMA Wechelrichter hat. Ich bekomme nur noch sehr unregelmäßig Werte vom Wechselrichter und EVCC beschwert sich mit folgender Fehlermeldung im Frontend:
pv 2 power: read failed: dial tcp 192.168.2.32:502: i/o timeout

Angebunden ist die PV via Modbus (Sunspec) über die GUI

[Pogofant]

So... Ich hab mich mal wieder in das Thema Network-Sniffing eingelesen und mittels Wireshark den Netzwerktransfer mitgesnifft, um zu sehen was mein Modbus-Tester Tool so an Datenstream produziert (unten ein Screenshot von Wireshark mit dem markierten Modbus-TCP Datenpaket.

Ich drösel hier mal den Modbus-TCP Datenstream auf, für den ich Daten vom Wechselrichter zurück bekomme:
00 6b => Transaction ID
00 00 => Protocol ID
00 06 => Nachrichtenlänge = 6 byte
02 => Slave-ID
03 => Funktionscode
00 e5 =>Adresse des Registers (229 entspr. 0xE5)
00 01 => Anzahl der auszulesenden Register (= 1)

Soweit sogut... Die einzige Unterscheidung die ich also hier sehe ist, dass mein Modbus-Testertool den Funktionscode "03" (=>Read Holding Registers) verwendet, wohingegen evcc (siehe Post oben, wo ich --log trace gecheckt habe) den Funktionscode "04" (=> Read Input Registers) verwendet...
Was ist denn da der Unterschied? Kann dass das Problem sein?

[andig]

Dann nimm doch bitte den richtigen Code- das sind einfach GANZ andere Register...

[Pogofant]

Das Register ist exakt das gleiche wie beim o.A. trace von pv1:

[modbus] TRACE 2024/08/24 13:50:38 modbus: send 00 01 00 00 00 06 02 04 00 e5 00 01
Power: read failed: read tcp 10.0.0.123:46732->10.0.0.99:502: i/o timeout

Die gesendeten Kommandos zw. evcc (siehe trace, welche zu timeouts führt) und dem funktionierenden Testertool unterscheiden sich lediglich im Funktionscode:
04 (evcc) liefert Timeouts
03 (Testertool) liefert eine Antwort vom Wechrichter zurück

[andig]

Dann nimm doch bitte den richtigen Code- das sind einfach GANZ andere Register...

Input != Holding

[Pogofant]

Achso... Du meinst in evcc.yaml type: holding statt type: input?

[Pogofant]

Oh Mann, jetzt hab ich endlich die Lösung gefunden und es funktioniert!
Das war ne' schwierige Geburt für mich...

Der Trace liefert nun valide Werte (bei mir scheint gerade die Sonne^^):

pv1
---
[modbus] TRACE 2024/08/25 11:41:56 modbus: send 00 01 00 00 00 06 02 03 00 e4 00 02
[modbus] TRACE 2024/08/25 11:41:56 modbus: recv 00 01 00 00 00 07 02 03 04 00 00 0f dc
Power: 4060W

pv2
---
[modbus] TRACE 2024/08/25 11:41:56 modbus: send 00 02 00 00 00 06 02 03 00 e8 00 02
[modbus] TRACE 2024/08/25 11:41:56 modbus: recv 00 02 00 00 00 07 02 03 04 00 00 10 67
Power: 4199W

Es lag daran, dass man type: holding in evcc.yaml verwenden muss. Zusätzlich habe ich auch den Wertebereich von int16 auf int32 umgeändert und jetzt funktioniert es!

Vielen lieben Dank nochmal für die Hilfe!
@andig: Wenn ich den Wechselrichter komplett konfiguriert und getestet habe, wollt ihr die evcc.yaml dann haben um ein Template daraus für den FSP-Wechselrichter zu erstellen? Wäre sicher sinnvoll damit zukünftige Tüftler nicht in die selben troubles mit ihren FSP-Wechselrichtern laufen...

[andig]

Klar, gerne. Einfach Issue mit Config dazu.