openWB Forum

Tutorial Umstieg software 1.9 auf software2
https://openwb.de/main/?page_id=1104

raffix hat geschrieben: ↑Mo Feb 05, 2024 5:48 pm

mrinas hat geschrieben: ↑Mo Feb 05, 2024 1:11 pmBei mir hat das mit der Latenz bei Tronity zumindest heute Nacht und auch den Tag über heute recht gut gepasst.

Darf ich dich bitten, dir das SoC-Modul von Tronity oder die Berechnung des SoC während dem Laden noch einmal anzuschauen?
Irgendwo ist in der openWB-SoC-Berechnung och ein Bug drin.
Das Abrufen des SoC von Tronity klappte nach dem Einstecken des Fahrzeugs wunderbar (als ich gerade eben nach Hause kam).
Das sieht man auch auf dem Screenshot (Sprung von 100% auf 19%). Dann aber als er während dem Laden den SoC berechnen sollte, trat eine Exception (?) auf, die den Wert auf 0 setzte. Das ist natürlich wiederum doof. (Sieht man auch auf dem Screenshot)
Bildschirmfoto zu 2024-02-05 18-40-27.png
Folgendes tauchte dann im SoC-Log auf:

Code: Alles auswählen

2024-02-05 17:40:12,292 - {modules.common.fault_state:49} - {ERROR:fetch soc_ev2} - Tronity: FaultState FaultStateLevel.ERROR, FaultStr <class 'TypeError'> ("unsupported operand type(s) for -: 'float' and 'NoneType'",), Traceback: 
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 66, in update
    car_state = self._get_carstate_by_source(vehicle_update_data, source)
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 111, in _get_carstate_by_source
    return CarState(soc=calc_soc.calc_soc(vehicle_update_data,
  File "/var/www/html/openWB/packages/modules/vehicles/common/calc_soc/calc_soc.py", line 13, in calc_soc
    imported_since_start = vehicle_update_data.imported - imported_start
TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'

Man sieht also deutlich, dass hier irgendwas schief läuft. Ich habe den Ladevorgang unterbrochen das Auto noch mal raus gezogen und wieder reingesteckt, so dass der SoC nochmal neu von Tronity geladen wird. Das hat dann wieder geklappt.
Manchmal klappt die interne Berechnung des SoC also und ab und an nicht (wie hier).
Wo klemmt es denn da?

Hm, da brauchts vermutlich das gesamte Log, oder zumindest den Regelzyklus mit dem Fehler um zu sehen woher der Fehler kommt. Die manuelle Berechnung des SoC wird als zentrales Modul bereitgestellt und wurder vorher genau so auch vom PSA Modul genutzt. War das in Verwendung, hat das geklappt?
Am besten im Thread für die 2.0er Software posten damit man sich das dort mal anschauen kann.

Schein kein grundsätzliches PRoblem zu sein, hab' das eben mal bei mir angeschmissen. Bisher tut das was es soll, der SoC wird brav hochgerechnet.

mrinas hat geschrieben: ↑Mo Feb 05, 2024 8:38 pmSchein kein grundsätzliches PRoblem zu sein, hab' das eben mal bei mir angeschmissen. Bisher tut das was es soll, der SoC wird brav hochgerechnet.

Leider ist es doch ein grundsätzliches Problem. Es tritt bei mir auch nicht immer auf, aber sporadisch habe ich es schon beobachtet (übrigens auch als das PSA-SoC-Modul noch funktioniert hat, ist es ein bis zweimal aufgetreten).
Ich hatte die Hoffnung, dass sich ein Entwickler mal die Methode anschaut, wo die Exception auftaucht, sich kurz überlegt welche Werte die Parameter haben können (die Exception sagt ja schon, dass da ein falscher Datentyp (?!) kommt) und dann einfach entsprechende Probleme in der Methode direkt abfängt. Beispielsweise könnte man einen falschen Input einfach verwerfen und mit dem alten Wert weitermachen anstatt auf 0 zu setzen. Was die korrekte Lösung ist, müsste man sich im Code anschauen.

Danke für den Tipp mit dem Fehler melden. Doch damit habe ich bislang keine guten Erfahrungen gemacht. Ich habe bereits ein Problem im Beta-Thread gemeldet, doch reagieren tut niemand darauf, auch keine Rückfrage oder dergleichen.
Der einzige von mir bislang gemeldete "Fehler" (Problem) war der der fehlenden Zwischenberechnung, den du direkt via PR in den master gelöst hast.
Ich selbst weiß immer nicht wie ich die Probleme melden soll, dass sie auch wirklich mit entsprechender Prio angegangen (und nicht ignoriert werden). Einen anderen Fehler, den man mMn recht gut im Code finden sollte, hatte ich bereits via GitHub gemeldet. Das Ergebnis: Ich sollte mich an den Support wenden (und das GitHub issue wurde geschlossen). Das habe ich auch gemacht, allerdings wird da wenig bis nichts rauskommen, weil es mMn kein Konfigurationsproblem ist, sondern ein Bug im Code, der erst in den letzten Wochen aufgetaucht ist. Das Problem existiert nach wie vor (und ist echt ärgerlich).

Wenn dieser sporadische Fehler jedenfalls behoben würde, wäre die Nutzung der openWB deutlich komfortabler. Man müsste auch nicht immer mit der Unsicherheit im Hinterkopf leben, ob es wohl wieder klappt oder doch eine Exception auftritt und die Wallbox bis 100% durchlädt, was sie ja genau _nicht_ tun soll.
Das ist der Hintergrund meiner Bitte.

Jup, ich hab' das auch eben bei mir erlebt. Hab' meine Logs eben gepostet, müsste sich das openWB Team anschauen woher das kommt.

Vermutlich fehlt ein korrekter Wert für 'imported_start'. So verstehe ich das, die Operation '-' kann nicht durchgeführt werden da die Datentypen float (vehicle_update_data.imported) nicht mit Datentype 'NoneType' (imported_start) zusammenpassen. Warum der imported_start nun aber fehlt vermag ich nicht zu sagen.

mrinas hat geschrieben: ↑Di Feb 06, 2024 12:54 pm...Hab' meine Logs eben gepostet...

Vielen Dank dafür. Habe den Post von dir soeben im 2er Thread gesehen. Jetzt habe ich auch eine ungefähre Vorstellung wie eine solcher Fehlerbericht aussehen sollte. Das hilft mir vielleicht in der Zukunft.

Hallo,

mal eine andere Idee:
Ist es evtl. möglich den SoC nicht von PSA abzufragen sondern im Auto so einen relativ günstigen OBD2-Bluetooth-Adapter einzubauen und diesen dann per Bluetooth abzufragen?
Entweder mit einem separaten RPi oder direkt mit der OpenWB.

heiko.pv hat geschrieben: ↑Di Feb 06, 2024 1:00 pmIst es evtl. möglich den SoC nicht von PSA abzufragen sondern im Auto so einen relativ günstigen OBD2-Bluetooth-Adapter einzubauen [...]

Im Prinzip schon, aber beim Opel Corsa-e muss die Zündung dafür an sein. Man kann sich zwar auch ohne Zündung mit dem OBD-Adapter verbinden, dann lässt sich aber nicht der SoC auslesen. Findet das Auslesen beim Parken an der Wallbox also schnell genug statt, würde es gehen. Während dem Laden ginge es aber schon wieder nicht und auch nicht, wenn man zwischendurch aus steckt und später wieder einsteckt.

Beim PSA-CarController scheinen sie eine Möglichkeit gefunden zu haben.

Hilft das den Entwicklern hier irgendwie?

https://github.com/flobz/psa_car_controller/pull/754

Gruss
Marty

Marty99 hat geschrieben: ↑Mi Feb 07, 2024 10:18 am Beim PSA-CarController scheinen sie eine Möglichkeit gefunden zu haben.

Hilft das den Entwicklern hier irgendwie?

https://github.com/flobz/psa_car_controller/pull/754

Gruss
Marty

Ehrlich gesagt nicht so richtig. Der Workaround erfordert dass man sich anmeldet, dann die Debug-Konsole des Browsers öffnet (F12) und dort aus einem der vielen Aufrufe den Redirect findet um einen Code zu kopieren.
Also technisch würde das wohl gehen, ja. Aber ich halte das für keinen guten Weg. Zu fehleranfällig, nicht wirklich für die breite Masse an Anwendern geeignet.