Node-Red Modbus mehrere Slave ID´s abfragen
-
@malaus So ich habe ja kein Modbus - und im Prinzip sendest Du ja nicht nur ein Nachricht in dieses Flex Getter, sondern wie ich das sehe 21 * 3 - und dass da die Hardware aus dem Tritt kommt, das wundert mich ehrlich gesagt nicht.
Mir ist auch nicht klar, warum Dein Array oder Deine Objekte soviele Informationen haben (aber vielleicht ist das nur ein anderer Output), wenn Du dann bei Deinem ReadModbus dann die meisten Informationen wieder wegschmeisst.
So hier ein paar Optimierungsvorschläge:
Nun wie bekannt, bin ich kein Freund von Codierung und function Nodes, wenn es nicht sein muss. Wenn es also um reine Änderungen der payload geht - solltest Du es in meinen Augen vermeiden - dafür gibts die Change Nodes. Wie sowas geht habe ich Dir in meinem Flow mal gezeigt.
Als erstes habe ich festgestellt, dass Du in Deiner split Node hier msg.parts eingetragen hast - ich weiß das Feld ist rot - aber Du kannst es ignorieren, weil Du ja kein Objekt aufsplittest, sondern ein Array. Insofern gilt das für Dich gar nicht.
So ich musst natürlich diese Modbus Flex Getter Node simulieren - deshalb hab ich nur mal in etwas das angenommen, was vielleicht aus dieser Node rauskommen könnte anhand der Screenshots die ich gesehen habe.
Du hast ja auch bereits schon viel richtiges gesagt und festgestellt:
Die einfachste Variante ist wohl einfach wirklich die Nachrichtenrate mit einer delay Node zu begrenzen, um der Getter Node genügend Zeit zu geben bzw. der Hardware genügend Zeit zu geben, die Anfragen zu kompletieren. Die werden halt nicht selbst gepuffert. (dann kommt man auch ganz ohne function Nodes aus).
Die 2. Variante entspricht in etwa der, die Du jetzt hast, wobei - da alles gleich ist bis auf die ID - ich diese 3 Flows halt zusammengefasst habe. In dem Fall musst Du wirklich mit einer function Nodes arbeiten, da diese einen Kontext hat, der durch das Array der IDs, durch die Du iterieren willst speichern kann und einen zugrhörigen pointer. Mit jeder payload wird der pointer wieder zurückgesetzt.
Der Code ist nicht kompliziert - aber ist halt wirklich eine der Fälle, wo eine Function Node Sinn macht und ein paar JS Kenntnisse haben sollte.
if (msg.payload) { context.set("data",msg.payload); context.set("pointer",0) } var array = context.get("data"); var pointer = context.get("pointer"); pointer ++; if ( pointer <= array.length) { msg.payload = array[pointer - 1]; context.set("pointer",pointer); return msg; }Wie gesagt woher diese Mengen Adressen etc. herkommen das weiss ich alles nicht und muss es auch nicht wissen. Ich hab nur einfach das was Du mit Deinen Function Nodes machst, mit Change Nodes vereinfacht.
Was aus der Getter Node rauskommt ist natürlich reine Fantasie. msg.payload = { data : [0,0], buffer: Buffer.alloc(3) } msg.modbusRequest = { address : 99, quantity : 2 } if (msg.parts.index === msg.parts.count -1) return [msg,{payload:true}];Ich hab jetzt halt nur gewartet bist das ganze Array mit den 21 Nachrichten durchgelaufen ist.
Viel Spass beim Nachvollziehen - wenn ich keine groben Fehler gemacht habe und ich Deinen Flow einigermassen verstanden habe, sollte dann meine Optimierung funktionieren.
Auch und noch eine kleine Bemerkung:
node.send zu nutzen, sollte man vermeiden und lieber return msg verwenden. Warum manche meinen sie wollen jetzt node.send verwenden, weiß ich nicht. node.send sollte man nur bei asynchroner Verarbeitung nutzen und dann auch mit node.done abschließen. Also sollte das immer der Sonderfall sein.
Hier ein Auszug aus der Online Doku. Was sonst nämlich passieren kann ist, dass die function Node noch weiter wurschtelt und der Flow hinten dran schon munter weiter läuft.
Bei Dir machte das zwar nichts aus, da es der letzte Befehl ist, aber muss ja nicht sein, wenn man mit return msg die function Node korrekt beenden kann.
Fazit aus dem Ganzen: Funktioniert eigentlich wie es soll - nur sollte man warten, bis ein Gerät auch alle Anfragen bearbeiten konnte und deshalb wartet bis die Getter Node wieder aufnahmefähig sind.
Den Rechtschreibfehler in der ChangeNode mit Read Modubis statt Read Modbus im Namen der Change NOde möge man mir verzeihen, deswegen exportiere ich nicht wieder alles neu.
EDIT:
Falls das aber mit der einen GETTER Node nicht funktioniert mit dem Trigger und Dein Flow nur funktioniert, weil Du 3 Getter-Nodes hast, dann muss Dein Flow so bleiben, da nur dann die GETTER Nodes parallel arbeiten können. Oder Du setzt wirklich die Delay Node ein. Die Frage ist halt ob der 2. Ausgang der Getter Node wirklich signalisiert, dass sie fertig ist oder nicht. Wie gesagt, ich tu mir bei dem Ganzen halt schwer, weil ich diese Hardware nicht kenne und deshalb auch die Nodes nicht. Aber in jedem Fall denke ich, hab ich ein paar Alternativen aufgezeigt- -
@mickym sagte in Node-Red Modbus mehrere Slave ID´s abfragen:
Mir ist auch nicht klar, warum Dein Array oder Deine Objekte soviele Informationen haben (aber vielleicht ist das nur ein anderer Output), wenn Du dann bei Deinem ReadModbus dann die meisten Informationen wieder wegschmeisst.
Das liegt daran, dass ich diese Daten direkt aus dem Modbus Adapter genommen habe. Aber wie du schon bemerkt hast, sind die meisten Daten irrelevant.
So hier ein paar Optimierungsvorschläge:
Nun wie bekannt, bin ich kein Freund von Codierung und function Nodes, wenn es nicht sein muss. Wenn es also um reine Änderungen der payload geht - solltest Du es in meinen Augen vermeiden - dafür gibts die Change Nodes. Wie sowas geht habe ich Dir in meinem Flow mal gezeigt.
Sehr schöne Idee, diese Change Nodes für sowas zu nutzen!
Als erstes habe ich festgestellt, dass Du in Deiner split Node hier msg.parts eingetragen hast - ich weiß das Feld ist rot - aber Du kannst es ignorieren, weil Du ja kein Objekt aufsplittest, sondern ein Array. Insofern gilt das für Dich gar nicht.
Das kam von ein paar vorherigen Versuchen, das ganze zu splitten, Modbus Abfrage und mit dessen Wert, das ganze wieder zusammenzufügen.
Die 2. Variante entspricht in etwa der, die Du jetzt hast, wobei - da alles gleich ist bis auf die ID - ich diese 3 Flows halt zusammengefasst habe. In dem Fall musst Du wirklich mit einer function Nodes arbeiten, da diese einen Kontext hat, der durch das Array der IDs, durch die Du iterieren willst speichern kann und einen zugrhörigen pointer. Mit jeder payload wird der pointer wieder zurückgesetzt.
Die 2. Variante funktioniert nicht. Ich vermute, dass es daran liegt, dass nun jeder Wert einzeln abgefragt wird und dadurch der Trigger next ID aktiviert wird. Durch mein Abfragen der Namen habe ich das verhindert.
Auch und noch eine kleine Bemerkung:
node.send zu nutzen, sollte man vermeiden und lieber return msg verwenden. Warum manche meinen sie wollen jetzt node.send verwenden, weiß ich nicht. node.send sollte man nur bei asynchroner Verarbeitung nutzen und dann auch mit node.done abschließen. Also sollte das immer der Sonderfall sein.Hier ein Auszug aus der Online Doku. Was sonst nämlich passieren kann ist, dass die function Node noch weiter wurschtelt und der Flow hinten dran schon munter weiter läuft.
Bei Dir machte das zwar nichts aus, da es der letzte Befehl ist, aber muss ja nicht sein, wenn man mit return msg die function Node korrekt beenden kann.Danke für diesen Hinweis! Werde ich mir merken.
EDIT:
Es wird mir das topic nicht mitgenommen.
vor dem Read Modbus
Nach dem Read Modbus
-
@malaus Ok das war mein Fehler. Wenn das alles war - ansonsten schau ich gerade - dass man erst wenn sich die id wechselt triggert.
Du musst die Change node im Read Modbus entsprechend ändern, um das topic zu setzen:
Bei Dir war aber der Name auch nicht Bestandteil der payload, sondern im topic:
msg = { topic : msg.name, payload : { 'fc': fc, 'unitid': msg.unitId,//JSON.parse(unitid), 'address': msg._address,//JSON.parse(y.number), 'quantity': 2, 'value': 2 } } -
@mickym ich hätte bei bei dem trigger ein switch benutzt, der Ausschau nach dem letzten Wert hält.
Muss das nicht anders herum sein?
Ich hab ja vor dem Read Modbus ein payload.name
und möchte diese nun als topicDann sollte das doch so aussehen:
Das kommt nach der Änderung zurück:
-
@malaus Nein das sieht nicht andersrum aus. Du musst das Lesen wie es geschrieben ist.
Setze msg.topic auf msg.payload.name. Du willst das topic doch setzen - das vorher gar nicht da war.
Bei mir kommt wenn du die Change Node entsprechend änderst, der Name aus dem ursprünglichen Objekt als payload an:
-
@mickym achso habe das anders herum verstanden.
Aber jetzt geht es! und mit dem Switch funktioniert auch.
Danke!
-
Wie sieht der switch aus? ggf. kannst dann auch eine filter Node nehmen.
-
-
@malaus Na ja - ich verstehe, weil Du sagst das ist das letzte Element in Deinem array. Dann finde ich es intuitiver und besser - wirklich die id als topic zu nehmen und hab mal eine filter Node verwendet. Ich weiss nicht, ob aus dem unteren Teil einfach die Eingangsobjekte durchgereicht werden. Aber dann spart man sich das topic einfach.
Falls also am unteren Ausgang der GETTER Node einfach das Eingangsobjekt durchkommt:
Für mich wäre dann das am saubersten:
Dann kann man nämlich auch mal eine andere Reihenfolge beim createArray erstellen verwenden ohne das es Folgen haben würde.
-
Bei debug 19 erhalte ich keine Werte. Der Durchlauf wird nur mit einer ID gemacht.
Den Filter verstehe ich nicht so ganz:
Bei Read Modbus hast du das Topic rausgenommen, ist das so gewollt? Ändert aber auch nichts, wenn ich es wieder einsetze.
-
@malaus Ja ich weiss - ich war der Meinung . dass unten einfach die Eingangsobjekte rauskommen - deswegen habe ich das topic auch wieder raus genommen. Kannst Du mal die Nachrichten, die aus debug 18 rauskommen posten und ist da die ID drin? Ich kann halt immer nur Vermutungen anstellen, was die GETTER Node ausspukt.
Am Besten das ganze Nachrichtenobjekt in debug 18 ausgeben lassen und hier in CodeTags einbetten. -
Die Getter Node spuckt mir jeden Wert einzeln aus.
-
Nein ok - ich habe gerade einen Denkfehler gemacht - es wird ja nun bei jedem 1. Element geändert - sorry mein Fehler. Ich werde was einbauen, dass man das letzte Element automatisch erkennt. Sorry - einen Augenblick!!!
Noch eine Frage ich sehe gerade die GETTER node - und deshalb auch der Fehler die queued je ID.Kannst Du mal schauen, ob das letzte Element aus debug 18 queuelength 0 hat?
-
@mickym das letzte hat die 20
-
Ok danke.
- Das heißt die queuelänge baut sich auf und wird nur intern abgearbeitet Die msg.parts Eigenschaft scheint nicht durch zu kommen, sondern nur das topic - dann müssen wir ggf. doch das topic nutzen aber nicht anhand des Namens sondern dann würde ich wirklich nach der msg.parts Eigenschaft das topic setzen.
das heißt wir wissen ja wieviele Elemente kommen und setzten da topic entsprechend.
-
@mickym
das erste:
das letzte:
-
@malaus Ok wenn das topic das Einzige war was durchkommt (das msg.parts Objekt wird leider durch die GETTER Node nicht durchgereicht oder ist das enthalten?) , dann nehmen wir im Prinzip deine Lösung, setzen das topic aber nicht einen bestimmten Namen in dem array, sondern lassen einfach runterzählen.
Das sollte dann aber auch tun.
Ist also im Prinzip dein Flow mit dem switch als trigger nur das ich im topic nun die Anzahl der noch zu erwartenden Elemente durchreiche:
Hier konntest Du ja auch nach dem topic filtern: https://forum.iobroker.net/post/947167 - also sollte es jetzt auch gehen.
Wie gesagt Deine Lösung https://forum.iobroker.net/post/947177 funktioniert ja auch - aber mich würde halt stören, dass ich als Marker für das array Ende einen festen Namen im Array verwenden muss.
-
@mickym ich musste die zahlen um eins erhöhen, weil der die null nicht wollte aber jetzt funktioniert es.
Die letzte Zahl ist also die 1.Ich habe den Trigger ID´s nochmal angepasst, damit am Ende es automatisch wieder von vorne anfängt.
Ansonsten funktioniert es jetzt.
Danke! -
@malaus Ich habs zwar nicht verstanden, warum die 0 nicht funktioniert - aber wenn es jetzt funktioniert bin ich erst mal raus. Ich denke Du hast das Prinzip ja verstanden. Vielleicht setzt die GETTER Node ein eigenes topic wenn keines gesetzt war und interpretiert deshalb die 0 als falsch. Das kann natürlich sein und Du hast Dir ja dann geholfen. Wie gesagt, ich habe halt keine getter Nodes und tapse deshalb bissi im Dunkeln.
-
@mickym mir ist aufgefallen, wenn das ganze mal z.B. durch einen Neustart oä gestoppt wird, nicht von alleine weiter macht. Gibt es bei NodeRed sowas, dass bestimmte Sachen gestartet werden, wenn die Instanz startet?
Ebenfalls habe ich das Gefühl, dass das ganze durch Backitup unterbrochen wird und danach nicht wieder anläuft.Oder ist sinnvoller eine Art Überwachung, wenn nach x Minuten keine neue Variable eingelesen wird, mache Neustart.
Hast du Erfahrung mit sowas? Bzw. hattest du so einen ähnlichen Fall schon mal?
