rtrbt

Habe mit Schrecken festgestellt wie alt das Thema ist :D Ich sehe mir das mit den CModules die Tage mal an. Eventuell kann man da eine schnelle Lösung finden.

Moin, Ich glaube du und damit dann auch @MatzeTF sind falsch abgebogen. Die ESP32-Firmware zu erweitern ergibt eigentlich nur Sinn, wenn du auch die ganzen Features der Firmware nutzen willst. Webinterface, API usw. Wenn du eine kleine Firmware für einen ESP und ein paar Bricklets schreiben willst, ist es sinnvoller, eine "ganz normale" neue Arduino-Firmware zu schreiben. Die ganze Struktur kannst du dir anlegen wie hier: https://docs.platformio.org/en/latest/integration/ide/vscode.html#setting-up-the-project beschrieben (den Teil kennst du vermutlich, wenn du mit VSCode schon ESP-Firmwares geschrieben hast). Damit du mit den Bricklets kommunizieren kannst, brauchst du dann unsere C/C++-Bindings für Mikrocontroller, die kannst du hier: https://download.tinkerforge.com/bindings/uc/tinkerforge_uc_bindings_latest.zip herunterladen und dann folgende Ordner/Dateien in dein Projekt packen: Den source\bindings-Ordner aus der Zip-Datei in dein Projekt nach src\bindings Aus source\hal_arduino_esp32_brick bzw. hal_arduino_esp32_ethernet_brick (hängt davon ab ob du den Brick mit oder ohne Ethernet gekauft hast) die .h und .cpp (nicht die .ino!) nach src\hal_arduino_esp32_brick Wenn du die Beispiele verwenden möchtest, die zu jedem Bricklet in der Dokumentation (und der Bindings-Zip-Datei) enthalten sind, dann kannst du die .ino-Dateo aus source\hal_arduino_esp32_(ethernet_)brick als main.cpp nach source legen und dir eins der Beispiele daneben legen. Alternativ habe ich das ganze für das E-Paper-Bricklet mal durchgespielt, die Zip im Anhang beinhaltet alles, was du brauchst. esp32_epaper_example.zip

Der konfiguierbare (grüne) Eingang ja, der Abschalteingang hat nur drei Pins. Um einen der Eingänge zu schließen musst du ihn mit GND verbinden. Also beim konfigurierbaren Eingang Pin 2 (IN) mit Pin 4 (GND), beim Abschalteingang Pin 1 mit einem der beiden anderen, die sind beide Masse.

Moin, Das kannst du auf verschiedene Arten umsetzen: Variante 1: Falls die Wallbox relativ weit vom Smart Meter entfernt ist, kannst du den Lastabwurf über einen WARP Energy Manager umsetzen: https://www.warp-charger.com/energy-manager.html Der Energy Manager hat unten am Gehäuse zwei Eingänge, über die du den Ladestrom aller gesteuerter Wallboxen limitieren kannst. Die Kommunikation zwischen Wallbox und Energy Manager läuft übers Netzwerk. Variante 2: Die Wallbox selbst hat am Ladecontroller einen Abschalteingang und einen konfigurierbaren Eingang. Da laut der Vorgaben die Ladeleistung nur anteilig reduziert werden muss, kannst du den konfigurierbaren Eingang verwenden und diesen im Webinterface der Wallbox entsprechend konfigurieren: Die Eingänge findest du am Ladecontroller hier: (grün - konfigurierbarer Eingang, orange - Abschalteingang) Um das Steuerungskabel in die Wallbox zu bekommen musst du ein Loch ins Gehäuse bohren und mit einer Kabeldurchführung abdichten.

Firmware: WARP Energy Manager 1.0.2 Wolkenfilter hinzugefügt Support für PWA-artige Lesezeichen hinzugefügt Monatsgraph zur Energiebilanz hinzugefügt Statistiken zur Energiebilanz hinzugefügt Minimalen Ladestrom für ein- und dreiphasiges Laden aufgeteilt Einstellung des minimalen Ladestroms anhand des konfigurierten Fahrzeugtyps hinzugefügt Verwendung der RTC des Energy-Manager-Bricklets hinzugefügt Füllung für Stromzählerplot hinzugefügt Konfiguration des Web-Interface-Ports hinzugefügt WLAN-Empfangsqualität durch Deaktivierung des HT40-Modus und 11b verbessert Robustheit der Stromzähler-Initialisierung verbessert Robustheit der statischen IP-Konfiguration der LAN-Schnittstelle verbessert Löschen kontrollierter Wallboxen auf der Lastmanagement-Konfigurationsseite repariert Übersetzungen verbessert Zeitzonen-Datenbank aktualisiert Ausgabe der Verbindungsdauer bei Verlust einer LAN-, WLAN-, MQTT- oder WireGuard-Verbindung hinzugefügt Defekte Links auf der Status-Seite entfernt, falls Lastmanagement-Konfiguration geändert, aber nicht angewandt wurde MQTT-Timeout erhöht NetBIOS-Unterstützung entfernt DNS-Cache vergrößert Fehlermeldungen von Texteingabefeldern repariert Längenprüfung von Text- und Passworteingabefeldern repariert Klickbare Links für kontrollierte Wallboxen auf der Statusseite hinzugefügt Prüfung auf duplizierte Wallbox-Hostnamen bzw. IPs in der Lastmanagement-Konfiguration hinzugefügt Auflösung von .local-Hostnamen via mDNS-Scan hinzugefügt Veraltete WLAN-Empfangsqualitäts- und IP-Werte entfernt wenn WLAN-Verbindung verloren wird MQTT-Fehlermeldungen verbessert Download: WARP Energy Manager 1.0.2

Prinzipiell ja, sobald wir die Benutzer für mehr verwenden, als nur zur Freigabe eines Ladevorgangs. Zum Beispiel soll es künftig Administratoren und "normale" Benutzer geben. Das wäre dann auch der Punkt, wo man das Users-Modul für den Energy Manager übernehmen und von der EVSE-Logik trennen würde.

Die Zählerüberwachung sollte auch wenn du die Zählerstände per MQTT schickst funktionieren. Weil die Zählerüberwachung noch nicht veröffentlicht ist, ist sie aber noch nicht gut dokumentiert. Im Endeffekt macht sie folgendes: Alle Stromzählerwerte werden als NaN initialisiert (damit wir unterscheiden können welche Werte nie gesetzt wurden, sei es über MQTT oder einen physisch angeschlossenen Zähler) Wenn der Energie-Wert nicht auf etwas anderes als NaN gesetzt wird, blockieren wir den Ladevorgang. Dann ist der Zähler defekt, die Kommunikation gestört, oder ähnliches. Standardmäßig ist auf einer Wallbox die Zählerüberwachung aus und im Moment wo das erste Mal ein Zähler auftaucht wird sie aktiviert. Also bei einer Pro schon bei uns beim Testen, bei einer Smart wenn du per API die ersten Werte schickst. Lief die Wallbox seitdem durch? Falls ja zieh mal einen Debug-Report. Mich wundert, warum nicht der End-Zählerstand der Ladung vor dem Neustart verloren gegangen ist (Das werden wir bald in den getrackten Ladungen reparieren können: https://github.com/Tinkerforge/esp32-firmware/issues/213), sondern der anscheinend da ist, aber der Startwert der Ladung nach dem Neustart fehlt. Das ist einer der Gründe, warum es jetzt die Zählerüberwachung gibt. Wenn ESP und EVSE zu schnell booten (das kann man gut erzeugen wenn man bei einer WARP2 viele Features, vorallem Ethernet komplett deaktiviert), kann es ohne die Überwachung passieren, dass bei einem Ladestart noch kein Stromzähler gefunden wurde, und deshalb kein Stromzählerstand aufgezeichnet wird. Die Überwachung verhindert das, indem sie den Ladestart blockiert, bis ein Stromzählerwert ankommt. Im Moment geht das nicht. Die Ladevorgänge werden direkt hintereinander in Dateien gespeichert, an die wir aus Robustheitsgründen nur Daten hinten hinzufügen, aber nie Daten modifizieren. Eventuell bauen wir das bald ein.

Je nach Wallbox könnte das platzmäßig interessant werden: Der Piezo Speaker 2.0 ist relativ groß. Die Software dafür anzupassen sollte mit relativ wenig Aufwand klappen, folgendes müsstest du tun: Dich entscheiden, wann genau der Piezo Speaker Geräusche machen soll. Das kann z.b. sein: - Bei jedem bemerkten Tag, egal ob es ein bekanntes oder ein unbekanntes ist - Nur bei bekannten Tags ein Geräusch, bei unbekannten ein anderes - Bei bekannten Tags, aber nur wenn damit auch wirklich ein Ladevorgang gestartet wird - Auch wenn die Nutzerfreigabe von anderen Quellen gesetzt wird Abhängig davon, wann du Geräusche haben willst, musst du dich in eins oder mehrere der Module hängen: Im NFC-Modul läuft dieser Code bei jedem bemerkten Tag: https://github.com/Tinkerforge/esp32-firmware/blob/e44d2c98c47deab1e3394c615e9014ac7f306112/software/src/modules/nfc/nfc.cpp#L165C11-L197 Wenn ein Tag eine Aktion auslöst läuft immer dieser Code: https://github.com/Tinkerforge/esp32-firmware/blob/e44d2c98c47deab1e3394c615e9014ac7f306112/software/src/modules/users/users.cpp#L842 Wenn du (was in Summe am einfachsten ist) immer dann ein Geräusch willst, wenn auf der Front-LED ausgegeben werden soll, dass ein Tag erkannt wurde, kannst du dich hier vor die ganzen Priorisierungschecks hängen: https://github.com/Tinkerforge/esp32-firmware/blob/e44d2c98c47deab1e3394c615e9014ac7f306112/software/src/modules/evse_led/evse_led.cpp#L64 Das hat den Vorteil, dass wenn die Freigabe anders funktionieren würde (Man kann bald die Front-LED per API/Modbus TCP steuern) das einfach funktionieren würde Bei jeder dieser Varianten musst du dann aber immer, wenn du die Firmware deiner Wallbox aktualisieren willst, deine Variante davon neu bauen.

Bei meinem Zoe sieht das z.B. wie folgt aus, wenn man den Bereich von 18 Ampere bis 6 Ampere in 100mA-Schritten abfährt und jeweils 30 Sekunden zum einpendeln lässt: Der spannungskompensierte Strom ist der L1-Strom, aber auf 230V skaliert. In Echt bricht die Spannung beim einphasigen Laden etwas ein, habe ich testweise mal rausgerechnet, um besser das Verhalten des Zoes zu sehen, aber selbst dann wird der Abstand relativ groß. Edit: Auf geglätteten Werten sieht mans besser: Der Zoe lässt immer ~ 500W Luft: (X-Achse ist der erlaubte Strom)

Wenn die Wallbox in deinem Netz ist, solltest du über http://warp2-xyz/ darauf zugreifen können. Alternativ mit der IP, die in deiner Fritzbox angegeben wird.

Wenn das so funktioniert, wie im Artikel beschrieben, dann musst du dafür die Honda-Wallbox benutzen: 1. brauchst du einen CCS-Anschluss, d.h. die Wallbox macht aus Wechselstrom Gleichstrom und andersrum beim Einspeisen. Das heißt auch, dass die Wallbox die Netzsynchronisierung übernimmt. 2. D.h. die Wallbox bzw. das Strommanagementsystem (ich gehe davon aus, dass das ein Extra-Rechner ist) muss diese Informationen verarbeiten. 3. Muss man dann so ein "virtuelles Kraftwerk" aufbauen, da bist du rein rechtlich vermutlich sofort ein Energieversorger. Die Bürokratie dafür dürfte anstrengend werden.

Das müsste funktionieren. Ich weiß aber noch nicht, wie EVCC das dann genau umsetzen wird, also ob man pro Wallbox festlegen kann, ob und wenn ja von welchem WEM die Phasenumschaltung durchgeführt werden kann. (Wenn wir die API angepasst habe, werde ich das mal nachfragen) Wenn ich mich richtig erinnere brauchst du eine Genehmigung bei mehr als 11 kW (also 16 A dreiphasig). Trotzdem darfst du nur maximal 20 A Schieflast auf einer Phase erzeugen. Also rein theoretisch müsstest du dir eine 32 A-Wallbox die einphasig angeschlossen ist nicht genehmigen lassen, dich dann aber selbst darum kümmern, dass die nur 20 A Schieflast erzeugen kann. Da gehe ich von aus. Mit dem Setup kannst du dann aber nur bei beiden Wallboxen gleichzeitig die Phasen umschalten.

Mit etwas Programmier-/Script-Arbeit kannst du dir das bauen: Du kannst den WARP Charger per HTTP- und MQTT-API steuern (die sind fast identisch). In beiden Fällen wäre das Vorgehen etwa wie folgt: Periodisch prüfen, ob ein Auto angeschlossen ist mit evse/state (darin der Wert "charger_state") (per http://warp2-abc/evse/state oder über MQTT auf warp2/abc/evse/state) Periodisch prüfen ob ein NFC-Tag gesehen wurde mit nfc/seen_tags (die API liefert dir die letzten 8 gesehenen Tags, typischerweise reicht es wenn man sich den ersten Eintrag davon ansieht) Wenn beides der Fall ist, den Ladevorgang mit einem HTTP PUT bzw. MQTT Publish vom gewünschten Ladestrom auf evse/external_current_update starten. Damit die externe Ladestromgrenze beachtet wird, musst du einmal im Webinterface unter Wallbox -> Ladeeinstellungen die externe Steuerung aktivieren. Wenn ein Auto abgezogen wird, den Ladestrom auf 0 setzen, damit der Ladevorgang blockiert ist. Damit du das nicht von Hand machen musst, kannst du mit evse/external_clear_on_disconnect festlegen, dass das automatisch passieren soll, wenn ein Auto abgezogen wird. Das kannst du dann mit evse/external_defaults persistent machen. Mit einer der nächsten Firmwares kannst du das ganze auch per Modbus TCP umsetzen, da fehlt im Moment noch die Ausgabe des/der gesehenen NFC-Tags: https://github.com/Tinkerforge/esp32-firmware/issues/227 Den SoC der Fahrzeuge rauszubekommen ist leider nicht ganz einfach. Eventuell hilft es, wenn du dir ansiehst, wie EVCC das macht. Als weniger flexible Alternative, bei der du aber nichts selbst programmieren musst, kannst du dir SteVe ansehen. Das ist ein OCPP-Server, der die Wallboxen steuern, NFC-Tags managen und Ladevorgänge aufzeichnen kann.

Jein. Man kann theoretisch per nfc/inject_tag ein NFC-Tag vortäuschen und damit per API den Ladevorgang für einen bestimmten Benutzer starten. Im Moment muss, damit diese API funktioniert aber ein NFC-Bricklet vorhanden sein (Das zu fixen ist dieses Issue:https://github.com/Tinkerforge/esp32-firmware/issues/133). Perspektivisch wollen wir aber dahin kommen, dass man per API (und dann auch übers Webinterface) für spezifische Benutzer einen Ladevorgang starten kann: https://github.com/Tinkerforge/esp32-firmware/issues/161

Was @poohnet sagt. WSS über TLS geht bereits, im Moment beinhaltet die Firmware den kompletten Satz Root-Zertifikate von Mozilla: https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-reference/protocols/esp_crt_bundle.html Die Möglichkeit ein eigenes Root-Zertifikat hochzuladen wird aber auf jeden Fall noch kommen. Damit der Gedanke nicht verloren geht habe ich ein Issue dafür angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/233

Oh sorry, das war bei mir untergegangen. Ich versuche nochmal das hier zu erzeugen. Eigentlich hatte ich mich mit den eCarUp-Leuten geeinigt, dass es so aussieht, als ob das Problem behoben war.

Teste am besten gleich mit 2.1.2, eventuell war das ein Problem mit den neu eingebauten Ladezeit- und Energielimits.

Firmware: WARP 2.1.2 und WARP2 2.1.2 UID der Wallbox zu Entitätsnamen der MQTT Auto Discovery hinzugefügt EVSE Coils für Modbus TCP hinzugefügt Füllung für Stromzählerplot hinzugefügt Konfiguration des Web-Interface-Ports hinzugefügt WLAN-Empfangsqualität durch Deaktivierung des HT40-Modus und 11b verbessert Robustheit der Stromzähler-Initialisierung verbessert Zugriff auf das Lastmanagement-Verteilungslog repariert Robustheit der statischen IP-Konfiguration der LAN-Schnittstelle verbessert Löschen kontrollierter Wallboxen auf der Lastmanagement-Konfigurationsseite repariert Übersetzungen verbessert Behoben, dass Zeit- und Energielimits weitere Ladevorgänge blockieren konnten Zeitzonen-Datenbank aktualisiert Ausgabe der Verbindungsdauer bei Verlust einer LAN-, WLAN-, MQTT- oder WireGuard-Verbindung hinzugefügt Behoben, dass OCPP nicht neu verbunden wurde, falls eine TLS-Verbindung direkt nach dem Verbindungsaufbau geschlossen wurde Behoben, dass Energie-Wert über Modbus-TCP mehr als einmal zurückgesetzt wurde Defekte Links auf der Status-Seite entfernt, falls Lastmanagement-Konfiguration geändert, aber nicht angewandt wurde PDF-Download-Timeout erhöht MQTT-Timeout erhöht Stoppen des Ladevorgangs im Webinterface, während ein anderer Ladestromslot blockiert, hinzugefügt Download: WARP 2.1.2 bzw. WARP2 2.1.2

Gute Idee. Habe ich gerade eingebaut: https://github.com/Tinkerforge/esp32-firmware/commit/a52e735a8d79b00ee8efe567bea726e65dc93730 Kommt mit der nächsten Firmware.

Dann warte ich einfach mal ab was kommen wird. Das ist übrigens dieses Problem: https://github.com/Tinkerforge/esp32-firmware/issues/173 tl;dr: Der Lastmanager sollte Wallboxen an denen ein voll geladenes Fahrzeug hängt komplett deaktivieren und nur, falls von den anderen Wallboxen noch Strom übrig ist, versuchen die mit dem Minimalstrom wieder aufzuwecken. Das ist im Moment leider nicht funktional. Das hier https://github.com/Tinkerforge/esp32-firmware/issues/225? Oder hast du noch einen anderen Bug gefunden? Kannst du hier posten.

Oh sorry, ich hatte im Kopf, dass ich vor dem Urlaub was dazu geschrieben hatte. Der Briefkopf wird im Moment in der Tat nicht gespeichert. Das ist erstmal Absicht insoweit, dass wir noch ein paar Sachen anpassbar machen wollen, bevor man sich festlegt, wie genau er gespeichert werden soll.

Du machst alles richtig, das war ein Bug auf unserer Seite, sorry. Habe ich gerade gefixt, nächste Firmware kommt diese Woche noch.

Du kannst, damit der type_override wieder deaktiviert ist auch genau wie oben über die Recovery-Seite einen API-Call machen, nur diesmal mit {"method":"PUT", "url":"/meter/type_override_update", "payload":"255"} Dann versucht die Wallbox wieder zu detektieren, was für ein Zähler verbaut ist, statt dass immer ein SDM630 angenommen wird.

Wenn du die Situation nochmal erzeugen kannst, zieh einen Debug-Report von der Wallbox und am besten auch ein EVCC-Log und poste beide hier. Da muss irgendwas mit der Ansteuerung schieflaufen.

Außer der Verbindung zum MQTT-Broker musst du auf der Wallbox nur genau eine Sache einstellen: Unter Wallbox->Lade­ein­stellungen musst du die externe Steuerung aktivieren. Ansonsten werden die von EVCC geschickten Befehle ignoriert. Ich sehe gerade, dass das aus irgendeinem Grund nicht in unserer EVCC-Anleitung steht. Fixe ich gleich.