rtrbt

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.Ä.?

So weit so gut. Der ESP ist konfiguriert, dass er sich zu deinem WLAN verbindet, den Access Point aber offen lässt. Du könntest noch testen, ob es klappt, wenn du mit deinem Mac auch in deinem WLAN (nicht dem des ESPs) bist und dann versuchst dich per Brick Viewer und mit dem C-Programm zu 192.168.178.55 bzw. esp32-Zj7 zu verbinden. Wenn du aber per Brick Viewer und per Browser auf den ESP zugreifen kannst, kann es ja eigentlich kein reines Netzwerkproblem sein. (Bin kein macOS-Experte) Musst du dem Programm eventuell Zugriff auf das Netzwerk erlauben o.Ä.? Ich habe hier mit einem Mac getestet und musste das nicht, aber vielleicht ist dein Setup subtil anders. Falls du mit z.B. Wireshark umgehen kannst, könntest du einen Blick auf den Verbindungsaufbau werfen. Du kannst auch mal andere Bindings testen, falls du z.B. Python installiert hast. Vielleicht ist es ein C-Bindings-spezifisches Problem.

Das ist nur das Event-Log. Im Debug-Report steht zusätzlich noch die Konfiguration des ESPs. Dann ist der ESP darauf konfiguriert sich zu deinem WLAN zu verbinden. Da aber die Zeile "Network connected. Stopping soft AP" fehlt sollte der Access Point des ESPs weiterlaufen, d.h. du hast ihn nicht auf "nur als Fallback" konfiguriert.

Versuch mal esp32-xyz statt 10.0.0.1. Aufs Webinterface kommst du noch? Falls ja, zieh unter System->Ereignis-Log mal einen Debug-Report und lad ihn hier hoch. Ich glaube nicht dass da was hilfreiches drinsteht, aber man weiß ja nie ;)

Moment. Ist dein Mac im WLAN des ESPs oder sind beide im WLAN deines Routers? Die IP 10.0.0.1 funktioniert nur wenn du mit dem Access Point des ESPs verbunden bist (oder sehr ungewöhnliche statische IPs konfiguriert hast). Statt 10.0.0.1 sollte übrigens auch (egal in welchem Netz du bist, solange es bei Mac und ESP das selbe ist) der Hostname warp2-xyz [Edit: esp32-xyz, nicht alles ist eine Wallbox] funktionieren (siehe Aufkleber auf dem ESP)

Der Code sieht soweit korrekt aus. Mir sind aber keine Probleme mit dem ESP32 und macOS bekannt. Ein paar Ideen: Teste sicherheitshalber mal das unmodifizierte IP-Connection-Enumerate-Beispiel (die Host musst du natürlich ersetzen, der Rest kann so bleiben) Hast du mehrere Brick Viewer-Instanzen offen? Der ESP erlaubt im Moment maximal vier TFP-Verbindungen (erhöhen wir mit der nächsten Firmware auf 10) Welche Version von Bindings, ESP-Firmware und Brick Viewer verwendest du?

Moin, Nein kannst du nicht. Du kannst keine USB-Geräte an die Wallbox anschließen, da ist "nur" ein Mikrocontroller, kein PC, Raspberry Pi o.Ä, verbaut. Wenn es M-Bus zu USB gibt, findest du eventuell auch einen Konverter auf Ethernet bzw. WLAN. Dann kannst du die Daten beliebig auslesen.

Die Fehlermeldung wenn das Update nicht sauber durchläuft ist auch zu leicht zu übersehen. Habs mir mal aufgeschrieben: https://github.com/Tinkerforge/esp32-firmware/issues/148

Firmware: WARP2 2.0.7 Weitere WebSocket-Verbesserungen vorgenommen Behoben, dass fälschlicherweise ein SDM630 detektiert wurde, wenn kein Stromzähler angeschlossen ist (durch Update auf Ladecontroller-Firmware 2.1.6) Download: WARP2 2.0.7

Moin, Das klingt verwirrend. Eventuell ein Browser-Cache-Problem? Versuch z.B. mal (je nach Browser) STRG+F5. Edit: Was für einen Browser benutzt du?