CptHildi

Ich würde an dieser Stelle nochmal ganz behutsam die Möglichkeit in den Ring werfen wollen, die Änderung der maximalen Ladeleistung der Batterie auch ohne Neustart der Box übernehmen zu können... [duck wech...🙃] Die passe ich nämlich anhand des zu erwartenden Ertrages (Prognose) gerne an, um eine möglichst gleichmässige (geringe) Ladeleistung über den Tag verteilt zu haben. Gelegentlich möchte ich aber auch bewußt möglichst schnell auf einen höheren SOC (aus PV-Überschuß) kommen, um z.B. das Auto noch aus Überschuß Laden zu können... Ich weiß, da gehört eine externe Steuerung hin, aber diese manuelle Eingriffsmethode reicht mir eigentlich... Weitermachen... 🙂

... und bitte nicht die Werte für die Batteriesteuerung vergessen - die hier: Insbesondere den ersten Wert passe ich desöfteren an die Ertragserwartung an... 😁 (duck wech...)

Vielleicht, weil die Nutzer selbst die Vorzüge der Warp erkennen? Mein Elektriker jedenfalls hatte noch nie davon gehört... 😗

...und vielleicht, daß geänderte Werte in der Batteriesteuerung schon beim Klicken auf "Speichern" übernommen werden und nicht erst durch einen kompletten Reboot... ;-) Weitermachen.

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…)