rtrbt

Nein die Bibliotheken musst du nicht selbst bauen. Die Anleitung im lib_builder-Ordner ist eher kurz weil das eher eine Erinnerungsstütze für mich ist. Eigentlich sollte pio -e prepare wie gehabt die Bibliotheken runterladen und nach esp32-firmware/software/packages packen (wo sie bei dir auch schon liegen sollten?). Der einzige Unterschied ist jetzt, dass davor platformio eine Kopie der jeweiligen Unterordner (also z.B. esp32-firmware/software/packages/arduino-esp32-warp2-2.0.2 gezogen hat und jetzt diese per Symlink reinzieht. Das spart etwas Platz und führt vorallem dazu, dass man Dinge ändern kann und die sofort in die Firmware kompiliert werden ohne Verrenkungen.

Offiziellen Support gibt es nicht. Du brauchst zwingend die Firmware-Modifikation, damit die drei Schütze geschaltet werden, den Code übernehmen wir aber nicht -> Du brauchst die Firmware mit den Änderungen von mattsches, die er (oder irgendjemand anderes, ist ja alles open source) zumindest gegen die jeweils aktuelle Version einmal kompilieren muss und gegebenenfalls anpassen, falls wir die Interna verändert haben. Wir helfen natürlich, wenn es da Fragen gibt, aber sozusagen ohne Erfolgsgarantie.

Du kannst (wenn du das nicht in der brickd.conf umkonfiguriert hast) von anderen Rechnern aus auf einen Brick Daemon zugreifen. D.h. funktioniert einfach, wenn du in deiner Software "localhost" auf die IP oder den Hostnamen des anderen Rechners änderst, an dem alle Bricks angeschlossen sind. (auf dem anderen Rechner muss natürlich auch Brick Daemon installiert sein) Alternativ kannst du WiFi- oder Ethernet-Extensions benutzen oder alle Stapel mit RS485-Extensions zusammenschalten.

Hm da habe ich gleich was gelernt, danke :) https://httpwg.org/specs/rfc7230.html#header.content-length sagt Der Ladetracker benutzt Transfer-Encoding: Chunked damit der ESP nicht das ganze Ladelog gleichzeitig im RAM halten muss. Die Content-Length wird gesetzt, für den Fall dass das Log groß ist und die Netzwerk-Verbindung langsam. Dann kann der Download ein paar Sekunden dauern. Zumindest die Browser verstehen das und man bekommt eine sinnvolle Fortschrittsanzeige. Da jetzt aber der Normalfall ist, dass man das Ladelog über das Webinterface runterlädt, dass die Binärdatei in Javascript noch in eine CSV umbaut, sieht man sowieso die Browser-Fortschrittsanzeige nicht. D.h. ich nehme das Setzen der Content-Length einfach raus, dann müsste es in Node-Red mit der nächsten Firmware auch funktionieren: https://github.com/Tinkerforge/esp32-firmware/commit/4b21a005257d08c44ac553315b744aff5da9532f

Zumindest den Teil dass du per MQTT die Stromzählerwerte setzen kannst haben wir schon: https://www.warp-charger.com/api.html?v=2#meter_state_update (und die Funktionen danach) Den Software-Support für den Umbau auf drei Schütze, die dann nicht direkt vom EVSE gesteuert werden, werden wir nicht übernehmen. @mattsches weil ich gerade nochmal über den Code gescrollt bin: Du solltest hier: sicherheitshalber https://www.tinkerforge.com/en/doc/Software/Bricklets/IndustrialQuadRelayV2_Bricklet_uC.html#c.tf_industrial_quad_relay_v2_set_monoflop statt set_value verwenden, zumindest für die Channels bei denen du das Schütz durchschaltest. Das hat den Vorteil, dass falls der ESP aus irgendeinem Grund abschmiert oder hängt, das Quad Relay abschaltet, wenn der Monoflop abgelaufen ist.

Genau.

Habe mal den Hardware-Entwickler gefragt, das Netzteil, dass die 12V für den Ladecontroller macht, funktioniert bis auf 85V runter, d.h. das sollte es nicht sein. Nur wenn du Lastmanagement machst. Genau, dann würde die Wallbox das als 2,7k interpretieren, dementsprechend das Schütz abschalten und auf State 2 gehen.

Wenn der Taster nicht angesteckt ist, denkt die Box permanent, dass er gedrückt wäre. Das ist erstmal nicht schlimm (weil der Ladecontroller auf Knopfdruckänderungen reagiert, d.h. dir wird nicht die ganze Zeit die Ladung abgebrochen), wird mit der nächsten Firmware-Version aber dazu führen, dass die Wallbox ~ 30 Sekunden langsamer bootet. Wenn du willst kannst du, damit der Taster die ganze Zeit gedrückt ist, Pin 3 und 4 der entsprechenden Buchse verbinden.

Was du tun musst hängt davon ab, ob in der neuen Firmware (oder falls du Updates überspringst in irgendeiner zwischen der installierten und der die du neu installieren willst) die EVSE-Firmware aktualisiert wurde. Das erkennst du daran, dass dann im Changelog etwas in Richtung "[Änderung...] (durch Update auf Ladecontroller-Firmware 2.1.6)" steht. Falls das nicht der Fall ist, kannst du: Das esp32-firmware-git pullen (da du keine Änderungen außer der Firmware-Datei haben solltest, müsste das immer klappen) Dann sicherheitshalber ein git checkout warp2-x.y.z machen (Ich tagge immer den Commit, der dem Stand einer veröffentlichten Firmware entspricht. Das sorgt dafür, dass du auf einem definierten Stand bist und nicht ein paar unveröffentlichte Änderungen mitnimmst. Eigentlich sollte die Firmware auf jedem Commit funktionieren, aber bei größeren Änderungen kann das zwischenzeitlich auch mal nicht klappen.) Deine Firmware sollte dann noch in esp32-firmware/software/src/modules/evse_v2 liegen Die ESP-Firmware neu kompilieren und flashen Wenn es eine neue Ladecontroller-Firmware gibt, musst du folgendes davor in evse-v2-bricklet/ tun: Mit git stash deine Änderungen bei Seite legen Mit git pull unsere Änderungen holen Dann git checkout vX.Y.Z damit du auch hier auf dem Stand einer veröffentlichten Firmware bist. Deine Änderungen wieder anwenden mit git stash apply (Falls das nicht klappt musst du nachsehen, was sich an der Code-Struktur geändert hat) EVSE-Firmware neubauen und wieder nach esp32-firmware/software/src/modules/evse_v2 packen Dann die Schritte von oben um die neue ESP-Firmware zu bauen

Ziemlich groß: https://github.com/Tinkerforge/evse-v2-bricklet/blob/90b0d370b231c3ca5b2ce9f093d318d988541c94/software/src/iec61851.c#L42-L56 Also alles < 1790Ω betrachten wir als 880Ω (State C = Laden), alles über 1790Ω als 2700Ω (State B = Auto will keinen Strom). Wenn dir einmal pro Sekunde reicht könntest du das z.B. über MQTT machen, oder mit einem Script dass http://warp2-xyz/evse/low_level_state abfragt. Das wäre prinzipiell möglich, würde ich aber nicht mitten beim Laden erwarten. Wäre trotzdem interessant, wenn du das mal loggst. Das ist absichtlich darauf ausgelegt, dass man theoretisch ohne Digitaltechnik auskommt, siehe auch hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung Hm vielleicht ein Problem mit der Antennenausrichtung bzw. anderen Netzen auf dem Kanal? Ist das ein Repeater? Vielleicht versucht die Box sich zu einem anderen AP deines Netzes zu verbinden (dann wäre die BSSID-Sperre an). Alternativ: Wenn das nur 80cm sind, kannst du viell ein LAN-Kabel verlegen. Was mir in einem der EVSE-Logs aufgefallen war, ist dass die Spannung auf L1 relativ niedrig ist, wenn er lädt. Meine mich an 216V erinnern zu können. Vielleicht bricht die Ladung ab wenn die Spannung unter irgendeinen Grenzwert fällt?

Hast du den Dateinamen in z.B. bricklet_evse_v2_firmware_2_1_6.zbin geändert und die Firmware die da schon liegt z.b. in .zbin.old umbenannt? Der Bauprozess erzeugt die evse_v2_bricklet_firmware_bin.embedded.h/cpp automatisch aus einer Firmware-Datei die auf das Schema passt. Ein Trick aus der Praxis damit man mit den Firmware-Dateien nicht durcheinander kommt: Die Versionsnummer ist in evse-v2-bricklet/software/src/configs/config.h hinterlegt. Für Entwicklungs-Firmwares kannst du die FIRMWARE_VERSION_REVISION auf z.b. 99 ändern, die Firmware neu kompiliern und als bricklet_evse_v2_firmware_2_1_99.zbin nach esp32-firmware/software/src/modules/evse_v2/esp32-firmware/software/src/modules/evse packen. Das reduziert die Wahrscheinlichkeit, dass du durcheinander kommst welche Firmware jetzt gerade eingebettet wird/auf dem EVSE läuft. Das Webinterface kann deutsch und englisch und zeigt dir die Sprache an, die dein Browser als die bevorzugte angibt. Da sollte also zwischen den Firmwares kein Unterschied bestehen, wenn du nicht gerade deine Browser-Einstellungen geändert hast. Du kannst mit der Entwicklerkonsole deines Browsers nachsehen welche Sprachen er anfordert, indem du navigator.languages eingibst. Bei mir kommt z.B. Array(3) [ "de", "en", "en-US" ] als Ergebnis, also wird Deutsch vor Englisch bevorzugt.

Hast du im Ereignislog Ausgaben dieser Art? Charger state changed from 0 to 2 Das ist der Fahrzeugstatus, also 0: Nicht angeschlossen 1: Angeschlossen aber Wallbox verbietet das Laden (rein technisch: Die Wallbox ein CP-PWM von 0% an) 2: Angeschlossen, Wallbox erlaubt das Laden (CP-PWM >= 10%), Auto müsste jetzt damits losgeht 880Ω anlegen 3: Lädt: Auto hat 880Ω angelegt, Schütz ist geschaltet 4: Fehler D.h. wenn dein Ladevorgang mit einem Charger state changed from 3 to 2 endet, dann hat das Auto wieder 2,7kΩ angelegt, also keinen Strom mehr angefordert -> Daraufhin hat die Box das Schütz abgeschaltet. Wenn der Ladevorgang mit Charger state changed from 3 to 1 endet, dann hat die Box den Ladevorgang beendet. Bezüglich der Stromtests: Wir haben das mit dem Oszilloskop nochmal nachgezogen, das CP-PWM passt zu dem Wert den der Ladecontroller ausgibt. Das hängt natürlich (bzgl. Flankensteilheit usw.) auch davon ab, wie dein Auto genau misst. Aber: Was auf jeden Fall seltsam ist, ist dass du nie über die 15,7A kommst. Ich habe spontan nichts über das Ladeverhalten von dem Aiways U5 finden können, aber kann es sein, dass die Regelung über 16A dann nicht mehr linear ist sondern z.B. erst ab 25A die Ladeleistung erhöht wird? Wie hast du bei dem Ladeziegel gemessen, dass das Auto dann wirklich 16A zieht? Auslesen ja (siehst du auf der Stromzählerseite wenn du die Details aufklappst) Nachregeln nein: Das Limit nachregeln wenn ein Auto weniger zieht ist extrem gefährlich, falls es sich nicht linear verhält. Wenn du willst kann ich dir kurz ein Python-Script schreiben, dass von 6 bis 20 Ampere in 0,1A Schritten abfährt, immer kurz wartet (damit das Auto reagieren kann) und dann Zählerwerte und PWM von der Box liest. Aber ich erwarte nicht, dass da mehr rauskommt, als das was du schon gemessen hast.

Noch ein Einwurf: Wenn du /home/andreas/git/evse-v2-bricklet/software/build gelöscht hast, sieh in /home/andreas/git/evse-v2-bricklet/ mit git status mal nach, dass du nicht noch andere Änderungen hast.

Aber auf /recovery kommst du? Dann zieh mal einen Debug-Report. Bei den Bricks auf meinem Tisch funktioniert das anstandslos.

You can enumerate all connected bricks and bricklets without knowing their UIDs: https://www.tinkerforge.com/de/doc/Software/IPConnection_Python.html#enumerate

Das können wir machen (als Compile-Flag in der EVSE-Firmware bzw. ein Define das gesetzt sein muss). Das führt natürlich trotzdem dazu, dass du bei jedem Wallbox-Firmware-Update, das eine neuere EVSE-Firmware mitbringt die EVSE-Firmware neu kompilieren und flashen musst. Persistent bzw. ohne dass du "manuell" eingreifen musst würde ich das nicht bauen wollen. Der DC-Schutz ist immerhin ein relativ wichtiger Sicherheitsmechanismus.

Wir haben ein paar Ideen, wie man den Lastmanager effizienter machen kann, dafür bräuchte er dann auch die Zählerwerte der gesteuerten Boxen. D.h. langfristig könnte das kommen ;) Sieh dir mal charge_manager/config an. Damit kannst du von Namen auf Hosts mappen.

Meinst du den aktuell erlaubten Strom pro Wallbox oder den aktuell verbrauchten Strom den der Stromzähler liest? Ersteres bekommst du aus charge_manager/state (jeweils allowed_current). Den wirklich gezogenen Strom musst du von den Wallboxen selbst runterkratzen. Das Lastmanagement benutzt die Information nicht, weswegen wird das Stand jetzt nicht zwischen den Boxen kommuniziert.

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.