Test Adapter sun2000 v0.1.x - Huawei Wechselrichter
-
@surfer09
https://forum.iobroker.net/post/1118425Weitere Informationen sollen später kommen.
Sonst einfach fragen.Stephan
-
Hi @bolliy ,
ich habe jetzt über die letzte Woche alle möglichen Kombinationston von Dealys und Intervallzeiten probiert. Schlussendlich habe ich immer im Log irgendwann die Timeout-Fehler vorgefunden. Aktueller Stand sieht ungefähr so aus:
Ich habe beispielsweise das Intervall mehr als doppelt so hoch gesetzte, wie ein kompletter Lesezyklus benötigt. Auch dann habe ich die Fehler im Log vorgefunden.
Im Moment habe ich keinen weiteren Ansatz, mit den bestehenden Parametern noch mehr in Erfahrung zu bringen bzw. den Adapter ohne Fehlermeldung an meiner Anlage zu konfigurieren.
... ich sehe aktuell keinen Zusammenhang zwischen den Fehlern und den mir zur Verfügung stehenden Variablen.
Ein Gedankengang, den ich noch habe: Ist evtl. die Menge an offenen noch nicht bereitgestellten zu lesenden Registern ein Grund für einen internen Bufferüberlauf im Dongle... ? ... ("laut gedacht")
Gruß
-
@trackerthecode Ich kann deinen Gedankengängen nicht ganz folgen. Würdest du das etwas genauer aufzeigen?
-
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
