EVNotiPi

[hominidae]

...ich meine das Ur-Original hat ein Kabel zum OBD-Port, braucht also keinen OBD-Adapter.
Die andere Variante ist es, einen OBD-Adapter mit Blauzahn zu verwenden.
Die SoC-Auslese-Software würde dann das Kabel durch ein "Bauzahn-Kabel", also serielle Kommunikation über Blauzahn ersetzen.
Die CAN-Bus Logik ist aber dann schon im OBD-Adapter

@ragnaroek hat das oben ja schon so gebaut....ich würde es nur einfach downsizen wollen, wenn man es ausserhalb der openWB hält.
Ein ESP32 könnte sogar CAN-Ports ansteuern, müsste es aber dann nicht. Die "alte" Version mit BT4.0 hat einen Dual-Core mit einem Realtime-OS...eine MQTT-Brücke schafft selbst der schmale ESP8266.

[aiole]

OK - ich dachte EVNotiPi wäre immer die Plug&Play-Variante mit kabelgebundenem OBD-connector und RPi.
EVnotify ist dagegen die SW:
https://evnotify.de/

Die ganzen OBD-BT-Teile sind mir nicht geheuer. Manche funktionieren, manche nicht und das sogar bei nur EINEM Typ. DAS willst Du mit dem ESP32 koppeln und die BT-Strecke nutzen?

Ich bin da eher skeptisch, dass man das stabil zum Laufen bekommt (hauptsächlich wegen der OBD-BT-Teile). Dann noch Funk (BT) und ESP32. Für DIY ok, aber sicher nicht im professionellen Umfeld. Dennoch interessant - probiert's aus.

VG aiole

[ragnaroek]

Hier zum Testen das evSoc als tar.ball

Code: Alles auswählen

# evSoc
Python evSoc, derived from EVNotipi and EVNotify, supporting IONIQ, KONA, NIRO and ZOE

evSoc can be installed directly on the RPi of the openWB wallbox.
evSoc can be installed on separate Server HW (Pi Zero) as a gateway between EV and openWB, but needs some configuration editing

evSoc will provide the StateOfCharge SoC of the Electric Vehicle EV via bluetooth OBD Dongle.
All EVNotipi-Files for supported CARS and DONGLES should remain unchanged (cloned from EVNotipi))

## Needed Hardware within EV
- ELM327 based OBD-Dongle for bluetooth (tested with TonWon BTS3.0 + EV Kona)

## Installation, (update @ March 19, 2021)
### Raspberry Pi
- sudo apt update
- sudo apt upgrade
- sudo apt install python3-{pip,rpi.gpio,serial,requests,sdnotify,pyroute2,smbus,yaml,gevent} gpsd git watchdog rsyslog-

### evSoc
#### UNPACK evSoc.tar files into /opt/evSoc with root-permissions
- cd /opt/evSoc
# nicht erforderlich: - sudo pip3 install -r requirements.txt
- sudo systemctl link /opt/evSoc/evSoc.service
- sudo systemctl enable evSoc.service

### Setup the Bluetooth Connection to OBD-Dongle
- sudo bluetoothctl
	power on
	agent on
	default-agent
	scan on
#### find your ID xx:xx:xx:xx:xx:xx
	pair xx:xx:xx:xx:xx:xx
	trust xx:xx:xx:xx:xx:xx
	scan off						#recommended
	quit
- sudo rfcomm bind rfcomm0 xx:xx:xx:xx:xx:xx
#### ADD Autostart IN /etc/rc.local 
	sudo rfcomm bind rfcomm0 xx:xx:xx:xx:xx:xx

### openWB
#### Configure SoC-receiption via MQTT

### OPTION
#### Setup WiFi connection of PI Zero to the openWB

#### Customizing
#### Edit /opt/evSoc/config.yaml according to your needs, e.g. type of car, IP address of your MQTT-Server, etc.

### Manual Start
- sudo systemctl start evSoc.service

Diese Installationsprozedur entstand aus Erinnerung. Bei Schwierigkeiten aktualisiere ich das hier gern. In meiner Installation läuft's direkt auf dem RPI4 einer openWB (zusätzlicher Dienst evSoc).

Mit einem PI Zero konnte ich es leider mangels HW nicht testen. ESP32 ist bei mir kein Thema.

Ich hatte bisher keine Stabilitätsprobleme mit dem BT Dongle, da er bei jedem Fehlerverdacht neu initialisiert wird. Steht openWB auf STOP, erfolgt keine SoC-Abfrage, so dass der Dongle sich selbst schlafen legen kann (power saving).

EDIT 16.März:2020
Hinweis1 zum gleichzeitigen Verwendung von BT und WIFI:
Kein RPi unterstützt die gleichzeitige Verwendung blockierungsfrei. Da mein wallbox nur über WIFI angebunden ist, gab es häufige Aussetzer, die die Abfrage von Statusinformationen aus der PV-Anlage behinderten. Das gab dann unschöne Grafiken, hatte aber abgesehen von Aussetzern im Browsing oder bei miesen Reaktionszeiten auf der Konsole keine funktionalen Katastrophen.
Ich habe nun daher einen externen bluetooth-Dongle vom Typ "Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" (Bluetooth CSR 4.0 Dongle) eingerichtet, der problemlos funktioniert. Wichtig dabei: das interne bluetooth deaktivieren in /boot/config.txt durch den zusätzlichen Eintrag "dtoverlay=disable-bt" (rasbian buster)

Hinweis2 zu Bluetooth-Dongeln:
Ich nutze erfolgreich den etwas teureren Dongle "TONWON BTS3.0", den ich wegen seiner kompakten Abmessungen und der nicht störenden fehlenden LED ausgewählt hab. Am Kona gibt es damit gelegentlich beim Zugriff auf das CAN-Steuergerät "7E4" Probleme. Daher re-initialisiert evSoc den Dongle. Das aktuelle EvNotify-Apk scheint mit dem Dongle das gleiche Problem zu haben, löst es aber nicht durch Re-Ininialisierung, und deshalb bricht die Kommunikation nach ca. 10 Abfragen zusammen, ist also in dieser Kombi "Kona => TONWON => EvNotify" absolut unbrauchbar.
Nun habe ich ein weiteres Bluetooth-Dongle direkt aus China bekommen (siehe Foto). Größere Bauform, fette LED, blau-durchsichtiges Gehäuse. Wie TONWON identifiziert es sich mit ELM327 v1.5, und ein Kompatibilitätscheck mit der "App EM327 Identifier" zeigt sogar an, dass alle Feature bis 2.1 zu 100% unterstützt werden. Ich war also sehr optimistisch. Fünf Stunden später bin ich mir sicherer, dass das Dongle den Zugriff auf den Kona-Steuergerät unter PID 7E4 überhaupt keinesfalls unterstützt. Die EvNotify App macht mit ihm gar nichts Sinnvolles. Meine Message: Nicht gleich gefrustet aufgeben, sondern das richtige Dongle kaufen.
Ich bin gespannt, ob es am Kona-Steuergerät oder am BT-Dongle liegt. Hinweise willkommen (siehe Postings weiter unten).

Nachtrag 1.4.2021 (kein Aprilscherz):
Es wird in dieser Version der SoC nur dann an openWB gesendet, wenn der Ladestecker eingestecktist und geladen wird. Da auch bei eingeschalteter "Zündung" des Autos der OBD2-Dongle spannungsversorgt wird, könnte ein aktueller SoC also auch übertragen werden, wenn man nicht laden will, aber sein Auto nahe der openWB abstellt. Ich habe dazu in der Datei /opt/evSoc/evSoc.py in Zeile 132 die Abfrage einfach geerdet. Es scheint keine unerwünschten Auswirkungen zu haben:

Code: Alles auswählen

try:
    while(True):
#        if(charging==True):			#Alte Zeile auskommentieren und durch die nachfolgende Zeile ersetzen#
        if(True):					#Neue Zeile, Einrückung genau beachten!!!
            soc=car.pollData()

[aiole]

Habe ich das richtig gelesen - der Datenabruf läuft so?

a) OBD -> BT-Dongle -> BT -> RPi (mit evSoc + openWB) oder
b) OBD -> BT-Dongle -> BT -> RPi Zero (Server mit evSoc) -> WLAN -> RPi (mit openWB)

VG aiole

[openWB]

Das geht im Zweifel auch mit nem ESP.
Da gibts was "halb" fertiges:
https://freematics.com/store/index.php? ... duct_id=85

Bedarf nur dem Auslesecode und dem zur Verfügung stellen für openWB.

[hominidae]

...mit dem freematics Ding hatte mal jemand im goingelectric Forum experimentiert....und wg. Stabilitätsproblemen wieder gelassen.
Ich denke ein ESP32 (der schon WLAN und BT-Classic kann), oder ein ESP8266 + HT06 BT-Modul für BT-Seriell/SPP sollten da stabiler sein.

Leider müsste man die BT-Seite und Dekodierung der Daten neu bauen, da MicroPython wohl keine BT Implementierung hat.

...ich gehe jetzt mal einen Zero-W shoppen

[hominidae]

Habe ich das richtig gelesen - der Datenabruf läuft so?

a) OBD -> BT-Dongle -> BT -> RPi (mit evSoc + openWB) oder
b) OBD -> BT-Dongle -> BT -> RPi Zero (Server mit evSoc) -> WLAN -> RPi (mit openWB)

VG aiole

genau genommen sollt es aus Sicht des evSoc, logisch gesehen immer das Selbe sein.

Der RPi mit evSoC nutzt BT zum OBD-Dongle, liest die Daten dort aus und schreibt ein MQTT-Topic (über IP, mittels eines MQTT-Client) in den Broker der openWB.

Das kann der RPi der openWB selbst sein oder ein RPi-Zero, der die IP-Strecke über WLAN überbrückt.
Sprich, beim EInsatz des RPi der openWB ist nur der "Draht" zum Broker extrem kurz ...evSoC ist es eigentlich egal.

[hominidae]

Hier zum Testen das evSoc als tar.ball
[...]
Ich hatte bisher keine Stabilitätsprobleme mit dem BT Dongle, da er bei jedem Fehlerverdacht neu initialisiert wird. Steht openWB auf STOP, erfolgt keine SoC-Abfrage, so dass der Dongle sich selbst schlafen legen kann (power saving).

Supi, danke!
...so, Teile sind bestellt...wie installiert man einen Pi?

@ragnaroek:

Du steuerst die Abfrage mit dem globalen Mode (sofortladen, ...,stop) -> openWB/global/ChargeMode.
Das ist mMn ungünstig, denn selbst wenn der Modus nicht auf stop steht, muss das BEV ja nicht in der Garage sein und selbst wenn, ja nicht laden.

Es ist:
- entweder gar nicht da, in der Garage
- in der Garage, aber nicht eingesteckt (openWB/lp/+/boolPlugStat = 0)
- eingesteckt, aber lädt nicht (openWB/lp/+/boolChargeStat =0)

...Ich würde versuchen das Dongle aufzuwecken wenn:
- der Nutzer den Modus auf etwas anderes als stop ändert (mach evSoC ja schon)
- das BEV eingesteckt wird (PlugStat = 1)...hier sozusagen "eifrig" probieren, den ersten (Start-)SoC zu holen
- das BEV lädt (ChargeStat = 1)..in dem Fall evtl auch gar nicht schlafen oder öfter aufwecken (zB 15min), bis openWB/+/%SoC = 100

...my 2 cents.

[ragnaroek]

Das ist mMn ungünstig, denn selbst wenn der Modus nicht auf stop steht, muss das BEV ja nicht in der Garage sein und selbst wenn, ja nicht laden.

Es ist:
- entweder gar nicht da, in der Garage
- in der Garage, aber nicht eingesteckt (openWB/lp/+/boolPlugStat = 0)
- eingesteckt, aber lädt nicht (openWB/lp/+/boolChargeStat =0)

Gute Idee. boolPlugStat-Abfrage habe ich jetzt in V2.1 integriert. Vom boolChargeStat selbst kann es m.E. nicht abhängen, da es Fälle gibt, da das Aktivieren/Deaktivieren des Ladens vom SoC abhängt. Die neue Version mit einigen Edits im ursprünglichen Post.

[ragnaroek]

Antwort auf eine PN zur Frage, ob evSoc auch zwei unterschiedliche EV Typen unterstützen kann:

Neben dem Kona, mit dem ich arbeite, unterstützt evnotipi (und damit auch evSoc) auch andere EV Typen, wie z.B. Ioniq.

Der evSoc-Dienst kann entweder nur den einen EV Typ oder den anderen EV Typ bedienen. Ich glaube nicht, dass man evSoc so umbauen kann, dass man den EV Typ dort erkennen kann... Ich denke, wenn jedes EV einen eigenen BT-Dongle hat, können zwei evSoc-Dienste parallel ihr passendes Modell immer korrekt finden. Es sollte aber nur ein (1) EV im Empfangsbereich der WB sein, sonst könnte es von beiden EVs Daten geben... Das kann man wohl nur vermeiden, wenn man im EV selbst prüft, ob es geladen wird. Aktuell kommt diese Info nur aus der wallbox, die natürlich nicht ihr EV kennt. Wäre sicher eine interessante Erweiterung, zugleich aber ein Fork der /cars/* Dateien aus evnotipi.