@CptHildi Danke fürs Ausprobieren. Wie sieht es ohne mDNS mit Crashes aus?

Falls es mit ausgeschaltetem mDNS bisher keinen Crash gab, teste bitte diese Firmware und aktiviere mDNS wieder. Bei dieser Version findest du im Webinterface unter System den Punkt „Debug“. Im Abschnitt „Stack-Hochwassermarken“ sollte es eine Zeile namens „mdns“ geben. Die Stackgröße sollte dort als 8.192 B angezeigt werden. Lass das mal eine Weile laufen und wenn es nicht crasht, poste hier mal den Wert von mdns unter „Genutzter Stack“. Falls du morgen in den Urlaub fährst, würde es mir sehr helfen, wenn du vorher noch einmal diesen Wert postest. Alternativ postest du dann nochmal einen frischen Debug-Report, in dem der Wert auch enthalten ist.

warp3_firmware_2_12_1_6a7471a0_3e374682bcdeabe_merged.bin

So, Test-FW läuft seit gut 2 h unauffällig. Die Stackwerte verändern sich nur unwesentlich, jedenfalls wächst nichts in auffälliger Weise. Hast Du etwas geändert? Hier aktuelle Werte für mDNS:

Ich lasse es weiter laufen und ziehe morgen früh nochmal ein Log-File…

bearbeitet August 6, 2026 at 19:166. Aug 2026 von CptHildi

On 8/6/2026 at 9:15 PM, CptHildi said:

Hast Du etwas geändert?

Ich habe die Stackgröße von 4096 auf 8192 erhöht. Da die maximale Stacknutzung aktuell bei 4312 Bytes liegt, hätte es mit der vorigen Firmware also bereits einen Crash gegeben. Lass das mal weiter laufen und beobachte, wie weit sich die Stacknutzung noch erhöht. Abhängig davon werde ich die neue Stackgröße festlegen. Die 8192 habe ich zum Testen absichtlich hoch angesetzt.

Meine Vermutung ist, dass irgendein Gerät in deinem Netzwerk ein mDNS-Paket sendet, das viel Stack-Speicher zum Parsen braucht. Das würde zumindest erklären, warum außer dir kaum jemand das Problem hat und warum wir das hier nicht reproduzieren können: Wir haben dieses andere Gerät einfach nicht. Zum Vergleich: Bei mir liegt die maximale mDNS-Stacknutzung gerade bei 3680 Bytes, also unter dem bisherigen Limit von 4096 Bytes.

Seit gestern abend bisher keine Abstürze etc. Ich hatte heute morgen nochmal neu gestartet, um die Batteriesteuerung anzupassen (da ist ja leider immer noch ein Neustart notwendig). Bei der Gelegenheit auch noch mal EEBUS aktiviert, aber abgesehen von periodischen Einträgen im Ereignis-Log (ca. alle 5 Minuten) - z.B.:

2026-08-07 10:52:09,197 | eebus            | SHIP: Connecting to 1 trusted peer(s)
2026-08-07 10:53:10,968 | eebus            | Closing connection to SMA3017569784.local, SKI: 79827fa680cb439800150de4f3ccc1533bee02a7

passiert diesbezüglich nichts weiter ....

Auffällig sind noch weitere, sich unregelmäßig wiederholende Einträge im Ereignis-Log, die ich aber nicht zuordnen kann (und die bei ausgeschaltetem EEBUS nicht vorkommen), z.B.:

2026-08-07 10:17:01,473 | evse_v2          | all_data_1 -1
...
2026-08-07 10:37:06,192 | nfc_bricklet     | Failed to get tag ID 3, rc: -1

Der mDNS Stack sieht derzeit so aus:

also stabil, aber definitiv größer 4096.

Debug-Log angehängt.

warp3-2eN4-Debug-Report-2026-08-07T16-16-14-363.txt

On 8/7/2026 at 4:17 PM, CptHildi said:

Der mDNS Stack sieht derzeit so aus:

also stabil, aber definitiv größer 4096.

Du hast nicht zufällig vor dem Neustart heute morgen nach den Zahlen geschaut? Ich brauche den größten jemals gesehenen mittleren Wert und bei einem Neustart wird der Wert zurückgesetzt. 4280 ist weniger als der Wert von gestern Abend und hilft mir somit nicht weiter. Falls du nochmal neustarten musst, schau bitte vorher nach dem mittleren Wert und poste ihn hier, falls du mehr als 4312 siehst. Einen Debug-Report brauchst du nicht posten; der eine Wert reicht mir. Bitte schau auch vor deinem Urlaub nochmal danach und poste, ob und wie weit sich der Wert noch erhöht hat.

On 8/7/2026 at 4:17 PM, CptHildi said:

Auffällig sind noch weitere, sich unregelmäßig wiederholende Einträge im Ereignis-Log, die ich aber nicht zuordnen kann (und die bei ausgeschaltetem EEBUS nicht vorkommen), z.B.:

Die ganzen auf -1 endenden Einträge sind Zeitüberschreitungen und die entsprechende Anfrage wird einfach wiederholt. Somit kannst du die bei der aktuellen Menge prinzipiell ignorieren. Im Zusammenhang mit den ganzen EEBUS-Verbindungen sehen wir uns das aber trotzdem mal an.

Der Wert stand heute morgen vor dem Neustart (habe natürlich geschaut) stabil bei 4312... 😉Hatte heute nach dem Neustart auch noch mal ein paar Geräte, von denen ich weiß, daß sie mDNS-Services am laufen haben (z.B. Fire-TV), im Hausnetz ein-/ausgeschaltet, hat aber nichts am derzeitigen Wert von 4280 verändert. Ich hatte auch geschaut, wieviele Geräte mit aktiven mDNS-Services im Netz hängen, das sind wohl mehr als 25 (Shellys, Apple Devices, Hausserver, Switche, SMA-Komponenten und und und...), einige mit bis zu 7 per mDNS angekündigten Diensten, teilweise mit TXT Records von etlichen zig Bytes... Nach dem konkreten mDNS-Traffic habe ich aber mangels Zeit noch nicht schauen können (wenn das überhaupt relevant ist)... Ich kann gerne auch nochmal starten und versuchen zu schauen, wie schnell sich der Stack aufbaut...

On 8/7/2026 at 4:42 PM, CptHildi said:

Der Wert stand heute morgen vor dem Neustart (habe natürlich geschaut) stabil bei 4312... 😉

👍

On 8/7/2026 at 4:42 PM, CptHildi said:

Ich kann gerne auch nochmal starten und versuchen zu schauen, wie schnell sich der Stack aufbaut...

Die Stacknutzung (der mittlere Wert) erhöht sich immer, wenn das erste mal ein mDNS-Paket empfangen wurde, das größer bzw. komplexer als die bisherigen ist. Somit hängt es ganz von den anderen Geräten ab, wie schnell die Stacknutzung wächst. Wird direkt nach einem Neustart das größte Paket empfangen, spring die Stacknutzung sofort auf das Maximum und es ändert sich dann nichts mehr. Werden erst andere Pakete empfangen, wächst die Stacknutzung langsam. Ohne zu wissen, von welchen Geräten welche Pakete kommen, hilft das also nicht weiter.

Wenn du neugierig bist und du zu viel Zeit hast, kann ich dir eine Firmware bauen, die loggt, wann sich die Stacknutzung erhöht. Dann könntest du mit Port-Mirroring alle mDNS-Pakete loggen und nachsehen, welche Pakete es jeweils zu den Zeitpunkten waren, die die Stacknutzung erhöht haben. Damit könntest du gewissermaßen den „Übeltäter“ finden. Außer unsere Neugierde zu befriedigen macht es unterm Stricht aber keinen Unterschied, solange ich einfach die passende maximale Stacknutzung kenne, unabhängig vom Verursacher.

Am 7.8.2026 um 16:54 schrieb MatzeTF:

Somit hängt es ganz von den anderen Geräten ab, wie schnell die Stacknutzung wächst.

... deshalb hatte ich ja heute morgen noch versucht, ein paar Geräte, von denen ich weiß, daß sie mDNS verwenden, einzuschalten - in der Hoffnung, den alten Wert von gestern wieder zu erreichen oder zu übertreffen... Aber so einfach war es dann wohl doch nicht... ;-)

Ich schaue weiter drauf und rühre mich, wenn ich Werte über 4312 sehe...

On 8/7/2026 at 4:17 PM, CptHildi said:

Auffällig sind noch weitere, sich unregelmäßig wiederholende Einträge im Ereignis-Log, die ich aber nicht zuordnen kann (und die bei ausgeschaltetem EEBUS nicht vorkommen),

Dein EEBUS ist nicht richtig eingerichtet. Der Kollege meinte dazu:

Der scheint auf SMA seite nicht trusted zu sein

[…]

Der Verbindet sich zum SMA weil der Kunde den im Webinterface als EEBUS peer hinzugefügt hat, der kommt bis zum Hello, wartet dort auf den SMA und der ghostet ihn dann halt irgendwann wodurch der 1 minute timeout triggered und die Verbindung schließt.
Repeat ad infinitum jedesmal wenn er versuch sich zu den trusted peers zu verbinden. In so einer Situation entweder im SMA hinzufügen damit eine verbindung zustande kommt oder halt in der WARP den EEBUS peer löschen

Am 7.8.2026 um 22:05 schrieb MatzeTF:

…im SMA hinzufügen…

Genau das klappt nicht, vermutlich wegen zu alter FW im HM2. Aus Gründen will ich aber SMA-seitig erst mal keine Updates fahren, also habe ich EEBUS einstweilen abgeschaltet (brauche ich momentan auch nicht).

Der mDNS-Stack wird auch nach wiederholten durchgeführten Neustarts nicht größer als 4312. Ich sehe entweder diesen Wert oder die schon reporteten 4280. Ich laß das Teil jetzt mal über meinen Urlaub so laufen…