Test Adapter sun2000 v0.1.x - Huawei Wechselrichter
-
Der neue Adapter sun2000 in der Version 0.3.0 wurde gerade hier https://github.com/bolliy/ioBroker.sun2000 veröffentlicht. Der Adapter ist ebenfalls auch auf https://www.npmjs.com/package/iobroker.sun2000 deployed.
Bitte den Adapter über npm installieren, damit keine unfertige Version in ioBroker eingespielt wird.Changelog:
- add battery unit information for example temperature #40
- modbus timeout, connect delay and delay can be configured #34
- device status as plain text
sun2000.0.inverter.x.derived.deviceStatus - Introduction of a driver model. A separate driver can be created for each device #41
Mit 2 Herausforderungen sehe ich mich zur Zeit konfrontiert. Zum einen existieren Setups mit unterschiedlicher Hardware. Neben alten Huawei sun2000 aus der Serie M0 und einem smartLogger3000 können noch andere Huawei Devices unterwegs sein. So habe ich den Adapter umstrukturiert. Über ein Treiber-Model können nun unterschiedliche Hardware in dem Adapter impelmentiert werden.
Zum anderen kämpfe ich immer noch mit Timeout-Problemen bei einigen Setups. Deshalb habe ich mir ein Konzept ausgedacht, dass automatisch eine „funktionierende“ modbus-Einstellung ermitteln soll. So wird nach der Installation des Adapter die auto-adjust Funktion aktiviert. Der Adapter durchläuft dabei mehrere Adjustment Steps. Immer wenn ein Fehler auftritt werden die Verzögerungswerte (delays) sukzessive erhöht bis ein stabiler Zustand eintritt. Der auto-adjust Vorgang kann mehrere Minuten dauern. Danach werden die ermittelten Werte abgespeichert und der Adapter automatisch neu gestartet und die auto-adjust Funktion wieder deaktiviert.
Allerdings muss ich gestehen, dass ich Timing-Konzept nicht richtig testen kann. Ich habe nur ein WR und der macht leider überhaupt keine Timeouts
modbus timing:
- ttimeout: modbus connection timeout (default: 10000 ms)
- delay: delay between modbus requests (default: 0 ms)
- connect delay: delay after modbus connected (default: 5000 ms)
- auto-adjust: automatic adjustment of the modbus settings
Über Tests und euer Feedback freue mich sehr.
-
@dragst3r teste mal die neue V0.3.0.
Stephan -
@bolliy Was ich mit meinem oben erwähnten Gedankengang teilen möchte ist folgendes:
- Es gibt via Socketanfrage abgesetzte Lesebefehle
- Diese Anfragen beinhalten eine Menge an angefragten Nutzdaten (Register die über Modbus gelesen werden)
- Der Dongle hat nur einen begrenzten Menge an Speicher für die Nutzdaten
- Das interne Mangement des Speichers kenn wir als Anfragender Dienst ja nicht
- Aus unserer Sicht ist nur zu langsam. Der Dongel antwortetnicht schnell genug und es resultiert ein Timeout
-> Somit wäre interessant zu wissen, ob das Verhalten das gleich ist, wenn die angefragten "Nutzdatenhäpchen" kleiner sind.
Es ist mir bewusst, dass die Abfragen mehr werden. In Summe dauert es auch länger, um die gleiche Menge an Nettodatenmenge zu lesen. Aber es würde den Rückschluss zulassen, dass die Menge der angefragten Daten pro Zeit ein Auswirkung auf das Verhalten hat.
-
@bolliy ich teste jetzt auch die v0.3.0
Zur neuen Funktion "auto adjust" habe ich noch eine Frage: welche Parameter werden automatisch eingestellt?
-
@bolliy habe die neue Version installiert und lasse diese nun mal laufen. Bis jetzt kommen keine Fehlermeldungen oder Timeouts. Mal schauen wie es mit der Zeit ist. Ob die Werte plausibel sind. Ein direkter Vergleich mit dem Online Portal ist ja nicht realistisch.
Klasse Arbeit !!!
-
@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
-
@trackerthecode Die Anzahl der gelesenen oder geschriebenen DatenBytes haben einen Einfluß auf das zeitliche Verhalten des Dongles. Um so größer die Datenpakete sind um so länger muss zwischen den Anfragen gewartet werden. Ich habe aber festgestellt, dass viele "kleine" Anfrage an den Dongle, diesen mehr belasten als relativ große Datenpakete (100 Bytes)
Sofern ein Delay Wert > 0 eingestellt ist, wird im Verhältnis zu den zuvor gelesenen oder geschriebenen Datenbytes vor der nächsten Donglezugriff gewartet.
Das Problem mit den Timeouts tritt überwiegend auf, sofern mehr als 1 WR im Einsatz sind. Das Umschalten der modbusID hat nach meiner Beobachtung keinen Einfluß auf das Timingverhalten.Auf den Dongle modbus (seriell) darf nur ein Client zur selben Zeit zugreifen! Auch z.B. beim Einsatz der smart charger (Wallbox) von Huawei entstehen diese konkurierende Zugriffe sofern man auf modbus zugreifen möchte. Dann kann ein smartLogger von Huawei oder ein sog. modbus-proxy helfen die Anfragen an den Dongle zu serialisieren.
-
Ü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
-
-
@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 
-
@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?
-
@bolliy Nur als das Ding nach Sonnenuntergang in Standby ging. Der geht ja komplett aus.
-
@dragst3r Der Slave geht komplett aus - ok. Dann werden also alle Leseversuche an den Slave mit einen Timeout quittiert. Ist das so richtig?
-
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
-
Ich meine es so zu verstehen. Ich stelle den Intervall auf 5Sek für Highlevel und dann ist der Lowlevel 1min.
Richtig?
-
@lub104 genau
-
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.
