Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[bolliy]

@dragst3r der Post https://forum.iobroker.net/post/1123119 war eigentlich für dich bestimmt.

[dragst3r]

@bolliy danke, der Fehler zu 37700 ist weg, jedoch habe ich noch

	Error while reading from 192.168.2.16 [Reg: 37200, Len: 3, modbusID: 2] with: Modbus exception 2: Illegal data address (register not supported by device)

Scheinbar nun auch der einzige.

[bolliy]

@dragst3r hi steffen, kann es sein, dass deine Software nicht aktuell ist?

Die Softwarestände findest du in der Fusion Solar App oder auf dem Portal:

Bei mir:
Dongle V200R022C10SPC108
Inverter V100R001C00SPC159

Stephan

[bolliy]

@dragst3r ich vermute mal das der Slave WR aus der M0 Serie ist. Der kann keine Optimizer verarbeiten und würde auch die fehlenden Register erklären.

Das könnte ich aber auch wegprogrammieren. :wink:
Zeig mal was im State "sun2000.0.inverter.1.info.model" steht.

Stephan

[lcars]

Ich habe auch mal meine Inverter und die Batterie neu gestartet um sicher zu gehen, dass da nicht intern der Rechner hängt. Weiterhin habe ich die 0.2.1 Version des Plugins installiert, gecheckt das Inverter und Batterie die neueste Version drauf haben und bei mir sieht es nun so aus:

Die Daten kommen schon rein aber ich bekomme ständig da Timeouts dazwischen.
Eingestellt habe ich bei mir:

Die Dev Version hatte ich auch mal laufen und habe die Timeouts mal hoch gesetzt aber da auch keine Verbesserung gewesen (war da noch in Version 0.2.0).

Bei euch mit zwei Invertern und einem Akku läuft das ohne diese Fehlermeldungen?

[bolliy]

@lcars zur Zeit gibt es nur eine Entwickler-Version, die das Problem lösen kann. Siehe https://forum.iobroker.net/post/1122230

Da ich z.Zt. den Adapter umstrukturiere, wird es etwas dauern bis ich ein neues Release rausbringen kann.

Stephan

[lcars]

@bolliy said in Test Adapter sun2000 v0.1.x - Huawei Wechselrichter:

https://forum.iobroker.net/post/1122230

Die Version läuft bei mir komplett nicht. Da habe ich z.B. das so eingestellt:

Und ich bekomme da nur im Protokoll:

Die Instanz bleibt auch gelb. Da funktioniert die 0.2.1 Version besser bei mir.

[bolliy]

@lcars erhöhe mal
delay 5000
connect delay 8000

...

[lcars]

Hab ich erhöht auf 8000 aber mit dem dev Teil sieht es schlechter aus und bleibt gelb. Hier das Log:

Nachtrag: Ich habe auch Errors im Inverter Logs gesehen. Ich stehe schon im Kontakt mit der Installationsfirma. Ggf. stimmt da was nicht.

Mit der "nicht" dev Version sieht es besser aus und der Adapter ist grün. Hier der Vergleich im Log dazu:

[bolliy]

@lcars bei meinem WR habe ich keine Fehlermeldungen. :thinking_face:
Ich melde mich sofern ich wieder etwas zum testen habe.

Stephan

[dragst3r]

@bolliy da hast du recht, es ist ein 15KTL-M0, aber dadurch dass du den Adapter eh nun anders strukturierst, wirst du sicherlich Rückmeldung der Schnittstelle zu fehlerhaften Register überprüfen und auf eine Art Blacklist setzen. Bin gespannt was kommt.

[surfer09]

Danke erst einmal für den Adapter! Meine Anlage ist auch vor ein paar Tagen in Betrieb gegangen und über diesen Weg kann man die Werte abrufen. Gibt es auch einen Batteriewert, der anzeigt, wie viele KWh noch im Speicher vorhanden sind? Im Moment hat man ja "nur" die %-Ausgabe.

Gruß surfer ;-)

[bolliy]

@surfer09 da der Batteriestand in kWh leicht aus den States sun2000.0.collected.ratedCapacity * sun2000.0.collected.SOC / 100 berechnet werden kann, würde ich gerne auf einen weiteren Wert verzichten. Weitere States verbessern nicht gerade die Übersicht unter dem Pfad sun2000.0.collected.

LG Stephan

[surfer09]

@bolliy Danke für die Rückmeldung. Nein, da hast du Recht. Ich habe jetzt teilweise schon Probleme die Werte zuzuordnen. Gibts irgendwo eine Beschreibung welcher State für was genau steht?

[bolliy]

@surfer09
https://forum.iobroker.net/post/1118425

Weitere Informationen sollen später kommen.
Sonst einfach fragen.

Stephan

[TrackerTheCode]

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ß

[bolliy]

@trackerthecode Ich kann deinen Gedankengängen nicht ganz folgen. Würdest du das etwas genauer aufzeigen?

[bolliy]

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.

[bolliy]

@dragst3r teste mal die neue V0.3.0.
Stephan

[TrackerTheCode]

@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.