Hallo,

ich wollte heute meine beiden WARP3 auf die neue Firmware Version 2.11.0 heben.

Das hat bei der Wallbox in der Garage (LastManager) nicht funktioniert, es gab kurz nach dem Restart einen Rollback auf die Vorgängerversion V2.10.3.

Bei der Wallbox im Carport (gesteuert vom LM) hat das Update problemlos funktioniert.

Nach einem zweiten Versuch auf der Garagen-Wallbox, der mit dem gleichen Problem geendet habe, habe ich den Debug-Report gezogen und hier mal angehangen.

Könnt ihr damit etwas anfangen?

Gruß Steffen

warp3-2cvd-Debug-Report-2026-06-10T17-42-30-942.txt

Das muss sich @photron ansehen.

Du könntest übrigens mal beim ioBroker MQTT-Server ausschalten, dass beim Verbinden alle eigenen States rausgeschickt werden. Das müllt die Wallbox zu, speziell das Ereignis-Log.

Danke für den Hinweis, hab ich rausgenommen. Wollte ich schon länger machen ist dann aber irgendwie in Vergessenheit geraten 🥺.

Gruß Steffen

Bei mir ebenfalls. Hoffentlich der selbe Bug wie bei Steff49. warp3-2doT-Debug-Report-2026-06-11T07-52-37-449.txt

Ja, das ist der selbe Bug, @photron sieht es sich gerade an

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

Sorry, da ist ein Bug in der Behandlung für die benutzerdefinierte Batteriesteuerung mit Wiederholungs-Interval 0.

Anbei eine korrigierte Testfirmware.

@CptHildi Ich vermute, dass dein Problem ein anderes ist. Im Fall der benutzerdefinierten Batteriesteuerung mit Wiederholinterval 0 crasht die Firmware reproduzierbar sofort beim ersten Senden der Steuerbefehle an die Batterie.

Edit: Veraltete Firmware entfernt.

Danke für die Testfirmware. Ich habe die gerade auf beiden Wallboxen installiert.

Auf der Garagen-Wallbox auf der gestern der Rollback aufgetreten ist konnte ich die nun auch problemlos installieren. Laden geht gerade nicht, da gerade kein Fahrzeug zum Laden da ist.

Ich habe Euch trotzdem einmal von der Garagen-Wallbox einen Debug-Log angehangen weil da nun die folgende Meldung auftaucht (auf beiden Boxen)

2026-06-12 19:12:42,182 | mqtt             | Recv buf is 10240 bytes. batteries/0/config_update requires 17004. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection!

Die Meldung ist mir vorher noch nicht aufgefallen.

Und noch eine Frage - was bedeutet es wenn in der Batteriesteuerung unter Zustand ein Warndreieck mit Ausrufezeichen erscheint? Im Screenshot (Anhang) steht da zwar jetzt Normal aber bevor ich die Testfirmware installiert habe war da eben dieses Warndreieck.

Gruß Steffen

warp3-2cvd-Debug-Report-2026-06-12T19-13-40-565.txt

On 6/12/2026 at 7:23 PM, Steff49 said:

Ich habe Euch trotzdem einmal von der Garagen-Wallbox einen Debug-Log angehangen weil da nun die folgende Meldung auftaucht (auf beiden Boxen)

2026-06-12 19:12:42,182 | mqtt             | Recv buf is 10240 bytes. batteries/0/config_update requires 17004. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection!

Die Meldung ist mir vorher noch nicht aufgefallen.

Das kannst du ignorieren. Ich habe in der Testfirmware einen Wert nicht angepasst, dadurch kommt diese Meldung. Das ist unkritisch und wird in der nächsten Release-Firmware korrigiert sein.

On 6/12/2026 at 7:23 PM, Steff49 said:

Und noch eine Frage - was bedeutet es wenn in der Batteriesteuerung unter Zustand ein Warndreieck mit Ausrufezeichen erscheint? Im Screenshot (Anhang) steht da zwar jetzt Normal aber bevor ich die Testfirmware installiert habe war da eben dieses Warndreieck.

Das Warndreieck kannst du anklicken, um einen Erklärung auszuklappen, ähnlich wie bei den Hilfe-Fragezeichen. Es kann bei der Batteriesteuerung vorkommen, dass abhängig vom Hersteller nicht alle Zustände vollständig umgesetzt werden können. Zum Beispiel ist es bei SAX Power nicht möglich, dass Laden zu erzwingen. In dem Fall wird das Laden auf normal belassen und das Entladen blockiert. Das Warndreiek zeigt dir an, wenn so ein Fall vorliegt, mit Erklärung dazu. In deinem Fall wurde das Warndreiek vorher bei dir aber fälschlicherweise angezeigt.

Da sind zwei Fehler in der aktuellen Firmware, dei bei den in der Testfirmware korrigiert sind. Einmal der Crash bei Wiederholungs-Interval 0 und das der effektive Zustand des Speichers bei benutzerdefinierter Registertabelle undefiniert war, was dann zur falschen Anzeige des Warndreiecks führen konnte. Mit der Testfirmware kannst du jetzt auch bei benutzerdefinierter Registertabelle den effektiven Modus einstellen, Falls der Fall vorliegt, dass es nicht Möglich ist den Speicher gewisse Zustände einnehmen zu lassen.

@photron

vielen Dank für die Rückmeldung.

Mittlerweile habe ich einige Ladevorgänge mit der Testfirmware durchgeführt und konnte keine Probleme feststellen.

Die Zentrale Nutzerverwaltung und den Zentralen Ladetracker muss ich noch testen.

Am 12.6.2026 um 18:20 schrieb photron:

<...>

@CptHildi Ich vermute, dass dein Problem ein anderes ist. <...>

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

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 0x400edc23

Debug-Log (mit Core-Dump) angehängt...

warp3-2eN4-Debug-Report-2026-06-24T14-19-22-547.txt

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

Bisher hat noch keiner drauf geschaut, da letzte Woche alles in den Start der WARP4-Produktion gesteckt wurde. Ich werde es mir heute ansehen. Auf jeden Fall bist du nicht der Einzige mit dem Crash. Leichter zu finden wird er dadurch aber nicht unbedingt. 🙈

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

bearbeitet July 2, 2026 at 07:202. Jul 2026 von CptHildi
Typo...

Nur kurz Zwischenbericht: bin weiterhin auf 2.9 und abgesehen vom "Hick-up" am 24.06. gibt es damit weiterhin keine Aufhänger / Abstürze oder Reboots... Gibt vermutlich nichts Neues zu diesem Problem, oder?

Hier scheint es momentan ja ähnliche Probleme zu geben: https://www.tinkerunity.org/topic/12432-warp3-h%C3%A4ngt-sich-seit-3-tagen-alle-24h-auf/#findComment-62847.

stefan12345352 hat ein Verbindungsproblem auf dem Level von Netzwerkkabel-Wackelkontakt.

Du hast aber einen Crash intern im TCP/IP Code. Wir haben das auch schon von anderen Kunden gesehen und sind dabei das zu debuggen, das Problem ist aber leider noch nicht behoben.

OK, danke für die Rückmeldung... Wenn ich weitere Versuche (i.e. mit neuer FW, anderen Settings etc.) unternehmen soll, einfach Bescheid geben...

Kannst du mal diese Firmware testen, falls du vor deinem Urlaub noch Zeit hast? Darin enthalten sind ein paar Änderungen an der Verwaltung von WebSocket-Verbindungen, bei der es vorher Netzwerkprobleme geben konnte.

Edit: Veraltete Firmware entfernt.

Gestern abend aufgespielt und schon (mindestens) 2 Neustarts gesehen - ohne Ladung, nur im „Leerlauf“.

Meldung im Ereignis-Log:

0,016 | | **** TINKERFORGE WARP3 CHARGER V2.12.1+6A737328 ****

0,022 | | Last reset reason was: Software reset due to exception/panic (4)

0,263 | coredump | Task 'mdns' panicked: '***ERROR*** A stack overflow in task mdns has been detected.'

Backtrace: 0x4008abe1 0x4008aba9 0x4008b34a 0x4008bb4a 0x4008aec4 |<-CORRUPTED

[…und dann Weiter mit Boot-Vorgang]

Log-File attached.

download.txt

bearbeitet August 6, 2026 at 05:126. Aug 2026 von CptHildi

Moin,

kurze Frage. Hast Du rein zufällig ein oder mehrer Amazon Alexa im Netzwerk?

Ja, eine DotClock - aber schon ewig. Keine Konfigurationsänderungen. Unterschied macht Warp-FW: 2.9 läuft, ab 2.10 dann diese Reboots + Freezes.

Nachtrag: die DotClock läuft nicht im gleichen Sub-Netz, habe ich seinerzeit „isoliert“. Somit sollte die WB eigentlich gar keinen Traffic von der DotClock sehen… falls das der Hintergrund der Frage war…

bearbeitet August 6, 2026 at 07:096. Aug 2026 von CptHildi

Hm, wenn der mDNS-Task sich zerlegt, dann versuch mal, ob das Problem verschwindet, wenn du mDNS (und EEBus, das funktioniert ohne mDNS nicht) ausschaltest. Die Implementierung im ESP-IDF ist leider nicht so robust wie man hoffen würde.

EEBUS war schon ausgeschaltet (hatte das nur mal testweise bei Erscheinen von 2.10 ausprobiert), mDNS war aktiv, habe ich jetzt mal ausgeschaltet. Ich berichte…

Am 6.8.2026 um 08:48 schrieb CptHildi:

Ja, eine DotClock - aber schon ewig. Keine Konfigurationsänderungen. Unterschied macht Warp-FW: 2.9 läuft, ab 2.10 dann diese Reboots + Freezes.

Nachtrag: die DotClock läuft nicht im gleichen Sub-Netz, habe ich seinerzeit „isoliert“. Somit sollte die WB eigentlich gar keinen Traffic von der DotClock sehen… falls das der Hintergrund der Frage war…

Ja, die Frage zielte darauf. Denn als ich mDNS gelesen hatte, hatte ich direkt hieran gedacht.
https://www.reddit.com/r/alexa/comments/1tr4zog/buggy_echo_dot_3rd_gen_firmware_flooding_entire/?tl=de

Hätte ja sein können. :)