CptHildi

So, bin aus dem Urlaub zurück, habe die mDNS Stack Size zwischendurch immer mal wieder geprüft (und die Warp auch mehrmals remote neu gestartet). Das Maximum liegt bei 4312, typische andere Werte waren 4280 und 4008 Bytes (meistens unmittelbar nach Neustart). Wer oder was da Stacksize verbraucht, ist einstweilen mal nicht weiter interessant, da es ja recht stabil <= 4312 Bytes zu bleiben scheint. Benötigst Du noch weitere Infos?

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…

@meierchen006 et al: Versuche mich nun auch mal an einer EEBUS-Kopplung zwischen Warp3 mit FW 2.12 und SMA HM2 mit FW 2.17.2.R. Hat das jemand hinbekommen, oder braucht es zwingend 2.18.4.R am HM2? Die Kopplung funktioniert Warp-seitig anscheinend einwandfrei, HM wird entdeckt und EEBUS-Status wird als aktiv gemeldet. Nur seitens SMA wird die Kopplung hartnäckig verweigert und die Warp nicht entdeckt. In dem Zusammenhang: kann man die 2.18.4.R problemlos einspielen, oder besser nicht? Es gab ja so einige Problemreports nach automatischen Updates der WR bei SMA (insbesondere mit den Hybriden, meiner läuft gemäß Grundsatz „Never change a running system“ noch stabil auf 3.06.18.R)…

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

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

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: 79827fa680cb439800150de4f3ccc1533bee02a7passiert 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

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…

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…

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…

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

Ich könnte mal versuchen, ein Packet Capture (mittels Port Mirroring am Switch) mitlaufen zu lassen, weiß nur noch nicht, ob ich das noch zeitnah machen kann (bin die nächsten 2 Wichen im Urlaub…)

Nachtrag: Eigentlich kennt die WB doch die max. erlaubte Ladeleistung des Hausakkus, da diese ja in den Parametern der Batteriesteuerung eingestellt ist... Solange diese nicht erreicht wird (momentane Ladeleistung wird ja ausgelesen), könnte der Regler die WB-Ladeleistung schrittweise reduzieren (natürlich nur solange der SOC unter dem eingestellten Wert liegt)... Nur so als Anregung, kenne natürlich die weiteren Komplexitäten der Steuerung nicht... ;🫣

OK, danke für die prompte Antwort. Die leicht konservative Parametrierung des Regelverhalten habe ich zwischenzeitlich auch schon als Lösung überlegt und entsprechend eingestellt (aber noch nicht testen können). Hatte mich aber gewundert, daß dieses Regelverhalten nach Ladestart durch Anstecken auftritt, dann aber nach zwischenzeitlichem Stop/Start über WebUI eben nicht mehr... Hätte da noch eine (mglw. fehlerhafte) Bedingung / Parameterauswertung vermutet. Der andere Fall mit dem Produktionsüberschuß und gleichzeitiger BEV-Ladung kommt ja nicht so häufig vor (> 10 kW werden bei 12 kWp auf 15° Dachneigung in NW/SO-Ausrichtung eher selten erreicht) und bedarf keiner akuten Optimierung. Gibt es re FW 2.10 + höher und dem "Einfrieren" (des IP Stacks) irgendwelche Erkenntnisse? Kann solange halt keine neuen FW-Versionen / Funktionen testen...

Habe hier nun ein merkwürdiges Phänomen beobachtet: Ladung steht auf PV Wechselnder PV-Überschuß (wg. Wolken) vorhanden, aber immer genug für Minimal-Ladung) Hausakku steht auf < 50% und lädt (max. 10 kW erlaubt) BEV wird angesteckt und erhält Willkommensladung Hausakku steht immer noch < 50% - hätte erwartet, daß die BEV-Ladung nach Willkommensladung stoppt, bis 50% SOC am Hausakku erreicht sind BEV lädt aber lustig weiter (hier im Bild1-phasig), Hausakku erhält nur noch den darüber liegenden Überschuß (dies sollte eigentlich erst auftreten, sobald Hausakku > 50% liegt) Nachdem ich den BEV-Ladevorgang manuell (via Web-Interface) angehalten wieder freigegeben habe, stellt sich das angenommene Verhalten ein: BEV-Ladung pausiert, bis Hausakku > 50% erreicht hat und started dann automatisch. Screenshots (aus iPhone App) und Log (download.txt) attached; Log beinhaltet leider nicht die Pause und das Fortsetzen, da vorher gezogen... Hinweis: bin wegen des "IP-Stack Fehlers" immer noch auf 2.9, da alle neueren Versionen zu unregelmäßigen Reboots oder Hängen des Systems führen... download.txt

… kein Problem - warten wir einfach auf die Rückkehr von MatzeTF aus dem wohlverdienten Urlaub! Nach dem die Zusammenhänge erkannt sind, kann ich ja mittels Workaround (Einstellungen) erstmal Abhilfe schaffen.

Ich kann nachvollziehen, daß Euer Algorithmus auf den Batteriebezug schaut, um den (vermeintlichen) Überschuß zu erkennen und der WB somit die entsprechende Leistung zuschlägt. Aber daß der Zähler am Grid gar nicht auf 0 geregelt wird, scheint dabei dann außen vor gelassen zu werden. Ohne Batterie-Steuerung funktioniert die Überschußsteuerung (nur über den Grid-Zähler) ja hervorragend. Vielleicht müßtet Ihr auch mit einer aktiven Batteriesteuerung den Grid-Zähler weiter berücksichtigen? Ich könnte mir vorstellen (noch nicht ausprobiert), daß der gleiche Fehler auch bei einer (via externer Steuerung über Modbus) erzwungenen Ladung der Batterie auftritt (ich weise via Modbus den WR an, den Akku mit X Watt zu laden, WB sieht die Ladeleistung und schlägt sie dem momentanen Wert zu - der WR kann aber ggf. nicht mehr abgeben, da nicht mehr PV zur Verfügung steht und es entsteht wieder ein Grid-Bezug in Höhe der Batterie-Ladeleistung...). Mittlerweile habe ich den Thread gefunden, in dem das Problem bereits beschrieben wurde (inklusive Workaround-Tip von MatzeTF): https://www.tinkerunity.org/topic/13702-mehr-pv-leistung-als-wechselrichterleistung-f%C3%BChrt-zu-netzbezug-beim-laden/. Trotzdem wäre es wünschenswert, wenn das oben geschilderte bzw. auch zusätzlich beschriebene Szenario mit abgedeckt werden könnten... 🤓 Auf jeden Fall Danke für die Erläuterung und den Hinweis!

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

Servus zusammen! Ich habe jetzt ein paarmal beobachten können, daß im Modus PV-Überschußladen Leistung aus dem Netz gezogen wird - s. Screenshot: Die Situation tritt auf, nachdem eine Wolke durchgezogen ist (~ ab 12:28:30 h). Zunächst gibt es ein Überschwingen in der freigegebenen Ladeleistung (das ist noch akzeptabel), dann settled aber die freigegebene Ladeleistung auf einem Niveau, das zu hoch ist, und zwar um ~ 1 kW. Diese 1 kW können entweder: (zufällig) dem Wert der maximal zulässigen Batterieladung entsprechen (ist hier auf 1000 W eingestellt, paßt also nicht ganz). Allerdings ist der Min-SOC für den Haus-Akku längst erreicht (also keine Bevorzugung der Haus-Akku-Ladung). oder (wahrscheinlicher) aber dem Wert der Überschußleistung der PV gegenüber der Maximalleistung des WR (10 kW) entsprechen - ich habe Werte von knapp über 11 kW PV-Leistung in der SMA-App gesehen. Daher scheint der WR die überschüssige Leistung an den Haus-Akku abzuführen (was erstmal gut ist, somit geht er nicht in die Leistungsbegrenzung / De-Rating). In jedem Fall scheint die Leistungsregelung der Warp damit ein Problem zu haben, da die berechnete mögliche Ladeleistung um genau diesen Wert zu hoch ist. Dadurch entsteht Bezug am Grid mit genau diesem Wert. Eigentlich sollte doch die Smart das Grid im Auge behalten und feststellen, daß Bezug vorliegt und die Ladeleistung entsprechend runterregeln - oder? Vielleicht hilft das beigefügte Log diese Situation besser zu verstehen / debuggen... warp3-2eN4-Debug-Report-2026-07-22T12-31-12-676.txt

Ich habe ziemlich genau das gleiche Problem ab Firmware 2.10 (bis einschließlich 2.12). Lasse derzeit weiter 2.9 laufen, da es hier praktisch nicht auftritt. Hatte bereits diverse Logs geschickt...

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.

Bin da eher bei Till - habe am Anfang auch gedacht - "Nanu, kein Display?" - Einstellungen funktionieren über die App sowieso besser, und zum Laden braucht es absolut nicht mehr, als Lademodus durchtoggeln (Rückmeldung via LED Ring - versteht sogar das nicht technik-affine Wifey). Und ansonsten: App installiert und von überall alles im Zugriff... (wieso sollte ich zur Wallbox laufen, um da was genau sehen / einstellen zu wollen, was ich nicht über die App viel bequemer machen kann...?).

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?