CptHildi

So, gestern nachmittag war dann auch mit 2.12 wieder kein Access (kein http, kein Ping) möglich. Link war up, auch ein Portwechsel am Switch hat keine Änderung gebracht (Link up, keine Kommunikation). Letztes Debug-Log wieder angehängt - dort sind mehrere Reboots (inklusive einem automatischen) enthalten, leider wieder kein Core Dump wegen CRC Fehler. Bin wieder auf 2.9 zurück... warp3-2eN4-Debug-Report-2026-07-02T09-08-59-620.txt

Hatte hierzu auch schon mal kurz nachgedacht - könnte man nicht den (bzw. die ) Wert(e) der Batteriesteuerung in der Warp von extern (z.B. Modbus) im laufenden Betrieb anpassen? Dann würde weiterhin nur der Warp-Prozeß über Modbus mit dem WR bzw. der Batterie kommunizieren, man könnte aber die gewünschten Werte von extern dynamisch verändern (hier - wie bei saveman168 - die max. Batterie-Ladeleistung)...

Kurze Rückmeldung zum Thema Batteriesteuerung - Aktivierung bzw.Übernahme der Werte: das funktioniert soweit alles NACH Neustart, dauert nur einen Moment (~ 1 Minute) - hängt sicher mit der umfassenden Zähler- / Kommunikationsaktivierung nach Neustart zusammen. Perfekt wäre es - wie schon oben gesagt - wenn die Übernahme der neuen Werte im laufenden Betrieb OHNE Neustart funktionieren würde. Ist hier einstweilen aber nicht zeitkritisch, just nice-to-have... Weitermachen... (übrigens gestern wieder mal ein erstauntes Gesicht bei einem Wallbox-Suchenden erzeugt, der von den vielen integrierten Möglichkeiten der Warp3Smart, insbesondere rund um das Überschußladen und das Lastmanagement, sichtlich angetan war...) 😎

Hat hier schon mal jemand drauf geschaut und evtl. irgendeinen Hinweis auf die Unregelmäßigkeit entdecken können?

Nachdem ich mit 2.10. und 2.11. ein paarmal Zugriffsprobleme und automatische Reboots hatte, bin ich auf 2.9. zurück, die bis dahin absturzfrei und ohne Probleme lief. Jetzt habe ich allerdings auch mit 2.9 das erste Mal einen automatischen Reboot gesehen (gestern nachmittag, leider eben erst gesehen) - Grund: Task 'tiT' panicked: 'assert failed: multi_heap_free multi_heap_poisoning.c:279 (head != NULL)' Backtrace: 0x4008a915 0x4008a8dd 0x4008e9be 0x4008d53b 0x40082363 0x4008ea31 0x401af4a7 0x401af55e 0x401af59b 0x401b1415 0x401b204d 0x401b20a5 0x401b450a 0x401b954a 0x401af42c 0x400edc23Debug-Log (mit Core-Dump) angehängt... warp3-2eN4-Debug-Report-2026-06-24T14-19-22-547.txt

Einfach ein weiteres LAN-Kabel mit reinwerfen... kann dann ggf. auch für eine einfache Relais-Signalisierung genutzt werden. Bei mir liegen insgesamt 3 Stück drin: 1x LAN Warp3 Smart 1x LAN zum Shelly 3em Pro (wertet die Warp3 Smart zur Warp3 Pro auf) 1x LAN Reserve (nicht angeschlossen)

OK, kein Problem (und keine Eile, da 2.9 ja hier problemlos läuft). Wenn Ihr zusätzliche Details oder weitere Logs braucht, bitte Bescheid geben....

Nur zur Info: Ich hatte dazu auch schon reportet (direkt an Olaf) - bei mir hängt sich die Warp3 Smart ab V2.10 unregelmäßig auf (kein Web-Access mehr, auch nicht remote) oder rebootet eigenständig (irgendein Watchdog-Fehler). Logs dazu hat Olaf. Mit 2.9 läuft alles problemlos...

Als ergänzender Hinweis: ich hatte jetzt 2x innerhalb von 24 h mit 2.10.2 einen Total-Aufhänger der WB - keine Verbindung mehr zum Web-Servers (weder lokal noch remote), keine Antwort auf Ping im LAN (wired), nur einen physikalischen Link. Umstecken auf anderen Switch-Port hat keine Änderung gebracht (Link, aber keine Reaktion auf Ping). 2x durch Pon neu gestartet, dadurch natürlich auch keine (letzten) Log-Einträge vor dem Hänger... Bin auf 2.10.1 zurück...

Hier dito - Log: 2026-05-11 12:55:19,166 | solar_forecast | Forecast download failed: ESP_ERR_MBEDTLS_SSL_HANDSHAKE_FAILED (0x801A); SSL - A field in a message was incorrect or inconsistent with other fields (0x6600) 2026-05-11 12:55:19,189 | solar_forecast | Next solar forecast API call will be in 30 minutes 2026-05-11 12:55:19,202 | solar_forecast | Error while downloading solar forecast: ESP_ERR_HTTP_CONNECT (0x7002) 2026-05-11 12:55:19,203 | solar_forecast | Next solar forecast API call will be in 30 minutes 2026-05-11 13:25:19,659 | solar_forecast | Forecast download failed: ESP_ERR_MBEDTLS_SSL_HANDSHAKE_FAILED (0x801A); SSL - A field in a message was incorrect or inconsistent with other fields (0x6600) 2026-05-11 13:25:19,682 | solar_forecast | Next solar forecast API call will be in 30 minutes 2026-05-11 13:25:19,694 | solar_forecast | Error while downloading solar forecast: ESP_ERR_HTTP_CONNECT (0x7002) 2026-05-11 13:25:19,695 | solar_forecast | Next solar forecast API call will be in 30 minutes 2026-05-11 13:35:21,949 | remote_access | Opening connection 2 for user 0 2026-05-11 13:35:22,832 | remote_access | Connection 2 for user 0 connected 2026-05-11 13:36:34,750 | remote_access | Opening connection 4 for user 0 2026-05-11 13:36:35,606 | remote_access | Connection 4 for user 0 connected 2026-05-11 13:39:28,720 | remote_access | Closing connection 2 for user 0 2026-05-11 13:55:20,150 | solar_forecast | Forecast download failed: ESP_ERR_MBEDTLS_SSL_HANDSHAKE_FAILED (0x801A); SSL - A field in a message was incorrect or inconsistent with other fields (0x6600) 2026-05-11 13:55:20,173 | solar_forecast | Next solar forecast API call will be in 30 minutes 2026-05-11 13:55:20,186 | solar_forecast | Error while downloading solar forecast: ESP_ERR_HTTP_CONNECT (0x7002) 2026-05-11 13:55:20,186 | solar_forecast | Next solar forecast API call will be in 30 minutes Seit letztem SW-Update (warp3_firmware_2_10_2_69fdc0c5_merged - zuvor mit warp3_firmware_2_10_1_69e9e031_merged keine Probleme) - hängt vielleicht mit den wieder hinzugefügten Zertifikaten zusammen? Log file angehängt... warp3-2eN4-Debug-Report-2026-05-11T13-54-58-570.txt

Sollte sich das Problem nicht einfach mit aktiviertem MAC Address Filtering lösen lassen? Setzt natürlich einen (managed) Switch voraus, der das unterstützt...

...oder einen Shelly pro 3em in der Anschlußleitung zuordnen, dann wird aus der Smart eben auch eine Pro (zumindest hinsichtlich Leistungsmessung, allerdings ohne MID-Eichung)... 😉

Batteriesteuerung ist aktiviert. Allerdings ist nur eine Regel angelegt - Entlade-Sperre bei Schnellladung. Die funktioniert auch, wird aber momentan gar nicht aufgerufen, da seit 1 Monat genug vom Dach kommt und nur mittels PV-Überschuß geladen wird. Könnte also sein, daß alles gut gespeichert ist (nach Neustart), aber es zu keiner initialen Auslösung kommt, die die Werte dann auch zum WR sendet. Da ich aber die Internas nicht kenne, ist das nur Vermutung... Debug-Report muß leider noch warten, da ich gerade in USA bin...

Ich hätte in diesem Zusammenhang eine Frage zur Persistierung bzw. Anwendung der in der Batteriesteuerung eingetragenen Werte: Man kann die Werte (temporär) verändern und testen (mit eine der 6 Funktionen). Nach Test-Stopp gelten die alten / zuvor hinterlegten Werte weiter. Nun kann man die Werte "Übernehmen" (Maske schließt) und muß dann wohl auch noch "Speichern". Keiner der Schritte scheint aber die neuen Werte auch ab diesem Zeitpunkt anzuwenden, zumindest wird bei mir bei Ertrags-Überschuß die Batterie im Normalbetrieb weiter mit den zuvor gültigen Werten geladen. Mit der Aktion "Speichern" wird auch die Message "Neustart" aufgerufen (die man abwählen oder bestätigen kann). Ist hier der Neustart zwingend notwendig zur Persistierung / Anwendung der Werte? Ein Neustart der Warp3 alleine scheint aber auch noch keine Wirkung auf die augenblickliche Ladeleistungseinstellung zu haben, da die Batterie immer noch mit dem alten Wert weitergeladen wird. Erst wenn ich wieder im Testmodus in der Batteriesteuerung eine Funktion aufrufe (da reicht schon "Normal laden / Entladen"), findet der gespeicherte Wert auch Anwendung (d.h. die Ladeleistung wird entsprechend angepaßt). Es wäre schon mal hilfreich, wenn ich auf den Schritt "Neustart" verzichten könnte... (oder vielleicht habe ich es nur nicht richtig getestet bzw. übersehen?) (Hintergund: ich passe die max. Ladeleistung für den Überschußbetrieb entsprechend des zu erwartenden PV-Tagesertrages derzeit manuell an - hohe erlaubte Leistung bei wenig Ertragserwartung, niedrigerer Wert für langsameres Laden bei höherer Ertragsleistung. Zukünftige Automation angedacht, aber noch nicht weiter evaluiert... evcc, HA, NodeRed etc.).

Ich fände beides eine willkommene Erweiterung... ;-) [aber beides keinesfalls lebensnotwendig...]

Grundsätzlich brauchst Du mindestens 1360 W zum Laden. Wenn Du also mit nur 800 W Überschuß laden möchtest, mußt Du den "PV+Min"-Modus aktivieren. Damit das nicht in der Nacht passiert, kannst Du entweder a) bei eingestelltem Lademodus "PV+Min" mittels Automatisierungsregeln den Ladevorgang zwischen (beispielsweise) 18 h und 8 h blockieren (Regel 1: steuere Ladevorgang - ab 18 h blockieren, Regel 2: steuere Ladevorgang - ab 8 h freigeben) oder b) mittels Automatisierungsregeln den Lademodus entsprechend wechseln (Regel 1: ab 8 h Lademodus "PV+Min", Regel 2: ab 18 h Lademodus "PV" oder "aus"). Habe aber beides nicht selbst ausprobiert, sollte aber schnell getestet sein... Deine Einstellung mit 3,6 kW Min verstehe ich nicht...

Willkommen im Forum! Die Einbindung ins SMA EnnexOS-Portal kann über einen vorgeschalteten Shelly (zB. Pro 3em) erfolgen, der als „Nebeneffekt“ aus der Warp3 Smart eine Warp3 Pro macht. Allerdings siehst Du die Wallbox im Portal nur als Verbraucher, nicht jedoch in der grafischen Hauptansicht. Für mich hat das aber keinen tatsächlichen Nutz-/Mehrwert, wohl aber die exakte Erfassung der tatsächlich ins Auto geladenen Energie. Alles andere hat Matze hervorragend beschrieben (läßt sich aber mit wenig Recherche auch in den Anleitungen und hier im Forum leicht finden) - und PV-Überschußladen sowie dynamisches Lastmanagement funktionieren mit „Bordmitteln“ der Smart auch ohne evcc hervorragend.

Mache ich gerne... Momentan ist es eine reine manuelle Steuerung (An/Aus, gewünschte Batterieleistung --> negativ = Laden, positiv = Entladen, 0 = Sperre). Ein Timer sorgt dafür, daß die aktuellen Einstellungen regelmäßg gesendet werden (ich sende die aktuellen Werte alle 60 s, scheint aber ausreichend, hier alle 30 Minuten für ein Update zu sorgen). Der Rest sind einfach nur nette Visuals für die aktuellen Werte. Eine dynamische Steuerung der Batterieleistung wäre natürlich mit entsprechendem Regelwerk (aka Programmierung) auch machbar (z.B. für verzögertes Laden, Lade- / Entladeleistungsbegrenzung, zeitgesteiuertes Laden etc.), aber für diesen Anwendungszweck nicht notwendig. Sinnvoller ist eine externe / intelligente Steuermöglichkeit, die bei bestimmten Betriebssituationen die Sperre aktiviert (z.B. Schnellladen, Sauna eingeschaltet etc.). Die Übernahme in die Warp 3 Smart / Pro sollte sehr einfach möglich sein. Wenn es die Möglichkeit gäbe, Modbus-Befehle direkt zu konfigurieren und ereignisgesteuert zu versenden, hätte ich es schon direkt selbst per Automatisierungsregeln (z.B. wenn Schnellladen aktiv und Lademodus = "lädt" --> Sperre ein) eingebaut... 😉 Einstweilen funktioniert derzeit soweit alles wie gewünscht ohne Auffälligkeiten...

App "richtig" beenden. Nach Neustart Verbindung neu aufbauen... geht bei mir immer...

Kurzer Bericht von mir zum Thema: Ich hatte eigentlich vorgehabt, in die Batteriesteuerung mit den 6 Registern (so, wie seitens Tinkerforge vorgesehen) testend einzusteigen. Brauchte aber recht schnell eine pragmatische Lösung für die gelegentlich notwendigen Schnelladevorgänge, bei denen ich ein "Absaugen" der Hausbatterie mit maximaler Entladeleistung gerne verhindern möchte. Habe als erstes eine SoC-Begrenzung via Web-Oberfläche probiert - funktioniert herorragend (einfach SoC [Minimum width of backup power area] auf den aktuellen Ladestand setzen, danach findet keine Entladung mehr statt). Dies funktioniert auch via Modbus (40723), das ist aber ein Parameter-Register und sollte nicht dauerhaft beschrieben werden. Da hier noch kein HA oder ähnliches läuft, habe ich dann ein Modbus-Tool für iOS gesucht und bin mit Virtuino IoT fündig geworden. Dies ermöglicht eine kostenlose Nutzung in einem begrenzten Umfang und ist auch für Android verfügbar. Habe mir damit ein Projekt gebastelt, womit ich mittels der Register 40149 (Lade-/Entladeleistungsvorgabe) und 40151 (Ladesteuerung) den gleichen Effekt erzielen kann. Die GUI hat einen recht hohen ist WAF (zumindest hier... 😉) und kann auch für andere "Betriebsumstände", z.B. Batteriesperre bei Saunabetrieb (in typischerweise PV-Überschußarmen Zeiten 🙃) und erzwungene Batterieladung / -entladung genutzt werden: 1 - Normalbetrieb 2 - Batteriesperre 3 - erzwungene Ladung mit 2000 W Reicht bei mir einstweilen, aber an eine von der WB ausgehende Steuerung bin ich natürlich weiterhin interessiert. Final werde ich wohl aber um eine externe Steuerung (z.B. HA, NodeRed, evcc etc.) nicht herum kommen (s. Anwendungsfall Sauna) - zumal auch der Eingriff mittels "6-Register-Satz" die Deaktivierung des prognose-basierten Ladens am SHM2 / SMA-Portal notwendig macht (dies ist für die oben geschilderte Lösung via 40149 / 40151 nicht notwendig). Bei Bedarf teile ich gerne das Virtuino IoT-Projekt (ist aber nach kurzer Einarbeitung auch recht einfach selbst zu erstellbar).

Fehler sehe ich auch gelegentlich - einfach App beenden und neu starten...

Bei "Min +PV" wird immer mit der angegebenen Mindestleistung geladen, egal ob Überschuß zur Verfügung steht oder nicht. Wenn nicht genügend Überschuß anliegt, wird auch aus der Batterie umgeladen. Wenn der vorhandene Überschuß > Mindestleistung ist, sollte aus dem Überschuß weitergeladen werden. Wenn Du nur aus dem Überschuß laden willst, wähle den Lademodus "PV", dann unterbricht die WB allerdings den Ladevorgang, wenn die konfigurierte Mindestleistung nicht als Überschuß vorhanden ist. Das komplette Sperren der Batterie während der BEV-Ladung gestaltet sich schwieriger und bedarf einer erweiterten Steuerung via Modbus - hierzu gibt es einige Threads (und das Entwicklerteam ist auch dran, dies zu unterstützen).

Ich hole mal mein pragmatische Vorgehen dazu noch mal raus: https://www.photovoltaikforum.com/thread/249226-erfahrung-mit-der-warp3-wallbox-11-22kw/?postID=4393488#post4393488. Ja, etwas Auffeilen (an der Durchführung des Stutzen) war notwendig und ja, IP65 ist streng genommen nicht mehr gegeben, aber etwas Silikon schafft hier sicher Abhilfe (und bei mir hängt die WB trocken).

OK, danke für die Analyse und die absolut nachvollziehbaren Erklärungen... insbesondere hinsichtlich der 3 Minuten am Ladestart (hatte ich wohl schon mal irgendnwo gelesen, aber wieder vergessen...). Re SMA Shadefix: das läßt sich nicht sinnvoll abstellen (nur das Intervall kann man ändern). Somit muß man eben aufpassen, daß die Dauer des Wolkenfilters und des Shadefix-Intervalls zueinander passen (also Shadefix > Wolkenfilter). Bei Wolkenfilter "mittel" (4 Minuten) sollte es mit dem Standardwert vom Shadefix (6 Minuten) klappen; wenn man Wolkenfilter auf "stark" setzt, wird wohl kein Phasenwechsel mehr erfolgen (sofern man nicht auch das Shadefix-Interval entsprechend verlängert - dies als Hinweis an andere SMA-Nutzer). Ich denke, es wäre wohl möglich, einen entsprechenden Filter für die sehr kurzen "Ausreißer" (Eurerseits) zu programmieren, aber das wäre wohl etwas zu viel verlangt, da es ja nur (?) die SMA-Nutzer betrifft... Re Ladestopp Batterie: ja, mit der (experimentellen) FW hatte ich schon rumgespielt und auch mein "Erfolgserlebnis" dazu gepostet: (...und folgende Posts). Ich habe dann angefangen, manuell per ModBus mit den verschiedenen Registersätzen zu spielen, die Entladeblockierung und Wiederfreigabe läßt sich mit den beiden Registern 40149/40151 ("2-Register-Steuerung") jedenfalls bewerkstelligen. An die "6-Register-Steuerung" bin ich noch nicht wieder rangegangen...

So, bin nun endlich zum Testen der 2.8.8+68b09baa gekommen. Der Verlauf und die Erkenntnisse sind im anhängenden PDF skizziert. Wen nur die Erkenntnisse interessieren, bitte die letzte Seite anschauen. Hier ganz kurz: - PV-Überschußladen unter Einbeziehung des Batteriezählers funktioniert soweit (einige Ungereimtheiten zu nicht erwartbarem, aber eher geringem Batterie-Bezug bleiben, ggf. auf Grund der aktuellen Parameter-Einstellung; hier wäre eine detailliertere Beschreibung des Regelmechanismus unter Einbeziehung der Parameter-Kombinationen hilfreich) - automatische Umschaltung 1-/3-phasig und zurück funktioniert problemlos - ebenso manuelle Umschaltung PV-Überschußladen --> Schnellladen - Schnellladen saugt (erwartbar) maximal am Haus-Akku, daher ist eine zusätzliche Batteriesteuerung (mindestens Bezugsblockade während des Schnelladens) wünschenswert 2 Debug-Logs sind auch noch angehängt, evtl. können die Aufschluß über das Regelverhalten bezüglich Batteriebezug geben... Wir sind auf einem sehr guten Weg... Danke für Eure unermüdliche Arbeit! Ladetest 01.09.25.pdf Debug-Log 20250901 1405.txt Debug-Log 20250901 1412.txt