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.
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
Code: Alles auswählen
sudo rfcomm bind rfcomm0 xx:xx:xx:xx:xx:xx
Code: Alles auswählen
#Restart=on-failure
Restart=always
Code: Alles auswählen
$ sudo systemctl daemon-reload
$ sudo systemctl restart evSoc.service 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?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?
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.- Wie würde das mit zwei EVs in der Garage gehen (jedes mit OBD-Dongle, latürnich vorausgesetzt)?
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.- ...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?
...ü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.ragnaroek hat geschrieben: ↑Mo Mär 09, 2020 11:56 am 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?
...oder zwei "light" Versionen in die Garage ?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.
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...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.
Klasse Idee. Dann kann in openWB die SoC-Abfrage mit MQTT konfiguriert werden, ohne dass eine Änderung notwendig zu sein scheint.
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.Kann der kleine Zero-W nicht gleichzeitig BT und WLAN nutzen?
...just in case...ESP32 habe ich genug