Einem Kollegen hatte ich eine Modbus-TCP Anbindung für seinen Huawei SUN2000 Wechselrichter zum Auslesen von Werten schmackhaft gemacht. Meine NodeRED Anbindung unserer E3DC Solaranlage läuft ja sein längerer Zeit sehr gut. Somit konnte ich ihm guten Gewissens auch anbieten seinen Huawei Wechselrichter mit meiner Unterstützung auszulesen.
Ich bereitete einen noch vorhandenen Raspberry Pi3 vor und los ging es an die Programmierung. Ich hoffte mein altes Script etwas anzupassen und damit die Anbindung herzustellen. Ich musste aber feststellen dass es so selbsterklärend dann doch nicht war und die SUN2000 Modbus Anbindung mir doch einige graue Haare bescherte.
Somit begann ich die vorhandene NodeRED Programmierung komplett zu überarbeiten, in Subflows zu kapseln und den Code so variablen zu gestalten dann man hinterher wesentlich einfacher andere Modbus Registerbereiche auslesen und verarbeiten kann. Es sollte wesenltich einfacher sein, am besten viel parametrieren und wenig zusätzlichen Code schreiben. Da ich auch noch mit 2 verschiedenen Modulen zur Modbus Anbindung experimentieren musste wurde der Code und die Parametrierung gleich variabler ausgelegt.
Dadurch ist es etwas komplexer die Modbus Abfrage zu erstellen, da man die Modbus-Parameterliste als vordefiniertes JSON Objekt schreiben muss, allerdings lassen sich sehr einfach andere/korrigierte Modbus Register abfragen da man nur noch die Parameterliste anpassen und neu speichern muss.
Im Bild sieht man 2 FLows.
- Im oberen Flow wird festgelegt welche Paramater aus dem Modbus Gerät ausgelesen werden sollen und wie die Ergebnisse zu interpretieren sind.
- Im unteren Flow erfolgt die Abfrage der im ersten Flow definierten Parameter, die Abfrage des Modbus Gerätes, das extrahieren und konvertieren der Modbus Antwort(en) und die Vereinzelung eines einzelnen Datenpunktes aus der gesamten schon in ein Objekt konvertierten Modbus Antwort.
Hier im Beitrag werde ich wieder die Variante mit der Ansteuerung der E3DC Solaranlage zeigen, auf den Huawei SUN2000 Wechselrichter gehe ich weiter unten speziell ein.
Die folgenden Voraussetzungen werden benötigt um meine Programmierung nutzen zu können:
- NodeRED in einer halbwegs aktuellen Version – ich nutze v3.0.2
- den Node node-red-contrib-modbus (hier dargestellt) oder node-red-contribtcp
- die IP Adresse des Modbus-TCP Gerätes
Alle weiteren Node sollten in der Grundinstallation von NodeRED schon mit dabei sein. Der Modbus Node node-red-contrib-modbustcp funktioniert prinzipiell auch gut, allerdings ist das timing und die Auslösung leicht unterschiedlich.
Dann müssen folgende Konfigurationen (Parametrierungen) durchgeführt werden:
Modbus-Parameterliste
- besteht aus mehreren Abschnitten, bitte die mitgelieferte Struktur nutzen und diese nur anpassen oder im gleichen Muster erweitern
- „ModbusParameter“ Abschnitt
- „unitid“ => nur diese ist hier relevant, es wird die id in der Modbus konfiguration (FlexGetter) damit überschirben
- die restlichen Objekte dienen nur der besseren Übersicht und werden nicht ausgwertet
- „ModbusCommands“ Abschnitt
- besteht aus einem oder mehreren Abschnitten (Objekten). Jeder Abschnitt (Objekt) enthält die Grundkonfiguration für die Anfrage an den Modbus Node. Die Beschriftungen sollten eindeutig sein. Das Element „interval“ wird nur ausgewertet wenn man den Modbus-Node „node-red-contrib-modbustcp“ benutzt, sonst nicht
- „quantity“ => wie viele 16 Bit Register ab „addressStart“ vom Modbus abgefragt werden sollen
- „ModbusAdresses“ Abschnitt
- besteht aus einer Anzahl von Objekten für jede Information (jedes Register) welches man auslesen möchte
- es gibt hier eine Definition der Registeradresse (Objektname) und dann einige Eigenschaften welche die Modbus Daten dieses Register genauer beschreiben und unter welchem Namen das Objekt am Ausgang des Subflows „ModbusResponseExtract“ dann publiziert (ausgegeben) wird.
- genaueres dann in der Beschreibung für diesen Subflow
- es müssen nicht zwingend alle Modbus Adressen, die abgeholt werden in diesem Abschnitt deklariert sein, Lücken sind kein Problem. Werden zu wenige Register abgeholt (quantity) können die hier angegebenen Register nicht ausgewertet werden, verursachen aber kein wirkliches Problem
- Sind Registeradressen angegeben die nicht abgerufen werden, so werden diese einfach ignoriert. Im Modus „LogError=true“ werden dazu in der NodeRED Konsole Meldungen ausgegeben sonst merkt man das nicht nur dass halt Werte nicht vorhanden sind.
- „ModbusPermission“ Abschnitt
- dieser Abschnitt dient nur zur Information und enthält eine mini Beschreibung welche Namen in der Parameterliste erlaubt bzw. berücksichtigt werden
der inject Node bekommt die folgenden Einstellungen:
- topic => beliebig
- payload => hier befindet sich die gesamte „Modbus-Parameterliste“
- einmalig injizieren => anhaken, damit wird bei jeder Änderung automatisch der Flow angestoßen damit die Parameterliste auch in der globalen Variable aktualisiert wird
- Wiederholung => diese Angaben dienen nur der doppelten Absicherung damit bei irgendwelchen Umständen der Nichtverfügbarkeit der Variable diese täglich erstellt wird
Name des Speicherplatz für die „Modbus-Variablenliste“. Genau dieser Name ist in den anderen Subflows in der Parameterliste anzugeben!
- „setze – global“ => in dieses Feld einen String eingeben. Unter diesem Namen wir die globale Variable erzeugt in welcher die „Modbus-Variablenliste“ abgelegt wird. Die restlichen Felder bitte nicht ändern
- den verwendeten Modbus Node „Modbus-Flex-Getter“ aus node-red-contrib-modbus (dieses Modul muss im NodeRED eventuell nachinstalliert werden) die Konfiguration der Modbus TCP Anbindung mit der eigene IP Adresse des entsprechenden Modbus TCP Gerätes versehen und die restlichen Parameter angeben dabei wird die „Unit-id“ im Code durch eine selbst definierte ID ersetzt (oder den modbustcp Node entsprechend parametrieren)
- der Node sollte nach einer kurzen Initialisierungsphase schon mal „active“ anzeigen
- Name => beliebig aber lesbar
- Host => die IP Adresse des Modbus Device
- Port => normalerweise bleibt es bei 502 (Modbus Device Dokumentation)
- Unit-id => beliebige Zahl, wird durch den Code ersetzt
- Timeout => bitte nicht zu kurz ansetzen
- Reconnect => bitte nicht zu kurz ansetzen
- hat man diesen Node erstmals neu installiert, muss man einen neuen „Server“ anlegen, der dann den Parametersatz für die Modbus-TCP Anbindung enthält.
- der FlexGetter fragt von sich aus keine Modbus Register ab, er muss am Eingang ein Mesage Objekt in einer entsprechenden Struktur erhalten. Dies liefert der „ModbusGetCommand“ Subflow dessen Inhalt sind die konfigurierten Parameter der „Modbus-Parameterliste“
- die Parameter im Node „ModbusGetCommand“
- Name => beliebig
- N_ModbusParam => der Name der globalen Variablen in dem die gesamte Modbus-Parameterliste enthalten ist (siehe oben)
- node-red-contrib-modbus => true wenn der anschließeden Node „node-red-contrib-modbus“ verwendet wird (hier der Abbildung verwendet) ODER false wenn der Node aus „node-red-contrib-modbustcp“ verwendet wird
- die Parameter im Node „ModbusResponseExtract“
- Name => beliebig
- N_ModbusParam => der Name der globalen Variablen in dem die gesamte Modbus-Parameterliste enthalten ist (gleich wie oben)
- ModbusAddrKorr => ein Korrekturfaktor für die Modbus Adressen, warum auch immer nutzen manche Device Adressen die von der Parameterliste um +- 1 bis 2 versetzt sind, hier kann der Korrekturfaktor eingetragen werden. Hat man den richtigen Wert, so kommen auch plausible Werte, liefert die Konvertierung „Müll“ so muss man den Korrekturfaktor anpassen (siehe Beschreibung der Modbus TCP Device Adressliste). Theoretisch kann man auch einfach die Registeradressen anpassen aber mit dieser Einstellung kann man 1 zu 1 die Registeradressen der Modbus Deviceliste nutzen und kann bei Fehlern 1 zu 1 vergleichen.
- LogError => Fehler Logging Ein-/Ausschalten (zum Fehler suchen)
- true => Fehler Logging eingeschaltet
- false => Fehler Logging ausgeschaltet
- oldPayload => Original Modbus Output mitsenden true/false (zum Fehler suchen)
- ModbusParam => Abfrage Modbus Parameter mitsenden true/false (zum Fehler suchen)
- die Parameter in einem oder mehreren (Sub-) Node „PayloadMultiToSingle“ beispielhaft für ein Modbus Register „PVLeistung“. Dieser Node wird so konfiguriert dass er aus den ganzen ausgelesenen Modbus Registern und den daraus sich erggebenden Payload Objekten nur dieses spezielle Objekt ermittelt und dessen umgerechneten Wert des Datenpunktes (Messwert) als payload ausgibt und dann noch einige ander wesentliche Objekte beschreibt. Will man also 7 Modbus Register auswerten, muss man 7 Abschnitte in der Modbus-Parameterliste definieren. Für diese 7 Register wird EIN Message Objekt (payload.*) mit 7 Unterobjekten ausgegeben. Jeweils eines davon lässt sich mit diesem Node aus dem Gesamtobjekt „herauslösen“ und vereinzeln
- Name => beliebig
- In jedem Parameter ist nur der String zwischen „payload.“ und „.val“ anzupassen, hier im Beispiel das Wort „PVLeistung“. Der richtige Name (Groß-Kleinschreibung beachten) wurde vorher in der Modbus-Parameterliste selbst gewählt. Es ist der identische String der pro Parameter im JSON Objekt bei „msgName“ angegeben wurde. Er sollte so gewählt werden dass man als Mensch noch vestehen kann was genau sich dahinter verbirgt. Bitte keine speziellen Sonderzeichen , Leerzeichen oder ähnliches benutzen!
- valSource => der Pfad und Name des Objektes dessen Value am Ausgang dieses Nodes in msg.payload stehen soll
- der String ist etwas davon abhängig wie man die Modbus-Parameterliste definiert hat. Normalerweise „payload.“ + Objektname + „.val“
- topicSource => der String ist etwas davon abhängig wie man die Modbus-Parameterliste definiert hat. Normalerweise „payload.“ + Objektname + „.nameUser“ (hier muss ich noch etwas in einer nächsten Version verbessern)
- unitSource => der String ist etwas davon abhängig wie man die Modbus-Parameterliste definiert hat. Normalerweise „payload.“ + Objektname + „.unit“ (die Unit wir 1 zu 1 aus der Modbus-Parameterliste durchgereicht
- nameSource => der String ist etwas davon abhängig wie man die Modbus-Parameterliste definiert hat. Normalerweise „payload.“ + Objektname + „.nameUser“ (der String wir 1 zu 1 aus der Modbus-Parameterliste durchgereicht, er sollte einen menschenlesbaren Namen in der Parameteriste erhalten
der inject Node „Zeitsteuerung der Abfrage“ dient einzig als zyklischer Trigger zum Anstoßen der Modbus-TCP Abfrage. Das Timing ist dem eigenen Bedarf anzupassen. Bei zu kurzen Abständen und zu vielen Modbus Abfragebereichen und Anzahl der abzufragenden Register können die Modbus Device eventuell nicht mehr richtig funktionieren.
- Wiederholung => in welchem Zyklus alle Modbus Parameter aus der Modbus-Parameterliste abgeholt werden sollen und im Anschluss dann zur Verfügung gstellt werden – Aktualisierungsrate aller Werte
- und dann kann man noch irgend etwas mit den vorhandenen extrahierten Modbus Daten anfangen – hier nicht weiter dargestellt
Nun erfolgt eine kurze Beschreibung des Zusammenhanges der „Modbus-Parameterliste“ und der Funktionalität des gesamten Flows
Modbus-Parameterliste
Die Modbus Parameterliste (im inject Node „E3DC – Modbus Parameter“) ist ein JSON Objekt und unterliegt den Restriktionen von JSON. Die Liste ist in 4 grundsätzliche Blöcke unterteilt „ModbusParameter“, „ModbusCommands“, „ModbusAdresses“ und „ModbusPermission“. Davon dient der Abschnitt „ModbusPermission“ nur zur Information und als Hilfe bei der Erstellung / Änderung von Parametern.
ModbusParameter=>Basis Modbus Abfrage
ModbusCommands=> ein oder mehrere Blöcke für die dierekt Modbus Register Abfrage
ModbusAdresses => Definition jedes einzelnen auszuwertenden Modbusregister mit allen Eigenschaften des Datenpunktes und des dann erzeugten NodeRED Message Objektes.
Bitte bei Änderungen beachten: die Kommasetzung und Leerzeichen / Sonderzeichen
ModbusAdresses (erster Hauptabschnit in der Modbus-Parameterliste)
- unitid => die Unit ID des Modbus Device (der genaue Wert ist bei Modbus TCP eingentlich unkritisch aber bei mehreren paralelen Modbus Anbindungen könnte das eine Rolle spielen: 0 oder 1 sollten funktionieren)
- ModbusName => beliebig, dient nur zur besseren Lesbarkeit
- ModbusMemo => beliebig, dient nur zur besseren Lesbarkeit
- VersionParameter => beliebig, dient nur zur besseren Übersicht
ModbusCommands (zweiter Hauptabschnit in der Modbus-Parameterliste)
Besteht aus einem oder mehreren JSON Objekten. Jedes Objekt beschreibt ab welcher Startadresse wie viele Modbus Register Adressen (Anzahl) abgeholt werden sollen, welcher Modbus Funktionscode dafür genutzt wird und legt eine Verzögerung fest damit mehrere Funktionsblöcke nacheinander nicht sofort vom Modbus Device abgeholt werden sollen sondern mit einer verzögerten Anfrage. Man kann also weit auseinander liegende Registerbereiche in Abschnitte unterteilen um nicht in einem Rutsch hunderte Register auslesen zu müssen. Man muss auch nicht zwingend alle abgeholten Register im späteren Flow auswerten.
- Objektname z.B. „Identifikationsblock“ => frei wählbar, hat keine Auswirkung
- addressStart => Startadresse für diesen Block. Ab dieser Registeradresse werden vom Modbus TCP Device die Daten abgeholt.
- quantity => Anzahl der aufeinanderfolgenden Registeradressen die ab „addressStart“ abgeholt werden. (Die einzelnen Registeradressen aus dem Abschnitt „ModbusAdresses“ sollte sich in einem der hier definierten Bereiche befinden)
- „delay_ms“ => enthält einen Zahlenwert in Millisekunden. Um diese Zeitspanne verzögert wird diese Modbus Registerabfrage gestartet. Nutzt man nur einen einzigen Block kann man hier eine 0 eintragen. Nutzt man mehrere Blöcke, so kann der erste Block eine 0 und im nächsten Block sollte man besser „1000“ oder größer angeben. Ich nutze „10000“ also 10 Sekunden, das gibt aktuell keine Probleme.
- „topic“ => frei wählbar – hat aktuell keine weiteren Auwirkungen
- „interval“ => diese Angabe wird nur bei Anwendung des Modbus Node „node-red-contrib-modbustcp“ ausgewertet und verwendet. Es gibt das zyklische Timing an, in welchem Intervall immer wieder dieser Adressbereich abgefragt wird. In der hier beschriebenen aktuellen Konfiguration wird ein anderer Node, der „Modbus-Flex-Gatter“, benutzt, dabei ignoriert der Code diese Angabe.
- „memo“ => frei wählbar, als Gedankenstütze zum Beispiel
ModbusAdresses (dritter Hauptabschnit in der Modbus-Parameterliste)
Der Abschnitt „ModbusAddresses“ enthält einen oder mehrere Blöcke (Objekte) welche immer eine Modbus Adresse – einen Modbus Datenpunkt – komplett beschreiben. Diese beschreibenden Informationen nutzt der Subflow „ModbusResponseExtract“ und erstellt aus der Modbus Antwort (aus den 16 Bit Registerwerten) von genau dem richtigen Abschnitt der Antwort ein Message Objekt welches alle relevanten Informationen und Umrechnungsdefinitionen des Datenpunktes enthält. Also wird dadurch aus dem 16 Bit Muster z.B. eine Zahl oder ein String.
- Registeradresse als Objektname mit den Elementen der Beschreibung des Datenpunktes – hier im Beispiel „40001“ bedeutet die Modbus Registeradresse 40001. Das Objekt enthält dann alle weiteren Deklarationen für genau diesen Datenpunkt.
- msgName => String, frei definierbar, daraus wird der Name des Message Objektes erzeugt der dann wiederum als (Unter-)Objekt im Payload am Ausgang des „ModbusResponseExtract“ Node ausgegeben wird. Hier keine Sonderzeichen und Leerzeichen benutzen!
- name => String, frei definierbar, es ist vorgesehen hier den Text aus der Modbus Registerbeschreibung des Devices zu hinterlegen damit bei späterer Kontrolle genau klar ist um welchen Parameter es sich handelt.
- „nameUser“ => String, frei definierbar, ein möglichst menschenlesbarer Name für diesen Datenpunkt. Im berechneten Message Objekt wird dieser Name als „topic“ ausgegeben, der dann evtl. zur Beschriftung bei Visuellen Elementen genutzt werden könnte.
- type => String, Datentyp des Modbus Register. Hier sind nur spezielle vordefinierte Strings erlaubt. Diese beschreiben wie der Modbus Datenpunkt in einen realen Wert umgerechnet (konvertiert) werden muss. In der aktuellen Version sind die folgenden Typkonvertierungen umgesetzt: HEX16 UINT16 INT16 UINT32 INT32 STRUINT8.STRUINT8 STRING BITFIELD16 BITFIELD16SWAP FLOAT64. Die Modbus Registerbeschreibung enthält einen Hinweis welche dieser Typkonvertierung angegeben werden soll. Sind für manche Typen mehrere Register nötig, werden automatisch die weiter aufsteigenden Register zur Berechnung mit benutzt.
- unit => String, frei definierbar, ein String zur Beschreibung der Maßeinheit des Datenpunktes. Im berechneten Message Objekt wird dieser String als „unit“ ausgegeben.
- gain => Integer, Manche Datenpunkte benötigen eine Division durch einen Wert um das richtige Ergebnis zu liefern. Dieser Divisor ist hier anzugeben. Beispielhaft für die Spannung der Phase L1 über den Modbus intern als Wert 2325 ausgegeben. Gibt man hier bei „gain“ die 10 ein, so wird der Wert durch 10 dividiert und als Ergebnis wird 232,5 ausgegeben was dem richtigen Spannungswert entspricht. Dieser Faktor kann aus der Modbus Registerbeschreibung entnommen werden.
- quantity => Integer, wird aktuell nur benätigt wenn „type:STRING“ genutzt wird da hier definiert ist wie 16 Bit Werte hintereinander in ASCII Zeichen umgewandet und als String ausgegeben werden sollen. Alles andern Konvertierungen ignorieren diese Angabe.
- memo => beliegbig, was man noch so hinterlegen will
NodeRED Programm Vorbereitung – Zusammenfassung
- den bereitgestellten Code in NodeRED importieren
- eventuell das Modul node-red-contrib-modbus nachinstallieren (wenn sich NodeRED beschwert)
- den Node „Modbus Parameter speichern“ parametrieren und bei Änderung des Variablennamen diesen sich merken
- einmalig muss der Modbus Node „Flex Getter“ mit den Modbus TCP Device Informationen parametriert werden
- Parameter des Nodes „ModbusGetCommand“ anpassen – Variablennamen!
- Parameter des Nodes „ModbusResponseExtract“ anpassen – Variablennamen!
- Parameter der Node „PVLeistung“ und „EVULeistung“ (Basis ist der Subflow „PayloadMultiToSingle“) anpassen mit den eigenen Angaben dessen Basisinformationen der Modbus-Parameterliste zu entnehmen ist
- eventuell weitere Nodes „PayloadMultiToSingle“ hinzufügen, Parameter anpassen und an den Ausgang des Node „ModbusResponseExtract“ anbinden
- Der Ausgang jedes „ModbusResponseExtract“ Node liefert dann ein Message Objekt mit den wesentlichen Daten aus der Modbus Abfrage für das jeweilige Register (den Datenpunkt)
- an dessen Ausgang kann man dann irgendwelche visuellen Elemente oder weitere function Nodes anbinden
- Die regelmäßige Modbus Abfrage erfolgt über den Trigger der im „inject“ Node „Zeitsteuerung Abfrage“ definiert ist. Damit lässt sich einstellen wie oft man vom Modbus Gerät Daten bekommen möchte. Bitte sorgsam mit dem Timing umgehen. Einige „schmalbrüstige“ Modbus Device vertragen keine Abfrage alle 10 Millisekunden.
- Hinweis: nutzt man für die Modbus TCP Anbindung den Node „node-red-contrib-modbustcp“ dann bitte hier kein extra Trigger deklarieren. Durch das erstmalige Triggern wird diesem Node ein „interval“ mitgegeben (Modbus-Parameterliste) den dieser selbsttätig immer wieder, parallel zu seiner eigenen Node Konfiguration, auslöst.
- Die regelmäßige Modbus Abfrage erfolgt über den Trigger der im „inject“ Node „Zeitsteuerung Abfrage“ definiert ist. Damit lässt sich einstellen wie oft man vom Modbus Gerät Daten bekommen möchte. Bitte sorgsam mit dem Timing umgehen. Einige „schmalbrüstige“ Modbus Device vertragen keine Abfrage alle 10 Millisekunden.
zum Start / Inbetriebnahme / Fehlersuche
- der Modbus Node „FlexGetter“ sollte den Zustand „active“ einnehmen solange er keine Daten abholt. Während der Datenabholung gibt es weitere Zustände. Erfolgt hier eine Fehlermeldung dann ist die Modbus Anbindung zu prüfen. Solange das nicht funktioniert braucht man sich um den Rest keine Gedanken zu machen.
- die einzelnen Debug Optionen anschalten um Fehler finden zu können
- Nachdem alles parametriert ist, Kontrolle des Messwertes (.val) eines Message Objekt von welchem man genau den Wert kennt (z.B. MagicByte oder Netzspannung), kommt hier quatsch an ist die Modbus-Parameterliste zu checken und mit dem Korrekturfaktor „ModbusAddrKorr“ im Node „ModbusResponseExctrakt“ zu ’spielen‘ bis der vom Modbus gelieferte Wert dem Sollwert entspricht.
- Wenn dann wenigstens eine richtige Information kommt stimmt die Modbus Anbindung und der eventuelle Modbus Adressversatz.
- Es sollten dann alle am Ende zur Verfügung stehenden Message Objekte kontrolliert werden. Die einzelnen Debug Optionen sollten helfen eventuelle Schreibfehler in der Modbus-Parameterliste zu identifizieren.
- Fehlermöglichkeiten:
- Modbus-Adressliste Abschnitt „ModbusCommands“ werden beginnend mit „addressStart“ nicht genügend weitere Register abgerufen – „quantity“ anpassen oder „addressStart“ anpassen
- Liegen die Registerwerte zu weit auseinander dann besser mehrere Abschnitte definieren
- ist eine Start Adresse angegeben die das Modbus Device nicht untertsützt, oder eine Länge angegeben für welche das Modbus Device auch keine Parameter mehr zur Verfügung stellt, kommt ein Timeout oder ‚komisches‘ Verhalten
- Typ des Datenpunktes nicht korrekt => Modbus-Adressliste Abschnitt „ModbusAdresses“ -> „type“ des Registerparameter korrigieren, hier ist ganz genau die Schreibweise zu kontrollieren. Nur identische Namen funktionieren.
- ein Messwert kommt aber mit einer falschen Zehnerpotenz des Datenwertes => Modbus-Adressliste Abschnitt „ModbusAdresses“ -> „gain“ des jeweiligen Registerparameter anpassen
- Modbus-Adressliste Abschnitt „ModbusCommands“ werden beginnend mit „addressStart“ nicht genügend weitere Register abgerufen – „quantity“ anpassen oder „addressStart“ anpassen
- Das gesamte NodeRED stoppen, warten und wieder starten. Es sollten nach kurzer Zeit wieder alle Nachrichten verarbeitet werden. (Neuanlauf testen)
Beispielhaft das Mesage Objekt ‚PVLeistung‘
- payload => Messwert (128 Watt“
- topic => Name (aus der Modbus Parameterliste – „nameUser“)
- unit => Maßeinheit für den Datenpunkt (aus der Modbus Parameterliste – „unit“)
- name => Name (aus der Modbus Parameterliste – „nameUser“ – aktuell identisch zu topic)
zur Laufzeit
- Ist eigentlich keine weitere manuelle Änderung nötig. Wer Lust hat sollte sich eventuell um ein Laufzeit Verfügbarkeits Monitoring kümmern.
- Das Debugging kann man dann in den einzelnen Subflows wieder deaktiveren damit der Traffic wieder reduziert wird.
NodeRED Download Files:
- gesamter NodeRED Flow wie oben abgebildet (mit Parameter für E3DC Hauskraftwerk)
- separate Modbus Parameterliste für den Huawai Wechselrichter SUN2000, getestet mit ‚SUN2000-8KTL-M1‘ (beispielhaft mit einer Modbus und Parameterdefinition ohne den restlichen Flows)
in eigener Sache:
Kommentare hier im Blog werden nicht zeitnah gelesen und freigeben (es gibt zu viele Spackos). Bitte etwas Geduld haben.