photron

Ich schreibe Register 1288 nie. Das klingt aber fast so, als wären die 128x Register weiterhin Big Endian, anstatt Little Endian. Ich detektiere die Byte Order aus Register 5 und schreibe dann auch Register 1280/1282 entsprechend der Byte Order aus Register 5. Der U32 Wert 60 ist 60,0 in Little Endian und 0,60 in Big Endian. Wenn du also 60,0 schreibst und Kostal versteht das Big Endian, dann kommt da bei Kostal als U32 der Wert 3932160 raus anstatt 60. 3932160 liegt außerhalb des Wertebereichs [30..10800] für Register 1288, daher dann vermutlich der ModbusServerDeviceFailure. Teste mal bitte mit diese Testfirmware. Da schreibe ich die beiden Register 1280/1282 immer Big Endian, auch wenn in Register 5 Little Endian angegeben ist. Falls das das Problem löst scheint mir das ein Bug bei Kostal zu sein, dass die Little Endian Einstellung nicht auf die 128x Register wirkt. energy_manager_v2_firmware_1_8_5_6ada1ff8_99d0429db771a1e_feature-kostal-g3-fix_merged.bin

Das Ablaufen des Timeouts für Register 1034 kann weiterhin nicht an einem Wechsel des Wertes nach 0 erkannt werden. Dein G3 brauch die G3 Spezial-Firmware auf dem Energy Manager. Aber da passieren neue komische Dinge. Hier mal der Ablauf aus dem Log: 2026-10-16 13:08:38: Energy Manager stellt erfolgreiche Verbindung zu Kostal her 2026-10-16 13:23:38: Setzen des "Laden erzwingen" Modus läuft in einen Timeout, funktioniert danach aber 2026-10-16 13:30:02: Setzen des "Laden erzwingen" Modus läuft wieder in einen Timeout, funktioniert danach aber 2026-10-16 13:54:08: Auslesen von Register 1034 zur Prüfung auf 0 läuft in einen Timeout, setzen des Modus "Entladen blockiert" wird dadurch verzögert 2026-10-16 15:45:49: 192.168.188.79 und wattwurm.local schließt die Verbindung zum Energy Manager, erneute Verbindunsgversuche scheitern 2026-10-16 15:48:29: Verbindung zu 192.168.188.79 und wattwurm.local werden wieder hergestellt 2026-10-16 15:48:30: Modbus/TCP Kommuniaktion mit 192.168.188.79 und wattwurm.local scheitern mit ModbusServerDeviceFailure 2026-10-16 15:52:37: Modbus/TCP Kommuniaktion mit 192.168.188.79 funktioniert wieder ohne Fehler, mit wattwurm.local tauchen sporadich bis zum Ende des Logs um 2026-10-21 13:33:54 noch Timeouts und ModbusServerDeviceFailure auf

Leider hat SolarEdge sich entschieden SunSpec nicht sinnvoll zu implementieren. In SunSpec gibt es Modell 160, das die PV Leistung liefert. Leider bietet SolarEdge Modell 160 nur bei den großen Wechselrichtern mit Synergie an. Die kleinen Wechselrichter haben Modell 160 nicht. Dort lese ich die Ausgangsleistungs des Wechselrichters aus SunSpec Modell 103/113 aus und verrechne das mit der Batterieleistung, die SolarEdge nicht in SunSpec bereitstellt, sondern in einer eigenen Registerstabelle. Register 57734/0xE186 beinhaltet den Status von Batterie 1. Ich lese zuerst den Status der Batterie aus, um zu sehen, ob ich etwas verrechnen muss für die PV Leistung. Das Lesen dieses Registers läuft bei dir einen Timeout. Also Modbus/TCP funktioniert bei dir grundsätzlich. Die Wallbox kann sich zum Wechselrichter verbinden, aber dann liefert das Lesen von Register 57734/0xE186 immer wieder einen Timeout. Hast du den SolarEdge SE8K (ohne Batterieanschluss), oder den SolarEdge SE8K-RWS (mit Batterieanschluss)? Ich vermute du hast das Modell ohne Batterieanschluss und SolarEdge hat sich einfach mal wieder falsch entschieden dabei wie sie ihre Registerstabelle implementiert haben. Anstatt im Batterie 1 Status Register mitzuteilen, dass keine Batterie vorhanden ist gibt es einfach keine Antwort, daraus kann ich nur schwerlich etwas ableiten. Versuch mal bitte, nur rein SunSpec zu verwenden. Stell dazu bitte mal die Klasse des Zählers auf SunSpec, führe dann eine Gerätesuche durch und häng das Log der Gerätesuche hier an. Wenn sich das alles so rausstellt, wie ich erwarte dann kann ich damit umgehen und dir eine Testfirmware geben, bei der das Auslesen der PV Leistung funktionieren wird.

@danny007 Speicher mal bitte von der Wallbox unter System > Ereignis-Log einen Debug Report und häng ihn hier an.

@laubblaeser Das klingt nach einem Plan. Am besten wäre, wenn du direkt nach einem "Laden erzwingen" nach "Normal" oder "Entladen blockieren" einen Debug Report herunterladen könntest, mit der normalen 1.8.5 Firmware.

Und wie ist jetzt der Stand mit den NaN Werten in den 1280er Registern? Sind die noch da, oder hat die Umstellung der Bytereihenfolge das jetzt alles korrigiert? [Nachtrag]: Interessant wäre jetzt auch zu sehen, ob bei dir mit der 1.8.5 Release-Firmware, der Übergang von "Laden erzwingen" nach "Entladen blockieren" jetzt doch funktioniert, oder ob für den G3 weiterhin da ein anderes Steurerungsverhalten notwendig ist, dass in der Testfrmware energy_manager_v2_firmware_1_8_5_6abfdb9b_9cd3224ba8ceb1c_feature-kostal-g3-fix vom 2. Oktober enthalten ist.

Wie erkennen und gehen mit der einstellbaren Bytereihenfolge bei Kostal um. Wir erkennen das aber nur einmal nach dem Verbindungsaufbau und nehmen dann an, dass sich das innerhalb einer Verbindung nicht ändert. Anscheinend ändert sich das aber sofort, wenn du es umstellst, auch für bestehende Verbindungen. Daher haben sich die Zählerwerte erst nach einem Neustart berappelt. Soweit alles gut. Das klingt jetzt fast so, als wenn der Timeout der externen Batteriesteuerung im Wechselrichter nicht mehr auf 30 Sekunden, sondern auf sowas wie 5 Sekunden steht. Kontrolliere das bitte mal.

Wenn etwas fehlt, dann sind wir typischerweise einfach noch nicht dazu gekommen.

@N1L5 Hier ein Schuss ins Blaue für die Batteriesteuerung. Damit kannst du jetzt in der Batteriesteuerung einen SolarEdge Batterie anlegen. Zum Testen gehts du am besten über den "Test starten" Knopf auf der Einstellungsseite der Batterie. Sehr hilfreich wäre für mich, wenn du alle 6 Modi durchprobieren könntest und beobachtets, ob sich die Batterie entsprechend verhält. Im Moment musst du noch die "maximale normale Ent-/Ladeleistung" angeben. Das fällt auf Dauer weg. Den Wert kann ich aus einem anderen Register auslesen, aber dass muss ich erst einbauen. warp3_firmware_2_13_5_6ac52d8b_853573e5a3f2405_feature-battery-control-solaredge_merged.bin

@laubblaeser Ist das im Zusammenhang mit der neuen Firmware aufgetreten? Welche Register mit welchen Werten geschrieben werden hat sich zwischen den 3 verschiedenen Varianten, die ich dir für den G3 gegeben habe, nie geändert. Es hat sich nur geändert wann die Register geschrieben werden. Die erste Variante hat die Register einfach immer alle 20 Sekunden geschrieben. Die zweite Variante hat beim Moduswechsel darauf gewartet, dass Register 1034/1035 auf 0 geht, was beim G2 notwendig ist, aber beim G3 nicht funktioniert, da das Register nicht auf 0 geht. Dadurch hattest du die Probleme beim "Entladen blockieren" nach dem "Laden erzwingen", weil dann unendlich darauf gewartet wurde das Register 1034/1035 auf 0 geht, was aber nicht passiert ist und dadurch, dann "Entladen blockieren" nie gesteuert wurde. Die dritte Variante wartet jetzt beim Wechsel von "Laden erzwingen" und "Entladen erzwingen" in einen anderen Modus darauf, dass der "Timeout ext. Bat­te­rie­steu­e­rung [s]" abläuft. Hast du versucht die Batterie an sich neu zu starten?

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

Hier eine aktuelle Firmware mit dem alten Registersatz. energy_manager_v2_firmware_1_8_5_6abfb611_a6ae71f7f1819ce_feature-kostal-g3-debug_merged.bin

Firmware: WARP1 2.13.4, WARP2 2.13.5, WARP3 2.13.5, WARP4 2.13.5, WARP Energy Manager 2.9.5, WARP Energy Manager 2.0 1.8.5 Unterstützung für Netzanschluss- und Batterie-Stromzähler der Sonnenbatterie hinzugefügt Batteriesteuerung: Unterstützung für SunSpec-Modell 124 hinzugefügt (z.B. Fronius-Wechselrichter) Modbus TCP: Robustheit der Netzwerkommunikation verbessert SunSpec: Robustheit der Gerätesuche verbessert Ladetracker: Fehlenden Wallbox-Namen und falschen Monat im monatlichen PDF-Export korrigiert Ladetracker: Robustheit der CSV/PDF-Erzeugung verbessert ISO 15118: Kompatibilität mit BMW iX2- und anderen Modellen mit Delta Electronics OBC verbessert, indem vorläufige SLAC-Anfragen akzeptiert werden (Nur WARP Energy Manager 2.0) Heizung: Maximum der minimalen Haltezeit auf 120 Minuten verlängert Fernzugriff: Neuverbindung nach Hinzufügen eines Accounts mittels Benutzername und Passwort repariert EEBUS: QR Code für SKI hinzugefügt "§14a EnWG"-Automatisierungs-Bedingung hinzugefügt Zeitzonen-Datenbank aktualisiert Übersetzungen verbessert Download: WARP1 2.13.4 bzw. WARP2 2.13.5 bzw. WARP3 2.13.5 bzw. WARP4 2.13.5 bzw. WARP Energy Manager 2.9.5 bzw. WARP Energy Manager 2.0 1.8.5

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.

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.

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.

Aktuell gibt es da nichts Neues von uns dazu. Wenn ich das richtig sehe kann EVCC nur eine Neoom-N Wallbox steuern, aber mit nichts anderem von Neoom interagieren. Für die Neoom Speicher Blokk und Terra gibt es laut deren Dokumentation eine Modbus/TCP Schnittstelle, die wir nutzen könnten: https://wissen.neoom.com/modbus-spezifikation-f%C3%BCr-externe-ems Macht Neoom überhaupt Wechselrichrer? Es scheint mir fasst so, als ob die nur Wallboxen, Speicher und PV-Module machen und dazu Wechselrichrer anderer Hersteller integrieren. Oder die lassen das Wort Wechselrichrer unter den Tisch fallen und reden einfach nur von Speicher. Zumindest kommen in der Dokumentation der Modbus/TCP Schnittstelle nicht die typischen Keywords vor die ich erwarten würde. Hast du mal einen Namen oder einen Link zu dem Neoom Wechselrichter, der dir angeboten wird?

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 ☹️

@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

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 msUm 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?

Korrigierte Firmware ist veröffentlicht.

Korrigierte Firmware ist veröffentlicht.

Firmware: WARP1 2.13.2, WARP2 2.13.2, WARP3 2.13.2, WARP4 2.13.2, WARP Energy Manager 2.9.2, WARP Energy Manager 2.0 1.8.2 Batteriesteuerung: Hinzufügen eines Batteriespeichers repariert Batteriesteuerung: Rücknahme einer Lade-/Entladeblockierung bei Sungrow repariert Home Assistant-Details für Fahrzeugbatterie repariert Langsames Speicherleck in der mDNS-Antwortbehandlung repariert Download: WARP1 2.13.2 bzw. WARP2 2.13.2 bzw. WARP3 2.13.2 bzw. WARP4 2.13.2 bzw. WARP Energy Manager 2.9.2 bzw. WARP Energy Manager 2.0 1.8.2

Okay, danke für's Testen. Repariertes Firmware-Release kommt morgen.

Okay, ich sehe wo das Problem liegt. Hier eine weitere Test-Firmware, die dieses Problem beheben sollte. Könntest du mit dieser Firmware auch einmal den "Laden erzwingen" nach "Normal" Übergang testen, ob dort auch der Speicher im "Laden erzwingen" Modus stecken bliebt? [EDIT: Test-Firmware entfernt]