Test Adapter sun2000 v0.1.x - Huawei Wechselrichter
-
Über Nacht hatte ich nun das ganze Log voll mit Abfragetimeouts. Logisch, da der zweite WR ja in Standby geht und nicht mehr abgefragt werden kann. Aber der Adapter sollte das berücksichtigen. Ich denke, dass hier sich auch das Abfrage Intervall ändert durch die Berechnung. Zumindest meldete der Adapter das.
-
@dragst3r das kann ich sicherlich berücksichtigen. Da ich nur ein WR habe und nachts keine Timeouts sehe habe ich ein paar Fragen:
-
Treten bei beiden WR modbus IDs die Timeouts auf, oder nur beim dem Slave der in den Standby geht?
-
Welche DeviceStates (sun2000.0.inverter.0.deviceStatus und sun2000.0.inverter.1.deviceStatus) findest du am Tag bzw. in der Nacht bei beiden WR?
In den States sun2000.0.inverter.x.derived.deviceStatus steht jeweils der Klartext zu den DeviceSates.
Stephan
-
-
@dragst3r das kann ich sicherlich berücksichtigen. Da ich nur ein WR habe und nachts keine Timeouts sehe habe ich ein paar Fragen:
-
Treten bei beiden WR modbus IDs die Timeouts auf, oder nur beim dem Slave der in den Standby geht?
-
Welche DeviceStates (sun2000.0.inverter.0.deviceStatus und sun2000.0.inverter.1.deviceStatus) findest du am Tag bzw. in der Nacht bei beiden WR?
In den States sun2000.0.inverter.x.derived.deviceStatus steht jeweils der Klartext zu den DeviceSates.
Stephan
-
-
@bolliy Antwort zu
1: Nein nur beim Slave mit "Reg 32064, Len: 2 modbusID: 2 with Timed out"2: Werte zu Inverter 1: 40960 mit Standby, no irradiation und Inverter 2: 2 mit Standby, detecting irrdadiation
-
@dragst3r TimeOut Fehler treten nur beim Lesen des Reg 32064 auf?
Hast du am Slave einen Speicher hängen, oder nur am Master? -
@bolliy Gar keinen Speicher :) aber das FusionSolar Portal zeigt mir einen Dummy Speicher an mit Null Werten :-D
-
@dragst3r Frage: Gab es nachts nur TimeOut Fehler beim Lesen des Reg 32064 auf dem Slave - oder traten auch Timeouts beim Lesen anderer Reg auf?
-
Hallo zusammen,
erstmal vielen Dank an bolliy, endlich ein Adapter für den sun2000.
Der wohl bemerkt schon super funktioniert.
Ich benutze zur Zeit aber noch das ganze über Node-Red.
Ich habe da eine Verständnis Frage, warum das ganze immer über ein Paket läuft wo alles abgefragt wird und ob es vielleicht irgendwann eine Möglichkeit besteht verschiedene Pakete mit verschiedenen Zeitintervalle zur Abfrage möglich ist?
Ich finde es toll z.b. wenn bei PV String Power oder Hausverbrauch sowie Akkuladeleistung, Akkuentladeleistung eine Abfrage innerhalb von ca. 3sek. Und andere Daten mit einem längeren Abfrageintervall.Gruß LUB 104
-
Hallo zusammen,
erstmal vielen Dank an bolliy, endlich ein Adapter für den sun2000.
Der wohl bemerkt schon super funktioniert.
Ich benutze zur Zeit aber noch das ganze über Node-Red.
Ich habe da eine Verständnis Frage, warum das ganze immer über ein Paket läuft wo alles abgefragt wird und ob es vielleicht irgendwann eine Möglichkeit besteht verschiedene Pakete mit verschiedenen Zeitintervalle zur Abfrage möglich ist?
Ich finde es toll z.b. wenn bei PV String Power oder Hausverbrauch sowie Akkuladeleistung, Akkuentladeleistung eine Abfrage innerhalb von ca. 3sek. Und andere Daten mit einem längeren Abfrageintervall.Gruß LUB 104
@lub104 der Adapter verfügt eigentlich über 2 Intervalle (high, low). Die Real-time Daten werden immer im eingestellten Intervall (1ter Intervall) gelesen. Der 2te Intervall wird aus dem 1ten Intervall berechnet (wenn der eingestellte Intervall < 1 Minute dann ist der 2te Intervall 1 Minute sonst low Intervall = high Intervall).
Im 2ten Intervall werden nur so viel Daten gelesen bis der Verarbeitungszeitpunkt des 1ten Intervalls wieder einsetzt. So divergieren über die Laufzeit der Lesezeitpunkt der Daten im 2ten Intervall, da im 2ten Intervall nicht alle Daten gelesen werden können. Im Mittel hat man aber so eine schnelle aber auch über die vielen Daten aktuelles Abbild der States.Und dann gibt es noch statische States zb. im info Pfad, die werden nur einmal gelesen.
Ich hoffe, das Konzept einigermaßen erklärt zu haben.
LG Stephan
-
@lub104 der Adapter verfügt eigentlich über 2 Intervalle (high, low). Die Real-time Daten werden immer im eingestellten Intervall (1ter Intervall) gelesen. Der 2te Intervall wird aus dem 1ten Intervall berechnet (wenn der eingestellte Intervall < 1 Minute dann ist der 2te Intervall 1 Minute sonst low Intervall = high Intervall).
Im 2ten Intervall werden nur so viel Daten gelesen bis der Verarbeitungszeitpunkt des 1ten Intervalls wieder einsetzt. So divergieren über die Laufzeit der Lesezeitpunkt der Daten im 2ten Intervall, da im 2ten Intervall nicht alle Daten gelesen werden können. Im Mittel hat man aber so eine schnelle aber auch über die vielen Daten aktuelles Abbild der States.Und dann gibt es noch statische States zb. im info Pfad, die werden nur einmal gelesen.
Ich hoffe, das Konzept einigermaßen erklärt zu haben.
LG Stephan
-
Ich meine es so zu verstehen. Ich stelle den Intervall auf 5Sek für Highlevel und dann ist der Lowlevel 1min.
Richtig?
-
Einige Slave Inverter gehen nach Sonnenuntergang in einen Standby mode (deviceStatus=2, Standby, detecting irrdadiation). Die Modbus Schnittstelle des Slave Inverters ist dann per tcp nicht mehr erreichbar (offline)!
In der neuen Entwickler-Version unterbinde ich die modbus-Anfragen sofern der Inverter in den Standby mode übergeht. Nach dem Ausbleiben der Anfragen an den Slave-Inverter, kann ich natürlich keine Veränderungen des deviceStatus mitbekommen. Deshalb fange ich nach Sonnenaufgang des nächsten Tages automatisch wieder mit den Anfragen an.
Da ich nur einen WR habe, kann ich das Verhalten nicht testen und bin auf eure Mithilfe angewiesen!
Die Installation erfolgt über den Expertenmodus. Danach auf die „Krakenkatze“ klicken und dann die benutzerdefinierte Urlhttps://github.com/bolliy/ioBroker.sun2000/tarball/dev
eingeben und die Installation starten.
Nach der Installation muss die Instanz manuell neu gestartet werden!
Ich freue mich auf eine rege Beteiligung. ;)
-
@lub104 der Adapter verfügt eigentlich über 2 Intervalle (high, low). Die Real-time Daten werden immer im eingestellten Intervall (1ter Intervall) gelesen. Der 2te Intervall wird aus dem 1ten Intervall berechnet (wenn der eingestellte Intervall < 1 Minute dann ist der 2te Intervall 1 Minute sonst low Intervall = high Intervall).
Im 2ten Intervall werden nur so viel Daten gelesen bis der Verarbeitungszeitpunkt des 1ten Intervalls wieder einsetzt. So divergieren über die Laufzeit der Lesezeitpunkt der Daten im 2ten Intervall, da im 2ten Intervall nicht alle Daten gelesen werden können. Im Mittel hat man aber so eine schnelle aber auch über die vielen Daten aktuelles Abbild der States.Und dann gibt es noch statische States zb. im info Pfad, die werden nur einmal gelesen.
Ich hoffe, das Konzept einigermaßen erklärt zu haben.
LG Stephan
-
@bolliy
Kannst du die Erklärung mit den Datenpunkten Highlevel bei GitHub auf der Infoseite mit rein bringen, dann fragt vielleicht auch keiner sowie ich nach. Fände ich super -
@trackerthecode die modbus timing settings
timeout, delay und connect delayDer Zusammenhang ist z.Zt. folgendermaßen:
delay = 0..6000 ms
timeout = 5 * delay, mindestens 10000 ms
connect delay = 1,5 x delay, mindestetens 2000 msStephan
@bolliy :+1:
Btw. habe v0.3.1 mit "auto adjust" laufen und es sieht sehr gut aus! Topp :call_me_hand:
-
@all Habe hier ein Wallbox liegen, die ich am WE in Betrieb nehme.
Kann jemand zufällig einen Modbus Proxy via Docker empfehlen? -
@all Habe hier ein Wallbox liegen, die ich am WE in Betrieb nehme.
Kann jemand zufällig einen Modbus Proxy via Docker empfehlen?@trackerthecode Ich habe leider keine mobus proxy Erfahrungen.
Zu einem anderen Projekt habe ich dieses gefunden: https://forum.openwb.de/viewtopic.php?t=6027https://github.com/tiagocoutinho/modbus-proxy#docker
LG Stephan
Support us
552
Online32.7k
Users82.5k
Topics1.3m
Posts