Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

[zut]

So, mögen die Tests beginnen. Im Anhang die Dateien zum freien Ausprobieren. Feedback ist ausdrücklich erwünscht.

Da das erst das zweite Mal ist, daß ich in python etwas mache (das erste Mal ist etwa 18 Jahre her), lerne ich auch gerne noch dazu, wie man die Funktion eleganter realisiert.

Hat jemand Lust, sich Gedanken über das Handling von Exceptions und Rückgabewerten zu machen? Momentan endet das Programm mit einem Knall bei vielen Funktionen, wenn etwas nicht wie erwartet funktioniert. Das mag ich nicht...

Dann würde ich gerne wissen, ob das Einbuchen in das Heimnetz mit einer Fritzbox als AccessPoint auf Dauer funktioniert. Ich kenne Berichte im Netz, daß das mit dem ESP32 (auch im WiCAN verbaut) nur jedes zweite Mal funktionieren würde. Da AVM in Australien (wo der WiCAN erntwickelt wird) vermutlich wenig verbreitet ist, besteht möglicherweise dort kein Problembewußtsein. Es gibt eine Firmware 2.10 Beta mit "improved WIFI Stability". Geht es damit besser?

[zut]

Im Code für die Übertragung zu Spritmonitor war noch ein Fehler, der beim Versuch einer Differenzbildung von int und byte das Prgramm mit einem Fehler beendete. In der Version im Anhang hoffentlich gefixt.

[zut]

Eben gerade alles erfolgreich durchlaufen: einbuchen, SOC setzen, laden, beim Abstecken einen Eintrag bei Spritmonitor. Bin zufrieden.
Der WiCAN scheint mit Firmware 2.10 auch zuverlässiger mit Fritzboxen zu arbeiten, habe ich gehört.
Hat jemand noch Software 1.9 und kann mir die topics der Wallbox (Steckerzustand mit Werten, aktueller SOC) sagen so dass ich die in die Konfigurationsdatei mit aufnehmen kann?

[ChristophR]

Ich antworte mal hier, da es in den anderen Thread ja nicht hingehört, warum ich mich nicht zum Testen gemeldet habe.
Ich würde von dem SoC-Modul schon erwarten, dass der SoC stets nachgezogen wird und nicht nur einmalig in den manuellen SoC geschrieben wird.
Allerdings ist es durch den aktuellen Fehler im manuellen SoC Modul ja sowieso schwierig zu nutzen?
Ich würde eher einen Ansatz mit HTTP SoC Modul gehen, dann steuert die openWB alles selbst und Du musst nur einen Webservice zur Verfügung stellen. Allerdings sagt sich das für mich ja leicht, da ich überhaupt nicht programmieren kann/will/muss
Ich frage mich auch, wie Du überhaupt den SoC zuverlässig in die Wallbox bekommst, wenn der WLAN Empfang dort schlecht ist.
Das sehe ich in dem Fall schon als grundsätzliche Voraussetzung.

Ein Modul zum Abfragen über einen ODBII Dongle gibt es ja schon (EVNotify), allerdings fände ich auch eine Lösung ohne Cloud sehr interessant.
Der Dongle schreckt mich weniger ab, als der zusätzlich benötigte Rechner, die openWB sollte schon supported bleiben, daher fällt die aus.
Bei EVNotify wird ein Handy benötigt, das ist auch nicht die ideale Lösung, aber damit teste ich gerade rum...

Ob der WLAN Dongle im Gegensatz zum Bluetooth Dongle nicht deutlich mehr Strom verbraucht und damit das Auto leersaugt, kann ich auch nicht beurteilen. (Das Problem gab es bei anderen SoC-Implementationen hier im Forum schon).

[zut]

Hallo Christoph,

danke für Deine Rückmeldungen. Ich möchte darauf eingehen:

Ich würde von dem SoC-Modul schon erwarten, dass der SoC stets nachgezogen wird und nicht nur einmalig in den manuellen SoC geschrieben wird. Allerdings ist es durch den aktuellen Fehler im manuellen SoC Modul ja sowieso schwierig zu nutzen?

Durch umkommentieren einiger Zeilen einiger Zeilen am Ende des Programms (Auskommentieren der Endlos-Warteschleife, einkommentieren der Schleife, die alle paar Minuten den SOC anfragt) kann man das so handhaben. Dann könnte man vermutlich auch das MQTT-Modul nutzen. Noch komme ich nicht dazu, das auszuprobieren. Aus meiner Sicht sprechen halt zwei Gründe dagegen:

1. Das Fahrzeug muß während des Ladevorgangs kontinuierlich die NV-Batterie laden, damit das Dongle aufwacht. Das ist beim e-up! so, schließt aber möglicherweise andere Fahrzeuge aus.
2. Wenn es während der Ladung zu Kommunikationsproblemen kommt, würde das MQTT-Modul aus meiner Sicht den SOC nicht weiter erhöhen, das Fahrzeug würde überladen. Bei Manuell ist die OpenWB nicht auf das Fahrzeug angewiesen, wenn die initiale Übertragung funktioniert hat - dies kann einmalig nach dem Abstellen des Fahrzeugs überprüft werden, zum Beispiel mit einem Blick auf das Wallbox-Display vor dem Anstecken.
3. Durch den Bug im Manuell-SOC wäre eine Anpassung während der Ladung in der Tat nicht so gut. Ich erwarte aber, daß das irgendwann - hoffentlich bald - behoben wird. Dann könnte man die zyklische Abfrage bei Vorliegen der mötigen Randbedingungen aktivieren und würde ein Auseinanderlaufen von berechnetem und vom Fahrzeug ermittelten SOC immer wieder korrigieren.

Ob der WLAN Dongle im Gegensatz zum Bluetooth Dongle nicht deutlich mehr Strom verbraucht und damit das Auto leersaugt, kann ich auch nicht beurteilen. (Das Problem gab es bei anderen SoC-Implementationen hier im Forum schon).

Das ist aus meiner Sicht das Schöne am WiCAN: Der Schlafmodus, der das Dongle in den Stromsparmodus versetzt, wenn die NV-Batterie eine Zeit lang nicht geladen wird. Damit ist der Stromverbrauch unkritisch, das Dongle allerdings nicht mehr erreichbar. Wie oben geschrieben, wacht es wieder auf, wenn das Fahrzeug bei Beginn des HV-Ladens auch die NV-Batterie lädt.

Zum http-SOC kann ich nichts sagen - damit kenne ich mich nicht aus. Mir erschien die Lösung per MQTT als so simpel und flexibel, daß ich sie einfach verfolgt habe. Einen Raspi habe ich sowieso seit 2 Jahren im Dauerbetrieb, um meine Heizung zu loggen, da hat mich das auch nicht abgeschreckt.

[zut]

Neue Version: Kommentare, README.txt überarbeitet und ergänzt.

Keine funktionalen Änderungen.

[zut]

Neue Version.

• Work-Around: Wenn zweimal bei gleichem km-Stand geladen wird, wird ein trip von 0,1km übermittelt, da Spritmonitor sonst den Eintrag als ungültig markiert.
• Fix: Der SOC bei Abstecken von der OpenWB wurde in die Speicherdatei mit der Bytestring-Formatierung ausgegeben. Das sollte behoben sein
• Feature: In der Konfigurationsdatei wird jetzt ein kWh-Preis angegeben, der bei Spritmonitor angegeben wird. Der Preis gilt für jeglichen Strom (Netzbezug, PV, Speicher). Immer noch besser als 0.

Alle Änderungen sind bis jetzt ungetestet.

[zut]

Die Änderungen von 2. und 3. Punkt funktionieren bei mir.

[zut]

Hat eigentlich jemand vor, das Projekt ebenfalls umzusetzen? Ich würde mich über Feedback freuen.

[zut]

Work-Around: Wenn zweimal bei gleichem km-Stand geladen wird, wird ein trip von 0,1km übermittelt, da Spritmonitor sonst den Eintrag als ungültig markiert.

Der Punkt ist jetzt auch einmal erfolgreich durchgelaufen.