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

[KrailPV]

Wäre interessiert, was wären die Kosten? Ist da das Skript schon drauf? Funktioniert das mit openWB 2.0?

Im letzten Doppelpack habe ich etwa 38€ pro Stück bezahlt. Skript: Da hast du wohl etwas falsch verstanden - soc_helper läuft auf einem separaten Rechner oder (bei Selbstbau) auf der OpenWB. Auf dem WiCAN ist eine aktuelle Firmware 2.98.
Der soc_helper funktioniert in der aktuellen Version nur mit SW 2.x

Leider keine Selbstbau openWB, aber noch einen Rpi mit Homeassistent, könnte ich dort dann die Software installieren? Wie komplex ist das?

[ChristophR]

Hallo zut,

Du schreibst in Deiner Doku:

MQTT elm327 log: Sollte auf Disable stehen bleiben. Ansonsten kann man mit dem weiter unten stehenden Filter CAN-Botschaften der OBD-Schnittstelle definierten, die automatisiert umgerechnet und an den Broker geschickt werden. Im Fall soc_helper passiert dies aber nicht auf dem WiCAN.

Könnte man in der openWB nicht auch das MQTT SoC-Modul nehmen und dann den WiCAN den SoC über die Filter direkt an die richtige Stelle im Broker der openWB schreiben lassen?
So könnte man sich den zusätzlichen Rechner sparen, wenn man nur den SoC benötigt und dieser regelmäßig abgefragt werden kann.

[zut]

Hallo zut,

Du schreibst in Deiner Doku:

MQTT elm327 log: Sollte auf Disable stehen bleiben. Ansonsten kann man mit dem weiter unten stehenden Filter CAN-Botschaften der OBD-Schnittstelle definierten, die automatisiert umgerechnet und an den Broker geschickt werden. Im Fall soc_helper passiert dies aber nicht auf dem WiCAN.

Könnte man in der openWB nicht auch das MQTT SoC-Modul nehmen und dann den WiCAN den SoC über die Filter direkt an die richtige Stelle im Broker der openWB schreiben lassen?
So könnte man sich den zusätzlichen Rechner sparen, wenn man nur den SoC benötigt und dieser regelmäßig abgefragt werden kann.

Das MQTT-Modul rechnet den SoC nicht alleine hoch, sondern muss periodisch den SoC geschrieben bekommen. Zumindest der eUp antwortet auf der OBD-Buchse nur, wenn er gefragt wird. Es muss also von aussen periodisch eine Anfrage kommen. Dafür braucht es einen Rechner. Dazu kommt, daß der WiCAN schlafen gehen soll, um die NV-Batterie zu schonen. Im Schlaf ist er nicht ansprechbar. Ich habe beobachtet, daß nach einiger Zeit des Ladens (vermutlich, wenn die NV-Batterie voll ist) der WiCAN bei weiterhin aktiver HV-Ladung einschläft. In diesem Zustand kann der SoC nicht einmal von aussen abgefragt werden.

[zut]

Leider keine Selbstbau openWB, aber noch einen Rpi mit Homeassistent, könnte ich dort dann die Software installieren? Wie komplex ist das?

Das ist nicht so schwer, wenn man die Unix-Kommandozeile beherrscht. Anleitung ist ja vorhanden: https://github.com/DerHerrW/soc_helper/ ... hon-pakete, ab Einspielen der python-Pakete.

Bei mir läuft ein RPi4, der ausserdem iobroker, influxdb, grafana und einen selbstgeschriebenen Heizungslogger laufen läßt.

[ChristophR]

Hallo zut,

Du schreibst in Deiner Doku:

MQTT elm327 log: Sollte auf Disable stehen bleiben. Ansonsten kann man mit dem weiter unten stehenden Filter CAN-Botschaften der OBD-Schnittstelle definierten, die automatisiert umgerechnet und an den Broker geschickt werden. Im Fall soc_helper passiert dies aber nicht auf dem WiCAN.

Könnte man in der openWB nicht auch das MQTT SoC-Modul nehmen und dann den WiCAN den SoC über die Filter direkt an die richtige Stelle im Broker der openWB schreiben lassen?
So könnte man sich den zusätzlichen Rechner sparen, wenn man nur den SoC benötigt und dieser regelmäßig abgefragt werden kann.

Das MQTT-Modul rechnet den SoC nicht alleine hoch, sondern muss periodisch den SoC geschrieben bekommen. Zumindest der eUp antwortet auf der OBD-Buchse nur, wenn er gefragt wird. Es muss also von aussen periodisch eine Anfrage kommen. Dafür braucht es einen Rechner. Dazu kommt, daß der WiCAN schlafen gehen soll, um die NV-Batterie zu schonen. Im Schlaf ist er nicht ansprechbar. Ich habe beobachtet, daß nach einiger Zeit des Ladens (vermutlich, wenn die NV-Batterie voll ist) der WiCAN bei weiterhin aktiver HV-Ladung einschläft. In diesem Zustand kann der SoC nicht einmal von aussen abgefragt werden.

Könnte man die Abfrage (Die muss natürlich funktionieren) dann nicht als SoC Modul auf der openWB laufen lassen? Das sind ja auch Phyton Scripte, die dort laufen. Ich hätte halt gerne am liebsten alles auf einem System. Leider kann ich genau gar nicht programmieren, so dass ich weder helfen noch das beurteilen kann.

Ich habe das Problem der leeren NV Batterien so verstanden, dass das Auto durch die Abfragen der Dongles zu oft aufgeweckt wurde und dies die Batterien belastet. Ich kann mir eigentlich nicht vorstellen, dass der kleine Adapter so viel Strom frisst (auch wenn er nicht schläft), dass er die Batterie komplett entlädt. Wenn das aber so ist, könnte man die "Schlafspannung" ja so niedrig einstellen, dass ab einer gewissen Entladung, die man nicht unterschreiten will, der Dongle erst einschläft, quasi als Notabschaltung.

[mattberlin]

Sicher könnte openWB das als SoC-Modul integrieren.
Dafür müsste aber entschieden werden, dies ins Lastenheft zu schreiben, was aktuell noch nicht der Fall ist.

[ChristophR]

Sicher könnte openWB das als SoC-Modul integrieren.
Dafür müsste aber entschieden werden, dies ins Lastenheft zu schreiben, was aktuell noch nicht der Fall ist.

Die ersten SoC Module wurden von openWB beigesteuert, der Rest kommt durch die Community.
Es wird also nur etwas, wenn sich hier passende Experten zusammenfinden.

Ich wollte nur eine Einschätzung, ob das überhaupt praktikabel ist oder die benötigten Einstellungen und Abfragen sich gar nicht für ein SoC Modul eignen würden.
Hier sind ja doch sehr spezielle Parameter nötig, die nicht für alle Fahrzeuge passen.

[zut]

Könnte man die Abfrage (Die muss natürlich funktionieren) dann nicht als SoC Modul auf der openWB laufen lassen? Das sind ja auch Phyton Scripte, die dort laufen. Ich hätte halt gerne am liebsten alles auf einem System. Leider kann ich genau gar nicht programmieren, so dass ich weder helfen noch das beurteilen kann.

Wahrscheinlich kann man das integrieren. Momentan habe ich jedoch nur 2 Fahrzeuge, die bestätigt funktionieren. Ich bin gerade im Gespräch mit jemandem mit einer alten Zoe, da wird das schon schwieriger. Daß es pro Fahrzeugtyp und teilweise Produktupdate da unterschiedliche Abfragen gibt, macht die Sache nicht leichter. Ich gehe auch davon aus, daß die Klimmzüge in ein paar Jahren für alle Neufahrzeuge Geschichte sind, da dann per Ladestecker der SoC zuverlässig abgefragt werden kann.
Dann ist das die Integration von Spritmonitor, die vermutlich auch Absprachen in der Zusammenarbeit mit OpenWB erfordern, und auf das ich nicht verzichten möchte. Vielleicht kann man einen Versuch starten, wenn vielleicht ein Dutzend geläufige Fahrzeuge funktioniert. Bis dahin bin ich ganz glücklich mit meiner Lösung.

Ich habe das Problem der leeren NV Batterien so verstanden, dass das Auto durch die Abfragen der Dongles zu oft aufgeweckt wurde und dies die Batterien belastet. Ich kann mir eigentlich nicht vorstellen, dass der kleine Adapter so viel Strom frisst (auch wenn er nicht schläft), dass er die Batterie komplett entlädt. Wenn das aber so ist, könnte man die "Schlafspannung" ja so niedrig einstellen, dass ab einer gewissen Entladung, die man nicht unterschreiten will, der Dongle erst einschläft, quasi als Notabschaltung.

Also, der Adapter wird vermutlich weniger als 100mA Strom ziehen. 100mA gingen gar nicht, 10mA wäre schon kritisch: Die Bleibatterien mögen keine Zyklisierungen. Was altert ist die Gesamtladungsmenge, die über Lebensdauer ausgetauscht wird. Technisch ginge das schon, daß man den Adapter erst unterhalb von z.B. 12V in den Schlafmodus gehen läßt. Für mich ist es aber momentan der Idealzustand, wenn der SoC beim Einfahren ins Carport in die WB geschrieben wird und danach das Fahrzeug keine Rolle mehr spielt.

Ich kenne keine Möglichkeit, ein Fahrzeug per OBD-Buchse aufzuwecken. Bei einigen mag das funktionieren, ich kenne sie nicht. Andere schlafen eventuell schon beim Laden ein. Das Motorsteuergerät legt sich bei vielen nach Wegnahme der Fahrbereitschaft nach einer Nachlaufzeit schlafen. Das HV-Steuergerät ist beim Laden meist wach, aber ist das CAN-Gateway das auch? Es gibt da keinen Standard.

Zum Punkt regelmäßig von der Wallbox aus abfragen: Ob ich nun den soc_helper auf der wallbox laufen lasse oder ein anderes Programm, das regelmäßig Abfragen stellt, scheint mir kein großer Unterschied
Ich habe übrigens von Leuten gelesen, die HomeAutomation oder Node Red so nutzen, daß sie alle paar Minuten stumpf eine Abfrage an den WiCAN rausschicken, egal ob der da ist und wach oder nicht. Das wäre auch eine Lösung.

[ChristophR]

Könnte man die Abfrage (Die muss natürlich funktionieren) dann nicht als SoC Modul auf der openWB laufen lassen? Das sind ja auch Phyton Scripte, die dort laufen. Ich hätte halt gerne am liebsten alles auf einem System. Leider kann ich genau gar nicht programmieren, so dass ich weder helfen noch das beurteilen kann.

Wahrscheinlich kann man das integrieren. Momentan habe ich jedoch nur 2 Fahrzeuge, die bestätigt funktionieren. Ich bin gerade im Gespräch mit jemandem mit einer alten Zoe, da wird das schon schwieriger. Daß es pro Fahrzeugtyp und teilweise Produktupdate da unterschiedliche Abfragen gibt, macht die Sache nicht leichter. Ich gehe auch davon aus, daß die Klimmzüge in ein paar Jahren für alle Neufahrzeuge Geschichte sind, da dann per Ladestecker der SoC zuverlässig abgefragt werden kann.
Dann ist das die Integration von Spritmonitor, die vermutlich auch Absprachen in der Zusammenarbeit mit OpenWB erfordern, und auf das ich nicht verzichten möchte. Vielleicht kann man einen Versuch starten, wenn vielleicht ein Dutzend geläufige Fahrzeuge funktioniert. Bis dahin bin ich ganz glücklich mit meiner Lösung.

Ich habe das Problem der leeren NV Batterien so verstanden, dass das Auto durch die Abfragen der Dongles zu oft aufgeweckt wurde und dies die Batterien belastet. Ich kann mir eigentlich nicht vorstellen, dass der kleine Adapter so viel Strom frisst (auch wenn er nicht schläft), dass er die Batterie komplett entlädt. Wenn das aber so ist, könnte man die "Schlafspannung" ja so niedrig einstellen, dass ab einer gewissen Entladung, die man nicht unterschreiten will, der Dongle erst einschläft, quasi als Notabschaltung.

Also, der Adapter wird vermutlich weniger als 100mA Strom ziehen. 100mA gingen gar nicht, 10mA wäre schon kritisch: Die Bleibatterien mögen keine Zyklisierungen. Was altert ist die Gesamtladungsmenge, die über Lebensdauer ausgetauscht wird. Technisch ginge das schon, daß man den Adapter erst unterhalb von z.B. 12V in den Schlafmodus gehen läßt. Für mich ist es aber momentan der Idealzustand, wenn der SoC beim Einfahren ins Carport in die WB geschrieben wird und danach das Fahrzeug keine Rolle mehr spielt.

Ich kenne keine Möglichkeit, ein Fahrzeug per OBD-Buchse aufzuwecken. Bei einigen mag das funktionieren, ich kenne sie nicht. Andere schlafen eventuell schon beim Laden ein. Das Motorsteuergerät legt sich bei vielen nach Wegnahme der Fahrbereitschaft nach einer Nachlaufzeit schlafen. Das HV-Steuergerät ist beim Laden meist wach, aber ist das CAN-Gateway das auch? Es gibt da keinen Standard.

Zum Punkt regelmäßig von der Wallbox aus abfragen: Ob ich nun den soc_helper auf der wallbox laufen lasse oder ein anderes Programm, das regelmäßig Abfragen stellt, scheint mir kein großer Unterschied
Ich habe übrigens von Leuten gelesen, die HomeAutomation oder Node Red so nutzen, daß sie alle paar Minuten stumpf eine Abfrage an den WiCAN rausschicken, egal ob der da ist und wach oder nicht. Das wäre auch eine Lösung.

Danke für Deine Ausführungen.

Ich habe inzwischen eine weitere VM vorbereitet, auf der ich den soc_helper laufen lassen kann.
2 Kleinigkeiten, die mir bei der Einrichtung aufgefallen sind:
Ich habe aus Github mir die ZIP-Datei heruntergeladen, die heißt dann im Standard soc_helper-main.zip.
Im Home-Verzeichnis habe ich sie dann einfach entpackt, dadurch passten die Pfade zu den CSV-Dateien, die erstellt werden nicht.
Als ich das bemerkt habe, habe ich das Verzeichnis entsprechend umbenannt.
Ich hatte einen anderen Benutzer, den ich benutzt habe, daher musste ich noch den Logpfad ganz unten in der configuration anpassen, da ist /home/pi fest hinterlegt.
Vielleicht kann man die beiden Pfadangaben relativ statt absolut gestalten, damit das auf Anhieb klappt.

Jetzt warte ich erstmal auf meinen Dongle und schaue, wie es bei mir läuft.
Habe schonmal in meinem jetzigen Tronity Modul das manuelle Berechnen aktiviert, um die Ladeverluste anzugleichen...
Wenn ich bei der 1-maligen Abfrage beim Anstecken bleibe, habe ich vielleicht auch kein Problem mit der Alarmanlage, das ist ja noch offen.

Mir gefällt halt die Vollständige Unabhängigkeit von Cloud/Internet bei Deiner Lösung, den Spritmonitor habe ich dabei verdrängt, da es mir nur um den SoC geht.
Daher fand ich die Idee eines SoC-Moduls, was nur in der openWB läuft und dort einmalig oder regelmäßig die SoC Abfragen steuert, ganz charmant.
Dann muss sich der geneigte Anwender ohne Zusatzwissen nicht noch um eine externe Installation kümmern, das würde bestimmt den nutzenden Personenkreis erweitern.
Allerdings müssen die regelmäßigen Abfragen schon zuverlässig laufen, sonst verwirft die openWB den letzten SoC als ungültig und geht auf 0%.
Ich werde dann mal beobachten, wie sich der Born verhält, aber ID.3 kennst Du ja schon...
Dann brauchen wir "nur" noch eine Unterstützung möglichst vieler Fahrzeuge, aber wenn es da je nach deren Softwarestand schon Abweichungen gibt, macht es das natürlich nicht einfacher...
In der neuen Firmware, die noch Beta ist, steht etwas von Auto PID Request, wird das für die Unterstützung anderer Fahrzeuge ggf. etwas vereinfachen oder ist das was anderes?

[KrailPV]

Hallo zusammen,
wäre super wenn es den Weg in die normale openWB Software finden würde