[HowTo] Huawei SUN2000 WR Modbus mit node-red (read + write)

[kmxak]

ist das bekannt das in den logs immer has to be stringified but received type "number" kommt?

[badsnoopy667]

@kmxak
Bei einigen Leuten passiert das wohl. Bei mir nicht. Um welches Objekt geht es?

[Doom.86]

@badsnoopy667 Das mit den Node kopieren ist mir noch klar. aber mir ist in deinem Flow nicht klar, wo ich die Datenpunkte angebe? Ich habe die einzelnen Nodes schon angeschaut, aber nichts gefunden oder übersehen.

Bei dem Flow des Eingangstrades, ist es mir klar, da steht in der iobroker out der Datenpunkt. Aber bei deinem Flow verstehe ich das noch nicht so richtig.

Ich hatte meinen aktuellen Flow schon mit 8 Sekunden Abfrageintervall ohne Probleme laufen. dann habe ich noch mit anderen Registern rum gespielt und bin zu dem fehler mit node is not ready gekommen. Daraufhin habe ich alles wieder in der vorherigen zustand versetzt, aber die 8 Sekunden wollte er nicht mehr.

[badsnoopy667]

@doom-86

Edit: Mein Flow ist der aus Thema 1. Und zwar der erste, nicht der untere mit den mehreren WR. Den habe ich nicht getestet.
Nimm den 1., der funktioniert.

[Doom.86]

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

[madmat17]

@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

[kmxak]

@badsnoopy667 hier die logs:

node-red.0
2023-11-22 18:40:01.019	info	State value to set for "0_userdata.0.Huawei.Meter.Active_Power" has to be stringified but received type "number"

node-red.0
2023-11-22 18:40:00.550	info	State value to set for "0_userdata.0.Huawei.Inverter.Peak_Active_Power_of_current_Day" has to be stringified but received type "number"

node-red.0
2023-11-22 18:39:56.640	info	State value to set for "0_userdata.0.Huawei.Inverter.Input_Power" has to be stringified but received type "number"

An sich sind es ja auch nur Zahlen die kommen

[badsnoopy667]

@kmxak

Sind Deine Objekte korrekt konfiguriert?

[kmxak]

@badsnoopy667
das ist so wie es der flow erzeugt hat. Manuell kann ich es natürlich ändern.

[madmat17]

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

[badsnoopy667]

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

[madmat17]

@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

[Franzosenfranz]

@madmat17

Ich habe das selbe Setup (RasPi 4 Modell B, 8GB), habe aber keine Meldungen bezüglich Timeouts.
Gefühlt habe ich jedoch auch recht viele Clients im Netzwerk.

[madmat17]

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

[Franzosenfranz]

@madmat17

Entschuldige, nein den von badsnoopy667 hier aus dem Forum.

[Doom.86]

@madmat17 Hallo Madmat. Erstmal vielen dank für deine erklärung. So langsam steige ich bei deinem Flow etwas dahinter.

Ich hatte tatsächlich das Problem mit dem Error, als ich deinen Flow genutzt habe.

node-red.0
2023-11-18 11:01:18.833	error	18 Nov 11:01:18 - [error] [modbus-getter:Inverter Data 32000-32116 Inverter 1] Error: Timed out at /opt/iobroker/iobroker-data/node-red/node_modules/node-red-contrib-modbus/modbus/maps/core/core/modbus-client-core.js:79:156
 
node-red.0
2023-11-18 11:01:18.832	warn	18 Nov 11:01:18 - [warn] [modbus-getter:Battery Charging Power 37001] Modbus Failure On State sending Get More About It By Logging
 
node-red.0
2023-11-18 11:01:18.831	warn	18 Nov 11:01:18 - [warn] [modbus-getter:Input Power & Inverter Active Power Inverter 1] Modbus Failure On State sending Get More About It By Logging
 
node-red.0
2023-11-18 11:00:07.336	warn	18 Nov 11:00:07 - [warn] [modbus-getter:Input Power & Inverter Active Power Inverter 1] Getter -> Inject while node is not ready for input.

Ich nutze aktuell wieder den Flow, wo mehrere Register gleichzeitig abgerufen werden.
Seit ich mal mit dem Register für Force Charge gespielt habe, ist mein Dongel eine richtige Diva geworden. Ich konnte davor alle Register in einem 8 Sekunden Intervall abrufen.
Seit dem Rumspielen bin ich jetzt bei alle 20 Sekunden und zwischen den Registern noch 5 Sekunden Pause. Trotzdem bekomme ich ab und an die Meldung, Node is not ready. Das selbe Problem habe ich auch, mit dem Flow im Eingangspost.

Bei deinem Flow kommt leider noch der error mit timeout und diw Warnung mit Sending more about logging.

Wie ich dieses Diva verhalten des Dongels wieder löse, weiß ich leider nicht. Ich bin schon mit meinem Raspberry Pi 4 4gb von einem USB stick auf eine SSD umgezogen. Hat aber leider keinen unterschied gemacht.

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?

[madmat17]

@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

[Doom.86]

@madmat17
Ich habe keine Ahnung, was ich gemacht habe, ich habe jetzt an meinem Flow so lange rumgespielt, bis mir auch meine Influxdb beschrieben wird. Siehe da, inzwischen bin ich wieder auf meinem 10 Sekunden Intervall.

Gestern hatte ich noch mein Netzwerk neu gestartet (so wie du es beschrieben hattest), den Raspberry direkt an die Fritzbox gehängt, weil dort schon der Dongel angeschlossen war (Wollte ausschließen, dass durch den switch irgendetwas untergeht oder verzögert wird). Die beiden Wechselrichter und die Luna hatte ich für ca. 15 - 20 Minuten komplett ausgeschaltet.
Das ganze hat Gestern Abend nur leider nichts gebracht.

Für Interessenten hier der Flow: Huawei NodeRed.txt
Es ist eine Mischung aus dem Flow von Mat und dem Flow, wo mehrere Register gleichzeitig abgefragt werde.
Die Mischung deswegen, weil ich wie von Mat die Daten in einer Influxdb haben wollte, aber zum anderen nicht auf meine aktuellen Datenpunkte verzichten. Ansonsten hätte ich einiges im Iobroker noch ändern müssen.

Aktuell versuche ich den Teil mit Solecast in einem Seperaten Flow zum kaufen zu bringen. Erstmal nur das Abfragen und schrieben in die Influxdb. Senden an Solecast soll kommen, wenn der erste Teil funktioniert.

Genau da habe ich auch mein Problem. ich habe keinerlei Meldungen, aber Es wurden nur mal 4 Datenpunkte mit Estimate in die Influxdb geschrieben. Auch nur einmal. Von Forecast absolut gar nichts.

Vielleicht kannst du mir dort noch weiterhelfen?

LG,
Flo

[madmat17]

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

@madmat17 Hallo Mat,

Ich habe meine Verwirrung gefunden.
Ich habe erwartet, dass in der Influxdb Punkte mit forecast auftauchen. Dies ist nicht geschehen.

Ich habe mir inzwischen die change node nach bewege msg.payload.forecast angeschaut:

In dieser steht

[[	{"value": $.payload.pv_estimate * 1000,	"time": $toMillis($.payload.period_end)},	{"topic": "pv_initial_estimate"}	],	[	{"value": $.payload.pv_estimate * 1000,	"time": $toMillis($.payload.period_end)},	{"topic": "pv_estimate"}	],	[	{"value": $.payload.pv_estimate10 * 1000,	"time": $toMillis($.payload.period_end)},	{"topic": "pv_estimate10"}	],	[	{"value": $.payload.pv_estimate90 * 1000,	"time": $toMillis($.payload.period_end)},	{"topic": "pv_estimate90"}	]	]

Somit funktioniert das auch, nur ich hatte einen andere Beschreibung erwartet.

Wie heißt es so schön: Meistens sitzt das Problem zwischen Bildschirm und Stuhl.