openWB Forum

Hallo zusammen,

seit dem Update auf 2.1.8p1 habe ich Probleme mit der Datenübertragung der Wechselrichterdaten. Mit der Version 2.1.7 hatte ich mit der gleichen Konfiguration kein Problem.
Ich habe folgendes Setup:

1) Solaredge Master-WR mit einer LG Batterie, AC-seitig angeschlossen
2) Solaredge Slave-WR mit einer LG Batterie, AC-seitig angeschlossen
3) Solaredge Slave-WR mit PV-Modulen
4) OpenWB-Master
5) OpenWB Slave
6) Home Assistant auf einem Synology-NAS als Virtuelle Maschine

Die OpenWB-Master holt sich die Daten vom Master-WR via ModBus. Dabei nutze ich einen Home Assistant ModBus Proxy, auf den der OpenWB-Master zugreift und der Proxy holt wiederum die Daten vom Master-WR. Dies ist notwendig, damit die Home Assistant Integration "SolarEdge Modbus Multi" die Daten für den HA bekommt. HA bekommt auch die Daten und verarbeitet diese korrekt, jedoch hat der OpenWB-Master Probleme.
Die Daten werden nur unvollständig und mit zeitlicher Verzögerung bearbeitet.Weiterhin gibt es immer wieder starke Peaks.
Wird der ModBus Proxy gestoppt und die OpenWB direkt auf den Master-WR umgeleitet, dann funktioniert es.

Das es sich um ein Firmwareproblem des WRs handelt kann ich ausschließen, der der Master-WR eine ältere Firmware (V. 4.22.0) besitzt, mit der die hier skizzierte Konfiguration mit der OpenWB-Version 2.1.7p5 bestens funktioniert hat.
Bei dem Update auf Version 2.1.8p1 habe ich lediglich der zweiten Batterie einen Index 1 geben müssen, da diese Einstellung vorher nicht existierte.

Nachfolgend die Screenshot und die Logs der OpenWB als auch des Modbusproxies.

Hier noch Log des Proxys und der OpenWB

https://paste.openwb.de/7Dad7wJ5fqUE5yI

Wenn ich dich richtig verstehe läuft es aber problemlos wenn der ModbusProxy aus ist und openWB direkten alleinigen Zugriff hat?

Korrekt
oder mit V2.1.7p5 via Modbusproxy

Ich habe noch etwas vergessen.

Es sieht so aus, als würden die Stromerträge der Batteriewechselrichter vom PV-Wechselrichter abgezogen.
Dabei produzieren die keinen PV-Strom, da nur Batterien angeschlossen sind und keine PV-Module.

Und angeblich produziert der PV-Wechselrichter auch nachts Strom.

Und angeblich produziert der PV-Wechselrichter auch nachts Strom.

Schau mal auf das Vorzeichen, vermutlich ist das der Eigenverbrauch.

Einige Änderungen an den SE Modulen gab es um robuster gegen die wackeligeren Firmwares von SE zu machen.
Da müsste man mal ein git diff zwischen den Versionen machen.

Wir haben natürlich eher immer gegen richtige Hardware getestet und nicht gegen einen Proxy. Das kann nun ggf. zu Problemen führen.

Danke für die Erläuterungen.

Kann ich irgendetwas tun?
Bei entsprechenden Tests helfen?
M.E. kommt die Proxy-Lösung öfter vor.
Weil eben mehrere Hausautomatisierungslösungen die Daten von der PV-Anlage bzw. den Batterien brauchen.

Weiterhin bietet die Modbus-Integration für den HA die Möglichkeit die Batterien zu steuern bzw. den SoH auszulesen.

Die unterschiede der Versionen raussuchen um eine Ursache zu finden.

Ist gerade bei SE ein großes Thema. Deren derzeit wackelige Implementation macht es nicht einfacher.
Das Problem haben sie ja schon erkannt. Es muss nur noch ein fix von denn kommen.

"Die unterschiede der Versionen raussuchen um eine Ursache zu finden. "

Danke, aber wie soll ich das machen? Ich selbst kann keinen Downgrade durchführen und alles ausprobieren.
Habt ihr vielleicht einen Tipp, mit welcher Firmwareversion es klappen könnte, dann kann ich SolarEdge um ein Downgrade bitten.


"Einige Änderungen an den SE Modulen gab es um robuster gegen die wackeligeren Firmwares von SE zu machen.
Da müsste man mal ein git diff zwischen den Versionen machen."

Die Änderungen sind für mich jedoch zum Nachteil. Könnt ihr mir denn sagen, was geändert wurde? Dann könnte ich das auch ggf. SolarEdge in einem Ticket mitgeben.

Danke und viele Grüße

Zur Info:

solche Meldungen werden für das Smartmeter geworfen:

Modulmeldung: <class 'pymodbus.exceptions.ConnectionException'> ('ModbusTcpClient(192.168.0.187:502): Connection unexpectedly closed 0.112939 seconds into read of 8 bytes without response from unit before it closed connection', 'Modbus-Client konnte keine Verbindung zu 192.168.0.187:502 aufbauen. Bitte Einstellungen, IP-Adresse und Port sowie Netzwerk-Anschluss prüfen.')