Der soc_helper hat den Zweck, den Ladezustand und Kilometerstand eines Elektrofahrzeugs auszulesen und die OpenWB zu übertragen.
Die OpenWB bietet die Möglichkeit, nur bis zu einem bestimmten Ladezustand zu laden. Auch kann in Abhängigkeit vom Ladezustand des Fahrzeugs auf verschiedene Weise geladen werden. So kann beispielsweise ein maximaler Ladezustand (SOC) von 80% definiert werden, um die Fahrzeugbatterie zu schonen. Oderes kanndirekt nach Anstecken bis zu einem Mindestfüllstand geladen werden, darüber hinaus per PV-Überschuß und dann zu bis zu einer definierten Uhrzeit bis zu einer Grenze. Alles das setzt voraus, daß der Ladezustand der Wallbox bekannt ist.
Um den Ladezustand in die Wallbox zu bekommen, bietet diese ab Werk schon verschiedene Möglichkeiten. So kann für eine Anzahl von Fahrzeugen beim Laden periodisch die Hersteller-Cloud abgefragt werden. Eine andere Möglichkeit ist, einen MQTT-Client periodisch einen SOC-Wert in die Wallbox schreiben zu lassen. Der einfachste Weg ist, vor dem Stecken des Ladesteckers manuell (am Handy oder Wallbox-Display) den Ladezustand einzugeben - anhand derhinterlegten Batteriekapazität und des Ladewirkungsgrades sowie der durchgesetzen elektrischen Arbeit kann die OpenWB den aktuellen Ladezustand des Fahrzeugs berechnen.
Der soc_helper kommt da ins Spiel, wo kein passendes Fahrzeug-Modul vorhanden ist oder man die Hersteller-Cloud nicht nutzen oder bezahlen möchte: Der WiCAN ist ein Dongle für die Diagnosebuche von Kraftfahrzeugen. Er bietet die Möglichkeit, sich in ein WLAN einzubuchen und mit einem erreichbaren MQTT-Broker zu kommunizieren. Wenn der WiCAN eingebucht und mit einem MQTT-Broker verbunden ist, kann per MQTT eine Anforderung über den WiCAN und die Diagnosebuchse an das Fahrzeug gestellt werden. Das Fahrzeug beantwortet eine gültige Anfrage, was vom WiCAN wiederum per MQTT bekannt gegeben wird.
Der soc_helper läuft auf einem beliebigen python-fähigen Rechner im Heimnetz und stellt die Verbindung zwischen WiCAN und OpenWB her. Sobald der WiCAN sich in den MQTT-Broker der OpenWB eingebucht hat, schickt der soc_helper Abfragen von Kilometerstand und Ladezustand ab. Die Antworten des Fahrzeugs werden ausgewertet. Der Ladezustand wird in die OpenWB übertragen und dient der oben erwähnten Ladesteuerung.Durch die zusätzliche Abfrage des Kilometerstandes kann auf Wunsch mit Spritmonitor über den Verbrauch Protokoll geführt werden.
Die hier vorliegenden Dokumente sollen eine Schritt-für-Schritt-Anleitung zum erfolgreichen Betrieb des soc_helper geben. Für die Anleitung wird angenommen, daß ein aktuelles Raspberry-Pi-System mit raspian verwendet wird. Auf anderen Rechnern funktioniert die Prozedur ähnlich, möglicherweise unterscheiden sich aber einzelne Schritte. Die Konfiguration umfasst Folgendes:
Der WiCAN hat ein nützliches Feature: Er kann so konfiguriert werden, daß er aus dem Heimnetz erreichbar ist. So könnte theoretisch vom heimischen Rechner aus der OBD-Port des Fahrzeugs abgefragt werden. (Die App "Car Scanner" kann das auch)
Ein neuer WiCAN bucht sich natürlich noch nicht in das heimische WLAN ein. Er spannt ein offenes WLAN mit dem Namen "WiCAN_xxxxxxxxxxxx" auf (die x stehen für die 12 Ziffern der Seriennummer). Nach Einstecken des WiCAN sollte das Netzwerk in der WLAN-Suche des Smartphones oder Laptops auftauchen. Das Smartphone / der Laptop soll sich mit diesem WLAN verbinden. Beim Verbinden ist das Standard-Passwort "@meatpi#" eingeben.Mit dem Browser kann der Dongle jetzt unter http://192.168.80.1 erreicht werden, sofern der Rechner ins WiCAN-WLAN eingebucht ist. Wichtig ist, dass kein "s" im "http" ist - Firefox setzt das automatisch!
Unter dem Reiter "Settings" muß zunächst das WLAN konfiguriert werden. Wichtige Einstellungen:
Unten den Knopf "Submit Changes" betätigen. Nach dem darauf folgenden Neustart sollte der WiCAN als Gerät im Heimnetzwerk auftauchen.Die IP-Adresse läßt sich im heimischen Router finden, bei der Fritz!Box unter Heimnetz->Heimnetzübersicht, Reiter Netzwerkverbindungen. Die folgenden Einstellungen erfolgen nach Aufruf der dort gelisteten IP-Adresse. Auch hier ist wieder wichtig, daß kein "s" hinter "http" vorhanden ist. Firefox setzt dieses automatisch, es muß dann per Hand entfernt werden.
Anmerkung: Meiner Erfahrung nach werden alle Einstellungen des WiCAN auf Werkseinstellung zurückgesetzt, wenn man sich über das WiCAN-eigene WLAN mit dem WiCAN verbindet. Nachdem der WiCAN im Heimnetz ist, sollte also nicht mehr in das vom WiCAN aufgespannte WLAN eingebucht werden!
Falls der WiCAN noch nicht mit Firmware 2.98 oder neuer läuft, ist ein Updateder Firmware erforderlich: Ab Version 2.98 ist es möglich, den Zweig der WiCAN-Topics im WiCAN vorzugeben. Dies ist nötig, damit das System mit der OpenWB-Software 2.1.4 oder neuer zusammen funktioniert.
Die aktuelle Firmware wird hier herunterladen: https://github.com/meatpiHQ/wican-fw/releases/
Der Name folgt dem Schema "wican-fw-vXXX_hv300.bin". Bitte das Archiv ohne den Namensbestandteil "usb" wählen!
Das Archiv auf dem Heimrechner auspacken und den Speicherort merken.
Nach Aufruf der WiCAN-Seite im Browser (siehe "WiCAN ins eigene WLAN holen") befindet sich die Updatemöglichkeit ist auf dem Reiter "About":
Die gesamte Konfiguration ist der Abbildung zu entnehmen:
Dazu folgende Anmerkungen:
Unter dem Reiter "Status" des WiCAN ist die gemessene Bordnetzspannung zu sehen. Bei eingeschalteter Hochvolt-Batterie (Fahrbereitschaft) sollten über 13.8V und unter 15V zu sehen sein. Bei abgeschalteter Hochvolt-Batterie sollte die Spannung unter 13,5V fallen. Stehen hier doppelt so hohe Werte, wurde die falsche Firmware geflasht (die mit "usb" im Namen). Dann bitte nochmal die richtige Firmware flashen.
Der WiCAN sollte sich einige Zeit nach Wegnahme der Fahrbereitschaft des Fahrzeugs schlafen legen, um die Niedervolt-Batterie zu schonen. Diesist der Fall, wenn die WiCAN-Seite im Heimnetz nach einigen Minuten nicht mehr erreichbar ist.
Anleitung: https://github.com/meatpiHQ/wican-fw
Linuxsystem konfigurieren Vorweg: Es ist nicht nötig, Linux als Grundlage für den soc_helper zu verwenden. Theoretisch kann auch ein Desktoprechner oder Laptop mit Windows verwendet werden. Empfehlenswert ist allerdings etwas stromsparendes wie der Raspberry Pi. Weil ich mit Windows keine Erfahrungen habe, beschreibe ich hier die nötigen Tätigkeiten nach dem Aufsetzen eines Linux-Grundsystems auf einem Raspberry Pi. Für die Bedienung eines Linux-Systems von der Konsole sei auf andere Anleitungen verwiesen, da dies den Umfang dieser Anleitung bei weitem sprengen würde.Für die Installation von Raspbian sei auf folgende Seite verwiesen:
Anleitung und Einführung in Raspbian: https://www.raspberrypi.com/documentation/computers/getting-started.html,
darunter das Beschreiben einer Micro-SD-Karte mit Raspbian: https://www.raspberrypi.com/documentation/computers/getting-started.html#install-an-operating-system
Es sollte ein minimales System (Raspian Lite) gewählt werden, da eine grafische Nutzeroberfläche nicht nötig ist. Die 64-Bit-Version sollte nur für die neueren Raspberries verwendet werden, den RPi4, 5 und 400. Alle anderen benötigen ein 32-Bit-System.
Bei der Installation oder beim ersten Start werden verschiedene Dinge abgefragt wie WLAN-Zugang (sofern gewünscht), Nutzername und Passwort, Lokalisierung. Wichtig bei der Konfiguration ist, daß "Enable ssh" angewählt wird. Damit ist später ein Betrieb ohne Monitor und Tastatur und eine Bedienung per Fernzugriff möglich.
Um später Änderungen in der Konfiguration von raspian durchzuführen, existiert das Kommando
sudo raspi-config,
soc_helper benötigt ein paar Python-Bibliotheks-Pakete, um korrekt zu funktionieren. Diese müssen einmalig nachinstalliert werden. Nach dem Anmelden per ssh auf dem Pi erfolgt dies mit dem Befehl:
sudo apt install python3-paho-mqtt python3-watchdog
python3-requests
Damit ist das Grundsystem konfiguriert.
Voraussetzung ist, daß der Raspberry Pi hochgefahren und die Erstkonfiguration erfolgt ist sowie der ssh-Zugang aktiviert ist. Die Adresse des Raspberries kann im Heimrouter gefunden werden. Wenn Tastatur und Monitor verbunden sind, kann nach Anmeldung mit dem Befehl "ifconfig" die Adresse angezeigt werden. Im Folgenden wird davon ausgegangen, daß ein Nutzer "pi" angelegt wurde und der Raspi den Namen socke die interne IP-Adresse 192.168.178.111 hat.
Mit einem geeigneten Dateiverwaltungs-Tool kann auf den Raspi zugegriffen
werden. Dazu wird als Adresse sftp://pi@192.168.178.111/home/pi/
oder sftp://pi@socke angegeben. Nach Abfrage des
Passwortes des Nutzers sollte der Inhalte des Homeverzeichnisses zu sehen
sein. (Unter Windows kann möglicherweise winscp genutzt werden: https://winscp.net/eng/docs/lang:de.
Unter Linux können beispielsweise nautilus und dolphin mit ssh umgehen.)
Das heruntergeladene zip-Archiv des soc_helper wird nun auf dem Desktop-Rechner entpackt und der Ordner soc_helper samt Inhalt per Dateiverwaltung in das Nutzerverzeichnis (/home/pi) auf den Raspi kopiert.
Fallstrick: Sollte sich bereits ein funktionierender soc_helper auf dem Zielsystem befinden, sollte vor dem Kopiervorgang die Konfigurationsdatei configuration.py gesichert werden, zum Beispiel durch Kopieren in configuration.py.funktioniert. Es empfiehlt sich beim jetzigen Entwicklungsstand, bei jeder neuen Version die mitgelieferte Konfiguration mit Hilfe der gesicherten configuration.py an die eigenen Bedürfnisse anzupassen, da sich das Format häufiger ändern kann.
Fallstrick 2: Wenn das Archiv auf einem Windows-Rechner entpackt
wurde, werden die Dateiattribute nicht gespeichert. Diese entscheiden
unter Unix (und Linux), ob eine Datei lesbar / schreibar / ausführbar ist
und für wen. In diesem Fall empfiehlt es sich nach dem Kopieren auf den
Raspberry, die Datei soc_helper.py per Hand ausführbar zu machen, um sie
direkt aufrufen zu können. Das geschieht nach dem Wechsel in das
Verzeichnis soc_helper mit dem Befehl chmod 755 soc_helper.py.
Siehe hierzu auch die Erklärung
von ubuntu zu chmod.
Die Nutzung von Spritmonitor ist optional und zur Zeit der Dokumentation kostenlos. Spritmonitor ist eine große Datenbank von Verbräuchen, die von den Nutzern eingepflegt wird. Man kann dort sehen, welche Verbäuche Nutzer mit verschiedenen Fahrzeugen erzielen und wie man im Vergleich zu anderen Nutzern seines Fahrzeugs abschneidet. Es kann Buch geführt werden über Kraftstoffkosten und bei Bedarf Wartung / Reparaturen. Vorausgesetzt man gibt entsprechende Daten bei den Betankungen / Ladevorgängen ein kann sich unter anderem auswerten lassen, in welchem Monat man welchen Verbrauch erzielt.
Spritmonitor hat keine Beziehung zu soc_helper.
Unter https://www.spritmonitor.de kann ein Nutzerkonto angelegt werden. Unter "Mein Account" kann ein (weiteres) Fahrzeug angelegt werden. Die ID (Nummer) dieses Fahrzeuges wird später gebraucht.
Für die Nutzung der Spritmonitor-Programmierschnittstelle durch ein Programm erfolgt keine Anmeldung per Passwort. Stattdessen wird ein App-Token und ein Bearer-Token verlangt. Das App-Token in configuration.py ist vorgegeben und sollte nicht geändert werden. Es signalisiert Spritmonitor, mit welcher App der Eintrag erfolgt. Das Bearer-Token ist nutzerindividuell und dient dazu, sich als Nutzer gegenüber Spritmonitor auszuweisen.
Um sich ein Bearer-Token zu beschaffen, meldet man sich bei Spritmonitor an und navigiert auf diese Seite: https://www.spritmonitor.de/de/mein_account/passwort_aendern.html (Von der Hauptseite: Mein Account->Passwort ändern). Dort kann man auf "Neuen Token erzeugen" klicken und bekommt ein Bearer-Token, das man sich auf seinen lokalen Rechner kopiert und gut sichert, weil es später nicht mehr angezeigt wird. Bei Verlust kann man ein neues Bearer-Token erzeugen lassen, muß dann aber eine Datei im homeverzeichnis ändern.
Das Bearer-Token wird nicht in der Konfiguratiosdatei abgespeichert. Zu groß ist die Gefahr, daß es beim Veröffentlichen oder Weitergeben in fremde Hände gerät und dann Fremde auf den eigenen Spritmonitor-Zugang zugreifen können. Statt dessen wird das BEARER_TOKEN als Umgebungsvariable des Nutzers definiert, der den soc_helper laufen läßt. Diese Definition erfolgt in der (versteckten) Datei ~/.profile (Die Tilde ist eine Abkürzung für das home-Verzeichnis, ausgeschrieben also /home/pi/.profile). Diese Datei wird bei der Anmeldung an den Rechner ausgewertet. Es ist folgende Zeile ans Ende der .profile anzufügen:
export SPRITMONITOR_BEARER_TOKEN=<Token>
<Token> ist dabei die lange Zeichenkette aus dem vorigen Abschnitt. Wenn man sich nun neu auf dem pi anmeldet, auf dem der soc_helfer läuft und mit dem Befehl "export" die Umgebungsvariablen auflistet, sollte die Umgebungsvariable und ihr Inhalt zu sehen sein.
pi@pi4:~$ export
declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
declare -x HOME="/home/pi"
declare -x LANG="de_DE.UTF-8"
declare -x LOGNAME="pi"
declare -x MOTD_SHOWN="pam"
declare -x OLDPWD
declare -x
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
declare -x PWD="/home/pi"
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x
SPRITMONITOR_BEARER_TOKEN="vdfakognevlvthrneptnhreptnrehptnrezptzhepqutzhreqp"
declare -x SSH_CLIENT="2003:e0:171f:d200:1a36:79d:e3df:bbf 51302 22"
declare -x SSH_CONNECTION="2003:e0:171f:d200:1a36:79d:e3df:bbf 51302
2003:e0:171f:d200:9d7:f4e0:527d:6594 22"
declare -x SSH_TTY="/dev/pts/0"
declare -x TERM="xterm-256color"
declare -x TEXTDOMAIN="Linux-PAM"
declare -x USER="pi"
declare -x XDG_RUNTIME_DIR="/run/user/1000"
declare -x XDG_SESSION_CLASS="user"
declare -x XDG_SESSION_ID="18410"
declare -x XDG_SESSION_TYPE="tty"
pi@pi4:~$
Um mit dem WiCAN zusammen zu arbeiten, sind ein paar Einstellungen in der OpenWB nötig. An dieser Stelle erfolgt die Beschreibung für Software-Schiene 2, für Software 1.9 ist die Konfiguration ähnlich, aber deutlich einfacher. Es wird nur der Teil beschrieben, der für den soc_helper relevant ist.
Für Software 2. Nur den für soc_helper relevanten Teil unter
Konfiguration->Fahrzeuge
Im zu nutzenden Fahrzeugprofil muß die Netto-Kapazität der Fahrzeugbatterie sowie der Ladewirkungsgrad korrekt eingestellt sein, da sonst das SoC-Modul während der Ladung den Ladezustand falsch berechnet (SoC bedeutet State of Charge und ist gleichbedeutend mit Ladezustand). Der e-Up! der zweiten Generation hat eine nutzbare Batteriekapazität von 32,3kWh, dies wird hier gerundet. Beim Laden hat das Fahrzeug Verluste. Diese kommen einerseits von Nebenverbrauchern und sind unabhängig von der Ladeleistung, zum anderen hat das Ladegerät selbst von der Ladeleistungs abhängige Verluste. Die im Bild angegebenen 90% sind daher en Mittelwert. Wenn die Ladung mit geringer Leistung stattfindet, sind die Verluste höher, weil die Nebenverbraucher mehr ins Gewicht fallen. Bei hoher Leistung wird der Wirkungsgrade etwas besser sein. Hier gilt es, durch Probieren einen sinnvollen Wert herauszufinden:
Wenn der SoC nach Abstecken grundsätzlich höher ist als von der Wallbox berechnet, sollte der Wirkungsgrad heraufgesetzt werden. Wenn der Ladezustand nach Abstecken meist zu niedrig ist, sollte der Wirkungsgrad verringert werden, um der Wirklichkeit Rechnung zu tragen.
Unter der Fahrzeugkonfiguration ist als SoC-Modul "Manueller SoC" auszuwählen. Dieses Modul nimmt normalerweise die manuelle Eingabe des SoC und rechnet anhand HV-Speicherkapazität, Ladewirkungsgrad und gemessener Ladearbeit den SOC während der Ladung fortwährend aus. Der soc_helper nutzt die Eingabemöglichkeit und schickt den aus dem Fahrzeug asugelesenen Ladezustand an die Wallbox, die dann während der Ladung den Fahrzeug-SoC berechnet.
Der SoC wird nicht direkt aus dem Fahrzeug gelesen - das klappt nur mit der OpenWB Pro im Zusammenspiel mit einigen Fahrzeugtypen. Während der Ladung soll jede Minute der SoC aktualisiert werden, ohne Ladung ist es nicht nötig (lange ZZeitintervalle, hier 720 Minuten) und im abgesteckten Zustandergibt die Funktion keinen Sinn, daher nur aktualisieren wenn angesteckt.
Die IDs (Nummern) der in der Wallbox konfigurierten Geräte sind wichtig für die Konfiguration des soc_helper. Die IDs sind übersichtlich auf der Statusseite der Wallbox aufgeführt:
Für den soc_helper sind die ID der verwendeten Wallbox (im Bild "Interne openWB", ID 3) und die Nummer des Fahrzeugs, das den WiCAN verwendet ("Nulli", ID 1) wichtig. Diese Nummern sind im folgenden Kapitel wichtig.
Alle Konfigurationsmöglichkeiten befinden sich in der Datei configuration.py.
Viele Definitionen in configuration.py sind blockweise hinterlegt - Beispielsweise Definitionen für OpenWB 1.9 oder 2.0 oder für einzelne Fahrzeuge. Bitte bei den richtigen Definitionen die Kommentarzeichen "#" entfernen und alle falschen Definitionen auskommentieren (ein Doppelkreuz vor jede betroffenen Zeile)configuration.py wird nach Änderungen vom soc_helper automatisch neu eingelesen, so daß der soc_helper nicht gestoppt und neu gestartet werden muß, sofern ein Eintrag geändert wurde. Falls sich der soc_helper durch eine Änderung mit einer Fehlermeldung beendet oder abstürzt, ist ein manueller Neustart erforderlich (siehe unten).
Fall ein Konto bei spritmonitor.de besteht, können Ladevorgänge nach Beenden automatisch dort hochgeladen werden. Erforderlich ist ein Konto und ein Fahrzeug dort.
USE_SPRITMONITOR = True - Soll Spritmonitor verwendet werden? Auf False setzen, falls Übertragung nicht erfolgen soll.
SPRITMONITOR_VEHICLE_ID = '1370192' - Bitte hier die eigene Fahrzeug-ID (In der App oder Webseite angezeigt) einfügen. Die Anführungszeichen bitte nicht löschen.
SPRITMONITOR_FUELSORT = 24 - über die API sind die Nummern der Kraftstoffsorten abrufbar. Hier wichtig: 19 - Elektrizität, 24 - Ökostrom
SPRITMONITOR_FUELPRICE = 0.08 - Preis in €/kWh. Im Winter der Arbeitspreis des Versorgers, im Sommer bei vorhandener PV die Einspeisevergütung plus evt. Umsatzsteuer auf Eigenverbrauch oder die voraussichtlichen Gestehungskosten ( Anlagenkosten / (Lebensdauer der Anlage * jährlicher Ertrag))
SPRITMONITOR_ATTRIBUTES = 'summertires,slow' - Folgende Attribute können der Betankung per default zugefügt werden (Werte aus den Klammern, maximal eins pro Klammer): Reifen (summertires wintertires allyeartires), Fahrweise (slow normal fast), Klimaanlage (ac), Anhänger (trailer), Standheizung (heating)
Bei der Übertragung wird für den Ladevorgang automatisch angewählt, daß mit 11kW AC geladen wurde und die Lademenge durch die Wallbox gemessen wurde. Momentan ist dies hart codiert. Falls Bedarf besteht, die Ladeleistung auf beispielsweie 3,6kW zu setzen (fixes Einphasiges Laden als Defaulteinstellung), kann ich den Wert konfigurierbar gestalten. Eine Berechnung der durchschnittlichen Ladeleistung halte ich für nicht sinnvoll, da eine Ladung für den soc_helper mit Stecken des Ladesteckers beginnt und mit Abziehen endet, auch wenn schon lange vorher kein Strom mehr geflossen ist.
OPENWB_IP = '192.168.1.102' # hier die Adresse der OpenWB einstellen - Lokaler Name könnte auch funktionieren, nicht ausprobiert
Es müssen folgende MQTT-Topics definiert sein:
OPENWB_SETSOC_TOPIC - Topic, um den SOC des verwendeten Fahrzeugs zu setzen.
OPENWB_GETSOC_TOPIC - Topic, um den aktuellen (von der Wallbox berechneten) SOC des verwendeten Fahrzeugs zu lesen.
OPENWB_CHARGECOUNTER_TOPIC - Unter diesem Topic kann der Zählerstand des Stromzählers der OpenWB gelesen werden.
OPENWB_GETPLUGSTATE_TOPIC - Zustand des Ladesteckers zum Fahrzeug. Änderungen dienen der Erkennung des Ladevorgangs.
OPENWB_FACTORCOUNTER - Faktor, um von der Einheit des Zählers (in 2.0 sind es Wh, in 1.9 kWh) auf kWh umzurechnen
Die in den Topics verwendeten Zahlen (1 und 3) sind die Gerätenummern der OpenWB. Sie sind auf der Statusseite der OpenWB ablesbar und müssen auf die eigene Konfiguration angepaßt werden.
OPENWB_SETSOC_TOPIC =
'openWB/set/vehicle/1/soc_module/calculated_soc_state/manual_soc'
OPENWB_GETSOC_TOPIC = 'openWB/vehicle/1/get/soc'
OPENWB_CHARGECOUNTER_TOPIC = 'openWB/chargepoint/3/get/imported' # Topic,
um den Ladezähler auszulesen. Insbesondere die Nummer ist anzupassen
OPENWB_GETPLUGSTATE_TOPIC = 'openWB/chargepoint/3/get/plug_state' # Topic,
um den Steckerzustand auszulesen. Nummer anpassen!
OPENWB_FACTORCOUNTER = 1000 # Faktor, um von der Einheit des Zählers (in
2.0 sind es Wh) auf kWh umzurechnen
OPENWB_SETSOC_TOPIC='openWB/set/lp/1/manualSoc'
OPENWB_GETSOC_TOPIC='openWB/lp/1/%Soc'
OPENWB_CHARGECOUNTER_TOPIC='openWB/lp/1/kWhCounter'
OPENWB_GETPLUGSTATE_TOPIC='openWB/lp/1/boolPlugStat'
OPENWB_FACTORCOUNTER=1
Sinnvollerweise sollte der Name auf das Fahrzeug hinweisen, in dem der WiCAN verbaut ist. Der Name definiert den MQTT-Zweig unter "others/wican/<WICAN_NAME>/, unter dem der WiCAN seine Informationen sendet und empfängt. WICAN_NAME muß zwingend mit dem übereinstimmen, der im Kapitel der WiCAN-Konfiguration vergeben wurde!
FIXME: contine
Für diesen Schritt muß immer eine Anmeldung auf dem Raspi erfolgt sein und mit
pi@pi4:~/$ cd soc_helper
in das Verzeichnis des soc_helper gewechselt werden.
Für erste Tests ist es sinnvoll,den soc-Helper nicht im Hintergrund zu starten. Auf diese Weise sieht ma die Ausgaben des soc_helpers auf der Konsole.
pi@pi4:~/soc_helper$ ./soc_helper.py
Auf einen Fallstrick in Verbindung mit Windows auf dem Desktop-Rechner
wird hier hingewiesen. Wenn die Dateirechte
nicht richtig sind, kann trotzdem mit python ./soc_helper.py gearbeitet
werden.
Um den soc_helper mit dem Abmelden nicht zu beenden, wird der Befehl nohup ("no hangup") verwendet.
pi@pi4:~/soc_helper$ nohup ./soc_helper.py&
Das kaufmännische & am Ende bewirkt, daß der Prozess von der Konsole gelöst wird und im Hintergrund weiterarbeitet. Damit ist die Konsole frei für weitere Eingaben, zum Beispiel die Ansicht der Ausgaben mittels tail:
pi@pi4:~/soc_helper$ tail nohup.out
2024-05-02 15:14:21,799;
INFO;[ soc_helper.py:245
- cb_status() ] WiCAN-Status:
others/wican/nulli/status b'{"status": "offline"}'
2024-05-02 15:14:21,800;
INFO;[ soc_helper.py:261
- cb_status() ] Fahrzeugstatus
ist nicht <<online>>
2024-05-02 16:37:51,714;
INFO;[ soc_helper.py:245
- cb_status() ] WiCAN-Status:
others/wican/nulli/status b'{"status": "online"}'
2024-05-02 16:37:51,714;
INFO;[ soc_helper.py:251
- cb_status() ] Fahrzeug ist
online. Sende SOC- und DST-Anforderung
2024-05-02 16:37:51,715;
INFO;[ soc_helper.py:254
- cb_status() ] Sende
SOC-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 2021,
"dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170,
170, 170] }] }
2024-05-02 16:37:51,716;
INFO;[ soc_helper.py:258
- cb_status() ] Sende
DST-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 2021,
"dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 189, 170, 170,
170, 170] }] }
2024-05-02 16:37:51,762;
INFO;[ soc_helper.py:334
-
cb_rx() ] Fahrzeug-SOC ist 75
2024-05-02 16:37:51,803;
INFO;[ soc_helper.py:344
-
cb_rx() ] Fahrzeug-Kilometerstand ist 10481
2024-05-02 16:42:09,821;
INFO;[ soc_helper.py:245
- cb_status() ] WiCAN-Status:
others/wican/nulli/status b'{"status": "offline"}'
2024-05-02 16:42:09,821;
INFO;[ soc_helper.py:261
- cb_status() ] Fahrzeugstatus
ist nicht <<online>>
In die Datei nohup.out werden alle Augaben eines Prozesses geschrieben,
der mittels nohup gestartet wurde.
Durch die Tastenkombination <Strg>+<C> wird der laufende Prozess abgebrochen.
pi@pi4:~/soc_helper$ ps ax | grep soc
501 ?
Ss 0:22 /usr/sbin/thd --triggers
/etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody
--deviceglob /dev/input/event*
359528 ?
Sl 7:02 python3 ./soc_helper.py
365331 pts/0 S+ 0:00
grep soc
ps bedeutet process status und gibt die Status der laufenden Prozesse aus. die Optionen ax zeigen alle Prozesse (nicht nur die der aktuellen Sitzung) und zeigen sie mit der kompletten Aufrufzeile. Der senkrechte Struch leitet die Ausgabe auf das Kommando grep um, das nur Zeilen durchlässt, die die Zeichenkette "soc" beinhalten.
Der Prozess mit der Nummer 359528 ist der zu beendende Prozess. (Die
Nummer ist individuell und fast nie die gleiche, daher wie oben
beschrieben nachsehen). Beenden des soc_helpers:
pi@pi4:~/soc_helper$ kill 359528
Die Prozessnummer ist dabei die oben ermittelte.
Eleganter geht das oben Beschriebene mit dem Befehl "pkill". Hiermit können Prozesse nach Namen beendet werden. Um alle Prozesse, die im Aufruf ein "soc_helper" tragen zu beenden, gibt man einfach
pi@pi4:~$ pkill -f soc_helper.py
ein.
Vorweg: Falls man sehr selten Stromausfälle hat und der Rechner, auf dem der soc_helper läuft, dauerhaft an ist, kann man den soc_helper per Hand starten. Etwas komfortabler ist es, wenn mit dem Systemstart der soc_helper gleich mitgestartet wird. Hier gibt es mehrere Alternativen:
cron ist Systemdienst, das bestimmte Kommandos zu definierten Zeiten ausführt. In einer Tabelle namens crontab stehen dazu die nötigen Informationen. Von dieser Tabelle gibt es neben der Version für das System für jeden Nutzer eine. In der System-crontab werden solche Sachen wie die Prüfung nach Updates, das Aufräumen temporärer Dateien oder Log-Dateien aufgerufen.
Ein Nutzer kann seine crontab mit dem Befehl crontab -e bearbeiten.
In die Datei kann die Zeile
@reboot . $HOME/.profile; $HOME/soc_helper/startAtBoot.sh
eingefügt werden. Damit wird bei Neustart die mitgelieferte
Datei startAtBoot.sh ausgeführt, die den soc_helper nach 10s Verzögerung
startet.Bitte darauf achten, dass das Executable-Bit von
startAtBoot.sh und soc_helper.py gesetzt sind. Das ". $HOME/.profile" ist
nötig, damit die in der Datei .profile definierte Variable
SPRITMONITOR_BEARER_TOKEN vorhanden ist und das Hochladen bei Spritmonitor
funktionieren kann.
Ein Systemdienst ist prinzipiell einfach zu erstellen, erfordert aber das Anlegen einer Datei in einem Systemverzeichnis. Wer sich das zutraut, findet unter diesem Link eine hilfreiche Anleitung.
Ganz wichtig: Nach erfolgreichem Hinzufügen eines bisher nicht unterstützten Fahrzeugs schickt mir bitte die Konfiguration unter soc_helper@vortagsmett.de
FIXME: continue
Um im Fehlerfall den Grund herauszufinden, ist der MQTT-Explorer hilfreich. Dieser zeigt alle Topics eines MQTT-Brokers an, so dass nachzuvollziehen ist, ob zum Beispiel eine Botschaft nicht gesendet wurde oder der Empfänger sie nicht wahrgenommen hat.
Links oben unter "Connections" das Plus-Symbol klicken. Dann die auf der rechten Seite zu sehenden Informationen und Schalterstellungen eingeben. Die Adresse der OpenWB natürlich auf die eigene Wallbox anpassen.
Im linken Bereich des Fenster sind empfangen Botschaften zu sehen. Die
kleinen Pfeile klappen die einzelnen Zweige der Hierarchie auf und zu.
Im Bild aufgeklappt zu sehen ist die Statusbotschaft des WiCAN, mit der
er sich schlafen gelegt hat.
Im vorigen Bild auf der rechten Seite zu sehen ist der Abschnitt "Publish". Unter Topic kann das MQTT-Topic eingegeben werden, unter dem Daten veröffentlicht werden sollen. In dem Kasten darunter können diese Daten eingegeben werden. Der Knopf "Publish" sendet diese Daten unter dem angegebenen Topic an den Broker der Wallbox.