UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

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

[TrackerTheCode]

@bolliy ich teste jetzt auch die v0.3.0

Zur neuen Funktion "auto adjust" habe ich noch eine Frage: welche Parameter werden automatisch eingestellt?

[dragst3r]

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

[bolliy]

@trackerthecode die modbus timing settings
timeout, delay und connect delay

Der Zusammenhang ist z.Zt. folgendermaßen:
delay = 0..6000 ms
timeout = 5 * delay, mindestens 10000 ms
connect delay = 1,5 x delay, mindestetens 2000 ms

Stephan

[bolliy]

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

[dragst3r]

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

[bolliy]

@dragst3r das kann ich sicherlich berücksichtigen. Da ich nur ein WR habe und nachts keine Timeouts sehe habe ich ein paar Fragen:

1. Treten bei beiden WR modbus IDs die Timeouts auf, oder nur beim dem Slave der in den Standby geht?

2. 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]

@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

[bolliy]

@dragst3r TimeOut Fehler treten nur beim Lesen des Reg 32064 auf?
Hast du am Slave einen Speicher hängen, oder nur am Master?

[dragst3r]

@bolliy Gar keinen Speicher :) aber das FusionSolar Portal zeigt mir einen Dummy Speicher an mit Null Werten :-D

[bolliy]

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