laubblaeser

Könnte damit besser leben, wenn es nicht nach monatelangem Betrieb plötzlich das ganze System zum Stillstand bringt. Hätte natürlich bevorzugt die Einstellung von Anfang an korrekt zu setzen, um gar nicht erst in diese Situation zu kommen. Naja, wieder was gelernt. Ist doch auch schön, dass ich das hier dokumentiere, damit andere nicht den gleichen Kram durchmachen müssen. Eben FOSS durch und durch, ganz besonders auch in der Community. :)

Nach wochenlangem hin und her mit dem Kostal Support (und vielen grauen Haaren meinerseits) ist die Ursache wohl gefunden: Modbus muss im Wechselrichter auf CDAB Bytereihenfolge stehen, wenn man daran nur einen Batteriespeicher und keine PV angeschlossen hat. Bei mir stand es seit über einem halben Jahr auf ABCD und funktionierte bis vor kurzem auch tadellos. Die Notwendigkeit, die Modbus Bytereihenfolge so einzustellen, ist seitens Kostal auch nirgends dokumentiert. Nach der Umstellung sponn kurz der mittels Sunspec Modell 113 eingerichtete Zähler für den Wechselrichter in der WARP Software, was sich aber mithilfe eines Neustarts des WARP Gerätes beheben ließ.

Seit wann genau die Register mit Datenmüll beschrieben sind, weiß ich leider nicht, da ich sie erst gestern händisch ausgelesen habe. Ich weiß nur, dass die Probleme seit 1.8.0 begonnen haben, aber das muss nicht zwingend etwas mit den jetzt vorhandenen NaN Werten zu tun haben. Das erscheint mir gerade auch als der sinnvollste Weg, daher lass ich auch die letzte von dir modifizierte 1.8.5 drauf. Ja. Das führte zu der weiter oben beschriebenen rund 24 Stunden andauernden Ausgleichladung mit 1kW Ladeleistung. Das BMS hat sich nach dem Neustart wohl gerne einmal komplett neu kalibrieren wollen, weil die Batterie zu dem Zeitpunkt nur noch 21% hatte. Dabei bestand aber der Fehler in den Modbus Registern offensichtlich schon, denn die Werte sprangen ja im 5 Sekunden Rhythmus wild auf und ab, sobald ich die Batteriesteuerung im HEMS aktivierte.

Jupp, da ist was ganz dolle kaputt in den Registern 1280-1289, die für die Batteriesteuerung zuständig sind. AdrD AdrH NumD NumH Idx Hex AS Binary [15..0] U16 S16 U32BE U32LE S32BE S32LE F32BE F32LE U64BE U64LE S64BE S64LE F64BE F64LE 1280 500 1281 501 0 FFFF .. 1111 1111 1111 1111 65535 -1 1281 501 1282 502 1 7F7F .. 0111 1111 0111 1111 32639 32639 4294934399 2139095039 -32897 2139095039 NaN 3.4028234663852886e+38 1282 502 1283 503 2 FFFF .. 1111 1111 1111 1111 65535 -1 1283 503 1284 504 3 7F7F .. 0111 1111 0111 1111 32639 32639 4294934399 2139095039 -32897 2139095039 NaN 3.4028234663852886e+38 18446602786465349503 9187343237679939583 -141287244202113 9187343237679939583 NaN 1.4044474254567505e+306 1284 504 1285 505 4 FFFF .. 1111 1111 1111 1111 65535 -1 1285 505 1286 506 5 7F7F .. 0111 1111 0111 1111 32639 32639 4294934399 2139095039 -32897 2139095039 NaN 3.4028234663852886e+38 1286 506 1287 507 6 FFFF .. 1111 1111 1111 1111 65535 -1 1287 507 1288 508 7 7F7F .. 0111 1111 0111 1111 32639 32639 4294934399 2139095039 -32897 2139095039 NaN 3.4028234663852886e+38 18446602786465349503 9187343237679939583 -141287244202113 9187343237679939583 NaN 1.4044474254567505e+306 1288 508 1289 509 8 0000 .. 0000 0000 0000 0000 0 0 1289 509 1290 50A 9 003C .< 0000 0000 0011 1100 60 60 60 3932160 60 3932160 8.407790785948902e-44 5.510129769479473e-39 ASCII: ...................<Der Timeout (1288-1289) steht wie üblich auf den voreingestellten 60 Sekunden, aber die anderen vier Registerpaare sollten als Float (F32BE) gelesen werden und die sind alle vier als NaN angezeigt. 😵 Also nicht nur falsch beschriebene Werte in 1280-1283 sondern auch die zwei Registerpaare für Fallback (1284-1287). Wie kann denn so was passieren und wie zum Henker bekomme ich das wieder behoben?! Habe bereits vieles probiert, u.a. manuell die WR Firmware neu eingespielt, die Batteriesteuerung im WR auf intern gestellt und später wieder auf extern via Modbus, den WR mehrmals neu gestartet, usw. Edit: Habe versucht die Register 1280-1287 mit Nullen zu überschreiben, was auch für etwa 5 Sekunden funktioniert, aber dann springen alle Registerwerte wieder auf das oben gepostete NaN zurück.

Also irgendwas passt da jetzt so gar nicht mehr bei mir. Die WEM2 Batteriesteuerung habe ich gerade deaktiviert, weil es heftig mit irgendwas kollidiert. Das BMS forciert seit einigen Stunden eine Ausgleichladung mit maximal 1 kW, daran kann und will ich auch gar nichts ändern. Sobald ich im WEM2 die Batteriesteuerung aktiviere, schaltet sich nach erfolgter Vorprüfung der "normal" Zustand ein. Sobald das passiert ist, springt die Ladeleistung trotz laufender Ausgleichladung wild im 5 Sekunden Takt zwischen 1 und 15 kW (Maximalleistung des WR) hin und her. Da gibt es wohl heftig kollidierende Kommunikationsprobleme zwischen Modbus des WR und BMS der Batterie. Das ist super wild, denn eigentlich gibt das HEMS ja gerade keinerlei Anweisungen über Modbus raus. Da muss also irgendwas krass schief laufen. Irgendwelche Ideen hierzu? Bin echt ratlos, was da passiert. Ich lass die WEM2 Batteriesteuerung jetzt aus bis die Ausgleichladung abgeschlossen ist. Danach probier ich mal ein zwei Testläufe über den Energy Manager.

@photron Kannst du mir bitte noch eine gefixte Firmware mit 1.8.5 als Basis für den WEM2 erstellen? Ich hatte seit heute Morgen mit 1.8.4 einen Crashloop wegen des Versands des Ladelogs und möchte nach Möglichkeit aber nicht auf die Batteriesteuerung verzichten. Habe gerade den regulären 1.8.5 Release installiert, damit der WEM2 überhaupt wieder läuft. Danke!

Bisher (also vor 1.8.0) klappte bei mir eigentlich immer die Umschaltung zwischen den Modi ohne dass ich Probleme festgestellt hätte. Sicher gibt's irgendeinen edge case, den ich gerade nicht sehe. Hilf mir mal auf die Sprünge bitte.

1288/1289 haben den Wert 60, das ist also wie in der Modbus Doku beschrieben ein komplett eigenständiger Wert.

Mit Option 2 scheint es mir, als funktionierte alles wieder wie davor. Ich lass die Firmware jetzt mal drauf und teste das morgen nochmal, wenn ich auch das Auto wieder eingesteckt habe. Danke für's Kümmern so weit schon mal! wem2-2gbS-Debug-Report-2026-09-26T10-27-10-576.txt

Mit Option 1 funktionierte es nicht. Nach dem erzwungenen Laden direkt in Entladen blockieren gewechselt. Vorbedingungen nicht erfüllt. Danach war die Batteriesteuerung generell blockiert mit der Meldung "Keine aktive Steu­e­rung, prüfe Vor­be­din­gung". wem2-2gbS-Debug-Report-2026-09-26T10-15-30-825.txt

Wenn das Lesen eines Modbus Registers echt den Watchdog zurücksetzt, dann läuft da was bei Kostal schief imho. 🤨

Ich probiere das Testvorgehen gerne aus, sobald der Strompreis mal wieder für ne Stunde niedrig genug ist. (Gaskathis Wirtschaftspolitik macht den Strommarkt die letzten Wochen leider ziemlich kaputt und die Preise spielen ziemlich verrückt.)

Steht schon seit Ewigkeiten auf 30 Sekunden. Nein. Sorry, weiß nicht was du mit 2.9.0 meinst. (2.13.4 wäre die aktuelle Versionsnummer der WARP Charger Firmware?) Vor dem Update des WEM2 auf 1.8.0 (aktuell 1.8.4) habe ich dieses Problem nicht festgestellt und ich lade häufig am Wochenende über mehrere Stunden das Auto und belade zeitgleich die Batterie vom Netz. (Bei meiner relativ kleinen PV und großen Batterie lohnt sich das im dynamischen Stromtarif.)

Gerade getestet. Batterie wurde vor kurzem wegen günstiger Strompreise zwangsgeladen, danach einmal die Wallbox angemacht. Batterie entlädt wieder obwohl sie gesperrt sein sollte. wem2-2gbS-Debug-Report-2026-09-20T14-51-49-532.txt

Hatte gestern schon die logs gezogen, aber ich versuch das Verhalten heute noch mal zu provozieren und lade dann direkt nochmal die logs. Evtl finden sich darin ja mehr Infos.

Selber Fehler trat gerade noch mal auf, nachdem die Batterie sich nach dem Neustart des Wechselrichters wieder auf den Zielwert vom Netz beladen hatte. Der Entladeblock danach warf einen Fehler und funktionierte nicht. Habe im Konfigurationsmenü des Batteriespeichers die Testfunktion angeworfen. Beim Entladeblock kam ein Fehler, dass eine Voraussetzung für diesen Modus nicht erfüllt ist: Starte Test für Modus "normal Laden, Entladen blockieren" Verbinde zu wattwurm.local:1502 KOSTAL PLENTICORE G3 meldet Big-Endian Byte-Reihenfolge Prüfe Vorbedingung für Modus "normal Laden, Entladen blockieren" Vorbedingung des Modus "normal Laden, Entladen blockieren" nicht erfüllt bei Registerblock 1 von 3 Der"Normal" Modus warf den gleichen Fehler. Der "Alles Blocken" Modus ließ sich testen, aber nur für wenige Sekunden und anschließend entludt sich die Batterie direkt wieder, obwohl im Interface eine aktive Regel angezeigt wird. Da ist auf jeden Fall das Problem im Moduswechsel begraben.

Der Wechselrichter Neustart hat geholfen. Sehr komisches Verhalten, denn wenige Minuten zuvor wurde die Batterieregel zum erzwungenen Laden der Hausbatterie noch korrekt ausgeführt und nachdem das mit Erreichen des Ziel-SOCs abgeschlossen war, war der WR wohl nicht mehr erreichbar, um die Entladung zu blockieren. Werde das mal im Blick behalten, ob das noch mal vorkommt. Da scheint wieder irgendwas mit den Wechseln zwischen den Zuständen im Batteriemanagement nicht zu funktionieren, obwohl das doch erst in einer der letzten Versionen hatte verbessert werden sollen? Hatte vor 1.8.x keine Probleme damit. Mit welcher genauen Patchversion das Problem dann begann, kann ich leider nicht nachvollziehen. :/

Hi, heute ist mir beim Auto laden aufgefallen, dass die Regeln zum blockieren des Entladens nicht mehr greifen und stattdessen die Hausbatterie in die Autobatterie entladen wird. Im Log steht folgendes: 2026-09-19 14:25:07,164 | batteries_mbtcp | Battery 0: Check of precondition for mode "charge normally, block discharge" failed at register block 1 of 3: Timeout (263) / After 498 ticks, 0 recvs, 2002 ms Ich versuch es jetzt mal noch mit einem Neustart des Wechselrichters (Kostal Plenticore G3), aber da ist wohl irgendwas in den letzten Updates schief gelaufen? Letzte Woche klappte es noch alles normal. Sowohl WEM als auch WARP3 sind auf den aktuellsten Firmwares.

Ah, damit hast du wahrscheinlich den Nagel auf den Kopf getroffen. Seit 2.8 gibt's ja die Autodiscovery für den WEM2, die ich dann auch mal aktiviert habe. Da scheinen sich jetzt, wie du wohl richtig vermutest, die topic prefixes zu beißen. Kenne mich mit MQTT nicht aus, daher wäre ich hier um weitere Hilfe dankbar. Beide Geräte haben derzeit den Topic-Präfix energy und jeweils eine eigene Client-ID. Wieso überschreibt sich hier dann etwas? Und wie muss ich es einstellen, dass beide gleichzeitig funktionieren? Danke schon mal! :)

Hm, die Google Passwortverwaltung nutze ich nicht. Ich benutze eine KeePass Datenbank für alle meine Passwörter (konkret KeePassDX als App) und das Autofill funktioniert in anderen Apps (allen voran Firefox) sehr gut über die Tastatur. Auch beim Login in die App selbst, also den WARP Account für Fernzugriff, funktioniert das wie gewohnt. Nur eben nicht bei der Login-Seite, wenn man sich über die App lokal bei einem Gerät anmelden will. Ließe es sich einrichten, dass das auch funktioniert?

Nee, eben nicht. Da scheint irgendwas in der MQTT Kommunikation zwischen WARP3 und HA nicht zu passen. Die autodiscovery Werte vom WEM2 in HA sehen nebenbei bemerkt gut aus. Debug Report der WARP3 ist anbei. Was genau ich bei HA für ein hilfreiches Log in Bezug auf dieses MQTT Gerät machen muss, weiß ich leider nicht. warp3-2hdj-Debug-Report-2026-09-12T17-42-52-605.txt

In Home Assistant springen alle Sensoren, die mit "Zähler WARP Charger" beginnen. Nicht nur zwischen 0 und sinnvollen Werten, sondern auch ins negative bei manchen Sensoren. Sehr wild. Die Sensoren des Netzanschlusszählers sehen stabil aus bis auf Strom L1, L2 und L3, welche zwischen 0 und einem sinnvollen Wert hin und her hüpfen. Im Interface der WARP3 selbst sind die Werte des integrierten Eltako Zählers stabil. (Wirkenergie auf korrektem Wert, Frequenz auf zweiter Nachkommastelle leicht schwankend, Wirkleistung stabil auf 0 W)

Seit dem Update auf 2.13.0 und heute auch weiterhin mit 2.13.1 bezieht die WARP3 laut Home Assistant Strom im Leerlauf. Es ist kein Auto angeschlossen, aber der Leistungszähler springt auf und ab, zwischendurch liegt der Bezug im kW Bereich. Es wird nun also nicht mehr der interne MID Zähler in mqtt gemeldet, sondern der Netzanschluss im HAK. In Home Assistant sind nun zwei Reihen an Sensoren vorhanden und einer davon spinnt rum (Werte springen sekündlich zwischen 0 und sinnvoller Anzeige). Das war vorher nicht so. Was hat sich da seitdem geändert? Wie bekomme ich das wieder sinnvoll hin?

Habe heute die App aktualisiert und 2.13.1 bzw. 1.8.1 installiert. Die App meldet mich jetzt gerne komplett ab und nach Neuanmeldung hat er sich auch nicht die zuvor schon eingegebenen Anmeldedaten der lokalen Verbindungen gemerkt. Was genau ist denn da jetzt das erwartete Verhalten? Nicht, dass ich ganz falsche Erwartungen habe.

Das würde mich auch freuen. Momentan ist es leider so, dass in der App zwar ein lokaler Zugriff möglich ist (schönes neues Feature btw), aber mein Autofill dort nicht funktioniert. Mag evtl an irgendwelchen Einstellungen auf meinem Android Smartphone liegen, aber ließe sich das eventuell so programmieren, dass die App sich den lokalen Login merken kann?