mbu

Hallo, ich betreibe einen WARP Charger Pro 1 mit 11 kW gedrosselt (Firmware 2.10.0+69e8cc76, EVSE-Bricklet fw 2.1.13) unter Steuerung durch EVCC 0.305.1. Externe Steuerung ist aktiv (evse/external_enabled: true). Ladevorgänge mit meinem MG4 brechen beim PV-Überschussladen (PV und Min+PV Einstellung in EVCC) regelmäßig nach 20–90 Sekunden ab. Normale Ladevorgänge ohne Anpassung von EVCC an den PV Überschuss (Schnell) laufen ohne Probleme durch. Das System ist reproduzierbar instabil. Die Einrichtung habe ich mit verschiedenen Möglichkeiten mit der Claude KI versucht. Letztendlich aber erfolglos. Da ich mich technisch in dieser Materie nicht auskenne, habe ich Logs vom Warp Charger, EVCC und ein Ladelog erstellt und von Cloud auswerten lassen um das Problem bzw. Fehlkonfiguration zu finden. Hier nun das Ergebnis ohne Anspruch zu erheben das es tatsächlich so ist. Wie gesagt ich kenne mich nicht aus und habe es deshalb der KI gegeben. Aber evtl. ist das ja tatsächlich das Problem. Claude hat alle drei verfügbaren Logs ausgewertet und zwei voneinander unabhängige Probleme identifiziert. Folgendes hat Cloude formuliert und ich hoffe das es jemand bestätigen oder prüfen kann, da ich so PV-Überschussladen nicht durchführen kann. „Das erste Problem ist ein MQTT-Empfangspuffer-Overflow. Im Ladeprotokoll-Eventlog erscheint folgender Eintrag: automation/config_update requires 4225 bytes. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! EVCC sendet Nachrichten auf dem Topic automation/config_update mit 4225 Bytes, der WARP-Empfangspuffer beträgt jedoch nur 4096 Bytes. Die Nachricht wird abgeschnitten, die MQTT-Verbindung destabilisiert und in der Folge gehen Steuerbefehle (external_current) verloren, was den Ladevorgang abbricht. Das zweite Problem sind akkumulierende SpiTfp-Kommunikationsfehler auf Port C, an dem das EVSE-Bricklet angeschlossen ist. Diese Fehler wachsen aktiv während des Betriebs: Im ersten Debug-Report zeigten sich SpiTfpChecksum 1 und SpiTfpFrame 6, etwa eine Stunde später im Ladeprotokoll bereits SpiTfpChecksum 7 und SpiTfpFrame 14. Alle letzten Boots zeigen reset_reason: 3 (ESP_RST_SW), also einen deliberaten Software-Reset über esp_restart(). Im EVCC-Log ist der Zusammenhang direkt sichtbar: [warp-ws] ERROR received close frame: status = StatusGoingAway and reason = "ESP reboot" gefolgt von [lp-1] INFO stop charging. Fehler auf anderen Ports (A, B, D, E, F) sind durchgehend null, was Port C als einzige Fehlerquelle isoliert. Das beobachtete Verhalten im Ladeprotokoll zeigt eine regelmäßige Charger-State-Oszillation zwischen State 3 (Laden) und State 2 (bereit, nicht ladend), teilweise mit Aussetzern von nur einer Sekunde Dauer, zum Beispiel: State 2→3 um 11:23:32, State 3→2 um 11:24:00 (28 Sekunden), State 2→3 um 11:24:05, State 3→2 um 11:24:06 (1 Sekunde), State 2→3 um 11:24:10, State 3→2 um 11:24:50 (40 Sekunden). Eine Session lief 14 Minuten stabil (11:42:20 bis 11:56:44), was zeigt dass das System grundsätzlich funktionieren kann. Meine Fragen: Ist der MQTT-Buffer-Overflow auf automation/config_update (4225 > 4096 Bytes) bekannt und gibt es einen Fix oder Workaround? Was triggert esp_restart() bei akkumulierenden SpiTfp-Fehlern auf dem EVSE-Bricklet-Port, und ist ein Zusammenhang bekannt? Können die 1-Sekunden-Charger-State-Aussetzer durch SpiTfp-Kommunikationsfehler auf Port C verursacht werden?“ Alle drei Logs sind angehängt: WARP Debug-Report, WARP Ladeprotokoll und EVCC Debug-Log. Danke und Grüße Marco warp-USZ-EVSE-Ladeprotokoll-2026-04-27T12-03-29-711.txt evcc-20260427-113939-debug.log download.txt