Manual SOC resets to initial SOC after target has been reached #1097
Comments
|
Ich konnte das selbe beobachten, allerdings mit einem mittels MQTT gesetzten SOC (Topic war dasselbe wie bei manueller Eingabe: openWB/set/vehicle/0/soc_module/configuration/soc_start). |
|
This reset to the initial SOC value seems to always happen approximately 12 h after charging has reached the target SOC value. Then, charging is started again, but SOC will jump right back to the real value. This pattern is repeated daily. This is despite the value of 72000 minutes entered as polling time for manual SOC in non-charging mode. Behavior observed in Release 2.1.1 with a sold openWB. |
|
The request of the manual soc has been rewritten in master branch with pr #1143. Do you still observe the same behaviour? |
|
Ich habe mit einer Master-Version von 2023-10-23(?) das Verhalten gesehen, daß beim Abziehen des Steckers der SOC sich auf den Wert von vor dem Laden zurückgesetzt hat: |
|
Heute hatte ich nach Abziehen des Ladesteckers wieder ein Rücksetzen auf den manuell vor Beginn der Ladung eingegebenen Wert. @andlem74: Hast du nachts eine Zwangstennung der Internet-Verbindung? Sind die von Dir erwähnten 12h nach Erreichen des Ziel-SOC eventuell nur die Zeitspanne bis zur Zwangstrennung? |
|
Das schöne an der 2.x Cloud ist, dass dort keine Topics hin gesendet werden. Heißt auch, dass nach einer Zwangstrennung keine veralteten Topics wieder in die openWB gesendet werden können. Daher würde ich die Cloud als Ursache vorerst ausschließen, lasse mich aber gerne eines Besseren belehren. |
|
Meines Wissens habe ich keine Zwangstrennung. Mein manueller SoC setzt sich auch zurück auf den Anfangswert, wenn ich den Ladestecker trenne. Am 08.11.2023 um 13:42 schrieb DerHerrW ***@***.***>:
Heute hatte ich nach Abziehen des Ladesteckers wieder ein Rücksetzen auf den manuell vor Beginn der Ladung eingegebenen Wert.
Möglicherweise ist es auch in diesem Zusammenhang relevant, daß nach Trennung der DSL-Verbindung (und damit der Verbindung zur OpenWB-Cloud) und dem Wiederherstellen ebenfalls ein Rücksetzen auf den manuell eingegebenen Wert erfolgte. Vielleicht ist das für den bei mir beobachteten Effekt erforderlich.
@andlem74: Hast du nachts eine Zwangstennung der Internet-Verbindung? Sind die von Dir erwähnten 12h nach Erreichen des Ziel-SOC eventuell nur die Zeitspanne bis zur Zwangstrennung?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Nach dem heutigen Steckerabziehen habe ich ein paar logfiles. Ausgabe eines mqtt-clients, den ich auf das SOC-Setzen angesetzt habe ergibt Den Stand am 10.11. habe ich per UI eingegeben. Die Botschaft am 11.11. kam nach Abziehen des Steckers. Von der cloud web.openwb.de kam nichts. (Cloud ist aus der Konfiguration auch entfernt). Hier die zwei Zeilen im Mainlog, wo die verschiendenen SOC genannt werden: Log hängt an. |
|
Heute habe ich geladen mit der Option "Nur aktualisieren wenn angesteckt=Ja" in der Fahrzeugkonfiguration. Der SOC wurde nach Abstecken nicht zurückgesetzt. |
|
Die Logik wurde mit #1251 nochmal überarbeitet. Bitte nochmal testen. |
|
Irgendwo hakt es noch. Ich habe zwar den Stecker mit der neuen SW noch nicht entfernt, konnte aber schon Auffälligkeiten erkennen. Meine Beobachtungen: Am 16.11.:
Der SOC bliebt zunächst so. Der Stecker ist weiterhin nicht gesteckt.
Im Mainlog habe ich einen Fehler gefunden: "2023-11-17 04:23:10,093 - {modules.update_soc:40} - {ERROR:SoC} - Fehler im update_soc-Modul
|
|
Kann der Fehler "<class 'TypeError'> unsupported operand type(s) for -: 'float' and 'NoneType'" dadurch kommen, daß mein soc_helper den soc jetzt als Integer an die Wallbox telefoniert statt als float? Ich habe das eingeführt, damit ein Setzen auch in Software 1.9 funktioniert, siehe auch https://openwb.de/forum/viewtopic.php?t=7451&start=40 |
|
Heute kurz nach dem Abstecken wurde der SOC ebenfalls wieder auf 0% gesetzt. Der Stecker wurde um 12:15:21 Uhr abgezogen. Das schon erwähnte Topic hat empfangen:
Im Mainlog keine direkt erkennbaren zusammenhängende Fehler: 2023-11-18 12:06:16,554 - {helpermodules.setdata:330} - {ERROR:Setdata} - Payload ungültig: Topic openWB/set/chargepoint/3/set/current, Payload 2 liegt in keinem der angegebenen Wertebereiche. |
|
Bitte nochmal mit der aktuellen Version testen. |
|
Mist - gerade aus versehen die Rückmeldung gelöscht. Ich habe Version 2023-11-21 12:36:53 +0100 [8009e5a]: Main-Log endet am 22.11. |
|
In calc_soc.py findet sich die Zeile "imported_since_start = vehicle_update_data.imported - imported_start" Ich vermute, daß imported_start nicht explizit als float klassifiziert ist, also "NoneType". Ich könnte mir vorstellen, dass beim aufruf der Funktion manchmal kein Typ definiert ist. Fehlt ein Argument am Aufruf? Trotzdem seltsam, da in der Funktion inported_start als float deklariert ist... |
|
Bitte das Debuglevel auf Details stellen und mehrere komplette Durchläufe aus dem SoC-Log unter System->Fehlersuche posten, wenn das Problem auftritt. Sensible Daten wie Benutzernamen und Kennwörter unkenntlich machen. |
|
Hier wie gewünscht das SOC-Log auf Debug-Level. Der letzte Eintrag vor dem ersten Eintrag der Datei ist von 14:20 und hat vmtl mit dem Fehler nichts zu tun. Die 67% hat mein soc_helper beim Anfahren an die Wallbox eingetragen. Die 68% gegen Ende habe ich per Hand eingegeben. Danach läuft das Laden wie gewollt. Mein Topic zum Setzen des Manuellen SOC ist Hier hat noch jemand anders das Problem. |
|
Bei mir tritt das Problem nicht auf. Bitte die dokumentierte Schnittstelle über das MQTT-Modul nutzen oder das manuelle SoC-Modul nur über das Eingabefeld in der openWB verwenden. |
|
Neue Erkenntnis: Ich sehe den Fehler auch dann, wenn ich den SOC per Hand vorgebe:
imported_start in configurable_vehicle ist None, wenn keine Ladung stattfindet, während man einen SOC setzt. Der Fehler kommt nicht, wenn ich nach Start der Ladung (und in diesem Fall Auftreten des Fehlers) einen SOC setze. In diesem Fall wird imported_start auf den Wert des Stromzählers gesetzt. Dies habe ich nur im MQTT-Explorer gesehen, im socLog.txt ist davon nichts zu sehen:
Im MQTT-Explorer konnte ich sehen, daß imported_start=None, manual_soc=46 nur für kurze Zeit (ein Regeldurchlauf, 10s?) stand, danach sprang imported_start auf den aktuellen Zählerstand und manual_soc wieder auf "Null" |
|
Heute noch ein wenig in den Code geschaut. Für mich sieht der Fehler wie folgt aus: calculated_soc_state = imported_start:null, manual_soc:69, soc_start: ..was immer voher drin stand.. Wenn das so bliebe, würde _get_carstate_source den Wert MANUAL zurückgeben und _get_carstate_by_source würde in Zeile 119 abbiegen. Deshalb funktioniert das Laden, wenn nach Ladebeginn manuell ein SOC gesetzt wird. Nun wird nach 10s manual_soc von irgendwoher genullt (im MQTT-Explorer gut zu sehen): calculated_soc_state= imported_start:null, manual_soc:null, soc_start:69 Wenn die Ladung nun erst beginnt, wird _get_carstate_source den Wert CALCULATION zurückgeben. Damit springt _get_carstate_by_source in Zeile 112 - und weil imported_start=None ist, tritt der Fehler (siehe) auf. Der Fix könnte sein, das automatische Übernehmen von manual_soc nach soc_start zu verhindern - da kann ich aber die Nebenwirkungen auf andere SOC-Module nicht richtig einschätzen. Ich weiss auch nicht, in welcher Funktion das geschieht. |
|
Bitte testen, ob die in PR # 1280 korrgierte Zeile das Setzen von imported_start verhindert hat. |
|
Also das Laden wurde jedenfalls begonnen und läuft ohne Rücksetzen. Ich glaube aber, der grundsätzliche Fehlermechanismus ist noch vorhanden: Jetzt tritt der Fehler nur einmal in Zeile 66 auf, bevor in Zeile 71 imported_start gesetzt wird. Das wird von der Fallback-Lösung noch geduldet. Als Hotfix funktionert die Änderung, sauber wäre es aus meiner Sicht, wenn in _get_carstate_by_source auch source == SocSource.MANUAL wäre - irgendwie scheint die Funktion darauf zu beharren, daß beim ersten Aufruf source == SocSource.CALCULATION sei. |
|
Bei mir hat das Laden jetzt fehlerfrei funktioniert. Leider hatte ich DEBUG nicht an, als der Stecker gesteckt wurde. Das SOC-Log ist aber leer, der MQTT-Explorer zeigt keine verdächtigen Botschaften und in meinem zusätzlichen MQTT-Logger ist auch nichts zu sehen, was auf ein Problem hindeutet. Ich schlage vor, diesen Issue zu schließen. Hier wurden ja verschiedene Fehler behandelt und behoben. Sollte noch ein Problem auftauchen, würde ich es mit passender Überschrift in einem neuen Issue einbringen. |
In manual SOC mode, the user entered an initial SOC of e. g. 15%. After the SOC has reached its target value, e. g. 80% the SOC displayed is reset to the initial value, e. g. 15%, after the polling delay for non-charging state (default is 720 minutes) has passed. This is both incorrect and confusing. Charging will restart from this incorrect value.
The text was updated successfully, but these errors were encountered: