EVU Kit mit ständigen Timeouts

[Gero]

Hattest du dann auch ab und zu Timeouts oder kompletten Abbruch? War das Kabel komplett durch oder nur ein paar Adern?

Es waren verlorene Pakete, also kein dauerhafter Verbindungsabbruch. Herausbekommen habe ich es mit einem Dauerping, der zwischendurch immer mal wieder mehr oder weniger verlorene Pakete gemeldet hat. Hat aber ein bisschen gedauert, bis ich auf den Schuldigen gekommen bin. Ich hatte auch erwartet, dass wenn man einmal ein Kabel aufgelegt hat, dass das dann auch so bleibt und nicht irgendwann mal einen Wackeligen ergibt. Die Adern eines Patchkabels sind aber irgendwie zu dünn um zuverlässig geklemmt zu werden.

[hhoefling]

Wenn, was zu prüfen wäre, beide Boxen die interne IP Adresse 192.168.193.5 für sich beanspruchen,
könnte es probleme geben wenn 192.168.193.15 mit der Master reden will.

[warbird]

Das tun sie natürlich, da alle Einstellungen auf "Standard" geblieben sind...
Ich kann natürlich die IP mal auf 192.168.193.7 ändern, bei der Slave Box und checken, ob sich was tut. Dazu muss aber das Auto abgesteckt werden...Versuche ich in der nächsten Stunde zu testen.

[rleidner]

Ich sehe diese timeouts des EVU-Kit V2 (Lovato / Elfin EE11) auch schon immer (> 2 Jahre) auf meiner "produktiven" Kaufbox
Anfrage an Support ergab: Kein Problem solange es nur sporadisch auftritt.
Trotz der Fehler ist die Funktion völlig normal, daher habe ich es bisher ignoriert.

Ich habe neben der Kaufbox zum Entwickeln und Test 2 Raspis laufen mit:
- Pi 3b+ mit owb 1.9
- Pi 4 mit owb 2.0

owb 2.0 läuft schon einige Zeit mit konfiguriertem EVU-Kit - im log sehe ich keine timeout Fehler.

In owb 1.9 test habe ich heute den EVU von MQTT auch auf EVU-Kit umgestellt und die IPs des *193-netzwerks angepasst.
Es reden also damit 3 owb-Instanzen direkt mit dem EE11!

In der 1.9 Test hatte ich zunächst auch die timeouts.

Ich habe dann im Code den Timeout des ModbusTcpClient auf 10 sec geändert.
Damit habe ich in owb 1.9 Test innerhalb einer Stunde keinen einzigen timeout gesehen.

Die Änderung sieht so aus (2 neue Zeilen, vorn mit +):

Code: Alles auswählen

diff --git a/packages/modules/devices/openwb_evu_kit/device.py b/packages/modules/devices/openwb_evu_kit/device.py
index 49bd3c1c..a3a70fd3 100644
--- a/packages/modules/devices/openwb_evu_kit/device.py
+++ b/packages/modules/devices/openwb_evu_kit/device.py
@@ -13,6 +13,7 @@ from modules.devices.openwb_evu_kit import counter
 from modules.devices.openwb_evu_kit import inverter
 from modules.devices.openwb_evu_kit.config import EvuKit, EvuKitBatSetup, EvuKitCounterSetup, EvuKitInverterSetup
 from modules.devices.openwb_pv_kit.inverter import PvKit
+from pymodbus.constants import Defaults
 
 log = logging.getLogger(__name__)
 
@@ -27,6 +28,7 @@ class Device(AbstractDevice):
     def __init__(self, device_config: Union[Dict, EvuKit]) -> None:
         self.device_config = dataclass_from_dict(EvuKit, device_config)
         self.components = {}  # type: Dict[str, Union[BatKit, counter.EvuKit, PvKit]]
+        Defaults.Timeout = 10
         self.client = modbus.ModbusTcpClient_("192.168.193.15", 8899)

Frage an die Modbus - Experten: macht ein PR Sinn oder könnten mögliche Nebenwirkungen bestehen?

EDIT:
Jetzt sind auf der Kaufbox die timeouts auch verschwunden.
Der Grund war also, dass die owb 1.9 test die gleiche IP Adresse benutzt hat, wie die prod, dabei ist es egal ob diese aktiv benutzt wird oder nicht.
Ich habe 2 Instanzen owb1.9 test, stretch und buster.
Soweit ich mich erinnere hatte ichh das vor langer Zeit schon mal und auf buster geändert.
Momentan auf stretch war die iP noch auf derselben wie in der PROD....

Also obiges Änderung ist nicht nötig.
BTW, der default timeout in pymodbus ist 3 Sek.

[hhoefling]

Wenn eine Box auf "Slave" umgeschalte wird..
muss sie rebootet werden wenn das 193.'er Netzt benutzt wird.
Sie behält die ...5 bis nach dem Reboot.


Siehe:
viewtopic.php?p=63230#p63230

[rleidner]

Irgendwie hatte ich im Hinterkopf dass wir das schon mal gelöst hatten ...: viewtopic.php?p=62876#p62876

[warbird]

Hab aus der 5 eine 7 gemacht, bei der Slave Box und siehe da, keine Timeouts mehr. Außerdem habe ich an der Slave Box das EVU Kit komplett deaktiviert.

Jetzt habe ich nur noch sowas drin:

Code: Alles auswählen

2022-12-22 18:01:19: PID: 4666: **** WARNING **** Regulation loop needs 8 seconds (LV0)
2022-12-22 18:00:57: PID: 29244: **** FATAL ********************************* (LV0)
2022-12-22 18:00:57: PID: 29244: **** FATAL Regulation loop needs 46 seconds (LV0)
2022-12-22 18:00:57: PID: 29244: **** FATAL ********************************* (LV0)
2022-12-22 18:00:22: PID: 30625: Pause nach Umschaltung: 15s (LV0)
2022-12-22 18:00:03: PID: 27568: ##### cron5min.sh finished ##### (LV0)
2022-12-22 18:00:02:  Load: 1.35 0.93 1.25

[LarsBr87]

Vll eine dumme Frage, aber wie ändere ich die IP?
Bin noch nicht ganz mit von der Partie. Würde das dann auch gerne testen. Danke schonmal

[rleidner]

Vll eine dumme Frage, aber wie ändere ich die IP?
Bin noch nicht ganz mit von der Partie. Würde das dann auch gerne testen. Danke schonmal

Einstellungen - System - Netzwerk-Einstellungen

[LarsBr87]

Danke

Edit: läuft seid dem einwandfrei. Vielen Dank an alle Beteiligten, immer wieder schön, wenn man Problem so schnell lösen kann!