Timeout Fehler bei connect zu EVU-Kit v2 - gelöst

[rleidner]

openWB-2 Standard+ , 1.9.262
EVU Kit v2 - Lovato, PE11 mit oWB Original-Setup

Ich finde regelmäßig und recht häufig (ca. 5/min) diese timeout Fehler im Debug Log:

Code: Alles auswählen

modules.common.fault_state.FaultState: ('TCP-Client konnte keine Verbindung zu 192.168.193.15:8899 aufbauen. Bitte Einstellungen (IP-Adresse, ..) und Hardware-Anschluss prüfen.', <FaultStateLevel.ERROR: 2>)
" aufbauen. Bitte Einstellungen (IP-Adresse, ..) und " + "Hardware-Anschluss prüfen.") from e
File "/var/www/html/openWB/packages/modules/common/modbus.py", line 95, in __read_registers
return self.__read_registers(self.delegate.read_input_registers, address, types, byteorder, wordorder, **kwargs)
File "/var/www/html/openWB/packages/modules/common/modbus.py", line 140, in read_input_registers
0x0001, [ModbusDataType.INT_32]*3, unit=self.id)]
File "/var/www/html/openWB/packages/modules/common/lovato.py", line 24, in get_voltages
self.__process_error(e)
File "/var/www/html/openWB/packages/modules/common/lovato.py", line 26, in get_voltages
voltages = self.__client.get_voltages()
File "/var/www/html/openWB/packages/modules/openwb_flex/counter.py", line 46, in update
self._components[component].update()
File "/var/www/html/openWB/packages/modules/openwb/device.py", line 49, in update
Traceback (most recent call last):

The above exception was the direct cause of the following exception:

pymodbus.exceptions.ConnectionException: Modbus Error: [Connection] Failed to connect[ModbusTcpClient(192.168.193.15:8899)]
raise ConnectionException("Failed to connect[%s]" % (self.__str__()))
File "/usr/local/lib/python3.5/dist-packages/pymodbus/client/sync.py", line 107, in execute
return self.execute(request)
File "/usr/local/lib/python3.5/dist-packages/pymodbus/client/common.py", line 125, in read_input_registers
address, number_of_addresses, **kwargs)
File "/var/www/html/openWB/packages/modules/common/modbus.py", line 85, in __read_registers
Traceback (most recent call last):
2022-04-09 19:06:47: PID: 2718: root: EVU-Kit: FaultState FaultStateLevel.ERROR, FaultStr TCP-Client konnte keine Verbindung zu 192.168.193.15:8899 aufbauen. Bitte Einstellungen (IP-Adresse, ..) und Hardware-Anschluss prüfen., Traceback:
2022-04-09 19:06:47: PID: 2718: pymodbus.client.sync: Connection to (192.168.193.15, 8899) failed: timed out

Die Regelung funktioniert normal.

Es scheint, dass der PE11 nicht immer zeitnah antwortet.
Die Netwerk-Verbindung zwischen OWB und EVU-Kit läuft über 2 Switches (Netgear GS105Ev2, GS108Ev3) und CAT7 Kabel.
Die beiden Switches sind mit 1 GBit verbunden, OWB und PE11 über 100Mbit.
Im Monitor der Switches sehe ich keine CRC Fehler auf den beteiligten Ports.
Alle weiteren Verbindungen sehen auch gut aus.
Ich habe alle Verbindungen nach der Installation vor ca. 2 Jahren fehlerfrei durchgemessen.

Ich kann nicht genau sagen, wann das begonnen hat aber im Dezember/Januar hatte ich solche Fehler noch nicht bemerkt.

Verdacht 1:
Ich hatte vor einiger Zeit versucht, das EVU-Kit in einer 2. OWB Installation (RasPi mit Alpha 2.0) zu verbinden.
Da das nicht funktioniert hat, habe ich das wieder rausgenommen und "füttere" den 2. OWB über MQTT.
Kann der Fehler damit zu tun haben?

Verdacht 2: Ich habe damals bei der Verkabelung auch die Abschirmungen beidseitig verbunden.
Sollte ich mal versuchen die Schirmung einseitig zu lösen?

Weitere Tipps was ich prüfen sollte?

[derNeueDet]

Was hast du denn bei dem PE11 unter Communication Settings Protokoll Settings eingestellt?

Ich hab da 5 stehen. Das sind meiner Meinung nach die maximalen parallelen Verbindungen.

Evtl. Ist das bei dir zu niedrig? Falls du mit mehreren Geräten zugreifst.

VG
Det

[rleidner]

Danke Det,
Unter Communication Settings (netp) - Protocol Settings - Max Accept stand 3.
Ich habe das jetzt auf 5 geändert und werde das beobachten.
EDIT: Beim Check ist der Wert ist immer noch auf 3 - lässt sich scheinbar nicht so einfach ändern.

[derNeueDet]

Komisch, ich konnte das von 5 auf 7 ändern und bleibt auch auf dem Wert.

VG
Det

[rleidner]

Die Einstellung mit 3 hat ja seit der Installation vor über einem Jahr funktioniert.

Das Problem taucht auch irgendwie "regelmäßig unregelmäßig" auf.
Ich sehe Phasen von 25 min, in denen im debug log 5 mal nur der "cron5min.sh started/finished" steht und dann wieder 4 mal hintereinander mit Abstand 10 sec dieser timeout.
Auch der Zugriff auf das Web-UI des PE11 reagiert gelegentlich recht langsam.
Kann das ein Problem des PE11 sein?

Wenn mir nichts anderes einfällt werde ich am Montag die Verkabelung prüfen.

[TheSCC]

Seit dem Update auf die aktuelle Stable habe ich ein ähnliches Problem feststellen können, ebenfalls mit PV-Kit. Leider kann ich unter Status den Debug Log nicht einsehen, da dann OpenWB abschmiert, (Seite reagiert nicht mehr).
Jedoch erscheint im PV Wechselrichter 2 alle 10 sek diese Fehlermeldung:

[rleidner]

Prüfung der Verkabelung und Netzwerkstecker hat nichts ergeben.

Der ModBusTCP-Adapter ist kein PE11 sondern ein Elfin EE11. Das sollte aber keinen Unterschied machen.

Ich habe parallel 2 pings mit timestamps zu EE11 und OWB länger lassen.
Zu dem Zeitpunkten an denen der Fehler auftritt laufen die pings normal.
Das Netzwerk sollte also OK sein.

Ich habe dann aus dem debug log von 2 Tagen die Intervalle zwischen den Fehlern extrahiert.
Es läuft sehr häufig ~22:10 oder ~22:20 (mm:ss) ohne Fehler, dann einige Male alle 10 sec (also bei jedem regel-Durchlauf).
Hier ein typischer Ausschnitt:

Meistens sind diese Fehlerphasen weniger als 1 Minute lang, die längste 04:20.
Mir fällt nichts ein, was dieses Zeitverhalten erklären könnte.

Ich habe mir dann den Code angesehen.
Es sieht aus, dass in der alten Stable solche Fehler nicht abgefangen wurden und damit kein log geschrieben wurde (modules\bezug_ethmpm3pm/readlovato.py).
Mit dem legacy run server wird der Fehler abgefangen und gelogged. (packages/modules/common/modbus.py).

Ich denke, dass das Problem schon länger existiert und erst mit dem Update auf Stable 1.9.262 sichtbar wurde.

Die Preisfrage ist, was den Fehler verursacht.

[rleidner]

Was soll ich sagen: Problem gelöst - und ein ziemlich blöder Fehler.

Ursache war meine 2. oWB Test -Instanz, die im Standard die gleiche IP 192.168.193.5 für den virtuellen Netzwerk-Adapter benutzt hat.
Nach Änderung auf *.8 in der Test-Instanz tritt das Problem nicht mehr auf.

Das sollte man beachten, wenn im gleichen Netzwerk mehrere Instanzen der oWB betrieben werden sollen und eines der originalen oWB Kits benutzt wird.

[derNeueDet]

Guter Punkt. Wäre ich aber aus der Ferne nicht drauf gekommen. Ich hab bei der Entwicklung der V2.0 angeregt, dass dort die eigene IP nicht auf 192.168.193.5 gelegt wird, damit die Tester da nicht mit der installierten openWB kollidieren.

VG
Det

[rleidner]

Yupp, die unterschiedliche IP in 2.0 hatte ich sogar gesehen.
Das war u.a schwer zu finden, da das virtuelle Netzwerk mit den üblichen Tools nicht zu sehen ist.

Für den Test-Pi habe ich momentan 3 images: 1.9/stretch, 1.9/buster und 2.0/bullseye.
Gebootet wird ohne SD via PXE vom NAS.
Momentan läuft meistens 1.9, um Smarthome MQ zu testen.