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...]