Replies: 10 comments 21 replies
-
Beispiel-Config für evNotify über evNotify-Server:
|
Beta Was this translation helpful? Give feedback.
-
Nachtrag: hier gibt es noch eine Lösung basierend auf evNotiPi, die den SoC direkt auf einem MQTT Broker publiziert. |
Beta Was this translation helpful? Give feedback.
-
Danke @mclane Was ich noch hinzufügen könnte, wäre der WiCAN von MeatPi Für den MeatPi gibt es aber angeblich eine Software, die einzelne IDs vom CAN-Bus auf MQTT übersetzt und anders herum. Hat jemand Erfahrungen mit dem Freematics / MeatPi und sich eine Brücke von OBD -> Freematics -> Wlan -> MQTT gebaut? |
Beta Was this translation helpful? Give feedback.
-
Hi, das ist von mir :-) Der aktuelle Auto SOC kommt vom WiCan und geht per HomeAssistant an die CFOS Wallbox. |
Beta Was this translation helpful? Give feedback.
-
Hallo, gibt es Bezugsquellen in Deutschland oder Europa? Oder kann man den Dongle aktuell nur über Mouser beziehen? |
Beta Was this translation helpful? Give feedback.
-
Ich bin auch gerade dabei, mir einen zu beschaffen. Könnte 2 bestellen, dann sind sie versandkostenfrei. Quelle in D kenne ich auch nicht. |
Beta Was this translation helpful? Give feedback.
-
Der Stick sieht ja ganz gut aus. Wir haben einen älteren Kangoo im Einsatz für den ich das schon gut gebrauchen könnte. |
Beta Was this translation helpful? Give feedback.
-
Ich hatte mit einem OBD Dongle im BMW IX3 für ABRP herumgespielt und das Teil dann wieder herausgezogen, weil es in den ungünstigsten Momenten die Alarmanlage des Autos getriggert hat. Ich würde einen OBDII Bluetooth Dongle nicht dauerhaft im Auto haben wollen, auch aus Sicherheitsbedenken. |
Beta Was this translation helpful? Give feedback.
-
Hallo,
|
Beta Was this translation helpful? Give feedback.
-
Ich hab den Wican funktionierend seit etwa einem Jahr in Betrieb. Die Automatisation dazu macht der Home-Assistant, und der reicht auch den SOC an evcc durch. |
Beta Was this translation helpful? Give feedback.
-
Einige Fahrzeughersteller sind gerade dabei, den Zugang zu ihren Telematik-Diensten zu verriegeln (Hyundai, Kia) oder haben eine hohe Änderungsfrequenz ihrer APIs (z.B. Tesla). Das Reverse-Engineering der APIs ist deshalb recht mühsam, einmal funktionierende Implementierungen versagen plötzlich ihren Dienst.
Man kann den aktuellen SoC des Fahrzeugs (und viele weitere Daten) aber auch über die Fahrzeug-Diagnose-Schnittstelle (OBD) auslesen. Auch hier ist ein Reverse-Engineering notwendig, da die Parameter IDs (PIDs) für die Elektrofahrzeug-relevanten Daten im Gegensatz zu den Verbrenner-Daten nicht standardisiert sind. Allerdings ist die OBD Kommunikation selbst standardisiert.
Ich habe ein wenig herumgeforscht und folgende Wege gefunden:
1. EVNotify
Auslesen der OBD Daten über einen Bluetooth OBD Dongle an der OBD Buchse des Fahrzeuge mit Hilfe der Handy-App EVNotify. Die Daten landen in einem Backend (ggf. auch selbst gehostet); von dort kann evcc sich dann den SoC holen. Dazu müsste man ein Handy z.B. in der Nähe des Fahrzeugs platzieren.
1a. EVNotiPi
funktioniert wie EVNotify, im Unterschied dazu läuft das z.B auf einem Raspi(Zero) und nutzt dessen BT und WLAN-Hardware. Der Raspi muss sich einerseits in der Nähe des Fahrzeugs befinden und dort Zugang zum häuslichen WLAN haben. EVNotiPi ist in Python geschrieben, die Sourcen findet man hier.
Vorteil: diese Lösung wird von einigen evcc Nutzern bereits eingesetzt; vielleicht kann einer der Nutzer das etwas genauer beschreiben und eine Beispielconfig beisteuern.
Problematik: beide Lösungen unterstützen nur eine Auswahl an Fahrzeugen. Mein Kia eSoul ist leider nicht dabei. Die PIDs für dieses Fahrzeug sind allerdings bekannt; damit sollte es möglich sein, eine Version für dieses Fahrzeug zu entwickeln.
2. Torque Pro
funktioniert wie EVNotify. Auch hier gibt es die Möglichkeit, die Daten in ein eigenes Backend hochzuladen.
Vorteil: Torque Pro funktioniert für meinen Kia e Soul einwandfrei.
Problematik: Mobiltelefon in der Nähe des Fahrzeugs notwendig
3. IOTconnect
HW technisch funktioniert diese Lösung wie die beiden oberen: die Verbindung zum Fahrzeug wird über einen BT OBD Dongle hergestellt. Ein Raspi(Zero) verbindet sich mit diesem über Bluetooth. IOConnect liest die OBD Daten und published diese über WLAN direkt auf einem MQTT Broker, von wo sich evcc diese Daten direkt holen kann.
Vorteil: Die Daten landen ohne Umwege direkt auf dem MQTT Broker.
Problematik: IOTconnect ist aktuell nur für den Hyundai Ioniq implementiert und müsste deshalb für andere Fahrzeuge entsprechend erweitert werden.
4. ELMduino auf ESP32
Auch in dieser Lösung werden die OBD Daten über einen Bluetooth Donge ausgelesen. Ein ESP32 wird über BT mit dem Dongle verbunden und liest dann unter Verwendung der ELMduino Library die PID Daten aus. Diese werden dann über das ESP32 WLAN an einen MQTT Broker weitergereicht.
Vorteil: wie Lösung 3
Problematik: Dies ist die "Hardcore" Version, da es keine fertige Lösung gibt. Man muss also die notwendigen Libraries und deren Funktion selbst erforschen und die entsprechende Ablaufsteuerung und Absicherung selbst entwickeln.
5. ELMduino auf Freematics One+
Freematics one+ ist ein frei programmierbarer OBD Dongle auf Basis des ESP32. Die OBD Schnittstelle wird hier über einen Coprozessor angesprochen; die Daten werden direkt an den ESP32 weitergereicht. Softwaretechnisch entspricht dies weitgehend der Lösung 4; man hat aber nur ein einziges Device welches sich vom Fahrzeug aus direkt ins heimische WLAN einklinken kann.
Vorteil: wie Lösung 3. Zudem kann man direkt eine Überwachung der 12V Batterie einbauen denn 12V liegen direkt auf dem OBD Stecker und sind mit dem ESP32 A/D Wandler verbunden. Abhängig vom 12V Bornetzzustand kann man dann ggf. den Dongle komplett abschalten
Problematik: wie Lösung 4
Gibt es weitere Ideen oder Implementierungen?
Beta Was this translation helpful? Give feedback.
All reactions