rtrbt

Leider noch nicht. Es gibt ein offenes Issue dazu, damit wir das Problem nicht vergessen. https://github.com/Tinkerforge/esp32-firmware/issues/262 Erledigt, danke für den Hinweis :) https://github.com/Tinkerforge/esp32-firmware/commit/7478a93af5469069ae14c3d1070b3e304afc4d38

Du musst dir zwei Keypaare generieren (wie z.b. hier beschreiben: https://wiki.archlinux.org/title/WireGuard#Key_generation) und dann die entsprechenden Schlüssel verteilen. Wenn du zum Beispiel mit wg genkey | (umask 0077 && tee warp.key) | wg pubkey > warp.pub wg genkey | (umask 0077 && tee peer.key) | wg pubkey > peer.pub die Keys erstellst, dann musst du auf der Wallbox warp.key als eigenen privaten Schlüssel und als öffentlichen Schlüssel der Gegenstelle. Bei deiner Gegenstelle musst du dann peer.key als dessen privaten Schlüssel konfigurieren und warp.pub als öffentlichen Schlüssel (der Gegenstelle der Gegenstelle, also der Wallbox)

Firmware: WARP 2.5.0 neuveröffentlicht Das Fernzugriffs-Modul des Webinterfaces fehlte in der gestern veröffentlichten Firmware. Download: WARP 2.5.0

Firmware: WARP 2.5.0 Firmware-Update-Prüfung und -Download hinzugefügt Fernzugriff hinzugefügt Download: WARP 2.5.0

Firmware: WARP Energy Manager 2.2.0 Firmware-Update-Prüfung und -Download hinzugefügt Fernzugriff hinzugefügt Firmware-Updates signiert Fokusverlust bei Bearbeitung des Anzeigenamens repariert Übersetzung der Namen von heruntergeladenen Dateien repariert Sichergestellt, dass lange SSIDs nicht das Webinterface-Layout brechen Fehlermeldung hinzugefügt, falls Recovery-Seite das Zurücksetzen auf Werkszustand nicht starten kann MQTT-Automatisierungsregeln mit Präfix repariert Fehlenden Leistungsgraphen bei Victron Energy GX-Stromzählern behoben Download: WARP Energy Manager 2.2.0

Firmware: WARP 2.4.2, WARP2 2.5.0 und WARP3 2.5.0 (Nur WARP2/WARP3) Firmware-Update-Prüfung und -Download hinzugefügt (Nur WARP2/WARP3) Fernzugriff hinzugefügt Konfigurierbare Totzeit nach Erkennen eines NFC-Tags zum Ladestart hinzugefügt Blinken der LED bei Neustart der Wallbox hinzugefügt Firmware-Updates signiert (Nur WARP2/WARP3) Kompatiblilität der OCPP-Autorisierung verbessert Repariert, dass Wallboxen vom Lastmanager mehr als 32 Ampere zugeteilt wurden Generierung von leeren Ladelog-PDFs repariert Fokusverlust bei Bearbeitung des Anzeigenamens repariert Übersetzung der Namen von heruntergeladenen Dateien repariert Sichergestellt, dass lange SSIDs nicht das Webinterface-Layout brechen Fehlermeldung hinzugefügt, falls Recovery-Seite das Zurücksetzen auf Werkszustand nicht starten kann MQTT-Automatisierungsregeln mit Präfix repariert (Nur WARP1) Fehlenden Leistungsgraphen bei Victron Energy GX-Stromzählern behoben Download: WARP 2.4.2 bzw. WARP2 2.5.0 bzw. WARP3 2.5.0

Fairerweise: Die API ist nicht dokumentiert, weil ich mir offen halten will, sie nochmal zu ändern.

Wenn der charger_state == 3 ist solltest du eventuell noch auf evse/low_level_state["time_since_state_change"] nachsehen, dass nicht jetzt gerade angefangen wurde zu laden. Das sind Millisekunden, also kannst du z.B. auf > 40000 prüfen, um dem Auto 40 Sekunden zu geben, mit dem Ladevorgang anzufangen. 40 Sekunden ist ein sinnvoller Wert, weil die Wallbox nach 30 Sekunden einmal versucht das Auto per CP-Trennung zu wecken. Es ist robuster, wenn du nicht genau während der CP-Trennung stop + start aufrufst, sonst sieht das Auto das nicht.

Die Ladeleistung kannst du auf zwei Arten abfragen: 1. Über die alte Meter-API https://docs.warp-charger.com/docs/mqtt_http/api_reference/meter#meter_values_warp3 z.B. mit curl -s http://$HOST/meter/values | jq .power 2. Über die neue Meters-API (die ist komplizierter, aber flexibler) https://docs.warp-charger.com/docs/mqtt_http/api_reference/meters#meters_X_values_warp3 z.B. mit curl -s http://$HOST/meters/0/values | jq '.[24]' Dass du auf Index 24 zugreifen musst, kannst du wie folgt herausfinden: https://docs.warp-charger.com/docs/mqtt_http/api_reference/meters#meters_X_value_ids_warp3 gibt dir die IDs der Messwerte des gewünschten Zählers (Zähler 0 ist der in der Wallbox verbaute), die Liste der IDs und deren Bedeutung findest du hier: https://github.com/Tinkerforge/esp32-firmware/blob/master/software/src/modules/meters/meter_value_id.csv und auf der Liste suchst du Power Active LSum ImExDiff (Die Active Power, also Wirkleistung, summiert über alle drei Phasen, Import (also Bezug des Autos) - Export (theoretisch mögliche Einspeisung des Autos)) Edit: Da warst du schneller :D

Damit ich das Protokoll richtig lese (Siehe Zahlen im Graph) Du hast das Protokoll gestartet, als du gerade in dem Zustand warst, dass das Auto nicht laden wollte, hast dann Stop+Start gedrückt dann hat es dreiphasig angefangen zu laden. Dann hast du auf einphasig umgeschaltet, das Auto lädt wieder. Dann hast du auf dreiphasig umgeschaltet und das Auto lädt nicht mehr. Dann hast du ~ 4 Minuten später Stop+Start gedrückt Das Auto sieht die Phasenumschaltung und fordert dann wieder Strom an (das sind die beiden rot eingekreisten Stufen bei 4 und 6 auf dem CP-Widerstands-Messwert). Bei einer Phasenumschaltung geht der CP-Widerstand auf "unendlich" also ~ 4 Milliarden Ohm, weil die Wallbox die CP-Leitung trennt, dann die Phasen umschaltet und dann die CP-Leitung wieder verbindet. Dann sehen wir kurz 2700 Ohm (das bedeutet, dass ein Auto angeschlossen ist, aber nicht lädt) und kurz danach 880 Ohm (das bedeutet, dass das Auto Strom anfordert). Das Schütz wird dann wieder durchgeschaltet, das Auto zieht dann aber keinen Strom, obwohl es könnte. Zwei Fragen dazu: 1. Hast du bei 6. auf dreiphasig umgeschaltet? Das Timing ist extrem interessant, weil diese Umschaltung genau 30 Sekunden nach der 3->1phasig-Umschaltung passiert. Wir haben einen anderen Prozess, der 30 Sekunden nach der Ladefreigabe CP trennt, aber nur, wenn das Auto nicht die 880 Ohm anlegen würde. Das sollte bei dir nicht passieren. 2. Wenn du die Wallbox auf einphasig stellst, dann das Auto ansteckst, es > 5 Minuten laden lässt und erst dann auf dreiphasig umschaltest, funktioniert das ohne dass du Stop+Start drücken musst? Edit: Wenn du den Graph im Original sehen willst, kannst du das Debug-Protokoll auf https://vislog.warp-charger.com/ hochladen. Das ist aber noch etwas experimentell.

Unter Wallbox -> Ladestatus kannst du ein Lade­proto­koll erstellen. Drücke da mal auf Start (ab dann musst du den Tab auflassen, kannst aber zurück auf die Statusseite gehen) und mach dann die einphasig -> dreiphasig-Umschaltung. Dann warte 2 Minuten und drück Stop + Download. Das Log kannst du hier anhängen, eventuell sehen wir dann noch etwas. Prinzipiell sieht das aber nicht gut aus. Wenn die Wallbox auf Ladebereit steht, dann muss das Auto Strom anfordern, sonst passiert nichts.

Firmware ist aktuell? Wir hatten bei anderen Autos das Problem, dass der Weckruf (das ist eine Trennung der CP-Leitung für ein paar Sekunden, womit dem Auto vorgetäuscht wird, dass du das Kabel Wallboxseitig rausgezogen hast) zu kurz war. Deshalb machen wir seit Firmware 2.3.0 noch eine 30 Sekunden lange Trennung, wenn die kürzere nicht geholfen hat. Ansonsten scheint das beim 500e ein häufiges Problem zu sein, z.B. hier haben mehrere Leute das Problem spezifisch bei einer Phasenumschaltung und verschiedensten Wallboxen: https://www.goingelectric.de/forum/viewtopic.php?f=231&t=69865 Was für einen Ladestrom gibst du vor, wenn du auf dreiphasig wechselst? Ich habe den goingelectric-Thread nur grob überflogen, aber es scheint da Probleme zu geben, wenn der Ladestrom zu niedrig ist. Z.B. bei Renault Zoes und älteren elektrischen Smarts gibt es das Problem, dass dreiphasig erst ab ~ 9 A effizient geladen wird.

Ja, in evse/low_level_state. Die API für die ESP-Temperatur ist noch undokumentiert, damit wir die nochmal ändern können. Im Moment haben wir die Temperaturdaten, aber fangen damit noch nichts an.

Genau. Fast. Der Watchdog ist nur relevant, wenn du direkt auf charge_manager/available_current_update schreibst. Also "statisches" Lastmanagement machst, aber selbst den verfügbaren Strom per API vorgibst und dann sichergehen willst, dass wenn das Programm crasht, dass die API befüllt, nicht der letzte verfügbare Stromwert weiter verwendet wird. Wenn du einen API-Zähler für den PV-Überschuss verwendest dun dann dein Programm crasht, wird im Moment der letzte Wert weiterverwendet. Auf der TODO-Liste steht, damit auch umzugehen, das wird im Zuge des dynamischen Lastmanagements kommen.

Laut Fehlermeldung sieht die Wallbox keinen Payload, was seltsam ist. Wie schickst du den HTTP-Request oder die MQTT-Nachricht? Der Auto-Start (bzw. manual charge release im Webinterface; ist übrigens umgekehrt, weil anscheinend die Nutzer so weniger verwirrt sind) ist eine der wenigen Einstellungen, die sofort greifen, das weiß aber das Webinterface nicht. D.h. wenn du nur den verstellst, kannst du dir den Neustart sparen. Jede Änderung des Auto-Starts wird aber in den Flash des Ladecontrollers geschrieben, du solltest den Wert also nicht zu oft schreiben (z.B. stündlich ist okay, sekündlich nicht), damit der Flash nicht abgenutzt wird.

Per Mudbus kannst du den Ausgang nicht steuern. Eventuell fügen wir ein Register dafür hinzu, habe dafür ein Issue angelegt:https://github.com/Tinkerforge/esp32-firmware/issues/362 Über HTTP und MQTT kannst du den Ausgang steuern, indem du true oder false auf evse/gp_output schreibst: https://docs.warp-charger.com/docs/mqtt_http/api_reference/evse#evse_gp_output_warp2

Das kann ich dir gerade nicht erklären und @MatzeTF ist im Urlaub. Die Einschränkung wird aber nur im Webinterface geprüft, d.h. über die API können wir 25 Ampere einstellen: Geh mal auf die Recovery-Seite deiner Wallbox (z.B. http://warp3-AbCd/recovery oder http://10.0.0.1/recovery falls du im AP der Wallbox bist) und füge da bei API ins obere Eingabefeld folgendes ein: {"method":"PUT","url":"/power_manager/dynamic_load_config","payload":{"enabled":null,"meter_slot_grid_currents":null,"current_limit":25000,"largest_consumer_current":null,"safety_margin_pct":null}} und klicke auf "Call API". Im unteren Feld sollte dann eine 200 erscheinen und wenn du im Webinterface nachsiehst sollte der Hausanschluss auf 25 A stehen. Wenn du die anderen Einstellungen auf der Lastmanagement-Unterseite änderst musst du danach wieder den Hausanschluss über die Recovery-Seite setzen. Das Webinterface erlaubt es ja nicht Werte < 32 A zu speichern.

Firmware: WARP (1,2,3) Beta des neuen Lastmanagements Details hier:

Die gibt es in der Tat im Moment nicht, kommt aber möglicherweise in der Zukunft. Die Tag-Injection per Modbus hat ein paar Fallstricke, deshalb haben wir sie noch nicht implementiert. Ich habe aber mal ein Issue angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/359

Wenn du schon ein NFC-Tag zur Ladefreigabe verwendest, dann stoppe den Ladevorgang lieber über die nfc/inject_tag_stop API aus: https://docs.warp-charger.com/docs/mqtt_http/api_reference/nfc#nfc_inject_tag_stop_warp3 Wenn du per MQTT external_current auf 0 setzt, dann musst du auch per MQTT wieder freigeben (oder im Webinterface unter Wallbox -> Ladestatus von Hand die Stromgrenze zurücksetzen) Wenn du mit einer NFC-Tag-Injection über MQTT stoppst, dann kannst du den nächsten Ladevorgang einfach wieder mit deinem Tag starten.

Moin, @MatzeTF und ich haben in den letzten Monaten das Lastmanagment grundlegend überarbeitet. Der Lastmanager kann jetzt: Dynamisches Lastmanagement: Der Lastmanager stellt sicher, dass der Netzanschluss nicht überlastet wird, auch wenn andere (ungesteuerte) Verbraucher den Hausanschluss dynamisch belasten. PV-Überschussladen: Der Lastmanager stellt sicher, dass nur der PV-Überschuss verwendet wird, um Fahrzeuge zu laden. Statisches Lastmanagement: Der Lastmanager stellt sicher, dass die gemeinsame Zuleitung des Wallbox-Verbunds nicht überlastet wird. Und das alles mit bis zu 32 Wallboxen. Insbesondere sollte jetzt auch das PV-Überschussladen mit mehreren Wallboxen deutlich besser funktionieren. Details zur Funktionsweise finden sich hier: https://docs.warp-charger.com/docs/warp_charger/new_charge_management Im Moment funktioniert das neue Lastmanagement nur mit Wallboxen: Es kann nicht auf dem WARP Energy Manager verwendet werden und auch keine Wallboxen über einen WARP Energy Manager Phasenumschalten. Beide Punkte werden wir bis zur fertigen, also nicht-Beta-Veröffentlichung noch fixen. Die Konfiguration sollte für das statische Lastmanagement und das PV-Überschussladen unverändert weiter funktionieren, damit das dynamische Lastmanagement verwendet wird, muss es unter Energiemanagement -> Lastmanagement konfiguriert werden. Falls das Lastmanagement nicht wie erwartet funktioniert, oder seltsame Entscheidungen trifft, können die Informationen der Lastmanagment-Debug-Unterseite hilfreich sein. Dort kann unter anderem ein Lastmanagement-Log heruntergeladen werden, dass aufschlüsselt, was in der letzten ~ Stunde passiert ist. Falls Probleme auftreten können wir diese mit dem Log hoffentlich nachvollziehen. Wir freuen uns auf euer Feedback! Edit: Veraltete Firmware entfernt.

Firmware: WARP Energy Manager 2.1.2 Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: Alpha ESS SMILE, Shelly Pro (3)EM Sungrow-Registertabelle repariert Laden im “schnell”-Modus erlaubt, selbst wenn PV-Überschuss-Zähler noch keine Werte geliefert hat Lastmanagement-Startphase repariert Repariert, dass Webserver für immer gehangen hat, wenn Laden der Energiebilanzdaten fehlgeschlagen ist Hinzugefügt, dass Netzwerkverbindungen vor Neustart geschlossen werden Hinzugefügt, dass manche Stromzählerwerte aus anderen berechnet werden, falls sie nicht vom Zähler gemeldet werden Repariert, dass manche MQTT-Fehler nicht im Ereignis-Log angezeigt wurden Download: WARP Energy Manager 2.1.2

Firmware: WARP 2.4.1, WARP2 2.4.1 und WARP3 2.4.1 Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: Alpha ESS SMILE, Shelly Pro (3)EM Sungrow-Registertabelle repariert Laden im “schnell”-Modus erlaubt, selbst wenn PV-Überschuss-Zähler noch keine Werte geliefert hat Lastmanagement-Startphase repariert Modbus-TCP-Registertabellen-Dokumentation verbessert Repariert, dass Webserver für immer gehangen hat, wenn Laden der Energiebilanzdaten fehlgeschlagen ist Hinzugefügt, dass Netzwerkverbindungen vor Neustart geschlossen werden Überschreiben des Energie-Limits repariert Hinzugefügt, dass manche Stromzählerwerte aus anderen berechnet werden, falls sie nicht vom Zähler gemeldet werden Repariert, dass manche MQTT-Fehler nicht im Ereignis-Log angezeigt wurden Berechnung der Belegungsanzeige des Ladetrackers repariert Titel des Ladelog-PDFs repariert Erzeugung des Ladelog-PDFs beschleunigt Überlauf der Stromzählerwerte behoben (Nur WARP1) CP/PE-Messung verbessert (durch Update auf Ladecontroller-Firmware 2.1.10) Download: WARP 2.4.1 bzw. WARP2 2.4.1 bzw. WARP3 2.4.1

Schalte die Status-LED-Steuerung mal ab. Die ist nur notwendig, wenn du die API benutzt.

Hast du unter Wallbox -> Einstellungen die "Status-LED-Steuerung" aktiviert? Das sollte für Automatisierungsregeln nicht notwendig sein, könnte aber dazu führen, dass die Regel ignoriert wird. Wie genau sieht deine Automatisierungs-Regel aus? Siehst du im Ereignislog "Running rule #[zahl]" wenn du auf das MQTT-Topic schreibst?