rtrbt

Hm ich fürchte, dass muss sich @MatzeTF mal detailliert ansehen, der ist aber noch im Urlaub. Er wird sich melden.

Das ist ein bekanntes Problem, für das wir im Moment leider keine Lösung haben: https://github.com/Tinkerforge/esp32-firmware/issues/342 Irgendwie implementiert Safari auf iOS die Digest Authentication nicht richtig. (das betrifft dann auch alle anderen Browser weil Apple der Meinung ist, keine anderen Browser-Engines zuzulassen) Langfristig wollen wir auf eine andere Variante des Logins umsteigen, aber es ist noch niemand dazu gekommen, das zu implementieren.

Wir hatten das gleiche Problem in der Tat schon mal: https://github.com/Tinkerforge/esp32-firmware/issues/338 und hatten dann die erlaubte Headergröße auf 1536 und später anscheinend auf 2047 Byte erhöht. Kannst du nachsehen, wie groß die Header sind, wenn du die Cloudflare-Auth aktiviert hast?

Laut der PDF gibt es das Register 1080 "Battery management mode" mit den möglichen Werten (Note 4 auf der nächsten Seite): 4 Battery management modes 0x00 No external battery management 0x01 External battery management via digital I/O 0x02 External battery management via MODBUS protocol Das Register ist read-only, also muss es irgendeinen anderen Weg als Modbus geben, wie du das aktivieren kannst. Du kannst aber z.B. mit GModbus das Register lesen. Wenn das schon auf 2 steht, hast du ein anderes Problem.

Die Wallbox schickt sofort wenn sie merkt, dass der Stecker gezogen ist eine MQTT-Nachricht. Sofort heißt in dem Fall nach spätestens einer Sekunde, es sei denn du hast das MQTT-Sende-Intervall versetellt. Wenn du das Problem nochmal erzeugen kannst, zieh bitte mal sowohl einen Debug-Report von der Wallbox, als auch das EVCC-Log. Dann sehen wir vielleicht mehr.

Hm, weil bei dir die 32 A einphasig voll ausgefahren werden, kommt die Umschaltung auf dreiphasig in der Tat erst sehr spät: Das PV-Überschussladen versucht Schaltvorgänge zu minimieren, deshalb bleibt es möglichst lange einphasig. Weil bei dir die 32 A einphasig voll ausgenutzt werden, muss die Wallbox 4 Minuten lang (das ist die Wolkenfilterzeit wenn der Filter auf mittel steht) mehr als 32 A * 230 V = 7360 W sehen, damit sie umschaltet. Die Idee dahinter ist, dass wenn wir auf dreiphasig umschalten und dann der Überschuss fällt, wir spätestens bei 4140 W wieder auf einphasig schalten müssten (weil 6 A der Minimalstrom ist, den man dem Auto vorgeben kann -> 6 A * 3 Phasen * 230 V = 4140 W), oder Strom aus dem Netz beziehen. Sobald wir die Schieflastvermeidung umgesetzt haben, wird das aber vermutlich so passieren, wir werden dann einphasig ja nur noch maximal 4600 W (20 A * 230 V) los und müssten dann auf dreiphasig wechseln.

Prinzipiell muss mehrere Minuten lang genug Überschuss für den dreiphasigen Betrieb verfügbar sein (das ist Teil des Wolkenfilters), damit umgeschaltet wird. Das kann unintuitiv spät sein (ich arbeite gerade daran, dass das Lastmanagement/PV-Überschussladen sich im Webinterface mehr erklärt). Zieh im Zweifel mal einen Debug-Report, damit kann ich ~ eine Stunde in die Vergangenheit die Entscheidungen des PV-Überschussladens nachvollziehen. Das ist prinzipiell geplant, gibt es aber noch nicht. Habe mal ein Issue dafür angelegt. https://github.com/Tinkerforge/esp32-firmware/issues/424

Auf 6 zu ändern oder? Dann würde sowohl NFC wie auch OCPP jeweils den gleichen slot freischalten. Ist schon sehr hacky vermutlich tut's aber, meinste du nicht auch? Ganz so einfach ist das leider nicht: Wenn OCPP nicht freigibt, wird der maximale Ladestrom mehrfach pro Sekunde auf 0 mA geschrieben:https://github.com/Tinkerforge/tfocpp/blob/8f315f5ea976e00a3f177a983b62871ad4f8e200/src/ocpp/Connector.cpp#L66 Ohne dass ich das jetzt genau durchdacht habe müsstest du zusätzlich zumindest noch hier: https://github.com/Tinkerforge/esp32-firmware/blob/19ec67bc6b041a01d6a573fb1f3bb8c5bdb968e0/software/src/modules/ocpp/ESP32Platform.cpp#L672 mittracken, ob der letzte Übergang von 0 mA nach >= 6000mA durch OCPP verursacht wurde (wenn nicht, dann war es wohl NFC) und nur wenn das der Fall ist, erlaubst du OCPP wieder 0 mA zu schreiben um den Ladevorgang zu stoppen, sonst ignorierst du das. Ggfalls musst du noch mehr Hacks einbauen, damit das immer funktioniert.

Genau. Wenn du eine Wallbox mit Zähler hättest, könnte das PV-Überschussladen jetzt sehen, dass dein Auto nur 16 A zieht und würde sich dann einpendeln. Ohne Zähler pendelt es sich dann bei den 32 A ein. Edit: 32 A zeigen wir immer einfach als "freigegeben" an, eben weil das das größte Limit ist, dass die Wallbox kennt. Das ist zum Beispiel bei den Ladeslots praktisch, die nur entweder "freigegeben" (= 32 A) oder "blockiert" (= 0 A A) sind.

Der maximale Gesamt­strom für das Lastmanagement (unter Energiemanagement -> Wallboxen) ist auf 16 A konfiguriert, das sorgt dafür, dass das Lastmanagement nie mehr als 16 A verteilt. Wenn die Zuleitung zur Wallbox das erlaubt (wovon ich ausgehen würde, sonst hätte dein Elektriker die Schiebeschalter in der Wallbox falsch eingestellt), solltest du den maximalen Gesamtstrom auf 32 A erhöhen können.

Zieh mal einen Debug-Report (unter System->Ereignis-Log) und hänge ihn hier an. Im Report ist das detailliertere Log des Lastmanagers, mit dem können wir nachvollziehen, warum nicht auf dreiphasig umgeschaltet wird.

Die Dokumentation ist da etwas dünn, hier die Liste welcher Ladeslot welche Bedeutung hat: https://github.com/Tinkerforge/esp32-firmware/blob/c66f1d936b42740d99d0a26e808e6f283f5a620b/software/src/modules/evse_common/evse_common.h#L37-L51

Ist sie nicht. Ladebereit bedeutet, dass die Wallbox dem Auto kommuniziert, dass Strom verfügbar ist. D.h. wenn das Auto dann Strom anfordert, wird das Schütz geschaltet. Wenn EVCC aber blockiert, dann darf die Wallbox dem Auto nicht das Laden erlauben -> Wir sind nicht ladebereit. Ja, aber die musst du selbst aufbereiten: https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/evse#evse_slots_warp3 gibt dir alle Ladestromgrenzen (Siehe auch im Webinterface unter Wallbox -> Ladestatus). Das Minimum aller Grenzen, die "active" sind, ist der erlaubte Ladestrom.

Ist tag_type 1 korrekt? Im Debug-Report sind die Tag-Typen und IDs zensiert, deshalb muss ich fragen. Wenn das die Tags sind, die du mit der Wallbox erhalten hast, würde ich tag_type 2 erwarten. Bzw. kannst du in der NFC-Config auch nachsehen:https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/nfc/#nfc_config_warp3 beschreibt welche Tag-Typ-Nummer welcher angezeigte Tag-Typ ist.

Firmware: WARP1 2.8.5, WARP2 2.8.5, WARP3 2.8.5, WARP Energy Manager 2.4.5, WARP Energy Manager 2.0 1.3.5 (Nur WARP1, WARP2, WARP3) Hinzugefügt, dass Stromzähler verwendet wird um die Versorgungsspannungen zu prüfen Sichergestellt, dass Debug-Report niemals WireGuard-Keys enthält Striktheit der Prüfung eingegebener IP-Adressen erhöht, um Tippfehler zu vermeiden (Nur WARP3) Behoben, dass Phasenumschaltung zu langsam durchgeführt wurde, wenn das Fahrzeug wieder schnell genug reagiert (durch Update auf Ladecontroller-Firmware 2.2.13) Modbus TCP: PV-Leistung für Deye-Niederspannungs-Hybrid-Wechselrichter repariert Übersetzungen verbessert Download: WARP1 2.8.5 bzw. WARP2 2.8.5 bzw. WARP3 2.8.5 bzw. WARP Energy Manager 2.4.5 bzw. WARP Energy Manager 2.0 1.3.5

Siehe auch https://www.meinid.com/thread/9219-probleme-mit-ladepausen-beim-photovoltaik-überschussladen-mit-software-5-4 Das Problem tritt mit diversen Wallboxen, auch denen von VW selbst auf.

Leider nicht. Die Ladefreigaben (von denen OCPP und die "externe Steuerung" also meistens MQTT) sind alle parallel, es müssen also alle Freigaben, die aktiv sind, freigeben. Kurze Bestandsaufnahme: Die Freigabe über EVCC läuft über die Fahrzeugerkennung? Oder benutzt du da ein NFC-Tag, dass EVCC kennt? Wie gehst du im Moment mit dem anderen Fall um, dass EVCC blockiert, wenn OCPP freigibt?

Firmware: WARP1 2.8.4, WARP2 2.8.4, WARP3 2.8.4, WARP Energy Manager 2.4.4, WARP Energy Manager 2.0 1.3.4 (Nur WARP1, WARP2, WARP3) Fronttaster-Zustandsregister zur WARP-Modbus-TCP-Registertabelle hinzugefügt Modbus TCP: Unterstützung für Carlo Gavazzi EM580-Stromzähler hinzugefügt Modbus TCP: Unterstützung für Fox ESS H3 Smart und Pro Wechselrichter hinzugefügt Modbus TCP: Unterstützung für virtuellen Last- und PV-Stromzähler für Fox ESS-Wechselrichter hinzugefügt Modbus TCP: Unterstützung für virtuellen PV-Stromzähler für GoodWe-Wechselrichter hinzugefügt Modbus TCP: Unterstützung für Solax String-Wechselrichter hinzugefügt Modbus TCP: Unterstützung für virtuellen PV-Stromzähler für Solax-Wechselrichter hinzugefügt Modbus TCP: Unterstützung für virtuellen PV-Stromzähler für Sungrow-Wechselrichter hinzugefügt Modbus TCP: Voreingestellten Messort für Carlo Gavazzi EM270- und EM280-Stromzähler repariert Modbus TCP: Fox ESS-Wechselrichter Netzanschluss-Energie-Export-Wert repariert Modbus TCP: GoodWe-Wechselrichter Leistungswerte und Leistungsfaktoren sowie Lastenergiewerte repariert Modbus TCP: Behandlung des GoodWe-Wechselrichter-Batteriespeichers repariert Modbus TCP: Alpha ESS / Hailei-Wechselrichter PV-Energiewert repariert Modbus TCP: Virtueller Victron Energy GX-Wechselrichter-Stromzähler auf PV umgestellt Robustheit der SMA Speedwire-Implementierung verbessert Robustheit von WireGuard und Fernzugriff verbessert (Nur WARP1, WARP2, WARP3) Repariert, dass Ladelimits nicht korrekt wiederhergestellt wurden (Nur WARP2, WARP3) Standardkonfiguration der von OCPP gesampleten Zählerwerte korrigiert (Nur WARP1, WARP2, WARP3) Ladetracker: Hinzugefügt, dass gespeicherter Briefkopf gelöscht werden kann mDNS-Spam behoben (Nur WARP Energy Manager) Abschalten des Schützes bei Fehlern repariert (Nur WARP Energy Manager) Sichergestellt, dass Schützfehler nur beim Auftreten gemeldet wird (Nur WARP Energy Manager, WARP Energy Manager 2.0) Jahr der Echtzeituhr repariert, falls diese noch nicht gestellt wurde (Nur WARP2, WARP3) Unterbrechungen des Ladevorgangs mit BMW PHEVs behoben (durch Update auf Ladecontroller-Firmware 2.2.12) (Nur WARP2, WARP3) Behoben, dass Phasenumschaltung zu schnell durchgeführt wurde, wenn das Fahrzeug nicht reagiert; behebt Probleme mit Polestar EVs (durch Update auf Ladecontroller-Firmware 2.2.12) (Nur WARP2, WARP3) Sichergestellt, dass Schützprüfung nicht direkt nach einem Neustart kurz einen Fehler meldet (durch Update auf Ladecontroller-Firmware 2.2.12) (Nur WARP2, WARP3) Dritten und vierten Versuch des Fahrzeug-Weckrufs (mittels IEC-Zustand F) hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.12) Übersetzungen verbessert Download: WARP1 2.8.4 bzw. WARP2 2.8.4 bzw. WARP3 2.8.4 bzw. WARP Energy Manager 2.4.4 bzw. WARP Energy Manager 2.0 1.3.4

Dafür musst du übrigens den EM300 auswählen. Mit der nächsten Firmware wird der EM340 mit erwähnt: https://github.com/Tinkerforge/esp32-firmware/commit/563ec60583389d03fb3422c23d5d7a3d41415d21

https://github.com/Tinkerforge/dbus-warp-charger die hohe CPU-Load sollte gefixt sein. Stellt sich raus das Script hat alle 250ms 9 HTTP-Requests gemacht, das war etwas viel. Es gibt jetzt in der config.ini den Wert UpdateInterval, der angibt wie oft die Daten aktualisiert werden, mit default 1 (=Sekunden). Außerdem macht ein Update nur noch die Hälfte an Requests und die Auto-Start-Logik war kaputt, das sollte jetzt auch passen.

Die config liest nicht den error_state, sondern den charger_state. charger_state 4 bedeutet, dass irgendein Fehler vorliegt.

Leider noch nicht.

Zieh bitte einmal einen Debug-Report (unter System->Ereignislog) und poste ihn hier oder schicke ihn an erik@tinkerforge.com

Das steht leider nicht direkt auf der API, sondern das Webinterface baut den Text zusammen. Im Endeffekt musst du evse/slots auswerten. Jeder Slot dessen Wert gleich dem Minimalwert ist, ist einer der vom Webinterface aufgelistet werden würde. Die Namen der Slots findest du z.B. hier: https://github.com/Tinkerforge/esp32-firmware/blob/586496e0e54e6ab4c4fa5e9efe5e6e9877dae3ff/software/web/src/modules/evse_common/translation_de.tsx#L123-L139 (da steht ein TODO an der API-Dokumentation, weil die Slotnamen fehlen, das hat leider noch keiner geschafft einzubauen)

Das liegt vermutlich daran, dass deine WARP2 als Energiewert (für Ladetracker usw.) noch den Bezugs + Einspeisungswert verwendet. Der wird dann auch im Modbus Register 2004 ausgegeben. Details hier: https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/ (letzte Zwischenüberschrift) Du kannst jetzt entweder stattdessen Register 2160 lesen oder wie im Blogpost beschrieben einmal die aufgezeichneten Ladevorgänge löschen, dann wechselt die Wallbox auf den Bezugswert. (Oder das "offizielle" Registerset aus der Testfirmware verwenden)