[HowTo] Huawei SUN2000 WR Modbus mit node-red (read + write)
-
@ple, ich habe dann mal weiter recherchiert, denn leider sehe noch immer keine Werte für den unteren Teil des Flows :-(.
Herausgefunden habe ich, dass der obere Teil auf die Register zugreift, die auch in diesem Dokument beschrieben sind SDongle MODBUS TCP Guide https://www.photovoltaikforum.com/core/attachment/260120-sdonglea-05-modbus-tcp-guide-pdf/
Die Register, die im unteren Teil verwendet werden, sind im folgenden Dokument beschrieben Solar Inverter Modbus Interface Definitions (V3.0)
https://www.photovoltaikforum.com/core/attachment/180219-solar-inverter-modbus-interface-definitions-v3-0-pdf/.Da die Dokumente auch für meine Hardware zutreffen, sollten die im Flow verwendeten Register alle richtig sein …. aber trotzdem kommt zum unteren Teil, dem zweiten und dritten Trigger nichts an. Warum geht es bei anderen? Warum geht es bei mir nicht?
-
@leonundjulie
Puh, ist schon ein wenig her bei mir. Hier mal mein aktueller Flow.
Wie du schon erkannt hast, habe ich für den oberen Teil die Adressen direkt vom Dongle genommen, mit der neusten Software kann man die auch schneller abfragen.
Der untere Teil betrifft nur den Inverter, da musst du die passenden Strings wählen. Kann sein, dass dein WR andere verwendet.
Meine Hardware besteht aus KTL30-m3, powersensor und dongle. -
Hallo zusammen,
hat einer eine Idee warum auf einmal, meine active Last, also mein Hausverbrauch (32080) identisch ist mit der Dachproduktion? Das war vorher nie so
Danke für Eure Ideen
-
@joogibaer
Ich glaube der Fehler liegt in der Annahme, das "Active Power" der Hausverbrauch wäre. Das ist definitiv nicht so. Den Hausverbrauch muss man sich selber berechnen. Kann Dir gerade nicht genau sagen, was "Active Power" dann sein soll, aber ich glaube das ist eher das, was gerade über den Wechselrichter läuft. Also nachts dann auch das, was aus der Batterie kommt.
Bei mir sind die beiden Werte aktuell auch gleich. Ich speise ein. Sobald die Batterie ge- oder entladen wird, sind die beiden Werte nicht mehr gleich.
Ich habe weiter oben mein Blockly Skript zur Berechnung des Verbrauchs gepostet. Ist etwas komplizierter, aber guck Dir das mal an.
Hab jetzt nochmal nachgesehen, aber ohne Gewähr:
PV-Erzeugung = Active Power Inverter + Battery Power
Hausverbrauch = Active Power Inverter - Active Power Meter
Netzbezug/Einspeisung = Active Power Meter (Vorzeichen beachten!) -
@badsnoopy667 Hallo, ich hab das gleiche…… bin der Meinung, bis vor ein paar Tagen war aktiv Power der Hausverbrauch ( verbrauchte Leistung)…….
-
@svenh75
Solange scheiß Wetter ist und man nicht Einspeist, kommt das ja auch ungefähr hin.
-
hallo zusammen,
hat schon jemand schon eine möglichkeit gefunden die optimierer auszulesen?
ich meine damit die nicht die anzahl, sondern die daten der einzelnen optimierer.
hintergrund: ich habe ost- und westseite (je 6 module) sowie die fassade (8 module) an einem string und würde nun gern die erträge pro seite errechnen.
für sachdienliche hilfe wäre ich sehr, sehr dankbar.
Til -
Hallo, ich teste gerade Solaranzeige und die Variante alles über iobroker und Node-Red zu realisieren.
In Solaranzeige wird mir der Gesamtwert Import und Export in kWh angezeigt. (Also der Gesamtwert seit Inbetriebnahme des SmartMeter).
Ich habe zig unterschiedl. Dokumente von Huawei über Interface Definitions durchgelesen. Finde aber einfach die Adresse nicht.Hat jemand zufällig eine Idee? Die Werte sind für mich ausschlaggebend für eine sinnvolle Auswertung.
-
@exel Energie Export müsste 37119 sein, ich hab da auch schon was fertiges mit NodeRed. Habe ich mir damals auch von jemand geben lassen.
-
-
@ts_482 Vielen Dank. Das sieht gut aus.
-
Weiss jemand, mit welchem Register ich den oberen SOC schreiben kann?
Ich habe es mit dem Register 47101 probiert, nennt sich Target SOC. Das klappt aber nicht. Blöderweise habe ich den ursprünglichen Wert zuvor nicht ausgelesen, jetzt weiss ich nicht was das Register bewirkt und welcher Wert da reingehört...Könnte mal jemand das Register 47101 auslesen und mir mitteilen, was da drin steht?
Edit:
Hat sich erledigt. Target SOC ist wohl für das erzwungene Laden/Entladen. Den SOC kann man über das Register 47081 schreiben. -
@mickym Sorry für die späte Rückmeldung. Musste erst den zweiten Teil meiner PV Anlage fertig bauen und war dann im Urlaub
Ich meine bspw. sowas:
Hier werden die Adressen 32016-32019 einzeln ausgelesen und in die dazugehörigen Datenpunkte geschrieben.
Wie würde man es denn realisieren, dass die vier Adressen gleichzeitig ausgelesen und dann in die jeweiligen Datenpunkte geschrieben werden?Dein verlinkter Thread ist für mich wie bömische Dörfer
-
@christof-lewandowski Na ja ich kenne jetzt das Modbus nicht im Detail und es läuft ja auch. Aber man könnte ggf. den Verkehr oder die Anfragen vermindern indem man halt einmal die Adressen von 32016 bis 32019 ausliest und dann mit dem Bufferparser in 4 einzelne Nachrichten ausgeben lässt, wobei man ggf. sogar gleich das topic setzen könnte. Um das mit dir auszuprobieren müsste ich sehen, was Du in dem Flow machst und ob Du selbst mit der modbus Node alle Adressen aufeinmal auslesen kannst. ich glaube das geht, dass man angeben kann wieviel ausgelesen werden soll.
Exportiere halt mal den ausgewählten Schnipsel und poste mir mal was eine Modbus Node mit allen 4 Registern aufeinmal ausspukt hier in Code Tags, dann kann ich das mit einer Inject Node nachstellen.
Wie gesagt wenn Du Deine Anlage in größeren Blöcken abfragst, minimierst Du Netzwerktraffic und die Systeme im Allgemeinen.
-
@Christof-Lewandowski
Ich frage drei größere Adressbereiche ab, das wird dann über einen Buffer-Parser ausgewertet und alle Werte in einzelne Datenpunkte geschrieben. Ich denke im Prinzip das was du suchst, anbei der Flow.
Zwischen den Abfragen habe ich aktuell eine Minute Verzögerung, das Abfrageintervall kann man sicher auch noch runtersetzen, läuft so aber bereits seit Wochen problemlos. -
Noch einmal kurz zusammengefasst, wie ein Adressbereich / mehrere Register auf einmal ausgelesen werden können.
Man legt im Read-Befehl das Start-Register fest und zudem auch die Länge bzw. die Anzahl der Register. Hier im Bespiel das Register 32016 bis 32114. Jedes Register hat eine Länge von 2, d.h. die Anzahl beträgt somit 100:
Über ein Buffer-Parser kann man dann die empfangenen Werte auswerten. Hierbei muss einerseits das Offset der einzelnen Werte definiert werden (es können auch Werte übersprungen werden falls diese nicht relevant sind). Zudem kann auch direkt der Umrechnungsfaktor festgelegt werden. Die Ausgabewerte können dann in einzelne Datenpunkte geschrieben werden:
Anbei ein Beispiel-Flow, in welchem der WR in einem Block ausgelesen (32016-32114) wird sowie die Batterie/Smartmeter in einem weiteren Block (37000-37123).
-
@spexx Eine Verbesserung und wesentliche Vereinfachung habe ich aber.
Du kannst in dem Bufferparser set topic ankreuzt und im Namen gleich den richtigen Pfad zum Datenpunkt eingibst und nicht was beschreibendes - dann ist das bereits das topic und Du brauchst das fan Out nicht und kannst alles in eine iobroker - OUT Node schreiben. Dann ist der Flow viel übersichtlicher.
-
Mega, vielen Dank!
Da kommen wir der Sache doch schon sehr sehr viel näher
Habs jetzt mal auf meine Daten angepasst und läuft! Werde jetzt mal beobachten, ob und wie viele Timeouts ich nun bekomme.
Eine Frage hätte ich noch bzgl. des Schedules. Der Intervall steht auf alle 3 Minuten. Dann gibts da noch ne Verzögerung von 1 bzw. 2 Minuten (im Flow von @Spexx )? Wie darf man das verstehen?
-
@mickym
Ist schon eine Weile her als ich das gemacht habe. Ganz verstanden habe ich es noch nicht, könntest du mal ein Beispiel erstellen?
Vermutlich wird das dann nicht gehen, wenn die Werte noch eine zusätzliche Umrechnung benötigen (wie z.B. die Uhrzeit) oder wenn ich bei einigen Werten direkt noch ein Text hinterlege, z.B. beim "Device Status"? Dennoch würde mich dein Vorschlag interessieren.@Christof-Lewandowski
Ja der Trigger kommt alle 3 min. Beim Auslösen des Triggers wird der 1. Block abgefragt, 1 min später dann der 2. Block und 2 min später dann der 3. Block. Dann geht es wieder von vorne los, es wird somit jede Minute eine Abfrage über Modbus gestartet (jeder Block selbst hat dann ein Abfrageintervall von 3 min).Hintergrund des hohen Abfrageintervall war bei mir, dass ich ansonsten Probleme mit FusionSolar habe... Wenn ich etwas ändern möchte, z.B. AC laden aktivieren, dann klappt das meistens erst nach mehrmaligen versuchen, weil FS und meine Modbus Anfrage sich wohl in die Quere kommen!?
Ich bin aber schon am überlegen wie man das anpassen könnte. Ich hätte gerne einzelne Werte im 10-Sekundentakt.
Aktuell habe ich eine Kaskade (zwei WR + Luna) über einen SDongle. Hat jemand Erfahrung damit, ob das mit dem Abfrageintervall besser wird, wenn man die Kaskade trennen würde und zwei SDongle nimmt? -
@spexx sagte in [HowTo] Huawei SUN2000 WR Modbus mit node-red (read + write):
@mickym
Ist schon eine Weile her als ich das gemacht habe. Ganz verstanden habe ich es noch nicht, könntest du mal ein Beispiel erstellen?
Vermutlich wird das dann nicht gehen, wenn die Werte noch eine zusätzliche Umrechnung benötigen (wie z.B. die Uhrzeit) oder wenn ich bei einigen Werten direkt noch ein Text hinterlege, z.B. beim "Device Status"? Dennoch würde mich dein Vorschlag interessieren.So ich habe mich mal ein paar Stunden hingesetzt und - klar da musste ich selbst bissi rumprobieren - wie folgt vereinfacht.
Ich habe kein Modbus - deswegen habe ich einfach einen Forumstext genommen und nur die Bytes die ggf. modifiziert werden müssen zum Testen entsprechend angepasst.
So ich habe mal Deinen ersten Kasten "Inverter" vereinfacht!!
Der ganze "gelbe Kasten" schrumpft also auf den "grünen Kasten" - ohne dass Du was an Funktionalität einbüßt.
Grundsätzlich ist es meist nicht sinnvoll die Werte als beschreibbar zu exportieren - auch wenn du value genommen hast. Aber kann man machen (muss man in meiner Lösung nur umstellen, dann werden alle neu angelegten States beschreibbar). Die Werte sind natürlich Käse - ich habe nur darauf geachtet, dass bei der Zeit was sinnvolles rauskommt und beim Device-Status.
Letztlich hast Du ein paar nette Formatierungen eingebaut - wie den State-Name und State-Units. Ich habe das jeweils in einer eigenen Change Node abgefüttert - da das ja im Grunde optional ist.
So nun zur Erläuterung der Vereinfachungen und dem Flow im Detail:
Kernpunkt ist, dass Du den Namen in der Parser-Node bereits so benennst wie die States später heißen sollen - da diese zum Topic werden:
Das Aufsplitten in einzene Ausgänge habe ich also nicht gemacht (kein fan out).
Die Namen - sollten den State Namen entsprechen, diese werden vorerst zum topic
Den Device Status habe ich als Hexstring ausgeben lassen - muss man nicht - aber Du hast in Deiner function Node mit Hex-Strings gearbeitet, deswegen habe ich es auch gemacht - wobei ich aber die Buffer Node umrechnen lasse.Die Units in den States, die Du ja gesetzt hast, werden in der 1. Change Node gesetzt. Den StateName noch solange der topic unmodifiziert aus der Parser Node rauskommt. 1. und 2. Change Node kann man natürlich in eine Change Node zusammenfassen - das dient hier nur der Demonstration.
Vermutlich wird das dann nicht gehen, wenn die Werte noch eine zusätzliche Umrechnung benötigen (wie z.B. die Uhrzeit) oder wenn ich bei einigen Werten direkt noch ein Text hinterlege, z.B. beim "Device Status"? Dennoch würde mich dein Vorschlag interessieren.
Wie Du siehst geht es - man fischt halt die Nachrichten über das topic raus, die man noch modifizieren möchte (s. switch Node).
Die anderen lässt man durchflutschen und macht halt nichts mehr.
Es wurde bewusst auf Javascript und function Nodes verzichtet und alles mit JSONATA gemacht - da dies halt weniger Code-Schreiberei ist und in meinen Augen sehr elegant - auch wenn man sich da erst reinfuchsen muss.
Zu Schluss wird halt das Topic um den ganzen Pfad erweitert, um die States in die richtigen Datenpunkte zu schreiben:
Also easy. Und somit ist nur noch eine iobroker-Out nötig und wie gesagt - ich würde die States auf Read-Only setzen - kannst natürlich auch ändern.
Alles andere wird ja in den Nachrichtenobjekten selbst gesetzt.
Hier der Flow zum Import:
Die Change Nodes sind glaube auch von allgemeinem Interesse - weil sie zeigen, wie schön und schnell man mit JSONATA über "Übersetzungsobjekte" eine payload anpassen kann.
