Ich nutze Kernel: Linux 5.10.17-v7l+ GNU/Linux mit openWB Version: 1.9.235,
Der SoC kommt bei mir immer korrekt an. Ich habe dieses Phänomen bei EVsOC 2.2 bisher nie beobachtet.
Ich würde an Deiner Stelle im Debug-Log mal schauen, ob EV und evSoc tatsächlich einen SoC=0 gemeldet haben.
Vielleicht wurde so ein Wert falsch vom EV geliefert.
Zur Not dann in evSoc.py mal die folgende Zeile abändern:
Statt
Code: Alles auswählen
for repeat in range(2): # repetitions in case of faults
SoC=car.pollData() # -1 if fault happend (ECUs unpowered in car)
polled = (SoC >= 0)
if not polled:
log.warning("Re-Init Dongle - repeat "+str(repeat))
dann
Code: Alles auswählen
for repeat in range(2): # repetitions in case of faults
SoC=car.pollData() # -1 if fault happend (ECUs unpowered in car)
polled = (SoC > 0) #geändert
if not polled:
log.warning("Re-Init Dongle - repeat "+str(repeat))
Dadurch liefert evSoc niemals einen SoC==0 an openWB. Dies ist ein dirty-patch, aber falls es hilft...sofern die Batterie nicht wirklich absolut leer ist.
Ich selbst teste seit einigen Wochen ohne Probleme
evSoc 2.3. In dieser neuen Version kann über MQTT mit einer Nachricht an evSoc eine zusätzliche SoC-Abfrage initiiert werden, falls z.B. das Garagentor geöffnet wird und das EV an die Wallbox fährt, OHNE dass der Ladestecker angesteckt wird.
Dadurch wird immer der aktuelle SoC im openWB angezeigt. Die MQTT-Nachricht muss dann von einem Homeserver generiert werden. Ich nutze "fhem" dafür und einen Garagentorstatus. Die geänderte Datei habe ich hier für Interessierte beigefügt, sie ersetzt die gleichnamigen aus version 2.2.
Der Garagentorstatus wird von evSoc 2.3 fest codiert im MQTT topic "evSoc/carport/boolOpenStat" erwartet. (bei Tor eine "0", bei allen anderen Werten versucht evSoc eine Verbindung zum EV aufzubauen.) Da das Garagentor meistens zu ist, wird die 12V Batterie auch nicht exzessiv strapaziert.
Der Patch auf 2.3 hat KEINEN Einfluss auf das von Dir beobachtete Verhalten!
