MatzeTF

Lies dir mal diese beiden Threads komplett durch und überlege dann, ob du den Umbau wagen willst. eweri, der in beiden Threads aktiv war, ist auch von einer WARP1 ausgehend gestartet. WARP2 zu WARP3 aufrüsten WARP3 im Selbstbau - die Details Sämtliche Einzelteile einer WARP bekommt man im Shop als Ersatzteile. Im zweiten Thread haben sich auch ein paar Nutzer eine WARP3 selbst gebaut, indem sie einfach alle „Ersatzteile“ gekauft und zusammengebaut haben.

Das dynamische Lastmanagement der Wallbox ist darauf ausgelegt, dass du dort einfach das Limit deines Hausanschlusses einträgst, also in deinem Fall 50 A, und die Wallbox kümmert sich dann darum, dass abhängig von anderen nicht-Wallbox-Verbrauchern der Ladestrom der Wallbox reduziert wird. Ist mehr Strom frei, als die Wallbox freigeben kann, gibt sie den Maximalstrom frei (also 16 oder 32 A). Ist wegen anderer Verbraucher nicht genug Strom frei, reduziert die Wallbox den Ladestrom, um die 50 A am Hausanschluss genau zu halten. 40 A von anderen Verbrauchern → Wallbox gibt 10 A frei. Ist wegen anderer Verbraucher weniger als der minimale Ladestrom frei (6 A), wird die Ladung sofort unterbrochen. Was genau fehlt dir daran, was du durch ein HEMS erledigen lassen möchtest?

Für alle Wallboxen ab WARP2 und neuer ist EEBUS über Netzwerk dafür vorgesehen, aber die WARP1 wird leider kein EEBUS bekommen, da ihr die Prozessor-Ressourcen dazu fehlen. Die WARP1 hat eigentlich auch keinen Abschalteingang, aber du kannst den Kontakt für Taster und Schlüsselschalter dafür missbrauchen. Im Stromlaufplan siehst du oben links den EN-Eingang, an dem Schlüsselschalter und Fronttaster angeschlossen sind. Wenn du eine einfache Signalleitung („Klingeldraht“) in die Wallbox legst, kannst du mit einem Relais die EN-Leitung unterbrechen, was die Wallbox sofort deaktivieren würde. Andernfalls bleibt dir wahrscheinlich nur der Austausch der Wallbox gegen ein neueres Modell oder der Umbau. Hier im Forum haben schon ein paar Nutzer ihre Wallboxen selbst umgerüstet und wenn ich deine alten Posts überfliege, scheinst du ja auch bastelfreudig zu sein. Die Umrüstung von WARP1 zur neuesten Generation ist aber recht aufwändig. Die Hausanschlussüberlastung kannst du schon jetzt mit dem dynamischen Lastmanagement verhindern. Das kannst du unter Energiemanagement → Lastmanagement aktivieren. Der Wallbox ist die Wärmepumpe egal; sie schaut nur auf den Hausanschluss. Wenn der am Limit ist, regelt die Wallbox runter oder schaltet ganz ab, unabhängig davon, ob die andere Last von der Wärmepumpe oder einem anderen Verbraucher verursacht wird.

Das Lastmanagement gibt nur Strom frei, wenn ein Auto angeschlossen und ladewillig ist. Ist kein Auto angeschlossen, wird dort immer die Blockiert-Meldung angezeigt. Welches PV-Menü meinst du? Unter Energiemanagement → PV-Überschussladen sehe ich keine Einstellung für ein- oder dreiphasiges Laden. Meinst du Wallbox → Einstellungen → Zuleitung? Das solltest du auf dreiphasig stellen. Dann wird die Phasenumschaltung bei Bedarf automatisch durchgeführt. Eine Einbindung ins SMA Portal wäre wahrscheinlich rein kosmetisch. EEBUS ist aktuell noch in Arbeit und kommt später per Firmware-Update. Das reine Lastmanagement brauchst du für PV-Überschussladen. Falls du das dynamische Lastmanagement meinst: Das brauchst du, wenn dein Hausanschluss eine kleine Absicherung hat oder du viele größere Verbraucher hast. Hast du nur einen 35 A-Hausanschluss, solltest du das auf jeden Fall aktivieren.

Ich vermute, dass das keinen oder nur einen geringen Einfluss auf die Lebenserwartung des Kabels hat. Die Kabel sind schließlich dafür gemacht, auch häufigen Regen zu tolerieren.

Korrekt. Rollback für die Config, ist, wie so Vieles, angedacht, existiert aber aktuell nicht.

Wie immer macht die Dosis das Gift. Die Ladekabel sind recht widerstandsfähig gegenüber Regen, Salzwasser und Ölen, aber trotzdem wird das Kabel schneller altern, als wenn es trocken aufgehängt wird. Es könnte helfen, am Ende des Winters, wenn nicht mehr gestreut wird, oder wenn jemand Motoröl auf der Straße verloren hat, das Kabel mit klarem Wasser abzuspülen. Meine Vermutung wäre allerdings eher, dass unabhängig von der Feuchtigkeit Schmutzpartikel ein größeres Problem sein könnten, also wenn Regen Split oder anderen scharfkantigen Dreck gegen das Kabel spült und es beim Überfahren der Rampen darauf gedrückt wird oder daran scheuert. Wenn das Kabel unter der Bordsteinrampe für dich ein wichtiges Feature ist, kannst du es natürlich auch einfach als Verschleißartikel betrachten. Falls es dann vielleicht nach fünf Jahren ein Problem hat, lässt du es austauschen. Ein Tinkerforge-Ersatzkabel kann jeder Elektriker vor Ort einfach austauschen; ein Kabel eines anderen Herstellers erfordert ggf. mehr Aufwand, da das offene Ende für die Wallbox angepasst werden muss. Der Zeitraum von fünf Jahren war nur ein Beispiel. Ich habe leider keine Vergleichsdaten für entsprechend verlegte Kabel. Ich glaube aber nicht, dass du jedes Jahr das Kabel tauschen müsstest.

Nein, das ist nicht möglich. Mir sind auch keine entsprechenden Präfixe bekannt. Wenn du einen eigenen OCPP-Server einrichtest und die Wallbox steuern lässt, sollte das möglich sein, allerdings musst du dir dafür halt einen eigenen OCPP-Server einrichten.

Es gibt neue Beta-Firmwares für die Speichersteuerung im ersten Post dieses Threads. Neben allen anderen Verbesserungen aus dem letzten offiziellen Firmware-Release enthält die Beta einen Fix für das vorhin diskutierte Sungrow-Problem und Markierungen für gerade aktive Speicherregeln. Auf weniger gigantischen Monitoren kann man jetzt die Regel-Tabellen horizontal scrollen. Nicht verwirren lassen: Manche Browser zeigen die Scrolleiste aber nicht immer an, sodass es auf den ersten Blick aussieht, als ob rechts etwas fehlt. Wenn vorher schon die Beta vom 23. Dezember lief, sollten mit der neuen Beta alle Speicher- und Regeleinstellungen übernommen werden. Wer viele Regeln angelegt hat, sollte zur Sicherheit trotzdem Screenshots davon machen.

Der Fehler tritt allerdings auch auf, wenn die gewünschte Ladeleistung zu hoch eingestellt ist. Hat das schon mal mit der aktuellen Einstellung funktioniert oder ist der Wert vielleicht einfach zu hoch?

2026-01-30 01:35:31,757 | wh_today=25109 changed 2026-01-30 01:35:31,780 | Discharge 0 match 2026-01-30 01:35:31,780 | Chg=N DChg=B Mode=2 (Entladen verboten) 2026-01-30 01:35:35,267 | wh_today=21051 changed 2026-01-30 01:35:35,284 | Discharge 0 match 2026-01-30 01:35:35,284 | Chg=N DChg=B Mode=2 (Entladen verboten) ... 2026-01-30 02:59:00,001 | Discharge 0 match 2026-01-30 02:59:00,002 | Chg=N DChg=B Mode=2 (Entladen verboten) 2026-01-30 03:00:00,719 | Charge 0 match 2026-01-30 03:00:00,720 | Chg=F DChg=U Mode=3 (Netzladung) ... 2026-01-30 04:59:00,189 | Charge 0 match 2026-01-30 04:59:00,189 | Chg=F DChg=U Mode=3 (Netzladung) 2026-01-30 05:00:00,106 | Chg=N DChg=N Mode=1 (Normal) ... 2026-01-30 05:35:36,961 | wh_today=24972 changed 2026-01-30 05:35:36,986 | Chg=N DChg=N Mode=1 (Normal) 2026-01-30 05:35:40,445 | wh_today=29230 changed 2026-01-30 05:35:40,465 | Chg=N DChg=N Mode=1 (Normal)Laut Log wurde um 3 Uhr von „Entladen verboten“ auf „Netzladung“ gewechselt und um 5 Uhr auf „Normal“. Änderungen bei der PV-Vorhersage gab es gegen 01:35 und 05:35 und blieben immer unter 30 kWh. Die Fehler im Log bedeuten, dass der Speicher das Kommando für die Netzladung nicht angenommen hat. In der letzten Beta gibt es einen Bug dazu, der mit dem nächsten Release repariert wird.

Mich wundert, dass es ein bis zwei Minuten gedauert hat, bis der Pi die Wallbox vergessen hat, nachdem es vorher fast 25 Minuten lang hing. Die Standardeinstellung des WPA Supplicant für nicht antwortende Stations ist fünf Minuten, also hätte ich irgendwas in dem Bereich erwartet: Ich dachte eher daran, dass jemand bewusst seinen AP wieder einschaltet und dann u. U. noch zwei Minuten warten muss, bis sich die Wallbox wieder verbindet. Ich kann das Problem hier mit UniFi-APs nicht reproduzieren. Ich habe den Brick 0, 1, 2 und 3 Sekunden nach dem Got-IP-Event crashen lassen und die WLAN-Verbindung wurde trotzdem immer problemlos aufgebaut. Aktuell ist mir das Verbindungsproblem noch zu nebulös und selten, als dass ich dafür die Zeit für neue Verbindungsversuche derart deutlich verlängern möchte.

Hast du zufällig noch den entsprechenden Abschnitt aus dem Log vom Pi? Möglichst mit den erfolgreichen Verbindungsversuchen davor und danach. Die Retry-Logik ist prinzipiell von uns. Aktuell wird drei Mal mit 10 Sekunden Abstand ein Verbindungsversuch gestartet, danach alle 30 Sekunden. Das auf anderthalb Minuten zu erhöhen, würde bei manchen Verbindungsproblemen schon eine ziemlich lange Verzögerung bedeuten. Das Problem ist, dass die Bibliothek im Hintergrund anscheinend einen eigenen Timeout für DHCP-Leases hat. Den können wir leider nicht beeinflussen.

Da die Verbindungsprobleme einen Neustart der Wallbox überstanden haben, hatte ich schon den Pi in Verdacht. Dass die Session beim Pi hängen bleibt, ist gut möglich, da die WARP direkt nach dem Verbindungsaufbau nicht mehr antwortet und das den Pi durcheinanderbringen könnte. Es ist auch möglich, dass sich die WLAN-Bibliothek der WARP immer mit den selben Session-Daten versucht anzumelden und der Pi das nicht akzeptiert, wenn er die exakt gleichen Daten gerade erst gesehen hat. Während sich die Wallbox die ganze Zeit über WIFI_REASON_AUTH_EXPIRE beschwert, steht im Log des Pi dann nichts Neues? Das Lost-IP-Event habe ich in der Kombination schon mal gesehen. Die WLAN-Bibliothek hat anscheinend einen Bug, der dazu führt, dass ein IP-Timer bei einer getrennten Verbindung nicht richtig abgebrochen wird und dann kurz nach dem erfolgreichen Aufbau der Verbindung auslöst. Da die WLAN-Bibliothek ein Closed-Source-Blob ist, den ich nicht debuggen kann, und sich das Problem sofort selbst behebt, habe ich das nicht weiter verfolgt. [Später] Ich habe nun tatsächlich jemanden gefunden, der genau die gleichen Symptome beobachtet hat. Anscheinend war da der Reset direkt nach dem Verbindungsaufbau relevant. Leider hat derjenige nicht gepostet, wie er schlussendlich das Problem gelöst hat. Andere Nutzer hatten überwiegend das Problem, dass am IO0-Pin des ESP32 eine zu hohe Spannung anlag. Das kann beim ESP32 Ethernet Brick aber eigentlich nicht der Fall sein. Andere Nutzer hatten wohl auch wegen zu schwacher Versorgungsspannung das Problem. Du überlastest nicht zufällig die 3V3-Versorgung mit deinen ganzen zusätzlichen Bricklets? Ansonsten hatten anscheinend auch einige Nutzer Probleme mit DHCP vom AP und eine statische IP hat das Problem gelöst. Danke für deine Ausdauer, dem Problem auf den Grund zu gehen.

Wie lange waren „ein paar Sekunden“? Das 12 V-Netzteil einer WARP1 hält nach einem Stromausfall noch mehrere Sekunden durch. Fünf Sekunden solltest du mindestens warten. Fun-Fact: Ich nutze ein Dual AC In Bricklet an einem ESP32 Ethernet Brick, um die Stromversorgung einer Tauchpumpe für Drainagewasser im Keller zu überwachen, und das Ding kann zuverlässig über Netzwerk den Ausfall seiner eigenen Versorgungsspannung melden. Als Netzteil verwende ich das gleiche, das auch in einer WARP1 sitzt.

Leider haben viele Nutzer ihre WARPs per WLAN verbunden und wenn die Wallbox nach einem Rollback komplett aus dem WLAN verschwinden kann, wüssten wir schon gerne, wie es dazu kommen kann. Ich werde das jetzt trotzdem erstmal nicht weiter verfolgen, da ich hoffe, dass sich das Problem üblicherweise durch ausreichend lange Strom abschalten umgehen lässt. Es ist zwar suspekt, dass Strom abschalten bei dir nicht geholfen hat und du erst USB anschließen musstest, aber das WLAN-Modul speichert nichts über einen Stromausfall hinaus und nach einer gewissen Zeit sollte auch der AP das Gerät vergessen haben. Mir ist allerdings bei der Suche nach dem WLAN-Problem aufgefallen, dass das Arduino-Framework unsere WLAN-Buffereinstellungen überschreibt. Das erklärt zwar nicht dein Problem, könnte aber alte Probleme mit langsamen Verbindungen oder Crashes wegen zu wenig RAM erklären. 🙈

Ich wollte damit nicht sagen, dass die Schuld beim Pi liegt. Ich kann allerdings sagen, dass ich das WLAN-Problem hier mit anderen APs nicht reproduzieren kann. Nach dem Crash wird bei mir ein Rollback durchgeführt und der Brick verbindet sich sofort mit dem WLAN, auch mit aktiviertem BSSID-Lock. Wegen zwei möglicher Ursachen hatte ich vorgeschlagen, mal in den Logs des Pi nachzusehen: Nach dem Rollback sendet der Brick Unsinn und der Pi lässt ihn deswegen nicht rein. Der Pi hat irgendein Problem, das der Brick aber nur durch den Rollback trifft.

Im nächsten Release entferne ich WLAN. 🙈 Dein AP ist angeblich ein Raspberry Pi. Vielleicht sagen dir dessen Logs, warum sich die Wallbox nicht verbinden darf.

Der Brick kann gefahrlos gleichzeitig per USB angeschlossen und vom Netzteil mit Strom versorgt werden, sofern die Wallbox korrekt geerdet ist. Am besten ist ein Laptop im Akkubetrieb, damit keine Erdschleife entstehen kann. Wenn der Berührungsschutz deiner WARP1 installiert ist und somit keine Netzpotential berührbar ist, kannst du den Brick auch im Betrieb per USB verbinden oder trennen. Ist der Berührungsschutz nicht installiert oder aus anderen Gründen Netzpotential berührbar, musst du entsprechend vorsichtig sein und das USB-Kabel ggf. vorher bei abgeschaltetem Strom verbinden.

Der Rollback wird eigentlich direkt beim ersten Crash durchgeführt. Es sollte somit nicht möglich sein, dass die kaputte Firmware ein zweites Mal gestartet wird. Dementsprechend sollte die WARP nach 15 Sekunden (für den Crash) plus der üblichen Neustart-Zeit wieder erreichbar sein. Wäre es möglich, dass du dir die Konsolenausgaben ansiehst, noch während die WARP nicht erreichbar ist, also ohne vorher einmal den Strom abzuschalten?

Ja, das ist ein Stack-Frame vorher. Habe ich eben bei uns auf Master repariert. Verstehe ich das richtig, dass der Brick vorher die ganze Zeit nicht erreichbar war und erst durch Strom aus- und wieder einschalten wieder zum Leben erweckt wurde?

Kannst du den Backtrace gerade einmal in das decode-Script oder gdb werfen? Wenn das hier (↓) ist, ist das seit fünf Minuten bekannt und ich brauche keinen Debug-Report dafür. 😉 0x4013ce97: LpcUsecase::get_current_limit_w() const at /home/user/tf/esp32-firmware/software/src/modules/eebus/eebus_usecases.h:859Edit: Und gefixt.

Das ist schon mal ein guter Hinweis. Ich kann den EEBUS-Crash hier reproduzieren, aber bei mir wird dann anschließend korrekt ein Rollback durchgeführt.

Weißt du, ob der Wechselrichter an den Stromzähler vom Netzbetreiber oder einen anderen externen Netzbezugszähler angeschlossen ist?

Auf welcher Seite des Wechselrichters ist die Wallbox angeschlossen? Load- oder Grid-Seite?