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.

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

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.

Edited September 19, 2026 at 02:52 PMSep 19, 2026 by laubblaeser
mehr Infos

Bitte direkt nachdem das Problem aufgetreten ist, einen Debug-Report runterladen und hier anhängen. @photron kann sich das dann ansehen. Ich weiß aber nicht, wann er dazu kommt.

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.

Wenn die Logs von gestern jeweils direkt nachdem das Problem auftrat runtergeladen wurden, sind die auch okay. Häng einfach die an.

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

Es gibt sporadisch Kommunikationsprobleme mit dem Wechselrichter. Leider reicht das detallierte Trace Log nur bis 2026-09-20 13:02:03 zurück.

Dieser einzelne Modbus-Timeout ist im Trace Log. Das ist aber nur ein einzelner Modbus-Timeout, danach ging es ohne Fehler weiter. Die anderen Kommunikationsprobleme sind leider schon rausrotiert.

2026-09-20 14:20:09,804 | batteries_mbtcp  | Battery 0: Setting mode "force charge, block discharge" failed at register block 2 of 3: Timeout (263) / After 512 ticks, 0 recvs, 2002 ms

Um 2026-09-20 14:42:59 wurde von "Laden erzwingen" nach "Entladen blockieren" gewechselt. Dabei warte ich jetzt seit Energy Manager v2 Firmware 2.9.0 darauf, dass der Watchdog im Wechselrichter das Register 1034 auf 0 zurücksetzt, um zu prüfen wann das "Laden erzwingen" wirklich beendet wurde. Das ist aber bis zum Ende des Trace Logs um 2026-09-20 14:51:23 nicht passiert.

Ich nehme mal an du hast den "Timeout ext. Bat­te­rie­steu­e­rung [s]" im Wechselrichter nicht hochgestellt? Bzw. auf was steht dieser Wert in deinem Wechselrichter?

Hast du mit der aktuellen Firmware überhaupt schon einen erfolgreichen Wechsel von "Laden erzwingen" nach "Entladen blockieren" gesehen?

Funktioniert es besser mit Energy Manager v2 Firmware < 2.9.0 1.8.0?

Am 21.9.2026 um 13:50 schrieb photron:

Ich nehme mal an du hast den "Timeout ext. Bat­te­rie­steu­e­rung [s]" im Wechselrichter nicht hochgestellt? Bzw. auf was steht dieser Wert in deinem Wechselrichter?

Steht schon seit Ewigkeiten auf 30 Sekunden.

Am 21.9.2026 um 13:50 schrieb photron:

Hast du mit der aktuellen Firmware überhaupt schon einen erfolgreichen Wechsel von "Laden erzwingen" nach "Entladen blockieren" gesehen?

Nein.

Am 21.9.2026 um 13:50 schrieb photron:

Funktioniert es besser mit Energy Manager v2 Firmware < 2.9.0?

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

@laubblaeser Ich habe WEM1 und WEM2 verwechselt. 2.9.0 ist die erste WEM1 Firmware mit den vermutlich problematischen Änderungen für Kostal G3. Für WEM2 ist das Firmware 1.8.0.

Hier zwei Testfirmware

• Aktuelle Firmware mit ein paar Änderungen im Detail: energy_manager_v2_firmware_1_8_4_6ab259b6_30b79274d704b5e_merged.bin

• Aktuelle Firmware mit der Kostal G3 Registertabelle auf dem Stand von vor Firmware 1.8.0: energy_manager_v2_firmware_1_8_4_6ab25c35_5496aabb88774b2_feature-kostal-g3-debug_merged.bin

Kannst du bitte mit beiden Firmwares folgenden Ablauf durchführen:

• Die Batteriesteuerung des WEM2 deaktivieren und mindestens 1 Minute warten, damit sicher der 30 Sekunden Timeout im Wechselrichter abgelaufen ist

• Über den Testmodus den Speicher in "Laden erzwingen" schicken und den Test 5 Minuten laufen lassen

• Über den Testmodus den Speicher in "Entladen blockieren" schicken und den Test 5 Minuten laufen lassen

• Direkt danach einen Debug Report herunterladen

energy_manager_v2_firmware_1_8_4_6ab259b6_30b79274d704b5e_merged.bin energy_manager_v2_firmware_1_8_4_6ab25c35_5496aabb88774b2_feature-kostal-g3-debug_merged.bin

Ich habe es gerade nochmal mit einem Kostal Plenticore G2 getestet und dort funktioniert die Batteriesteuerung mit der aktuellen WARP Firmware genau wie erwartet.

Ich lese Register 1038 zurück, um zu erkennen wann der Watchdog das erzwungene Ent-/Laden zurückgenommen hat. Dieses Lesen aber wiederrum scheint bei deinem G3 dafür zu sorgen, dass der Watchdog nicht abläuft ☹️

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

Am 22.9.2026 um 19:01 schrieb photron:

Dieses Lesen aber wiederrum scheint bei deinem G3 dafür zu sorgen, dass der Watchdog nicht abläuft ☹️

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

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

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

Register 1034/1035 bliebt bei dir auf dem letzten geschriebenen Wert stehen. Beim G2 des anderen Testkunden springt das Register auf 0 zurück, wenn der "Timeout ext. Bat­te­rie­steu­e­rung [s]" abgelaufen ist. Durch wiederholtes Lesen des Register erkenne ich, wenn das der Fall ist und ich in einen Modus ohne erzwungenes Laden/Entladen wechseln kann.

Dieser Mechanismus funktioniert leider bei deinem G3 nicht. Entweder hält Lesen des Registers den Timeout auf, oder das Register springt beim G3 generell nicht auf 0 zurück, wenn der Timeout abgelaufen ist. Von deinen vorherigen Schildrungen klingt es fast nach zweiterem.

Könntest du nochmal einen Test mit der energy_manager_v2_firmware_1_8_4_6ab259b6_30b79274d704b5e_merged.bin Firmware machen?

Gleicher Ablauf wie zuvor mit der zusätzlichen Frage, ob die Batterie 30 Sekunden nach dem Wechsel von "Laden erzwingen" nach "Entladen blockieren" mit dem erzwungenen Laden aufhört, während der Test für's "Entladen blockieren" weiterhin meldet, dass die Vorbedingung nicht erfüllt sei und es vom Register 1034/1035 weiterhin so aussieht als würde "Laden erzwingen" weiterhin anliegen.

Wenn dem so ist, dann kann ich an Register 1034/1035 nicht erkennen wann der Timeout angelaufen ist. Aber der G3 hat Register 1288/1289, das dem G2 fehlt. Die Frage dazu ist, ob das ein eigener Timeout nur für die Register 1280/1281 und 1282/1283 ist, oder ob das der Timeout ist, der auch für Register 1034/1035 gilt.

Könntest du das bei dir ausprobieren? Also Register 1288/1289 lesen und falls dort 30 Sekunden drin steht die "Timeout ext. Bat­te­rie­steu­e­rung [s]" Einstellung ändern und prüfen, ob sich Register 1288/1289 entsprechend mit ändert?

Wenn das der Fall ist, dann kann ich für den G3 den Timeout für Register 1034/1035 aus Register 1288/1289 auslesen und entsprechend mitrechnen.

Am 28.9.2026 um 09:57 schrieb photron:

Könntest du das bei dir ausprobieren? Also Register 1288/1289 lesen und falls dort 30 Sekunden drin steht die "Timeout ext. Bat­te­rie­steu­e­rung [s]" Einstellung ändern und prüfen, ob sich Register 1288/1289 entsprechend mit ändert?

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

Dann wird die Lösung sein müssen, dass man beim G3 den "Timeout ext. Bat­te­rie­steu­e­rung [s]" in die WARP Batteriesteuerung übertragen muss, da ich keine andere Möglichkeit sehe damit sonst richtig umzugehen.

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.

Beim G3 funktioniert die Steuerung grundsätzlich, aber durch dass ich das erzwungene Laden/Entladen nicht aktiv abbrechen kann, sondern das nur durch den Watchdog beendet werden kann, wird z.B. beim Übergang von "Laden erzwingen" nach "Entladen blockieren" sofort "Entladen blockieren" im Webinterface der Wallbox angezeigt, wobei aber eigentlich für die Dauer des "Timeout ext. Bat­te­rie­steu­e­rung [s]" die Batterie weiter erzwungen lädt, auch wenn ich schon "Entladen blockieren" anzeige und auch steuere. Wobei "Entladen blockieren" normales Laden und nicht erzwungens Laden impliziert.

Das ist also eher kosmetisch, führt dann aber dennoch zu Verwirrung beim Kunden, vorallem wenn der "Timeout ext. Bat­te­rie­steu­e­rung [s]" länger ist. Bei meinem G2 Testkunden steht das z.B. auf 3 Minuten.

@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!

Hier eine aktuelle Firmware mit dem alten Registersatz.

energy_manager_v2_firmware_1_8_5_6abfb611_a6ae71f7f1819ce_feature-kostal-g3-debug_merged.bin

Hier eine Firmware die mit dem "Timeout ext. Bat­te­rie­steu­e­rung [s]" des G3 jetzt besser umgeht und nicht einfach nur ignoriert.

energy_manager_v2_firmware_1_8_5_6abfdb9b_9cd3224ba8ceb1c_feature-kostal-g3-fix_merged.bin

Am 2.10.2026 um 18:36 schrieb photron:

Hier eine Firmware die mit dem "Timeout ext. Bat­te­rie­steu­e­rung [s]" des G3 jetzt besser umgeht und nicht einfach nur ignoriert.

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.

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.

Edited October 4, 2026 at 12:12 PMOct 4, 2026 by laubblaeser
Mehr Tests