Tesla Wallbox Gen 3

Im Grund sind 10A Ladeleistung zwar für einen BMW 225xe mit einem kleinen 7kWh-Akku ausreichend, um ihn in ca. 3-4 Stunden wieder voll zu laden. Mit 16A würde sich die Zeit auf vielleicht 2h drücken lassen. Aber ich bin sicher, dass zukünftig ein Elektrofahrzeug mit mehr Speicher ansteht und da aktuell das KFW440 Programm den Kauf und Installation von Wallboxen bis 900€ fördert, habe ich mich natürlich umgeschaut und bin bei der Telsa Wallbox Gen 3 gelandet, die seit ca. Sep 2021 auch frei verkäuflich ist. Vorher musste man ein Tesla-Besitzer sein.

Warum von Tesla?

Ich habe mich einige Monate lange über Wallboxen, Technik, Förderfähigkeit Lieferzeiten u.a. informiert. Leider ist die Aufbereitung der KFW440 im Web alles andere als hilfreich. Eine einfache CSV-Datei oder Excel-Liste wäre sicher besser gewesen. Insbesondere in der Frage der Fördervoraussetzungen sind ernüchternd. Denn es gibt kein Standard, was denn "Remote steuerbar" bedeutet. Einige Geräte haben einfach einen Schaltkontakt oder analoge RS485-Modbus-Schnitstellen. Andere nutzen LAN oder WLAN um eine RESTAPI, EEBus oder Modbus-TCP anzubieten oder ihrerseits mit einem Cloud-Service (OCPP-Protokoll) zu kommunizieren. All diese Erweiterungen machen die Wallbox teurer aber ich denke nicht, dass je eine der Schnittstellen durch den Netzbetreiber je angesteuert werden wird. Zudem möchte ich nicht, dass meine Wallbox mit einer Hersteller-Cloud spricht, über die ich dann auch erst den RFID-Zugang verwalten kann.

Bei der Einrichtung gibt es die nächsten Unterschiede. Hat früher ein "Mäuseklavier" (DIP-Schalter) gereicht, muss es mit WLAN einen weg geben, die Box zu verbinden. Interessant, wie viele Boxen eine Konfiguration über eine Smartphone-App mit "Herstellerkonto" vorgeben. Ob es die App auch in 10 Jahren noch gibt? Eine Wallbox hat doch andere Lebenszyklen als Betriebssysteme. Tesla nutz eine Webseite, die mit jedem Browser die grundlegenden Einstellungen erlaubt. Das Ding muss einfach funktionieren und die Gen 3 scheint die meisten Voraussetzungen zu erfüllen, auf die es mir ankommt:

  • integrierten FI-A und DC-Schutz
    d.h. ich brauche keinen teuren FI-B oder FI-EV in der Hausverteilung sondern nur die Leitungsschutzschalter (3x16A Sicherung) und einen FI-A
  • WLAN zur Kommunikation mit Einrichtung ohne App oder Herstellerkopplung
    Nicht jeder hat ein CAT5-Kabel für LAN der RS485 o.ä. in der Garage. Ein WLAN-AP kann man ja einfacher in der Nähe verstecken.
  • Lokale API per HTTP/REST
    Damit kann ich die Daten per PRTG lesen. Leider kann man die Box damit nicht steuern. Ich hoffe mal, dass die API nicht später durch ein Firmware-Update mal abgeschaltet wird.
  • Preislich interessant mit 599€ am unteren Preissegment
    Eigentlich ist das schon sehr günstig. Die meisten anderen Wallboxen sind teurer oder schlechter ausgestattet.
  • 11kWh per Einstellung gedrosselt.
    Technisch kann sie aber auch 22kWh aber dann muss der Hausanschluss das hergeben. Mehrere Wallboxen können sogar von Hause aus ein Lastmanagement machen, wenn Sie sich per WLAN direkt sehen. Leider nur dann.
  • 7,3m langes Kabel. Erstaunlich, wie viele Wallboxen mit weniger als 5m kommen.
    Allerdings ist es etwas "dicker", da die Box auch 22kW könnte
  • Integrierter Energiezähler
    Die Box ermittelt nicht nur die Momentan-Ladung sondern summiert auch auf und stellt die Werte bis zur nächsten Ladung wieder bereit. Leider ist der Zähler wohl nicht MID-zertifiziert und reicht nicht für Dienstwagenabrechnung.
  • RFID-Leser, allerdings noch ohne Funktion.
    Leider kann man die Box noch nicht über dieses Modul steuern. Theoretisch könnte mir also jemand "Strom klauen". Ich bin aber sicher, dass das auffallen wird.
  • Lieferbar, versprochen 2-4 Wochen, Realität: Versand am nächsten Tag aus Einhoven, NL, Zustellung innerhalb einer Woche

Die Installation selbst muss natürlich ein zertifizierter Elektroinstallateur durchführen. Technisch muss im Hausanschlusskasten eine 3x16A Sicherung (C statt B) zum Schutz der Leitung gegen Überlastung und ein FI-A installiert werden. Der einzige Wermutstropfen ist eine noch fehlende Freischaltung eines Ladevorgangs per Schlüsselschalter, RFID o.ä., d.h. die Wallbox sollte so nicht unbemerkt frei zugänglich sein. Mit 11kW und 30ct/kWh könnte ein Fremdlader einen Schaden von ca. 3€/Stunde erzeugen.

Ob meine Einschätzungen und letztlich die Entscheidung korrekt war, werde ich dann in einigen Jahren wissen.

Hinweis: Achten Sie darauf, dass sie eine GEN3-Box mit der Nummer 1529455-02-D kaufen und nicht die frühere Version mit der Nummer 1050071-01-K.

Firmware

Ich habe noch keinen Hersteller einer Wallbox gesehen, der seine Firmware als Source bereitgestellt hat. Aber Tesla hat Ende Sep 2021 auf seiner Webseite zumindest eine Firmware zum "normalen Download" angeboten.

Damit ist die Firmware selbst zwar noch nicht offen aber ein Blick in die Binärdatei zeigt einige interessante Strings und Hinweise auf mögliche APIs. So scheint die Box bei einer Verbindung mit dem Internet mit drei Diensten zu kommunizieren. Ich hoffe mal, dass Tesla bei einer Installation in Europa auch die europäischen Datacenter nutzt.

hermes-stream-prd.sn.tesla.services
hermes-prd.sn.tesla.services
hermes-stream-prd.energy.tesla.cn
maestro-prd.sn.tesla.services
wc-maestro-prd.sn.tesla.services

Das gilt es später mal zu prüfen. Wobei ich erst einmal gar nicht vor habe, die Box nach Außen zu lassen. Über eine reine Textsuche finden wir noch mehr in der Firmware:

  • NTP-Server 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org
    Für die Prüfung von Zertifikaten muss das System natürlich eine korrekte Uhrzeit haben
  • lib/marvell-wmsdk/sdk/src/incl/platform/os/freertos/wm_os.h
    Anscheinend ist die CPU von Marvell und das Betriebssystem ein freertos
  • wifi/src/uds/tp_link_config.c
    Das finde ich nun wieder interessant, dass hier TP-Link auftaucht. Ist der WLAN-Anschluss vielleicht einfach ein USB-Stecker? Vielleicht lässt sich auch ein 10/100-Ethernet/USB-Dongle nutzen
  • Hinweise auf ein Command Line Interface (CLI)
    So wird das Kommando "iwpriv" (https://en.wikipedia.org/wiki/Wireless_tools_for_Linux#iwpriv) mit Optionen beschrieben.
  • Hinweise aus 2,4 und 5 GHz WLAN und WPA3
    In der offiziellen Beschreibung wird nur das 2,4 GHz-Band aufgeführt. Im Code sehe ich aber auch Hinweise zu 5 GHz und sogar WPA3.
  • Zertifikate
    In der Firmware selbst sind einige Zertifikate ohne sichtbaren privaten Key hinterlegt. Ich vermute mal, dass Sie damit die TLS-Verbindung verifizieren, denn genauso finde ich Fehlermeldungen, wenn dies nicht möglich ist. Folgende Zertifikate waren einfach zu finden.

    Spätestens 2036 muss es also ein Firmware-Update mit einer neuen RootCA geben. Wobei die Box vermutlich auch Update weiter läuft aber dann keine Verbindung mehr zu Tesla aufbauen dürfte.

Die Firmware kann natürlich auch "ohne" Internet offline aktualisiert werden. Die Tesla Wallbox hat dazu eine eigenes WLAN, welches durch den Druck auf die Taste am Stecker oder nach dem Einschalten aktiviert wird. Wer sich dann verbindet, kann über das "interne Netzwerk" (http://192.168.92.1/)" die Wallbox konfigurieren. URLs sind:

Das bringt mich natürlich auf die Idee, bei eine Tesla Wallbox in einem Hotel einfach mal den Knopf zu drücken.

Tesla kann durch neuere Versionen die Funktion natürlich jederzeit verändern. Insbesondere die API kann sich ändern, da seitens des KFW440 Programs auch nichts vorgeschrieben wird.

Anschluss und Konfiguration

Mit 380V/400V ist nicht zu spaßen und daher sollte die Wallbox immer durch einen Elektriker angeschlossen werden. Für die KFW440-Förderung muss der Elektriker sowieso die fachgerechte Installation bestätigen. Nachdem die Montageplatte installiert und angeschlossen wurde, kann die eigentliche Wallbox fest aufgedrückt werden. Dazu braucht man schon etwas Kraft, damit die vier Kontaktmesser in die Halterung rutschen.

Ich habe noch nicht heraus gefunden, wozu die mit "+" (rot) und "-" (weiß) gekennzeichneten Kontakte dienen.

Sobald "Strom" drauf ist, sollte die Wallbox "grün blinken" und damit auf die Ersteinrichtung warten. Mit einem PC oder Smartphone sollten Sie dann ein neues WLAN "TeslaWallConnector_xxxxxx" finden. Die Zugangsdaten sind in als Ausdruck in der Anleitung und auf der Innenseite der Wallbox zu finden.

Der WLAN-Zugang wird angeblich nach einiger Zeit abgeschaltet und kann durch einen Druck über 5 Sekunden auf die Taste am Stecker wieder aktiviert werden, wenn nicht gerade geladen wird. Zur Verbindung brauchen Sie natürlich immer noch den WPA-Schlüssel.

Hinweis: Die Einbindung in mein LAN funktionierte nur über 2.4GHz und auch nur, wenn WPA2 das einzige Authentifizierungsverfahren war. WPA2/WPA3-Mixed oder WPA3 alleine funktioniert nicht. Da aber auch andere IoT-Geräte damit mal Probleme haben, nutze ich für IoT eh eine eigene WLAN-SSID mit VLAN und WPA2 Only.

Der Zugriff ist dann einfach per Browser möglich. Tesla hat keine besondere App für die Wallbox, was ich lobenswert finde. Einen Browser sollte auch es in vielen Jahren noch geben. Bei Apps und Smartphones wäre ich mir da nicht so sicher.

Über die Startseite http://192.168.92.1 kommen Sie auf die Einrichtungsseite zur Konfiguration. Hier eine Homepage, von der aus sie auch WLAN, SoftwareUpdates, Ausgangsstrom, Zugriffssteuerung und Leistungsverteilung einrichten können.

Wenn Sie das rechte Bild sehen, dann ist die Box schon einige Zeit aktiv und muss erst wieder in den Einrichtungszustand versetzt werden.

Tesla Wallconnector V3: Einstellungen & Interface, Software 21.29.1
https://www.youtube.com/watch?v=gpDP6c7-Nzw

Tesla Wall Connector Wallbox Gen 3 Inside Teardown
https://www.youtube.com/watch?v=qsrTextE7ac

RESTful API

Das KFW440-Programm fordert, dass die Wallboxen "steuerbar" sind aber interessanterweise haben die Beamten wohl vergessen, die API zu beschreiben. So gibt es wohl noch mehr APIs als Hersteller. Einige haben einen Webserver, andere sprechen mit der "Cloud des Herstellers" (z.B. ABB, VW etc.), wieder anderen nutzen OCPP während auch RS485 (Modbus-RTU) oder Ethernet mit Modbus-TCP zu finden sind. Ob das im Interesse des Gesetzgebers war? Ob das auch auf das Konto des Fach-Ministers Scheurer geht? Ich befürchte, dass auch hier die Schnittstellen nur den Preis erhöht haben aber letztlich nie zum Einsatz kommen.

Umso wichtiger sind mir einfache lokal erreichbare APIs. Diese kann ich dann z.B. zur Auswertung oder Überwachung nutzen. Ein Schritt weiter geht die Steuerung der Wallbox um z.B. das Laden mit Solarstrom zu optimieren. Aber auch hier ist das Potential eher überschaubar, wenn das Auto tagsüber unterwegs ist. Dann wäre es eigentlich eher eine Aufgabe des Auto, dass der Fahrer beim Aussteigen vorgibt, bis wann das Auto wieder voll sein muss. Dann könnte das Auto mit verminderter Leistung laden. Die meisten Eigenheime haben maximal 10kWp und erzeugen im besten Fall 6-7kW. Schon eine "Ruheladung" bis Dunkelheit von 2kW würde den Eigenverbrauch anheben.

Nicht alle Hersteller gehen offen mit ihren APIs um. Einige machen ein richtiges Geheimnis draus. Leider ist auch Tesla hier nicht offen und es gibt keine Zusicherung, dass die gefundenen APIs zukünftig auch funktionieren.

Folgende URLs sind in der Firmware zu finden. Ich habe nur einen einfachen GET darauf gemacht.

URL Beschreibung und Beispiel

http://<IP address>/api/1/vitals

PS C:\> Invoke-RestMethod http://192.168.137.22/api/1/vitals

contactor_closed    : False
vehicle_connected   : True
session_s           : 106
grid_v              : 224,5
grid_hz             : 49,839
vehicle_current_a   : 0,2
currentA_a          : 0,2
currentB_a          : 0
currentC_a          : 0,2
currentN_a          : 0,3
voltageA_v          : 8
voltageB_v          : 0
voltageC_v          : 0,9
relay_coil_v        : 11,9
pcba_temp_c         : 14,2
handle_temp_c       : 8,9
mcu_temp_c          : 20,9
uptime_s            : 516
input_thermopile_uv : -143
prox_v              : 0
pilot_high_v        : 8,7
pilot_low_v         : -11,8
session_energy_wh   : 0
config_status       : 5
evse_state          : 8
current_alerts      : {}

http://<IP address>/api/1/wifi_status

PS C:\> Invoke-RestMethod http://192.168.137.22/api/1/wifi_status

wifi_ssid            : SU9U
wifi_signal_strength : 28
wifi_rssi            : -76
wifi_snr             : 21
wifi_connected       : True
wifi_infra_ip        : 192.168.137.22
internet             : False
wifi_mac             : 98:ED:5C:93:41:19

http://<IP address>/api/1/lifetime

PS C:\> Invoke-RestMethod http://192.168.137.22/api/1/lifetime

contactor_cycles        : 33
contactor_cycles_loaded : 0
alert_count             : 39
thermal_foldbacks       : 0
avg_startup_temp        : 29,2
charge_starts           : 33
energy_wh               : 12400
connector_cycles        : 7
uptime_s                : 289786
charging_time_s         : 15204

http://<IP address>/api/1/version

PS C:\> Invoke-RestMethod http://192.168.137.22/api/1/version

firmware_version        part_number  serial_number
----------------        -----------  -------------
21.29.1+g4152353e50f744 1529455-02-D PGT21216001959

Dies sind sehr einfache REST-Aufrufe, die ich natürlich sehr einfach in eine andere Software übernehmen kann.

Diese API-Aufrufe funktionieren nicht über das "TeslaWallConnector_xxxxxx"-WLAN sondern nur über das eingebundene WLAN. Eine Authentifizierung ist hier nicht erforderlich.

Analyse

Natürlich wollte ich genauer wissen, was die Wallbox so anstellt. Nun ist es leider nicht so einfach, auf einem WLAN-Kontroller oder einer Fritz!Box gezielt die Pakete mitzuschneiden. Aber auch mit Windows 10 kann ich einen "Hotspot" aufmachen und meine LAN-Verbindung mit WLAN-Teilnehmern teilen. 

So gehen alle Pakete der Wallbox durch meinen PC als "NAT-Router" ins LAN. Das macht es dann schon einfach, die Pakete z.B. mit WireShark mitzuschneiden. Leider akzeptiert die Wallbox keinen Proxy und alle Verbindungen nutzen HTTPS. Über eine Dauer von 25 Minuten habe ich nur wenige HTTPS-Versuche zu drei Servern von Tesla gesehen und einige UDP-Pakete, die aber ebenfalls erklärbar sind

In HTTPS kann ich nicht direkt reinschauen aber die UDP-Pakete habe ich mir genauer angeschaut. Es waren aber nur das erwartete DHCP-Protokoll (Port 67/68) und DNS-Anfragen im Abstand von ca. 2-5 Minuten nach "hermes-prd.sn.tesla.services", der auf Server bei Amazon AWS auflöst.

C:\>nslookup hermes-prd.sn.tesla.services

Name:    nlb-hermes-us-west-2-prd-209dc4544fe4aab4.elb.us-west-2.amazonaws.com
Addresses:  54.189.221.190
          54.149.35.223
          54.189.232.34
Aliases:  hermes-prd.sn.tesla.services

Ich habe in meinem Netzwerk dann den Namen einfach mal auf einen lokalen WebServer geleitet, auf dem ich ein selbstsigniertes Zertifikat für "hermes-prd.sn.tesla.services" installiert habe und gewartet. Aber irgendwo muss Tesla da eine Validierung eingebaut haben. Ich sehe den DNS-Query, meine Antwort aber dann kommt nicht mal ein Verbindungsversuch. Ob ihm die private IP-Adresse nicht gefällt? Dann gebe ich mir doch mal die hermes-prd.sn.tesla.services auf einem HyperV-Host. Aber auch das hat noch nichts gebracht. Ich tippe aber erst einmal auf ein Problem bei meiner Testumgebung.

Wallbox ohne Internet

Ich nutze die Wallbox nur zum Laden eines "Nicht Tesla". Insofern braucht meine Wallbox dann auch keine Verbindung zu Tesla um dort irgendwelche Daten bereitzustellen. Firmware-Updates kann ich bei Bedarf und Gelegenheit immer noch freigeben. Es ist ja "nur" ein Ladegerät. Die Wallbox ist daher in eine IoT-WLAN, welches nur sehr restriktiv nach extern darf. In der Regel greife ich von meinen Systemen auf ausgewählte IoT-Systeme zu und natürlich ist MQTT erlaubt. Die fehlende Internet-Verbindung sieht man auch auf der Statusseite, wenn  ich mich mit dem "TeslaWallConnector_XXXXXX"-WLAN verbunden habe. Das bedeutet aber nicht, dass ich kein WLAN habe sondern nur, dass es keine Internet-Verbindung gibt.

Der Zugriff per Browser über das Betriebs-WLAN und die RestAPI funktioniert weiterhin problemlos.

Tesla und PRTG

Damit eröffnet sich mir natürlich ein Weg. die Box über PRTG oder andere Lösungen zu überwachen. Der eingebaute PRTG JSON-Sensor kann direkt die Daten abrufen.

Danach muss ich natürlich die URL zur REST-API eingeben. In meinem Fall nutze ich die "Vitals" API unter "http://<IP address>/api/1/vitals" und gebe in PRTG dann die gewünschten Knoten als Kanal an. Wenn ich einfach "Grid_v" angebe, dann ermittelt der Sensor die Versorgungsspannung.

Allerdings habe ich damit nur genau einen Wert in einem Graph und wenn ich mehrere Werte erfassen möchte, dann sollte das nicht durch viele einzelne Sensoren erfolgen. Komplexere Abfragen mit mehreren Kanälen kann ich aber über den "PRTG Manual: REST Custom Sensor" einrichten.

Dazu brauche ich aber neben der URL auch ein "Template" welche die Werte auf Kanäle mappt. PRTG liefert zwar schon einige Vorlagen mit, aber natürlich kein Template für einen "TeslaWallConnector gebaut.

Template für Tesla Wall Connector Gen3
teslawallconector.template.txt
Bitte die Datei im Programmverzeichnis speichern. Bei mir ist das "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\rest\teslawallconnector.template"

Das Template liest nicht alle Werte ein. Die Spannung der Pilot-Leitung habe ich mir gespart und auch die current_alerts habe ich noch nicht als Message eingepflegt.

Wenn ich dann einen neuen Rest-Sensor anlege, muss ich nur noch die Abfrage "/api/1/vitals" eingeben und das vorbereitete Template auswählen.

Nach kurzer Zeit sehe ich schon die ersten Werte:

Hier lädt ein Fahrzeug einphasig mit 13,7A, also ca. 3kWh/h, was für ein PlugIn-Fahrzeug (PEHV) schon die Obergrenze ist. Wie "genau" die Messwerte sind, steht aber auf einem anderen Blatt. Nur weil per REST hier Nachkommastellen geliefert werden, sollte man da nicht blind drauf vertrauen. Wenn ich mir die Wert aber ohne Dezimalstellen anzeigen lasse, dann rundet PRTG anscheinend ab und aus 49,99 Hz werden dann 49Hz. Über einige Tage sieht man schon mehr:

Der rote EVSE-Status zeigt am besten an, wann kein Fahrzeug verbunden (1), am Laden (19) oder nur verbunden (8) ist. Indirekt kann dies aber auch an der Temperatur des Type-2-Steckers erkannt werden, welche bei der Ladung doch merklich ansteigt aber ansonsten die Außentemperatur liefert. Der hier angeschlossene PEHV (BMW 225xe Erfahrungsbericht) lädt an der Tesla Wallbox 1-phasig mit 13A in ca. 2,5h komplett nach und der Griff erwärmt sich dabei von 10 Grad C Aussentemperatur auf 19 Grad C. Nicht kritisch aber merklich.

Hier dann noch mal das Ende einer Ladung mit vielen Linien

Die violette Linie zeigt den abnehmenden Ladestrom bei den letzten 10 Minuten. Die grüne Linie die Temperatur des Steckers. Interessant auch, dass durch das Laden die an der Wallbox gemessene Spannung um ca. 10 Volt von ca. 220V wieder auf 230V ansteigt was gefühlt recht viel ist. 10 Volt bei 13A sind ca. 130W Verlustleistung für die ca. 20-30m Zuleitung (Leider nur 5x2,5qmm aber laut Elektriker erlaubt)

Temperaturüberwachung

Die Wallbox hat vier per REST auslesbare Temperaturpunkte, die alle mit einem "_c" enden und in Celsius gemessen sind. Die Werte kommen mit Dezimalstellen, wobei ein "Komma" der Trenner ist.

  • handle_temp_c
    Hier misst die Wallbox die Temperatur des Steckers am Fahrzeug. Wenn ich den Stecker länger in der Hand halte, steigt die Temperatur. Auch beim Laden ist gut zu sehen, dass die Temperatur durch den Strom und Kontaktwiderstand etwas ansteigt. Pfiffige Idee, hier einen Schutz gegen schlechte Kontakte einzubauen. Ich weiß nicht, wann die Wallbox die Ladung unterbricht oder drosselt und ob andere Wallboxen das auch machen
  • pcba_temp_c
    PCB steht eigentlich in der Elektronik für "Printed Circuit Board". Da hat Tesla wohl einen Fühler auf der Leiterplatte, um frühzeitig Fehler zu erkennen.
  • mcu_temp_c
    Wenn man "mcu" mit "Microcontrollerunit" übersetzt, dann ist das wohl die Temperatur des Steuerungsprozessor

Wenn die Wallbox nicht gerade ein Auto lädt, dann ist die Temperatur des Steckers recht zuverlässig die Lufttemperatur ums Auto bzw. der Wallbox. Es gibt aber einfachere und günstigere Möglichkeiten, die Außentemperatur zu messen.

evse_state und config_status

Über die Schnittstelle bekomme ich verschiedene Statusmeldungen.

  • vehicle_connected
    Damit kann ich erkennen, ob die Wallbox ein Auto erkannt hat. Das bedeutet nicht, dass auch geladen wird
  • contactor_closed
    Dieser Werte bedeutet, dass das Lastrelais geschaltet ist und das Fahrzeug versorgt wird. Es obliegt aber dem Auto, die Ladeleistung zu steuern.
  • config_status
    Ich nehme an, dass hier die Box verschiede Statuus der Konfiguration ausgibt, z.B. ob sie Verbindung zum Internet hat oder nicht. Vielleicht auch ausstehende Firmware-Updates. Leider habe ich keine Liste und kann nur die bei mir schon aufgetretenen Werte dokumentieren.
config_status Bedeutung

0

Fahrzeug wird geladen (1-phasig 13A)

5

Fahrzeug verbunden und voll (Verriegelung egal)

  • evse_state
    Auch zu diesem Status habe ich keine Details und dokumentiere hier nur die Zustände, die ich gesehen habe.
evse_state Bedeutung

0

Wallbox startet

1

Kein Fahrzeug angeschlossen (LED blinkt grün. eventuell kein Internet)

2

Angeschlossen und nicht bereit

3

 

4

Angeschlossen und bereit

5

 

6

 

7

 

8

Fahrzeug angeschlossen und voll geladen (Verriegelung egal)

9

Zum Laden bereit, warten auf Fahrzeug
Feedback eines Tesla-Fahrers, der eine Ladung im Tesla geplant aber diese noch nicht angefangen hat

10

Lädt Leistungsreduziert. Die Wallbox erkennt gegen Ende des Ladevorgangs dass das Auto nicht mehr die komplette Leistung abruft. Bei meinen 1-pasigen PEHV

11

11 -> Ladung mit 3 Phasen a 16 Ampere (11kW)

Vielleicht finden Sie ja noch andere Werte und berichten mir. Es könnte durchaus sein, dass z.B. evse_state den LED-Status anzeigt.

Handbuch Wall Connector Gen 3
https://www.tesla.com/sites/default/files/support/charging/Gen_3_Wall_Connector_Manual_German.pdf
Seite 29/30 enthält die verschiedenen Fehlercodes

 Die genaue Bedeutung der Werte von "Config Status" und EVSE Status" sind mir noch nicht bekannt.

Der nächste Schritt ist dann die Information an die Personen, wenn sich ein Zustand ändert. So könnte ich den Status von "Vehicle Connected" überwachen, um beim Anstecken oder Abstecken informiert zu werden.

Weitere Benachrichtigungen kann ich natürlich auch noch definieren. So könnte ich ein beliebiges Programm ausführen, welches z.B. nach dem Abschluss einer Ladung die "nachgetankte" Energiemenge erfasst und speichert.

Es ist gut zu erkennen, wann ein Fahrzeug angesteckt wurde und die Ladung startet. Wenn das Fahrzeug "voll" ist, wechselt der Status des Relay auf "0". Über den "Difference"-Sensor kann ich auch die pro Zeiteinheit geladene Energie erfassen. Ebenso gut sind aber auch die Grenzen der Messwerte zu erfassen.

Allerdings kann dieser Sensor immer nur genau eine REST-URL erfassen. Wenn ich nun auch noch die WiFi-Kennzahlen (http://<IP address>/api/1/wifi_status) oder die Langzeitdaten (http://<IP address>/api/1/lifetime) erfassen will, braucht es weitere Templates und Sensoren.

Die Wallbox misst auch die übertragene Energiemenge. Insofern wäre sogar eine Abrechnung denkbar. Allerdings ist kein MID-zertifizierter Zähler verbaut, so dass die Finanzämter diese Schätzung vermutlich nicht akzeptieren. Ich werde später einmal die Werte der Wallbox mit dem MID-Zähler im Anschlusskasten vergleichen.

Weiterentwicklung

Mein Auto sagt mir schon über eine App, dass eine Ladung begonnen und beendet wurde, aber die Wallbox macht das natürlich nicht. Auch Tesla-Fahrer haben eine App für ihr Auto aber nicht für die Wallbox. Natürlich könnte Tesla so eine Funktion per App bereitstellen, da die Wallbox ja mit dem Tesla Backend kommuniziert und man als Inhaber der Wallbox sich z.B. über eine Registrierung und die Seriennummer der Wallbox verbinden könnte. Das gibt es aber aktuell (Okt 2021) noch nicht. Damit eröffnen sich natürlich ganz eigene Dinge.

  • Eigene App im LAN
    Ich könnte mir eine App schreiben, die im LAN direkt nach einer Wallbox sucht oder nach Angabe der IP-Adresse die Daten der Wallbox anzeigt und Änderungen am Status erkennt. Könnte ein interessantes "Progressive Web App"-Projekt werden.
  • Wallbox mit Haussteuerung
    Natürlich könnte auch eine der vielen Hausautomatisationsprojekte die Daten der Wallbox einlesen und über die entsprechend vorhandene App anzeigen, z.B. mit Node-RED als Mittler. Damit wäre auch eine Einbindung in MQTT/SYSLOG/Grafana etc. möglich.
  • Gateway zum Messenger
    Tesla hat aktuell keine App und die URL der Box möchte ich auch auch nicht aus dem Internet erreichbar machen. Ich kenne zwar nur den Weg die Daten zu lesen aber nicht zu schreiben. Aber das bedeutet ja nicht, dass es nicht doch möglich wäre. Aber man könnte ja einen ESP8266/ESP32 nutzen, der die Daten zyklisch abfragt und irgendwo hin sendet, z.B. als Bot an Microsoft Teams, Telegram, Signal u.a.
  • Eigenes (PRTG) Skript
    Vielleicht baue ich mir aber dennoch noch ein eigenes PowerShell-Script, welches z.B. die Moment erfasst, wenn eine Ladung zu Ende ist oder das Fahrzeug an/abgesteckt wird und diese Vorgänge in einem eigenen Protokoll speichert oder per SYSLOG bzw. SMTP versendet.
    Das kann sogar schneller kommen, denn Paessler hat den Sensor "REST Benutzerdef" schon abgekündigt.

Insbesondere ein Logging der "relevanten Änderungen" als eine Art Tagebuch oder Datalogger finde ich interessant, da die Datenmenge gering und die Aussagekraft höher ist als eine minütliche Erfassung des immer gleichen Status.

Bislang reicht mir aber die Erfassung mit PRTG und für die eichrechtskonforme Erfassung des Verbrauchs habe ich im Sicherungskasten einen MID-Zähler.

Weitere Links