@stoffel67
Es sieht so aus, als wären die Nodes bei dir inaktiv. Doppklick darauf -> Register "Setup" -> ganz links unten von Disabled auf Enabled umstellen und neu deployen.

Frage in die Runde:
Seit wenigen Tagen bekomme ich keinen Wert mehr aus den Registern 37015 (Battery - current day charge capacity) und 37017 (Battery - current day discharge capacity). Hat jeman ähnliches beobachtet? Früher bekam ich dort immer sauber die Werte...
Alle anderen Register geben die Werte wie gewohnt aus.
Dongle läuft auf FW Version V100R001C00SPC130
Inverter (SUN2000-6KTL-M1) läuft auf FW Version V100R001C00SPC150

Lösung gefunden: Die Register 37015 & 37017 sind jene, mit denen die Werte der einzelnen Akku-Module ("Engery Storage Unit") ausgelesen werden. Scheinbar sind diese plötzlich maskiert (wenngleich ich kürzlich kein FW-Update vorgenommen hatte - aber evtl. war das auch ein forced update) und werden über den TCP-MODBUS nicht mehr ausgegeben.
In den JSONs weiter oben werden ebenfalls diese Register abgefragt (war dann OK, solange man nur einen Akku hatte - inzwischen wie gesagt nicht mehr zu gebrauchen).
Lösung: Auf jene Register ausweichen, welche die Werte aller Akkumodule zusammenfassen. Auf der HUAWEI-Seite habe ich gerade die vollständige MODBUS Interface Definition nicht gefunden, kann man aber hier nachschlagen (Version 04 vom 29.03.2022 - direkter Link). Die Abfrage über die dort angegebenen Register 37784 und 37786 funktioniert klaglos.

LG,
Mat

@doom-86
Hauptsache ist, dass alles passt.
Freut mich, wenn es funktioniert!

@doom-86

Wenn du von Solcast nur die "Estimated Actuals" retour bekommst und davon nur 4, dann vermute ich, dass mit dem Probieren des Flows über die Zeit die Anzahl der kostenlosen API-Calls/Tag (müssten 20 sein, wenn ich nicht irre) aufgebraucht sein.
So fern du deine Daten in den beiden hervorgehobenen Query-Nodes korrekt eingetragen hast und auch sonst alles passt, kann ich mir nur das als Ursache vorstellen.

Bzw. checke noch einmal, ob du in dem HTTP-Call ("Solcast API - get LIve+Forecast JSON") die URL zu deiner PV-Anlage und auch den API-Key unter Token korrekt eingetragen hast:

LG,
Mat

@doom-86
Die Firmware auf dem Dongle ist einfach der letzte Mist.
Bei mir hat sich das Teil komplett weggehängt, als ich das Netzwerk manuell umkonfiguriert habe (und ich weiß, was ich da tue).

Ich habe mittlerweile hab eich die node-Warnungen (Inject before ready) nicht mehr und auch nur noch ganz sporadische Timeout-Error. Sporadisch heißt in dem Fall rund alle 30 Minuten einmal einen Error (= 0,06% aller Abfragen bei einem 5-Sekunden-Intervall). Das ist meiner Meinung nach noch vertretbar.

Was ich gemacht habe:

• Meinen Dongle wieder auf die eingeschränkte Modbus TCP Kommunikation umgestellt, sodass nur noch Pakete von einer Client-IP (= ioBroker) akzeptiert werden.
  Ich weiß nicht warum, aber scheinbar war der Dongle mit den UDP- und IxMP-Paketen überfordert. Warum das so ist, geht mir nicht ganz ein, aber sei es drum...
• Den Dongle vom WR komplett abgesteckt, das gesamte Netzwerk neu durchgestartet, ioBroker neu gestartet, Dongle wieder angeschlossen

Die Firmware dürfte auf bestimmte Dinge ganz allergisch reagieren und braucht dann einen Reset.
Aber wie das zu deinem Problem mit dem Force Charge passt, kann ich nicht sagen. Das kann mit dem Dongle (meiner bescheidenen Meinung nach) nichts zu tun haben, weil der Dongle ja nur die Pakete zum Wechselrichter durchreicht.

@doom-86 said in [HowTo] Huawei SUN2000 WR Modbus mit node-red (read + write):

Gibt es vielleicht in Nodered eine Möglichkeit, wenn er mit der ersten Node die abfrage macht, erst zur zweiten node geht, wenn er bei der ersten die Daten erhalten hat?

Den Effekt sollte man in node-red immer dann erreichen, wenn ein nodem dem anderen nachgereiht ist.
Der Output des ersten Nodes liefert erst eine Message, wenn er seine Aufgabe abgeschlossen hat. Diese Message nutzt man bei Bedarf, um den nachgelagerten Node über den Input zu triggern.

LG,
Mat

@franzosenfranz
Danke dir! Und nutzt den Flow, den ich gepostet habe?

@badsnoopy667 said in [HowTo] Huawei SUN2000 WR Modbus mit node-red (read + write):

Ach, Efficiency kommt bei mir irgendwie kein brauchbarer Wert mehr. Habe das deaktiviert und den Datenpunkt aber nicht gelöscht.

Ich habe das bei mir bislang auch geflissentlich ignoriert. Vielleicht ist es an der Zeit, den Datenpunkt komplett rauszuschmeißen...
.
.

@madmat17 said in [HowTo] Huawei SUN2000 WR Modbus mit node-red (read + write):

Es gibt noch ein Problem mit dem Timing. Die Abfragen über meine alte node-red Instanz (lief auf einem x86 FreeBSD-Derivat) war in dieser Konfiguration problemlos; im aktuellen Setup (node-red im ioBroker auf einem RasPi) wirft extrem viele Time-Outs und Warning (Inject Node not ready). Wenn ich auf die Lösung gekommen bin, gibt es ein Update zu meinem Flow...

Aktuell habe ich noch kein Muster in den Timeouts erkannt, wenn sie auftreten.
ABER manchmal bekomme ich innerhalb von 1 Minute duzende und manchmal ganz sporadisch. Was aber besonders interessant ist: Wenn weniger Netzwerk-Clients aktiv sind (zwischen 23 Uhr und 5 Uhr morgens) gibt es keine Timeouts.
Zudem haben die Timeouts abgenommen, seitdem der RasPi (auf dem ioBroker / node-red läuft) aus dem WLAN ins Ethernet gewander ist.

FRAGE:
Hat jemand ein ähnliches Setup (ioBroker auf einem RasPi) und nutzt meinen Flow und sieht Timeout-Meldungen vom Modbus?
Eventuell liegt es gar nicht am Flow, sondern an meiner Netzwerkkonfiguration. Sollte der Flow bei anderen dieses Verhalten nicht zeigen, wäre das zumindest schon ein Indikator.

LG,
Mat

@badsnoopy667 was hat's mit deinem Inverter, dass der eine so niedrige Efficiency ausspuckt?
Oder muss ich mir sorgen über falsche Werte machen, weil bei mir immer 100% angezeigt werden (was ja eigentlich auch Quatsch ist - 100% Effizenz gibt es bei so einem Teil nicht).

@doom-86 said in [HowTo] Huawei SUN2000 WR Modbus mit node-red (read + write):

@badsnoopy667 sollte eigentlich an @madmat17. Mit seinem flow. Ich hatte mich da echt verschaut.

OK - das ist bei mir etwas anders gelöst.

Bei mir werden ja mehrere Register gleichzeitig abgefragt und von den Parsern (die blauen nodes) wird dann je Register ein Objekt erstellt. Da ich 3 Abfragen habe, ich deren Resultate aber alle auf einmal in eine Datenbank schreiben will, werden die noch mit einem join-node in einer Message gesammelt. Sobald die 43 Objekte beisammen sind, übergibt der join-node diese an den Sub-Flow "JSON or Obj to IOBroker" (der baut die Message so um, dass sie direkt in ein ioBroker-Objekt geschrieben werden kann) und in diesem Node wird auch definiert, wo der nachgelagerte ioBroker Out-Node "IoB write value" hinschreiben soll.
Ich habe in meinem Flow das Top Huawei0 angegeben:

Und da das Stammverzeichnis für die ioBroker Out Nodes immer 0_userdata.0 ist, legt der Node daher die Objekte im Verzeichnis 0_userdata.0.Huawei0 an:

Wenn du die Namen der Datenpunkte ändern möchstes, musst du das direkt in den Parsern machen:

LG,
Mat

@doom-86
Das Schreiben ins Register 47078 nutze ich nicht - das ist einfach 1:1 aus dem Flow des allerersten Posts von @badsnoopy667 übernommen.
Irgendwo im Verlauf steht auch, wie man mehrere Inverter abfrägt, wenn ich mich nicht irre. Wenn ich nicht ganz falsch liege, brauchst du für jeden Wechselrichter jeweils einen eigenen Modbus-node (da sich die Unit-IDs der Wechselrichter unterscheiden müssen) und auch eine Server-Konfiguration je Wechselrichter (da dort auch die Unit-ID hinterlegt ist).

Warum dein node-red den Inverter gar nicht erreicht kann viele Ursachen haben. Als erstes würde ich einmal folgendes checken:

• Modbus TCP ist auf dem Dongle aktiv (und fall im eingeschränkten Modus die korrekte Client-IP hinterlegt)?
• Der Dongle wird im LAN erkannt
• Server-Konfiguration für die Modbus-Abfrage in node-red ist korrekt? (IP, Port, Device-ID)
• Device-ID in den Modbus-nodes des Flows ist korrekt?

LG,
Mat

Nun habe ich meinen Flow fertig, den ich hier gerne teile.

Abfrage der Werte des Huawei Sun2000 Wechselrichters
Folgendes stand hier im Vordergrund:

• Aufgrund der Trägheit des Huawei-Dongles die Anzahl der Abfragen so weit es geht reduzieren und damit die Geschwindigkeit erhöhen - daher werden die Register gesammelt abgefragt (aufgrund der Adressabstände mit insgesamt nur 3 Aufrufen je Abfrage)
• Da die Werte auch in eine Datenbank (InfluxDB) geschrieben werden, sollten ebenfalls so viele Register wie möglich gleichzeitig abgefragt werden (um so weit wie möglich die Datenkonsistenz zu wahren)
• Von einem 5-Sekunden-Heartbeat ausgehend werden im IOBroker alle 5 Sekunden die relevantesten Werte aktualisiert und in die IOBroker-Objekte geschrieben (so weit nicht neu) - die Objekte werden übrigens ordentlich von node-red angelegt. Nach jedem 12. Beat (also alle 60 Sekunden) werden statt nur(!) der relevantesten Werte alle benötigten Werte (inklusive der relevantesten) vom Modbus gelesen, in die IOBroker-Objekte geschrieben und in eine InfluxDB geschrieben.

Mein Basis-Flow kommt mit denselben node-red Modulen (node-red-contrib-calc, node-red-contrib-buffer-parser, node-red-contrib-buffer-parser) wie von @badsnoopy667 im allerersten Post angeführt aus.
Für das Schreiben in die InfluxDB (falls erwünscht) wird noch das Modul node-red-contrib-influxdb benötigt und für den PV-Forecast (siehe weiter unten) noch das Modul node-red-contrib-sun-position.

Der Basis-Flow mit InfluxDB-Integration und den Elementen zum Schreiben der Register (aus dem ersten Post).

PV-Forecast
Des weiteren werden auch Forecast-Daten von Solcast abgerufen und in die InfluxDB geschrieben, sowie die tatsächlichen Werte an Solcast zurückgeschrieben (Solcast lernt aus den zurückgelieferten Werten und die Freunde können so ihren Dienst verbessern.
Leider kann ich mich beim besten Willen nicht mehr erinnern, wo ich den Flow her habe (er stammt NICHT aus meiner Feder). ABER ihr braucht dafür einen Solcast-Account, eine in eurem Account angelegte PV-Anlage und einen API-Key zum Abfragen der Werte.

• Account und Anlage der PV-Anlage: https://toolkit.solcast.com.au/
• API-Key kann dann hier erstellt werden: https://toolkit.solcast.com.au/account/api-key

Nach dem Anlegen der PV-Anlage (Position, Dimensionierung, Ausrichtung, ...) bekommt die Anlage eine ID, über welche die auf die Anlage bezogenen Forecast-Werte abgerufen werden können. Diese URL ist im Flow in den nodes "Solcast API - get Live+Forecast JSON", "Solcast API - get Past + Estimated Actuals" und "Solcast API - post measurements" abzulegen. Ebenfalls in diesen Nodes ist unter "Token" euer API-Key (nicht zu verwechseln mit der Anlagen-ID!) zu hinterlegen.

Änderung der Namen der Datenpunkte:
Wird in diesem Post erläutert: https://forum.iobroker.net/post/1084664

Viel Spaß damit.
Huawei_Sun2000_InfluxDB_Solcast.txt

LG,
Mat

EDIT:
Es gibt noch ein Problem mit dem Timing. Die Abfragen über meine alte node-red Instanz (lief auf einem x86 FreeBSD-Derivat) war in dieser Konfiguration problemlos; im aktuellen Setup (node-red im ioBroker auf einem RasPi) wirft extrem viele Time-Outs und Warning (Inject Node not ready). Wenn ich auf die Lösung gekommen bin, gibt es ein Update zu meinem Flow...
Das Problem mit den Timeouts hat sich in Wohlgefallen aufgelöst. Mehr dazu hier: https://forum.iobroker.net/topic/51639/howto-huawei-sun2000-wr-modbus-mit-node-red-read-write/485

@badsnoopy667
Herrje - es tut mir unendlich leid. Ich war lange nicht im Forum aktiv (da ich selber IOBroker nicht eingesetzt hatte) und hatte nicht gesehen, dass Interesse am Flow besteht.
Ich kann den Flow gerne teilen (ist allerdings eine reine Modbusabfrage aus node-red heraus gefolgt von einem eintrag in meiner InfluxDB).
Da ich nun aber doch auf IOBroker umsteige (mit der Umstellung meines Servers von einem FreeBSD-Derivats auf Linux endlich vernünftig möglich!) würde ich den neuen Flow teilen sobald fertig.

Lg,
Mat