rtrbt

Stand jetzt geht das nicht. Ich hatte das vor längerem versucht zum Laufen zu bekommen, das ist aber leider komplex, deshalb hatte ich da nicht mehr Zeit investiert. https://github.com/Tinkerforge/esp32-firmware/issues/14 ist das Issue dazu. Unabhängig davon ist der Durchsatz des WLAN-APs aber auch eher schlecht (selbst wenn gerade nicht Bugs wie dieser https://github.com/espressif/arduino-esp32/issues/6706 auftreten kommt man nur auf 20 MBit/s) Eventuell lohnt es sich also einen kleinen WLAN-AP mit zwei Ethernet-Ports (einen für die Verbindung nach außen, einen für die Wallbox) in die Tiefgarage zu hängen. Versprechen kann ich das nicht, aber ich gehe stark davon aus. Ich arbeite gerade an der OCPP-Implementierung.

Ah das erklärt einiges. Dann musst du wie oben beschrieben dir eine Firmware für den Ladecontroller (das EVSE 2.0 Bricklet) kompilieren. Nach dem Aufsetzen der Build-Umgebung kannst du dir hier https://github.com/Tinkerforge/evse-v2-bricklet den Quellcode der EVSE-Firmware besorgen und dann software/src/dc_fault.c patchen. Auf den ersten Blick musst du nur sicherstellen, dass dc_fault.state immer auf DC_FAULT_NORMAL_CONDITION bleibt. Die Firmware kannst du dann mit make im software-Verzeichnis kompilieren (das benutzt automatisch die Docker-Build-Umgebung wenn du alles richtig eingerichtet hast), dann solltest du in software/build eine evse-v2-bricklet-firmware.zbin bekommen. Die Firmware musst du dann auf den Ladecontroller bekommen. Dafür gibt es folgende Möglichkeiten: Du kannst das EVSE Bricklet an einen ESP Brick anschließen, dann über http://[IP-deines-ESP-Bricks]/hidden_proxy den Proxy-Modus aktivieren und dich dann mit Brick Viewer zu eben dieser IP verbinden. Da sollte das EVSE als Unknown Bricklet auftauchen. Unter Updates/Flashing -> Bricklets kannst du als Firmware "custom" auswählen, dann mit Browse deine FIrmware auswählen und flashen Falls du einen Master Brick oder RPi HAT hast kannst du das EVSE Bricklet direkt an deinen PC anschließen und genauso flashen (dann unter localhost statt der IP des ESPs) Die robusteste Variante ist, deine EVSE-Firmware in eine Wallbox- (also ESP-)Firmware einzubetten. Dazu brauchst du das ganze PlatformIO-Setup, einen Klon von https://github.com/Tinkerforge/esp32-firmware und packst die evse-v2-bricklet-firmware.zbin nach esp32-firmware/software/src/modules/evse_v2/ Da müsste schon eine bricklet_evse_v2_firmware_x_y_z.zbin liegen, die musst du überschreiben. Beim Bauen der Wallboxfirmware wird eine .zbin mit exakt diesem Namensschema automatisch eingebettet. Beim Starten prüft die Wallbox-Firmware, ob auf dem EVSE Bricklet eine Firmware mit der erwarteten Versionsnummer läuft (das x_y_z aus dem Dateinamen) und wenn das nicht passt wird das Bricklet auf die eingebettete Firmware umgeflasht. Du kannst aber auch (falls auf dem EVSE schon eine Firmware mit der selben Version läuft) über das Webinterface unter Ladecontroller->Low-Level-Zustand ganz unten das neuflashen erzwingen. In allen Fällen musst du mit deiner gepatchten EVSE-Firmware dann mit dem "upstream", lies uns Schritt halten, falls du die Wallbox-Firmware aktualisierst. Sonst verlierst du deine EVSE-Änderungen falls wir eine neuere Firmware einbetten.

Das dürfte schon immer so gewesen sein. Auch bei den alten Firmwares reagieren evse/current_limit und evse/start_charging nicht auf HTTP GET (das ist was dein Browser macht wenn du die URL aufrufst) sondern nur auf HTTP PUT. Bei den Node-RED HTTP-Knoten kannst du die Method aber einstellen.

Das ist die relevante Information ;). Ich hätte für den Anfang auch nur auf das Core Profile abgezielt. OCPP kann noch durch weitere Profiles erweitert werden, z.B. für Reservierungen, Lastmanagement, Authorisierungscaches usw. die wir ggfalls nachziehen können. Der aktuelle Plan ist aber, sobald das "minimale" Feature-Set des Core Profiles läuft mal eine Alpha-Version zu veröffentlichen und die gegen verschiedene Backends zu testen. Dauert aber wie gesagt noch etwas.

Verständlich. Aber wenn man nach der Menge der Anfragen geht sind andere Features (allem voran OCPP an dem ich gerade arbeite) wichtiger.

Nein, die Box startet absichtlich neu. Es fehlte aber ein Hinweis in dem Modalfenster, dass sich öffnet wenn man auf Löschen klickt. Den habe ich mal eingebaut.

Immer gerne :) Im Idealfall gibst du öfter als alle 30 Sekunden den Strom vor. Dann kannst du den Watchdog aktivieren, der, falls deine Steuerung ausfällt, den verfügbaren Strom auf den "Voreingestellt verfügbarer Strom" zurücksetzt. Den kannst du dann z.B. auf 6A stellen, damit falls deine Steuerung ausfällt du immer noch laden kannst (dann möglicherweise mit Netzbezug). Du kannst ihn auch auf 0A setzen, dann werden alle Ladevorgänge gestoppt falls deine Steuerung ausfällt. Wenn du den Strom sehr hochfrequent aktualisierst sollte auch nichts passieren: Der Lastmanager regelt alle 10 Sekunden, ggfalls. gehen also Zwischenwerte verloren, was ja aber nicht schlimm ist. Wenn du kleine Leistungsänderungen regelst, kann es sein, dass die angeschlossenen Autos nicht so genau nachziehen, wie man das gerne hätte. Das haben die EVCC-Leute für ein paar Autos ausprobiert: https://github.com/evcc-io/evcc/discussions/3261 Typischerweise dauert es auch ein paar Sekunden (ich glaube die Spezifikation schreibt < 5 Sekunden vor), bis ein Auto auf einen geänderten Ladestrom reagiert, zusätzlich zu den bis zu 10 Sekunden Latenz durch das Regelintervall des Lastmanagers.

Doch der Fehlerstrom-Fehler bricht den Ladevorgang ab. Den würdest du ja aber nur erzeugen, wenn du die Fehlerstromüberwachung (Hardware!) aus der Wallbox ausbaust. Ich meinte, dass du einfach die (soft- und hardwareseitig!) unmodifizierte Wallbox hinter einem Typ-B-FI betreiben kannst. D.h. es ist garnicht notwendig, die Fehlerstromüberwachung auszubauen.

Es ist doof :D Die Wallbox sagt dem Auto per PWM z.B. "Es sind gerade 10,6 Ampere verfügbar" und das Auto darf dann bis zu 10,6A auf allen Phasen ziehen, muss aber nicht. Das würde funktionieren. Wenn es mal daneben trifft, (weil z.B. ein Auto spontan von 1 auf 3phasig wechsel, was theoretisch geht, aber mir unbekannt wäre, dass es das gibt) wäre das in deinem Setup ja nicht sehr schlimm, dann würdest du kurz mehr Strom aus deinem Hausanschluss ziehen und der Regelkreis korrigiert dann. Das geht aber z.B. nicht wenn die Lastmanagement benutzt wird um sicherzustellen, dass ein Hausanschluss nicht überlastet wird. Du kannst dann auf Nummer Sicher gehen und den "maximal verfügbaren Ladestrom" beim Lastmanagement-Master auf das Maximum, was die Leitungen und der Hausanschluss hergeben, konfigurieren, damit selbst wenn dein Regelkreis durchdreht nichts passiert.

Das stimmt. Die Verteilung ist immer auf alle Phasen und strombezogen (der Kommunikationskanal mit dem Auto geht auch über Ströme) Grundlegend kann der Lastmanager nicht Strom zwischen Phasen verteilen. Wenn du z.B. 16 Ampere pro Phase zu verteilen hast, kannst du nicht 24 Ampere auf eine Phase und dafür nur 12 auf eine andere legen. Wenn du dir sicher bist, was dein Auto tut, dann kannst du dir das /3 sparen und entsprechend 4000 / 230 ~ 17 Ampere setzen. Das ist nur nichts was wir in der Firmware tun können, weil es keine Garantie dafür gibt, dass ein Auto nicht spontan doch dreiphasig lädt bzw. du nicht irgendwann ein anderes Auto anschließt, dass dreiphasig lädt. Eine Variante das "sicher" zu machen wäre mit einer 1p-3p-Umschaltung, wie es z.B. unser Energie-Manager können soll.

Ah sorry, war gerade dabei auf deine Mail zu antworten. Dann lieber hier ;) Erstmal grundlegend: Wenn du einen Typ-B FI hast dann brauchst du die interne Fehlerstromüberwachung nicht, du musst sie aber auch nicht ausbauen. Je nachdem ob der FI oder die interne Überwachung eher auslöst fliegt dann eins von beidem, falls ein Fehlerstrom auftritt. D.h. es ist nicht notwendig, die EVSE-Firmware zu patchen. Falls du das trotzdem machen willst: - Du kannst das EVSE Bricklet flashen wenn du wie oben beschreiben den Proxy-Modus des ESPs aktivierst und dich dann zur IP des ESPs (also der Wallbox) verbindest. Das EVSE taucht vermutlich als Unknown-Bricklet auf, Flashen kannst du trotzdem. - Um eine neue EVSE Bricklet-Firmware zu bauen brauchst du den ganzen PlatformIO-Kram nicht. Das ist ein eigener Mikrocontroller mit eigener Firmware. Die Build-Umgebung dafür läuft in Docker, hier gibt es eine Anleitung zum Aufsetzen: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Build_Environment/Tutorial.html#docker - Deine gepatchte Firmware kannst du entweder über Brick Viewer flashen Achtung! Dafür müssen die Versionsnummern passen. Die Wallboxfirmware prüft periodisch ob die passende EVSE-Firmware läuft und flasht selber neu, falls sie nicht passt. - Oder du baust eine neue Wallbox-Firmware, bei der du deine EVSE-Firmware einbettest. Dazu musst du sie (mit passendem Dateinamen) in den esp32-firmware/software/src/modules/evse_v2-Ordner packen.

Hier die Testfirmware. Damit sollte das schnelle Hin-und-Herschalten bei deinem spezifischen Schützfehler behoben sein (falls du das nochmal erzeugt bekommst). Außerdem sollte das PWM jetzt genauer sein, d.h. dein Auto hoffentlich jetzt wirklich mit 16 Ampere laden. warp2_firmware_2_0_7_62bc1f4a_merged.bin

Das könnte man relativ einfach implementieren. Das wiederum ist kompliziert. Wenn du kein Tag vorzeigst startet die Ladung nicht, wenn die Benutzersteuerung aktiv ist. Wenn sie nicht aktiv ist, wird der Ladestart sofort aufgezeichnet (und dem unbekannten Nutzer zugeordnet). Das würde ich auch nur ungern ändern, weil das auf maximale Robustheit ausgelegt ist, damit möglichst nie Ladevorgänge verloren gehen. Prinzipiell ist es so, dass wenn du bestimmten Nutzern Ladevorgänge zuordnen willst, du die Benutzerfreigabe aktivieren musst. Ab dem Punkt können aber keine Ladevorgänge mehr auf den unbekannten Nutzer laufen, d.h. es muss immer ein Tag an die Wallbox gehalten werden. Was du dann machen kannst wäre einen zweiten Nutzer anzulegen für das Standardfahrzeug und dessen NFC-Tag z.B. neben die Wallbox zu legen. Wenn du dann das spezielle Fahrzeug mit eigenem Tag laden willst, hältst du statt dem Standard-Tag entsprechend das andere an die Wallbox. Wenn du ein bisschen programmieren kannst, könntest du dir auch z.B. ein Python-Script schreiben, das über die API prüft, ob ein Fahrzeug angeschlossen ist und wenn z.B. 5 Minuten lang kein Ladevorgang per Tag gestartet wurde, kannst du über die API den Ladevorgang starten. Ja das ist komplett getrennt voneinander. Es ist geplant, dass man künftig wenn die Anmeldung aktiviert ist auch über das Webinterface einen Ladevorgang als der entsprechende Benutzer starten kann. Das ist aber noch nicht implementiert.

Das klingt soweit sinnvoll. Du kannst mir eine PM schreiben, oder eine Mail an info@tinkerforge.com (mit z.B. einen Link auf den Thread). Es wird aber noch etwas dauern, bis die OCPP-Implementierung steht, da kann ich auch gerne einfach hier nochmal bescheid sagen.

In den Logs, die du gemailt hast wiederholt sich die ganze Zeit 2022-06-26 06:09:16,964 Charger state changed from 4 to 3 2022-06-26 06:09:18,105 EVSE: Contactor error 2 2022-06-26 06:09:18,105 EVSE: Error state 4 2022-06-26 06:09:18,986 Charger state changed from 3 to 4 2022-06-26 06:09:19,396 EVSE: Contactor error cleared 2022-06-26 06:09:19,397 EVSE: Error state cleared 2022-06-26 06:09:19,987 Charger state changed from 4 to 3 2022-06-26 06:09:20,943 EVSE: Contactor error 2 2022-06-26 06:09:20,944 EVSE: Error state 4 2022-06-26 06:09:21,011 Charger state changed from 3 to 4 2022-06-26 06:09:22,502 EVSE: Contactor error cleared 2022-06-26 06:09:22,503 EVSE: Error state cleared Das heißt, dass der Ladecontroller das Schütz schaltet aber die Schützüberwachung meldet, dass es nicht durchschaltet. Hast du die Wallbox alle ~ 3 Sekunden klicken hören als sie in dem Fehlerzustand war? Das wäre ein Hinweis darauf, ob das Schütz selbst, oder die Steuerung des Schützes kaputt ist. Das Problem jetzt ist das Gleichstrom-Fehlerschutzmodul, der in einem unbekannten Zustand ist. Unbekannt heißt in dem Fall, dass das Modul einen Status ausgibt, der nicht existieren können sollte: In Summe vermute ich, dass die Wallbox irgendein elektisches Problem hat. Kannst du die Box Stromlos machen, die Frontplatte abschrauben und ein Foto von den Innereien machen? Vielleicht sehen wir da mehr. Das ist in der Tat interessant. Ich habe mal einen Blick ins Debug-Log geworfen, die Wallbox setzt einen Duty Cycle von 26,6%, laut https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung ist die Ladeleistung der Duty Cycle mal 0,6 Ampere. Damit komme ich auf 15,96 Ampere. Vielleicht nimmt es dein Auto sehr genau und betrachtet das als "es sind nicht 16A erlaubt" und nimmt die nächst niedrigere Ladestufe (das ist je nach Fahrzeug teilweise sehr grob). Ich habe mit meinem Kollegen mal darüber geredet, ob wir das PWM genauer machen können.

Was hast du damit genau vor? Die Wallbox-Firmware ist nicht darauf ausgelegt, dass du per Brick Viewer händisch den Ladecontrollerzustand änderst. Das geht prinzipiell (dazu hatte ich hier: etwas geschrieben) und ist ganz praktisch wenn man die Ladecontroller-Firmware selbst modifiziert, aber du kannst die Wallbox damit durcheinander bringen wenn du nicht genau weißt was du tust. Wenn du die Wallbox-Firmware (also die des ESP Bricks mit Webinterface usw.) modifizieren willst dann sollte beim kompilieren mit PlatformIO eine _merged.bin-Datei rausfallen, die du direkt über das Webinterface hochladen kannst. Da musst du also nichts mit dem Brick Viewer machen. Du kannst aber, wenn du einen ESP-Brick per USB angeschlossen hast, diesen mit Brick Viewer flashen, das geht ohne auf Connect zu klicken unter Updates/Flashing -> Brick.

Kannst du hier posten oder an info@tinkerforge.com schicken und an Erik weiterleiten lassen.

Je nachdem in welchem Zustand der ESP Brick war, hättest du noch über die recovery-Seite http://warp2-xyz/recovery z.B. einen Debug-Report ziehen oder die Firmware downgraden können. Mir ist aber nicht ganz klar, wie eine kaputte NFC- oder Benutzerkonfiguration dazu führen kann, dass das Webinterface nicht mehr richtig funktioniert. Da du dir ja eine Entwicklungsumgebung aufsetzt: Falls du das nochmal erzeugen kannst, und überhaupt nicht mehr auf das Webinterface kommst (also auch nicht per /recovery ) schließ den ESP mal per USB an, aber flashe ihn nicht neu. Stattdessen kannst du mit pio device monitor -e warp2 die serielle Konsole aufmachen und ggfalls den Brick per Enable-Button neustarten.

Falls du eins der beiden Probleme nochmal erzeugen kannst zieh mal einen Debug-Report (unter System->Ereignis-Log). Bei dem Ladestart-Problem könnte auch ein Ladeprotokoll hilfreich sein. Das bekommst du wie folgt: Unter Ladecontroller ganz unten auf Start klicken. Wichtig: Webinterface offen lassen, das Protokoll wird im Browser aufgesammelt. Kabel anstecken, warten dass die Ladung nicht anfängt (~ 30 Sekunden sollten reichen) Kabel wieder abziehen auf Stop + Download klicken Die Wallbox gibt dem Auto nur einen maximalen Ladestrom vor, wie viel es dann wirklich lädt ist Sache des Autos. Wirf mal einen Blick auf die Ladestromgrenzen (unter Ladecontroller). Steht da alles auf 16 A oder mehr? 3,1 kW entspricht rund 13,5 Ampere.

Die yaml sieht soweit gut aus. Habe zum Testen nur die IPs und warp2/Wqg geändert und es klappt. Hast du daran gedacht EVCC nach den Konfigurationsänderungen neuzustarten? Was bekommst du an Logausgaben? https://docs.evcc.io/docs/guides/setup/#wie-kann-ich-ein-logfile-zur-fehleranalyse-erstellen

Du musst noch die meter hier aufzählen, also site: title: Mein Zuhause meters: grid: gridmeter pv: pvmeter Die EVCC-Anleitung sollte dahingehend jetzt aktuell sein: https://www.warp-charger.com/evcc.html?v=2#evcc-meter-sim

Einen Termin gibt es noch nicht, ich arbeite aber gerade an der OCPP-Implementierung. Bekommst du über die OCPP-Anbindung bei CityWatt noch Details raus? Also z.B. ob OCPP-J unterstützt wird und ob das Core-Profile reicht? Die Webseite von CityWatt schweigt sich darüber leider aus. Gibt es meines Wissens nicht, das wäre aber auch recht kompliziert.

Moin, Die Anleitung auf unserer Seite ist leider veraltet. Ich nehme mir mal vor, die zeitnah zu aktualisieren. EVCC kann inzwischen die Konfigurationsdatei selbst erzeugen, dazu kannst du evcc configure starten. Ich habe das kurz mit einer WARP Pro getestet und folgendes ausgewählt: Standard (PV System) Mein Gerät ist nicht in der Liste (Nein zu allen Punkten bis Ladepunkt) (Ladepunkt) Standardname (Wallboxwahl) TinkerForge WARP Charger Pro (Firmware v2 installiert) ja (IP-Adresse) Achtung das ist die Adresse des MQTT-Brokers, nicht der Wallbox. 192.168.178.72 (musst du ändern ;) ) (Port) 1883 (Topic) warp/Sx7 (müsste bei dir warp2/Wqg sein) (Zeitüberschreitung) Standardwert Alles danach musst du dir aussuchen Dabei fällt bei mir folgende .yaml raus: # open evcc at http://evcc.local:7070 network: schema: http host: evcc.local # .local suffix announces the hostname on MDNS port: 7070 log: info levels: cache: error interval: 10s # control cycle interval chargers: - type: template template: tinkerforge-warp fw2: true host: 192.168.178.72 port: 1883 topic: warp/Sx7 timeout: 30s name: wallbox1 loadpoints: - title: Garage charger: wallbox1 mode: off phases: 3 mincurrent: 6 maxcurrent: 16 resetOnDisconnect: false site: title: Mein Zuhause meters: Wenn du da den chargers:-Block übernimmst und den Namen wallbox1 auf warp änderst sollte es eigentlich klappen. Edit: Die meter müssen type custom statt default haben und source: script statt type: script. z.B. so: meters: - name: gridmeter type: custom power: source: script cmd: /bin/sh -c 'echo 1000' - name: pvmeter type: custom power: source: script cmd: /bin/sh -c 'echo 10000'

Was der Exception Decoder eigentlich nur tut ist addr2line auszuführen. Ich habe mir dafür ein Python-Script (esp32-firmware/software/decode) geschrieben, dass das selbe auf der Kommandozeile tut. Benutzen kannst du das indem du den Backtrace kopierst und dann im software-Ordner ./decode [dein backtrace] ausführst, also z.B. ./decode 0x4000c341:0x3ffc9ce00x40161c6e:0x3ffc9cf0 0x4011123a:0x3ffc9d50 0x400e891c:0x3ffc9de0 0x4012daa6:0x3ffca470 Das Script läuft standardmäßig gegen die aktuellste Firmware im build-Verzeichnis, du kannst aber mit -f [pfad/zur/elfdatei.elf] mit einer spezifischen Firmware decoden. Das hat noch eine Kurzschreibweise: z.B. -f warp2 nimmt die aktuellste warp2-Firmware, -f esp32 die aktuellste ESP32-Brick-Firmware, die im build-Verzeichnis liegt. ELF-Dateien zu den veröffentlichten Firmwares liegen hier: https://github.com/Tinkerforge/warp-charger/tree/master/firmwares Dafür brauchst du einen JTAG-Adapter und musst dich an ein paar Pins des ESPs dranhängen. Anleitung ist hier: https://docs.platformio.org/en/latest/tutorials/espressif32/arduino_debugging_unit_testing.html#debugging-the-firmware Das hat aber noch nie jemand getestet. Ich kann dir auch nicht garantieren, dass die Schaltung an den Pins nicht das Debuggen stört. Alternativ das gute alte printf-Debugging ;) (logger.printfln bzw. Serial.println falls die Probleme vor der Initialisierung des Event-Logs auftreten.)

Könnte das in einem kurzen Test gerade nicht reproduzieren. Hast du den Benutzer nach dem anlegen auch gespeichert und ihm dann das Tag zugeordnet oder ist das unabhängig voneinander? Wie kommst du aus dem Zustand dann wieder raus? Musst du die Seite neuladen, die Wallbox neustarten, o.Ä.?