NEWS
Verfügbarkeit von Sensoren über Node Red überwachen
-
@schmetterfliege Die Init Node - hatte ich ja geschrieben - die muss halt einmalig trigger - da musst halt den Haken setzen. Dann sind die Namen doch direkt nach NR Start verfügbar. Die Werte kommen erst peu a peu, wenn Du die halt unbedingt einmalig initialisieren willst - dann musst halt noch zusätzliche list Nodes zum Auslesen benutzen.
Also noch den Haken in der Init Node - dann werden die Namen sofort nach Systemstart gesetzt.
Manchmal scheine ich mich doch nicht klar auszudrücken:
@mickym
Sorry falls ich mich komplett blöd anstelle, solangsam befürchte ich es^^
Ich habe (im Prinzip) schon verstanden was du meinst!
Also den Haken in der Init Node habe ich nun drin.
Wenn ich den Flow neu starte, habe ich in damit also sofort alle Namen verfügbar.
Die Tabelle ist aber leer.
Die ist erst da, wenn irgendein Sensor nun einen Wert aktualisiert.
=> Das ist das, was du für mich aufgebaut hast.Genau das - das kursive - möchte ich nun verkürzen indem die Namen nicht nur sofort verfügbar sein sollen, sondern auch sofort in der Tabelle stehen.
Das habe ich gerade die ganze Zeit durch meine Tests versucht^^Wenn ich jetzt deine letzte Nachricht richtig interpretiere, müsste ich den Flow also so anpassen:
Also die Function node mit der Change Node verbinden, und in der Function meine msg ausgeben.
Oder muss ich die beiden Nodes nicht miteinander verbinden? -
@mickym
Sorry falls ich mich komplett blöd anstelle, solangsam befürchte ich es^^
Ich habe (im Prinzip) schon verstanden was du meinst!
Also den Haken in der Init Node habe ich nun drin.
Wenn ich den Flow neu starte, habe ich in damit also sofort alle Namen verfügbar.
Die Tabelle ist aber leer.
Die ist erst da, wenn irgendein Sensor nun einen Wert aktualisiert.
=> Das ist das, was du für mich aufgebaut hast.Genau das - das kursive - möchte ich nun verkürzen indem die Namen nicht nur sofort verfügbar sein sollen, sondern auch sofort in der Tabelle stehen.
Das habe ich gerade die ganze Zeit durch meine Tests versucht^^Wenn ich jetzt deine letzte Nachricht richtig interpretiere, müsste ich den Flow also so anpassen:
Also die Function node mit der Change Node verbinden, und in der Function meine msg ausgeben.
Oder muss ich die beiden Nodes nicht miteinander verbinden?
und dazwischen hängst eine trigger Node - damit nur die letzte Nachricht triggert - sprich alles fertig ist:
Irgendwann wirst Du Node Red schon noch lieben - ist doch alles super easy wie man vorhandenes einfach miteinander verkabeln kann, um den individuellen Wünschen gerecht zu werden. ;) ;) ;)
Übrigens nutzte selbst halt Debug Nodes soviel Du kannst um immer zu sehen, was passiert - also müsste aus der trigger Node nur eine Nachricht anstelle von 18 rauskommen. ;)
-
und dazwischen hängst eine trigger Node - damit nur die letzte Nachricht triggert - sprich alles fertig ist:
Irgendwann wirst Du Node Red schon noch lieben - ist doch alles super easy wie man vorhandenes einfach miteinander verkabeln kann, um den individuellen Wünschen gerecht zu werden. ;) ;) ;)
Übrigens nutzte selbst halt Debug Nodes soviel Du kannst um immer zu sehen, was passiert - also müsste aus der trigger Node nur eine Nachricht anstelle von 18 rauskommen. ;)
Ich liebe NR!
Es nervt bloß dass ich so viel Hilfe brauche und mich doof anstelle :D.
Meinem Spaß an NR tut das keinen Abbruch, im Gegenteil!Mit dem Trigger hat es nun geklappt, vielen Dank!
Bitte hasse mich nicht:
Nun müsste ich den Flow noch anpassen dass er mir nur die richtigen Sensoren beim aktualisieren liefert.
Hier zur Veranschaulichung:
Der obere Teil - also da wo die Aktualisierungen kommen - liefert mir Daten von 22 Sensoren. 18 die ich will, 2 Sensoren die nicht Konfiguriert sind, und 2 Motion Sensoren die dummerweiße auch einen Temp Sensor haben...
Der untere Teil, also da wo ich die Namen auslesen, spuckt eigentlich 32 Sensoren aus (weil 32 Zigbee Devices).
Über die Switch Node hole ich mir die 18 die ich brauche (haben alle "Multisensor" im Namen) raus.
Das klappt.
Nun muss ich den oberen Teil so anpassen, dass ich auch nur die Daten von den 18 Sensoren bekomme.
Ansonsten habe ich 4 Einträge in der Tabelle, die keinen Namen haben (von den unkonfigurierten und von den motion sensoren).Was ich tun würde:
Mit einer Switch Node VOR den Function Nodes checken ob das was ich bekomme ein bestimmtes Topic hat (die IDs von den Sensoren). Sprich: 18 Outputs, wo ich die 18 die ich brauche raussuche und jeweils einem Output zuweise.
Mit den anderen 4 würde dann nichts passieren, weil die nicht in die Funktionen kommen.
Zur Veranschaulichtung würde das dann so aussehen:
Die 18 outputs gehen dann alle in die Funktion Nodes jeweils.Alternativ könnte ich auch - statt mir die 18 rauszusuchen die ich möchte - die 4 raussuchen die ich NICHT möchte, und den Output dann nicht verwenden.
So:
Da würde dann output1-4 nichts machen, und output 5 hänge ich dann an die Funktion Nodes.
Aber ich nehme an das ist nicht gerade die beste Lösung? -
Ich liebe NR!
Es nervt bloß dass ich so viel Hilfe brauche und mich doof anstelle :D.
Meinem Spaß an NR tut das keinen Abbruch, im Gegenteil!Mit dem Trigger hat es nun geklappt, vielen Dank!
Bitte hasse mich nicht:
Nun müsste ich den Flow noch anpassen dass er mir nur die richtigen Sensoren beim aktualisieren liefert.
Hier zur Veranschaulichung:
Der obere Teil - also da wo die Aktualisierungen kommen - liefert mir Daten von 22 Sensoren. 18 die ich will, 2 Sensoren die nicht Konfiguriert sind, und 2 Motion Sensoren die dummerweiße auch einen Temp Sensor haben...
Der untere Teil, also da wo ich die Namen auslesen, spuckt eigentlich 32 Sensoren aus (weil 32 Zigbee Devices).
Über die Switch Node hole ich mir die 18 die ich brauche (haben alle "Multisensor" im Namen) raus.
Das klappt.
Nun muss ich den oberen Teil so anpassen, dass ich auch nur die Daten von den 18 Sensoren bekomme.
Ansonsten habe ich 4 Einträge in der Tabelle, die keinen Namen haben (von den unkonfigurierten und von den motion sensoren).Was ich tun würde:
Mit einer Switch Node VOR den Function Nodes checken ob das was ich bekomme ein bestimmtes Topic hat (die IDs von den Sensoren). Sprich: 18 Outputs, wo ich die 18 die ich brauche raussuche und jeweils einem Output zuweise.
Mit den anderen 4 würde dann nichts passieren, weil die nicht in die Funktionen kommen.
Zur Veranschaulichtung würde das dann so aussehen:
Die 18 outputs gehen dann alle in die Funktion Nodes jeweils.Alternativ könnte ich auch - statt mir die 18 rauszusuchen die ich möchte - die 4 raussuchen die ich NICHT möchte, und den Output dann nicht verwenden.
So:
Da würde dann output1-4 nichts machen, und output 5 hänge ich dann an die Funktion Nodes.
Aber ich nehme an das ist nicht gerade die beste Lösung?@schmetterfliege Warte halt mal - ich bin ja schon dabei - was als Lösung vorzuschlagen. Das heißt mit den Namen sind nur die gewünschten Sensoren vorselektiert und Du willst nur, dass diese dann auch trigger und in die Tabelle schreiben? - Habe ich hoffentlich so richtig verstanden.
-
@schmetterfliege Warte halt mal - ich bin ja schon dabei - was als Lösung vorzuschlagen. Das heißt mit den Namen sind nur die gewünschten Sensoren vorselektiert und Du willst nur, dass diese dann auch trigger und in die Tabelle schreiben? - Habe ich hoffentlich so richtig verstanden.
Genau.
Durch den Part der die Werte aktualisiert bekomme ich aber 4 zusätzliche, die dann ebenfalls in der Tabelle landen:
Hier ganz unten - da sind schon 2 von 4. Die sollen da nicht landen.
Wenn die 4 gar nicht erst reinkommen, könnte ich die JOIN Node auch wieder auf 18 begrenzen - da ja dann immer die gleichen 18 reinkommen. Aktuell muss ich das auf 22 lassen, weil sonst die 4 doofen Sensoren die eigentlichen Sensoren aus der Tabelle schmeißen^^ -
Genau.
Durch den Part der die Werte aktualisiert bekomme ich aber 4 zusätzliche, die dann ebenfalls in der Tabelle landen:
Hier ganz unten - da sind schon 2 von 4. Die sollen da nicht landen.
Wenn die 4 gar nicht erst reinkommen, könnte ich die JOIN Node auch wieder auf 18 begrenzen - da ja dann immer die gleichen 18 reinkommen. Aktuell muss ich das auf 22 lassen, weil sonst die 4 doofen Sensoren die eigentlichen Sensoren aus der Tabelle schmeißen^^@schmetterfliege So diese Node zwischen die Change und die Function Node - filtert alle unebkannten IDs aus:
-
@schmetterfliege So diese Node zwischen die Change und die Function Node - filtert alle unebkannten IDs aus:
-
Danke!
Verständnisfrage:
Sind die "Namen" der Objekte (rechts zu sehen) Topics? (also in dem Beispiel: ist 00158d... das "topic"?)@schmetterfliege Na was machen wir denn hier?
So fügt sich zusammen, was zusammengehört. ;)
Und das topic hole ich doch davor aus dem Pfad raus:
-
@schmetterfliege Na was machen wir denn hier?
So fügt sich zusammen, was zusammengehört. ;)
Und das topic hole ich doch davor aus dem Pfad raus:
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Na was machen wir denn hier?
So fügt sich zusammen, was zusammengehört. ;)
EDIT: Moment, muss doch nochmal kurz nachdenken.
Also:
In den Funktionen definieren wir die FlowVariablen. Das is klar.
Dass wir die anhand der Topics die wir übergeben bekommen setzen, ist soweit auch klar.
Nur: in dem Moment wo sie dann als FlowVariable gesetzt sind, ist der "Name" den jedes Object hat ein Topic?Gegenbeispiel: Wenn ich der Funktion die ID nicht per msg.topic, sondern als msg.id gebe (weil die über msg.id reinkommt statt msg.topic), dann erhalte ich doch ebenso die FlowVariable mit den richtigen "Werten".
Würde man dann in der Switch Node statt "topic" -> "id" nutzen, oder weiterhin topic?
Das ist nämlich der Kern meiner Frage:
ist die Definition hiervon ein TOPIC:
Sind das alles Topic per Definition oder weil wir in der Funktion Node den Namen per "msg.topic" gesetzt haben? (was für mich persönlich kein Sinn ergeben würde) -
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Na was machen wir denn hier?
So fügt sich zusammen, was zusammengehört. ;)
EDIT: Moment, muss doch nochmal kurz nachdenken.
Also:
In den Funktionen definieren wir die FlowVariablen. Das is klar.
Dass wir die anhand der Topics die wir übergeben bekommen setzen, ist soweit auch klar.
Nur: in dem Moment wo sie dann als FlowVariable gesetzt sind, ist der "Name" den jedes Object hat ein Topic?Gegenbeispiel: Wenn ich der Funktion die ID nicht per msg.topic, sondern als msg.id gebe (weil die über msg.id reinkommt statt msg.topic), dann erhalte ich doch ebenso die FlowVariable mit den richtigen "Werten".
Würde man dann in der Switch Node statt "topic" -> "id" nutzen, oder weiterhin topic?
Das ist nämlich der Kern meiner Frage: ist die Definition hiervon ein TOPIC:
Sind das alles Topic per Definition oder weil wir in der Funktion Node den Namen per "msg.topic" gesetzt haben? (was für mich persönlich kein Sinn ergeben würde)@schmetterfliege Kannst ja testen - Du kannst ja 2 Inject Nodew davor plazieren mit einem msg.topic und einer bekannten und unbekannten ID. Es sollte nur die mit der bekannten ID durchgelassen werden. Mach am Besten einfach eine Kopie der Switch Node damit kannst testen.
-
@schmetterfliege Kannst ja testen - Du kannst ja 2 Inject Nodew davor plazieren mit einem msg.topic und einer bekannten und unbekannten ID. Es sollte nur die mit der bekannten ID durchgelassen werden. Mach am Besten einfach eine Kopie der Switch Node damit kannst testen.
Dass es funktioniert glaube ich ja, ich möchte nur verstehen nach was genau wir da Filtern^^
Also was dieses "topic" ist. -
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Na was machen wir denn hier?
So fügt sich zusammen, was zusammengehört. ;)
EDIT: Moment, muss doch nochmal kurz nachdenken.
Also:
In den Funktionen definieren wir die FlowVariablen. Das is klar.
Dass wir die anhand der Topics die wir übergeben bekommen setzen, ist soweit auch klar.
Nur: in dem Moment wo sie dann als FlowVariable gesetzt sind, ist der "Name" den jedes Object hat ein Topic?Gegenbeispiel: Wenn ich der Funktion die ID nicht per msg.topic, sondern als msg.id gebe (weil die über msg.id reinkommt statt msg.topic), dann erhalte ich doch ebenso die FlowVariable mit den richtigen "Werten".
Würde man dann in der Switch Node statt "topic" -> "id" nutzen, oder weiterhin topic?
Das ist nämlich der Kern meiner Frage: ist die Definition hiervon ein TOPIC:
Sind das alles Topic per Definition oder weil wir in der Funktion Node den Namen per "msg.topic" gesetzt haben? (was für mich persönlich kein Sinn ergeben würde)Also die Flow variable ist ein Objekt. Dieses Objekt besteht aus Eigenschaften die wiederum ein Objekte sind.
Das Objekt der Flow variable heißt zigbee.
Das Objekt der nun Eigenschaften die ich so benennen wie das msg.topic. Das ist das A und O - die id - spielt nur für die Tabelle eine Rolle für uns nicht.
Im Prinzip interessiert uns wie das Objekt aussieht überhaupt nicht - wir benennen die Eigenschaften des Objektes immer nach dem msg.topic - und somit bleibt auch die Zuordnung immer korrekt:
Auch beim Setzen der Namen interessiert mich der Inhalt - der Wert der Eigenschaft überhaupt nicht, sondern es wird nur die Zuordnung über das msg.topic gesetzt
Die Eigenschaften im zigbee Objekt stammen also alle aus der msg.topic und nur die ist interessant für die Zuordung und Identifikation:
Nun liest Du mit der JSONATA das Objekt aus - wichtig ist hier die lookup Funktion:
Sprich da ich ja vorher die Eigenschaften alle mit msg.topic festgelegt habe, kann ich natürlich auch mit lookup suchen, ob das Wert existiert.
Die Switch Node prüft also ob es im Objekt zigbee eine Eigenschaft "00158d0003f13adf" gibt - falls ja wird das Objekt zurückgeliefert - also am Anfang nur : { "name" : " Gerät Büro"}. Das interessiert uns aber nicht. Deswegen rufe ich mit Exists nur auf - ob lookup ein Objekt zurückliefert oder nicht. Falls true - lässt er die Originalnachricht durch. Ansonsten wird undefined anstelle eines Objektes zurückgegeben und exists liefert false und die Nachricht wird blockiert.
Fertig - viel genauer kann ich es eingentlich nicht mehr erklären.
-
Also die Flow variable ist ein Objekt. Dieses Objekt besteht aus Eigenschaften die wiederum ein Objekte sind.
Das Objekt der Flow variable heißt zigbee.
Das Objekt der nun Eigenschaften die ich so benennen wie das msg.topic. Das ist das A und O - die id - spielt nur für die Tabelle eine Rolle für uns nicht.
Im Prinzip interessiert uns wie das Objekt aussieht überhaupt nicht - wir benennen die Eigenschaften des Objektes immer nach dem msg.topic - und somit bleibt auch die Zuordnung immer korrekt:
Auch beim Setzen der Namen interessiert mich der Inhalt - der Wert der Eigenschaft überhaupt nicht, sondern es wird nur die Zuordnung über das msg.topic gesetzt
Die Eigenschaften im zigbee Objekt stammen also alle aus der msg.topic und nur die ist interessant für die Zuordung und Identifikation:
Nun liest Du mit der JSONATA das Objekt aus - wichtig ist hier die lookup Funktion:
Sprich da ich ja vorher die Eigenschaften alle mit msg.topic festgelegt habe, kann ich natürlich auch mit lookup suchen, ob das Wert existiert.
Die Switch Node prüft also ob es im Objekt zigbee eine Eigenschaft "00158d0003f13adf" gibt - falls ja wird das Objekt zurückgeliefert - also am Anfang nur : { "name" : " Gerät Büro"}. Das interessiert uns aber nicht. Deswegen rufe ich mit Exists nur auf - ob lookup ein Objekt zurückliefert oder nicht. Falls true - lässt er die Originalnachricht durch. Ansonsten wird undefined anstelle eines Objektes zurückgegeben und exists liefert false und die Nachricht wird blockiert.
Fertig - viel genauer kann ich es eingentlich nicht mehr erklären.
@mickym
Lass dich nicht unterbrechen - ich werfe nur die Zwischenfrage ein weil die Bilder nur im Zwischenspeicher sind^^Wenn ich die Variable nun nicht über Topic, sondern "bla" setze - weil das was ich will nicht über msg.topic rein kommt sondern über msg.bla:
Würde die switch Node dann so aussehen:
Oder würde ich in der Switch Node trotzdem topic benutzen?Oder kann ich in der Funktion die Variable gar nicht erst basteln wenn ich statt "msg.topic" einfach "msg.bla" nehme?
-
@mickym
Lass dich nicht unterbrechen - ich werfe nur die Zwischenfrage ein weil die Bilder nur im Zwischenspeicher sind^^Wenn ich die Variable nun nicht über Topic, sondern "bla" setze - weil das was ich will nicht über msg.topic rein kommt sondern über msg.bla:
Würde die switch Node dann so aussehen:
Oder würde ich in der Switch Node trotzdem topic benutzen?Oder kann ich in der Funktion die Variable gar nicht erst basteln wenn ich statt "msg.topic" einfach "msg.bla" nehme?
@schmetterfliege richtig - in den function Nodes musst Du immer msg. angeben - in JSONATA braucht es nur die Eigenschaft im msg.Objekt.
Du müsstest halt in Deinem Beispiel beides Mal in msg.bla den Wert haben. Im Prinzip ist das ja egal. Im Prinzip ist der Vergleich im JSONATA
$exists($lookup($flowContext('zigbee'), '00158d0003f13adf'))
durch was der Wert nachdem geschaut hat verglichen wird ist also wurscht.
Ich kann das also mit msg.bla setzen und mit msg.topic, msg.xxx oder was auch immer abfragen - das sind doch alles nur Variablen, die zur Laufzeit gesetzt werden. Die Switch Node interessiert doch nicht durch was der Eigenschaftsname gesetzt wurde - ich gebe nur an mit was verglichen werden soll. Es bietet sich halt nur an die gleiche msg.Eigenschaft zu nehmen da ich diese ja sowohl zum Schreiben und Lesen genutzt habe. Wie gesagt es wird zur Laufzeit ja mit den Inhalten verglichen und das sind ja alles einzelne Nachrichten.
-
@schmetterfliege richtig - in den function Nodes musst Du immer msg. angeben - in JSONATA braucht es nur die Eigenschaft im msg.Objekt.
Du müsstest halt in Deinem Beispiel beides Mal in msg.bla den Wert haben. Im Prinzip ist das ja egal. Im Prinzip ist der Vergleich im JSONATA
$exists($lookup($flowContext('zigbee'), '00158d0003f13adf'))
durch was der Wert nachdem geschaut hat verglichen wird ist also wurscht.
Ich kann das also mit msg.bla setzen und mit msg.topic, msg.xxx oder was auch immer abfragen - das sind doch alles nur Variablen, die zur Laufzeit gesetzt werden. Die Switch Node interessiert doch nicht durch was der Eigenschaftsname gesetzt wurde - ich gebe nur an mit was verglichen werden soll. Es bietet sich halt nur an die gleiche msg.Eigenschaft zu nehmen da ich diese ja sowohl zum Schreiben und Lesen genutzt habe. Wie gesagt es wird zur Laufzeit ja mit den Inhalten verglichen und das sind ja alles einzelne Nachrichten.
Okay, ich glaube ich habe gerade den großes Durchbruch^^
In der Switch Node bezieht sich das "topic" NICHT auf das was im Flow steht, sondern das, was von der vorherigen Switch Node übergeben wird!
Also wenn die "change: 2 Regeln" Node statt msg.topic ein msg.blubb weitergeben würde, würde ich im JSONATA auch nach "blubb" statt "topic" suchen.Ich bin die ganze Zeit davon ausgegangen dass sich "topic" auf das was im Flow steht bezieht, und nicht auf das was die Switchnode als Input bekommt - ich schäme mich grade ernsthaft
-
Okay, ich glaube ich habe gerade den großes Durchbruch^^
In der Switch Node bezieht sich das "topic" NICHT auf das was im Flow steht, sondern das, was von der vorherigen Switch Node übergeben wird!
Also wenn die "change: 2 Regeln" Node statt msg.topic ein msg.blubb weitergeben würde, würde ich im JSONATA auch nach "blubb" statt "topic" suchen.Ich bin die ganze Zeit davon ausgegangen dass sich "topic" auf das was im Flow steht bezieht, und nicht auf das was die Switchnode als Input bekommt - ich schäme mich grade ernsthaft
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Okay, ich glaube ich habe gerade den großes Durchbruch^^
In der Switch Node bezieht sich das "topic" NICHT auf das was im Flow steht, sondern das, was von der vorherigen Switch Node übergeben wird!Der Kandidat hat 100 Punkte.
Also wenn die "change: 2 Regeln" Node statt msg.topic ein msg.blubb weitergeben würde, würde ich im JSONATA auch nach "blubb" statt "topic" suchen.
Genau kannst ja einfach testen - in dem Du in der Change Node nochmal msg.blubb auf msg.topic setzt und dann in der switch node blubb schreibst!!!!
Ich bin die ganze Zeit davon ausgegangen dass sich "topic" auf das was im Flow steht bezieht, und nicht auf das was die Switchnode als Input bekommt - ich schäme mich grade ernsthaft
Node Red ist so schön logisch - stell Dir vor Du bist eine Nachricht und wanderst von Node zu Node - bis zur Function Node bzw. Switch NOde - ist alles was im Flow Kontext steht völlig unbekannt. ;) Erst in der Switch Node - im JSONATA referenziere ich ja mit dem flowContext("zigbee") auf den entsprechenden Flow Kontext. Das was Du duchgestrichen hast ist nicht das topic - aber das was das lookup macht. Also insofern wird schon nachgeschaut ob das topic aus der vorangegangenen Change Node mit einer Eigenschaft des Zigbee Objektes übereinstimmt (sprich macht $lookup)
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Okay, ich glaube ich habe gerade den großes Durchbruch^^
In der Switch Node bezieht sich das "topic" NICHT auf das was im Flow steht, sondern das, was von der vorherigen Switch Node übergeben wird!Der Kandidat hat 100 Punkte.
Also wenn die "change: 2 Regeln" Node statt msg.topic ein msg.blubb weitergeben würde, würde ich im JSONATA auch nach "blubb" statt "topic" suchen.
Genau kannst ja einfach testen - in dem Du in der Change Node nochmal msg.blubb auf msg.topic setzt und dann in der switch node blubb schreibst!!!!
Ich bin die ganze Zeit davon ausgegangen dass sich "topic" auf das was im Flow steht bezieht, und nicht auf das was die Switchnode als Input bekommt - ich schäme mich grade ernsthaft
Node Red ist so schön logisch - stell Dir vor Du bist eine Nachricht und wanderst von Node zu Node - bis zur Function Node bzw. Switch NOde - ist alles was im Flow Kontext steht völlig unbekannt. ;) Erst in der Switch Node - im JSONATA referenziere ich ja mit dem flowContext("zigbee") auf den entsprechenden Flow Kontext. Das was Du duchgestrichen hast ist nicht das topic - aber das was das lookup macht. Also insofern wird schon nachgeschaut ob das topic aus der vorangegangenen Change Node mit einer Eigenschaft des Zigbee Objektes übereinstimmt (sprich macht $lookup)
Jap, da war wieder genau das Problem was ich schon die ganze Zeit habe:
Das Grundprinzip verstehe und kenne ich, sobald aber was neues kommt verkompliziere ich es für mich und denke überhaupt gar nicht mehr über die Basics nach - die mir sofort hätten sagen müssen dass sich das topic auf den Input der anderen Change Node bezieht.War eine lange Woche^^
-
Jap, da war wieder genau das Problem was ich schon die ganze Zeit habe:
Das Grundprinzip verstehe und kenne ich, sobald aber was neues kommt verkompliziere ich es für mich und denke überhaupt gar nicht mehr über die Basics nach - die mir sofort hätten sagen müssen dass sich das topic auf den Input der anderen Change Node bezieht.War eine lange Woche^^
@schmetterfliege Na Hauptsache es funktioniert nun so, wie Du willst - Es ist ja wichtig, dass Du lernst selbst Lösungen zu entwickeln. ;) Im Prinzip war Dein Ansatz ja nicht verkehrt alle bekannten IDs zu durchsuchen, wobei da gibts auch einen einfacheren Trick mit RegEx. Sobald man sich bisschen mit den Werkzeugen vertraut macht - stellt man halt fest, dass es viel einfacher Lösungen gibt.
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.
-
@schmetterfliege Na Hauptsache es funktioniert nun so, wie Du willst - Es ist ja wichtig, dass Du lernst selbst Lösungen zu entwickeln. ;) Im Prinzip war Dein Ansatz ja nicht verkehrt alle bekannten IDs zu durchsuchen, wobei da gibts auch einen einfacheren Trick mit RegEx. Sobald man sich bisschen mit den Werkzeugen vertraut macht - stellt man halt fest, dass es viel einfacher Lösungen gibt.
@mickym Wenn Du zum Beispiel nur bestimmte Textwerte (also nicht nur EINEN durchlassen willst) - kannst Du eine Switch Node mit RegEx wie folgt nutzen:
Damit wird ein payload nur durchgelassen wenn sie Schnee oder Regen ist.
In Deinem Fall hättest Du nun auch alles zigbee IDs so erfassen können.
Ich habe sowas auch immer in einem eigenen Testflow - weil ich es auch oft vergesse, wie was möglich ist:
Eine weitere Möglichkeit ist ein Array mit gültigen Werten und eine Überprüfung in einer Change Node:
Oben definiert man also ein Array mit gültigen Werten, die man unten wieder löscht. In der Mitte wird überprüft, ob die payload in den gültigen Werten enthalten ist. Du siehst die Möglichkeiten sind mannigfaltig.
-
JSON/JSONATA/RegEx sind definitv ein Thema, bei dem ich mich wirklich mal hinsetzen muss und mir das dann ins Gedächtnis einspeichern muss. Denn dass sind echt mächtige Werkzeuge, die (nicht nur hier) wirklich unzählige Möglichkeiten bieten!
752
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge