NEWS
Node-Red Modbus mehrere Slave ID´s abfragen
-
@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 } } -
@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:
-
@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:
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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:
-
@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:
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. ;)
-
@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.
-
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.
-
@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.
-
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?
-
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?
-
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.
-
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.
-
@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. ;)
-
@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! -
@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.
-
@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?
-
@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?
@malaus
Also einfach Deine Inject Node aufmachen - mehrere IDs.
Anhaken, dass einmal nach x Sekunden getriggert wird. Dieses X Sekunden beziehen sich auf den Start von Node-Red oder in dem Fall auf die Adapterinstanz.
Anasonsten kann natürlich alles andere auch triggern. Aber von irgendwas muss ein Flow ja angestossen werden, Hardware, Zeit,manuell oder eben einmal nach dem Start.
-
@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?
@malaus sagte in Node-Red Modbus mehrere Slave ID´s abfragen:
Ebenfalls habe ich das Gefühl, dass das ganze durch Backitup unterbrochen wird und danach nicht wieder anläuft.
Kann ich mir höchstens vorstellen wenn Dein Hardware durch das Backup überfordert wird und zuviel CPU verschlingt. Dann bleiben halt für die anderen Adapter nicht mehr soviel über. Ich bin ja auch grundsätzlich kein Freund - von solchen Pollmechanismen - also zyklisch die Hardware abzufragen - aber das ist eine andere Geschichte. Ich finde es besser immer die Hardware triggern zu lassen.
Das sind aber prinzipielle Fragen - wie man solche Flows aufbaut. Ich hätte wesentlich eher die modbus reads genommen und die Hardware triggern lassen - also zyklisch abzufragen. In der Beschreibung zu der Node sieht man auch http trigger - die also auch nicht zyklisch, sondern von der Hardware initiiert das Auslesen der Getter-Nodes initiiieren.
Lange Rede kurzer Sinn - Du musst halt schauen, ob Deine Hardware durch das Backup nicht in die Knie gezwingen wird.
Support us
689
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge