EVNotiPi

[lacky]

nachdem openWB das EVNotiPi PnP nicht mehr anbietet...
was wäre, wenn die openWB Wallbox über BT den OBD-Dongle im Fahrzeug auslesen würde wenn dieses an der WB hängt und lädt?
mir würde der SOC an der heimischen Wallbox reichen!

[hominidae]

...coole Idee!...solange das Blauzahn Kabel soweit reicht (fahre zuhause rückwärts an die openWB...das sind also 7-10m zwischen Dongle im Innenraum und der openWB.

[openWB]

Leider nicht, das ist das Problem.
Das EVNotiPi könnt ihr euch aber nachbauen - auch als WLAN Variante und lokal abfragen.

[ragnaroek]

nachdem openWB das EVNotiPi PnP nicht mehr anbietet...
was wäre, wenn die openWB Wallbox über BT den OBD-Dongle im Fahrzeug auslesen würde wenn dieses an der WB hängt und lädt?
mir würde der SOC an der heimischen Wallbox reichen!

Ich bin deiner Anregung gefolgt und habe nun erste Erfahrungen mit einer openWB Wallbox, die wie vorgeschlagen direkt über BT einen ELM327 basierten OBD-Dongle im Fahrzeug auslesen kann, gesammelt. Ich nutze in meiner openWB einen raspberry PI4 unter rasbian buster mit einer modbus-Verbindung zum SDM630-Zähler und zur EVSEDIN. Wichtig war mir, dass ich für die Kommunikation zum EV keinen weiteren raspberry benötige. Deshalb hatte ich zunächst auf dem wallbox-PI4 eine aktuelles evnotipi installiert. Das hat soweit auch zufriedenstellend geklappt, ist aber für eine so triviale Anwendung doch etwas overTheTop, für einige Meter Abstand einmal über einen cloud-Server zu gehen... Deshalb habe ich das evnotipi so sehr abgespeckt, dass es jetzt ohne cloud funktioniert.

Ich nutze das eingebaute Bluetooth des PI 4B 4GB und einen TonWon BT3.0 Dongle im Kona(2019). Die Reichweite liegt in meiner Installation bei mehr als 6 Metern für eine ausreichend stabile Verbindung. Die Wallbox selbst ist nur über WLAN angebunden, da ich keinen LAN-Anschluss in die Garage legen konnte. Da ein raspberry bekanntermaßen nicht gleichzeitig WLAN und Bluetooth-Scan durchführen kann, gibt es immer wieder kurze Blockierungen im WLAN. Deshalb werde ich demnächst auf einen separaten USB-BT-Adapter am PI4 wechseln. Mit LAN gibt es solche Probleme natürlich nicht.

Mein OBD-Dongle ist reproduzierbar immer wieder nach einigen Duzend Lesezugriffen "abgestürzt" und meldete sich dann nur mit "Elm.1.5..". Das passierte zuvor allerdings auch mit evnotipi. Deshalb initialisiere ich den Dongle bei jedem SOC-Lesezugriff komplett neu. Ob andere OBD-Dongle diese Probleme auch machen, habe ich nicht weiter verfolgt. Vielleicht ist das ja wieder so ein china-chip...

Vom evnotipi code habe ich die Module AtBaseDongle, ELM327, dongle und die EV-Modelle im Verzeichnis cars absolut unverändert übernommen und das alles mit einem kleinen python3 script mit openwb/modules/evnotify/main.sh zusammengeklebt, so dass sich die Web-Oberfläche von openWB für die Konfiguration erst mal nicht ändert. Hieran wäre also ggf. noch zu arbeiten. Mir war wichtig, die oben genannten Module aus notifipi unverändert zu übernehmen, damit die erprobte Funktionalität für unterstützten EV-Modelle nicht beeinträchtigt wird und hier zukünftig vielleicht noch weitere EVs übernommen werden könnten.

openwb fragt jeweils jede Minute den SOC über BT direkt ab. Das dauert auf dem PI4 knapp unter ca 9 Sekunden. Der Cloud-Server von evnotipi wird natürlich nicht mehr genutzt. Eine SOC-Abfrage ist also nur noch über die openWB Oberfläche möglich. Wer unterwegs den SOC abfragen will, nehme also z.B. evnotify APP mit Mobile im Auto.

Das BT pairing und BT bind erfolgt wie üblich:

Code: Alles auswählen

$ sudo bluetoothctl
	power on
	agent on
	default-agent
	scan on
	pair xx:xx:xx:xx:xx:xx
	trust xx:xx:xx:xx:xx:xx
	quit

Und im autostart in /etc/rc.local dann

Code: Alles auswählen

	sudo rfcomm bind rfcomm0 xx:xx:xx:xx:xx:xx

Folgende Dateien unter /opt/evnotipi sind anzupassen:
evSoc.py (Main), car.py
Folgende Datei unter openWB/modules/soc_evnotify
main.sh

EDIT 16.3.2020
In /opt/evSoc/evSoc.service muss die Restart-Option geändert werden in

Code: Alles auswählen

#Restart=on-failure
Restart=always

Danach

Code: Alles auswählen

$ sudo systemctl daemon-reload 
$ sudo systemctl restart evSoc.service  

EDIT 19.8.2021
Jetzt auch hier mit der neuen Version 2.3 mit Release-Infos in evSoc.py, mit aktualisierter Installation und Homeserver-Schnittstelle

Good Luck

[hominidae]

...oh, das hört sich ganz prima an, danke @ragnaroek!

Leider habe ich eine Fertig-openWB (mit nem RPi 3B+ drin) und will da eigentlich nicht dran rumfummeln...
Daher zwei(drei, vier) Fragen:

- Was brauche ich denn für eine solche externe "Garagenversion"?
Also einen rPi mit BT, ein OBD-Dongle ... und dann?

- Wie würde das mit zwei EVs in der Garage gehen (jedes mit OBD-Dongle, latürnich vorausgesetzt)?

- ...und wir kann ich einen Outlander PHEV in den EVNotiPi "einbauen"?

- in dieser Version wird der OBD ja von der Mini-"Starter-Batterie" versorgt.
Kann man sicherstellen, dass sich, nachdem der erste SoC nach dem Abstellen gelesen wurde und bis zur Beginn der Ladung (kann schonmal 2 Tage sein), das OBD schlafen legt? Liegt das am OBD, an EVNotiPi oder an Beidem?

[ragnaroek]

Leider habe ich eine Fertig-openWB (mit nem RPi 3B+ drin) und will da eigentlich nicht dran rumfummeln...

- Was brauche ich denn für eine solche externe "Garagenversion"?
Also einen rPi mit BT, ein OBD-Dongle ... und dann?

Wie soll der SoC vom rPi der externen Garagenversion dann in deine Fertig-openWB reinkommen, wenn Du nicht dran rumfummeln willst? Du könntest also nur eine der vorhandenen konfigurierbaren SoC-Schnittstellen der Fertig-openWB einstellen und ein passenen Schnittstellen-Gegenstück auf dem rPi der Garagenversion bauen. Wäre dann evnotipi als Kauf- oder Fummellösung nicht doch der einfachere Weg zum Ziel?

- Wie würde das mit zwei EVs in der Garage gehen (jedes mit OBD-Dongle, latürnich vorausgesetzt)?

Für (1) openWB und mehrere OBD-dongle ausgerüstete EVs müsste noch was implementiert werden, denn der aktuelle evCar-patch unterstützt bisher nur (1) OBD-dongle. Es müsste dann eine Liste von OBD-dongles über individualisierte rfcomms abgefragt werden.

- ...und wir kann ich einen Outlander PHEV in den EVNotiPi "einbauen"?

- in dieser Version wird der OBD ja von der Mini-"Starter-Batterie" versorgt.
Kann man sicherstellen, dass sich, nachdem der erste SoC nach dem Abstellen gelesen wurde und bis zur Beginn der Ladung (kann schonmal 2 Tage sein), das OBD schlafen legt? Liegt das am OBD, an EVNotiPi oder an Beidem?

evCar-patch müsste dann nach der SoC-Abfrage mit einem zusätzlichen abschließenden AT-Kommando "LP" den Dongle auf Low-Power setzen. Stromaufnahme des Dongle mit und ohne "LP" ist mir unbekannt.

[hominidae]

...danke für die schnelle Reaktion!

Wie soll der SoC vom rPi der externen Garagenversion dann in deine Fertig-openWB reinkommen, wenn Du nicht dran rumfummeln willst? Du könntest also nur eine der vorhandenen konfigurierbaren SoC-Schnittstellen der Fertig-openWB einstellen und ein passenen Schnittstellen-Gegenstück auf dem rPi der Garagenversion bauen. Wäre dann evnotipi als Kauf- oder Fummellösung nicht doch der einfachere Weg zum Ziel?

...über eine SoC-Schnittstelle in der openWB....zu Not "baue" ich eine über MQTT und hoffe, dass Kevin einem Pull-Request zustimmt, bzw. versuche ein Feature dafür zu sponsern.

Edit: das setzen über MQTT ist ja schon im Code der openWB drin, sehe ich gerade...
Würde das nicht evnotipy deutlich abspecken?

In die gekaufte Fertigversion, meine, eine, produktive openWB, direkt einzugreifen ist für mich ein no-go (ist schon ein Unterschied mal eine nightly auszuprobieren, als das)
Eine Kauf-Version des evnotipi ist Ressourcen-Verschwendung (Display, Akku)....oder gibt es eine "light", mit "Deiner Version" und zB einem rPi-Zero-W?...die würde ich dann kaufen
Edit: da sieht man, warum ich nicht basteln/fummeln will...ein pi-Zero-W scheint ja schon standard zu sein...sorry, irgendwie stand ich auf dem Schlauch...
Kann der kleine Zero-W nicht gleichzeitig BT und WLAN nutzen?
Ich wäre ja dafür, den mit Deiner abgespeckten all-in-one-mini Version zu nutzen um den OBD auszulesen und via MQTT in die OpenWB zu senden.

Für (1) openWB und mehrere OBD-dongle ausgerüstete EVs müsste noch was implementiert werden, denn der aktuelle evCar-patch unterstützt bisher nur (1) OBD-dongle. Es müsste dann eine Liste von OBD-dongles über individualisierte rfcomms abgefragt werden.

...oder zwei "light" Versionen in die Garage ?

evCar-patch müsste dann nach der SoC-Abfrage mit einem zusätzlichen abschließenden AT-Kommando "LP" den Dongle auf Low-Power setzen. Stromaufnahme des Dongle mit und ohne "LP" ist mir unbekannt.

OK, ich habe einen Dongle im Outlander, der sich schlafen legt, wenn die BT-Verbindung zur App beendet wird.Das reicht für Wochen mit der Mini-Starterbatterie...
Wenn die Ladung läuft, lässt sich der OBD wieder neu verbinden...muss also Strom da sein.
Vielleicht geht ja das: Der evnotipi-light müsste also, ohne das ein LP angestckt ist auf BT suchen.....dann BT beenden, wenn der SoC da ist...dann wieder re-Connecten, wenn der LP angesteckt wird bzw. wenn die Ladung startet.
...klingt kompliziert

[ragnaroek]

Edit: das setzen über MQTT ist ja schon im Code der openWB drin, sehe ich gerade...
Würde das nicht evnotipy deutlich abspecken?

Klasse Idee. Dann kann in openWB die SoC-Abfrage mit MQTT konfiguriert werden, ohne dass eine Änderung notwendig zu sein scheint.

evSoc.py (=evnitipi-light) habe ich so angepasst, dass der SoC zu openWB/set/lp1/%Soc eines konfigurierbaren MQTT-Servers geschickt wird. Du könntest es dann auf einem Zero-W in der Garage laufen lassen und brauchst nicht an der wallbox zu fummeln; und ich installiere evSoc ohne Zero-W direkt auf der wallbox und konfiguriere den MQTT-Server als "localhost".
Das läuft soweit und ist jetzt deutlich eleganter. Danke für den Tip!

Für das Powerdown könnte evSoc.py den Wert openWB/global/ChargeMode über MQTT abfragen, damit ohne Charging keine SoC-Abfrage über Bluetooth erfolgt. Vielleicht reicht Dir das schon. Hätte den Vorteil, dass durch unveränderte Module weiterhin alle Dongles und Fahrzeugtypen von evnotipi unterstützt blieben. (Wenn ich dagegen das ELM327-Dongle mit "LP" schlafen legte, müsste ich diese Module ändern und sie müssten zukünftig zusätzlich gepflegt werden...)

Kann der kleine Zero-W nicht gleichzeitig BT und WLAN nutzen?

Ich denke schon, dass das in diesem Fall geht. Da Zero-W und RPi den gleichen Prozessortyp haben, dürfte er zwar ebenfalls nicht gleichzeitig WLAN und bluetooth-Scans machen können, aber für den vorliegenden Anwendungsfall dürfte das nicht wirklich stören. Wenn dagegen in der Wallbox wegen bluetooth der web-browser klemmt oder die Abfragen zum PV-Wechselrichter plötzlich hakeln, dann ist das schon ziemlich ärgerlich.

[hominidae]

...prima!
Kann das "light" Modell nicht noch kleiner werden, als ein Pi-Zero-W?....sowas: https://docs.openmqttgateway.com/ ??
Ein ESP32 kann BLE und BT-Classic (SPP), aber ich glaube (Mikro-)Python hat da noch keine Lib für?
Mit Arduino-Werkzeugen geht es (BT-Serial und SPP)....

Ich würde dann auf jeden Fall mal einen Pi3+ und einen Zero ordern ...just in case...ESP32 habe ich genug

[aiole]

Muss nicht der CAN-Bus mittels OBD-HAT ausgelesen werden?
Beim originalen EVNotiPi gab es dafür ein spezielles RPi-HAT von Diamax, welches auch den Zero aufgesetzt wurde. Da war auch ein eigener µC mit auf dem HAT.

Wenn dieses Prinzip noch so von GcAk beibehalten wurde (ich denke, er hat das weiterentwickelt), müsste die RPi+HAT-Kombination durch den ESP32 ersetzt werden. Na ober er das alleine schafft?

VG aiole