CptHildi

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!