So, nun nachdem ich das System erst mal grundsätzlich auf dem Raspberry am Laufen habe, habe ich angefangen meine Wechselrichter, Smartmeter usw. zu integrieren. Bei meinen Kostal Plenticore Plus 10 und 8.5 Wechselrichtern, die ich über Modbus TCP auslese klappt das eigentlich schon ganz gut.
Lediglich beim Plenticore 10 bekomme ich den folgenden Fehler
5.5.2022, 15:58:10
WARN
io.openems.edge.bridge.modbus.api.ModbusWorker
[modbus1] FC3ReadHoldingRegisters [pvInverter1;unitid=71;ref=40372/0x9db4;length=2] execution failed: Transaction failed: Illegal Data Address: Illegal Data Address
Das scheint aber irgendwie nicht problematisch zu sein, da mir das UI trotzdem die erzeugte Leistung anzeugt.
Kritischer ist da schon mein Smartmeter SDM630, den ich an einen Waveshare RS485 to Modbus TCP gateway angeschlossen habe. Während meine Hausautomation IPSymcon den Smartmeter problemlos ausließt, klappt das aus openems Edge heraus nur sporadisch. meistens kommt folgender Fehler im Log.
Für die Zeiten wo das Smartmeter nicht ausgelesen werden kann wird natürlich die komplette Erzeugung als Verbrauch gerechnet. Wenn das Smartmeter mal werte liefert, dann stimmt alles.
Ich hatte erst die vermutung, dass es zwischen Hausautomation und openems irgendwie zu Hakeleien bei der Modbus TCP Abfrage kommt, aber dem ist nicht so. Der Fehler tritt in openems auch auf, wenn ich IPSymcon komplett abschalte.
Du meinst sicher den Stromzähler SDM630 von Eastron (oder OEM).
Ich habe 6 von den Dingern imm Einsatz und frage sekündlich mit OpenEMS und 5 minütlich mit fhem per Modbus ab. Bisher keine Probleme. Als Gateway hatte ich früher einen Raspi mit RS485 im Einsatz und jetzt Protoss PE11. Zwischenzeitlich einen Arduino. Letzterer machte öfter Probleme bei kurzen Zykluszeiten.
Eine Anpassung der RS485-Parameter auf 9600,8,N,1 machte es beim Arduino dann besser. Seither verwende ich nur diese Einstellung. Du bist aber sicher keine Unit-ID doppelt vergeben zu haben? Die 1 ist der Standard. Mein Wechselrichter hatte auch die 1 von Hause aus. Also musste ich die SDMs anpassen.
btw: Die PE11 sind die besten Modbus-Gateways die ich je hatte! Das Waveshare kenne ich noch nicht…
Ja genau den von Eastron habe ich und ich habe auch nur einen. Die IDs sind selbstverständlich nicht doppelt vergeben. Die beiden Wechselrichter haben zwar die gleice ID 71 aber unterschiedliche IP Adressen (192.168.178.49 und 192.168.178.41).Beide haben ja ein eigenes Modbus TCP Interface. Für den Eastron SDM630 verwende ich einen separaten TCP Server von Waveshare, auch wiede rmit einer separaten IP Adresse. Industrial serial server, RS485 to RJ45 Ethernet, TCP/IP to serial, rail-mount support | RS485 TO ETH (B)
An dem hängt nur der SDM630 dran. Im System habe ich also drei Modbus TCP Bridges, die jede auf eine andere IP gehen. Der eine Wechselrichter läuft einwandfrei, der zweite scheint irgendwie einen anderen Parametersatz zu haben liefert abe rzumindest die erzeugte Leistung und der SDM630 hängt halt sehr oft.
So, ich hab mal etwas weiter recherchiert. Wenn ich den Raspberry per Ethernetkabel an die Fritzbox anschließe, dann wird es besser mit dem Auslesen über Modbus TCP. Will heißen, die Fehlermelsungen sind nicht ganz weg, aber werden deutlich seltener. Meine Vermutung wäre jetzt, dass es vielleicht mit Latenzzeiten bei der WiFi-Verbindung zu tun haben könnte, da der Raspberry eben per WLAN im Netz, mein Hausautomatisierungrechner, von dem aus es schon immer ging, per Ethernetkabel angebunden ist. Ich schätze, da muss ich noch ein extra Kabel ziehen oder den Raspi im WLAN priorisieren.
Ich gebe es auf!
Leider ist es mir immer noch nicht gelungen eine stabile Verbindung zwischen openems per ModbusTCP und meinem Smartmeter-Gateway herzustellen. Die Verbindung von IPSymcon zum selbigen läuft seit mehr als einem Monat ohne einen einzigen Lesefehler. Da ich jetzt hardwareseitig alles geprüft, teilweise Komponenten ausgetauscht und auf 2.6 geupdatetd habe, kann es eigentlich nur ein Softwareproblem sein. Die Modbus Routinen von openEMS scheinen sehr zeitkritich zu sein. Auch kann ich aus der InfluxDB keine historischen Daten abrufen, obwohl diese vorhanden sind und mit Grafana angezeigt werden. Das hatte ich aber schon mal in einem anderen Thread geschrieben.
Solange ich aber keine stabile Verbindung hin bekomme, macht openEMS für mich keinen Sinn.
Ich warte, bis das System einen stabilen Stand erreicht hat.
Könnte es vielleicht an der Anzahl der gleichzeitigen Verbindungen zum Modbus-GW liegen? Manche Geräte sind da recht zickig…
Versuche mal die Verbindung zum IPSymcon zu deaktivieren. Am besten das Modbus GW resetten um den Socket auch wirklich zu beenden.
…mehr fällt mir leider auch nicht ein. Ich habe aktuell ebenfalls Probleme mit meinem Modbus GW. Die Problematik enstand aber erst nachdem ich einen zusätzlichen Zähler für die Wärmepumpe eingebaut hatte - dieser ist aber noch nicht aktiv (also aus - kein Strom). Könnte daran liegen. Ende der Woche weiß ich mehr.
Dies hat zwar nicht viel mit Deinem Problem zu tun - aber vielleicht gibt es Dir eine Idee…
Gruß,
Klinki
Nein daran kann es nicht liegen. Der Modbus-gateway ist extra dafür ausgelegt. Der Zugriff mit mehrern Instanzen von IPSymcon und zusätzlich noch mit dem modbus Monitor klappen einwandfrei. es ist nur openEMS was da rum zickt.
Da ich aber ohnehin gerade einen Deye Wechselrichter für mein Akkusystem betsllt habe werde ich sowieso selbst ein Modul dafür schreiben müssen. Da versuche ich mal heraus zu finden, woran e sliegt. Bei der Gelegenheit kann ich geich nach der Fehlermeldung schauen, die beim Zugriff auf meinen Plenticore 8.5 kommt, aber beim Plenticore 10 nicht.
Daher werde ich mich mal in die openEMS-Quellen einarbeiten. Da wäre es nicht schlecht, wenn es für Entwickler einen Guide geben würde, wo mal die Klassenstruktur usw. erklärt sind. Gibt es das, kennt jemand den Link oder muss ich da erst suchen?
So, mal ein kleines Update zum Problem mit dem ModbusTCP. Ich habe das jetzt eine Weile beobachtet. Wenn der Raspberry eingeschaltet wird tritt das Problem massiv auf. Da klappt nahezu keine Abfrage und imme rkommt folgender Fehler:
Mit der Zeit jedoch werden die Fehler weniger und nach 2-3 Tagen läuft es stabil. Jetzt frag mich bloß keiner, warum das so ist. Es scheint so, als ob sich da irgendwas vom Timing einspielen muss. Auf jeden Fall ist das ein sehr interessanter efekt, mit dme ich alleridngs icht leben kann. Momentan hab ch noch keinen Akku, aber wenn der erst da ist und das System braucht 3 Tage nach einem reboot um sauber zu arbeiten, dann weiß ich nicht, was es mir dann ales über den Haufen fährt. Auf jeden Fall scheint OpenEMS an etlichen Stellen noch sehr sehr instabil zu sein.