Vergleich von zwei Eingangswerten um Wert festzulegen
-
@rewenode sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
@mickym Nop. Aber schaden tut's auch nicht
PS. der $each() geht nicht durch ein array, sondern durch ein objekt. Und da der $reduce() ein array benötigt, nimmst du den $each(), weil der ein array draus macht.
Die eigentliche Arbeit macht sowieso der $reduce()Da hast Du natürlich Recht - ich muss mal schauen, ob mit Deiner Syntax eventuell diese Fehlermeldung nicht auftaucht - während der Initialisierung:
oder definiere noch ein leeres Objekt:
node-red.0 2021-12-01 00:38:48.406 error 1 Dec 00:38:48 - [error] [change:AND ?] Ungültiger JSONata Ausdruck: Argument 1 of function "each" does not match function signature1 Dec 00:38:48 - [error] [change:AND ?] Ungültiger JSONata Ausdruck: Argument 1 of function "each" does not match function signature node-red.0 2021-12-01 00:38:48.403 error 1 Dec 00:38:48 - [error] [change:AND ?] Ungültiger JSONata Ausdruck: Argument 1 of function "each" does not match function signature node-red.0 2021-12-01 00:38:48.401 error 1 Dec 00:38:48 - [error] [change:AND ?] Ungültiger JSONata Ausdruck: Argument 1 of function "each" does not match function signature node-red.0 2021-12-01 00:38:48.400 error 1 Dec 00:38:48 - [error] [change:AND ?] Ungültiger JSONata Ausdruck: Argument 1 of function "each" does not match function signature node-red.0 2021-12-01 00:38:48.396 error 1 Dec 00:38:48 - [error] [change:AND ?] Ungültiger JSONata Ausdruck: Argument 1 of function "each" does not match function signature node-red.0 2021-12-01 00:38:48.392 error 1 Dec 00:38:48 - [error] [change:AND ?] Ungültiger JSONata Ausdruck: Argument 1 of function "each" does not match function signatureHabs gerade ausprobiert - Deine Syntax ist besser:
Es wird kein Error erzeugt, sondern ein undefined - was OK ist.
-
@mickym Habe lange Zeit nichts mehr mit NR und ioB gemacht. Weil never change..
Bin echt beeindruckt, was ihr da inzwischen so zaubert! Und ich kenne nicht mal alle neuen nodes
Da kommt mir der tread grade recht
So, genug gelabert. -
@rewenode Eine Frage habe ich noch.
Wenn ich das reduce mit payload.* übergebe, dann habe ich halt keine Möglichkeit die Werte noch zu verändern, so wie ich das hier gemacht habe:
( $withAND := function($i, $j){$i and $j}; $reduce( $each( payload, function($v) {$not($v)} ), $withAND ) )also bei Umwandlung der Objekteigenschaften in das Array noch Einfluß zu nehmen. Im Prinzip müsste ich im Vorfeld noch eine Typprüfung vornehmen und ggf. ein leeres Objekt übergeben.
Also wenn man das übergebene Array noch manipulieren will, kann mit einer Typ-Prüfung den Fehler noch abfangen und ein leeres Objekt übergeben:
( $withAND := function($i, $j){$i and $j}; $reduce( $each( $type(payload) = 'object' ? payload : {}, function($v) {$not($v)} ), $withAND ); )anders bekomme ich es nicht hin.
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Im Prinzip müsste ich im Vorfeld noch eine Typprüfung vornehmen und ggf. ein leeres Objekt übergeben.
Kommt darauf an, was genau du machen willst. Hast du ein Object und du willst z.B. das Array für den $reduce() aus eigenen Elementen erstellen/berechen, dann nimmst du z.B. den $each(). Dabei meine ich nicht, dass du die key/value Paare des Objektes filtern mußt, das geht einfacher.
Willst du hingegen die Array-Werte manipulieren, bevor der $reduce() drüberläuft, kannst du das entweder vorher mit der $map() Funktion machen.
Willst du z.B. alle Elemente des Array vorher negieren und somit das Ergebnis, kannst du das nehmen.$reduce( $map(*,function($v){$not($v)}), function($i, $j){($i or $j)} )Allerdings kannst du das ganz bequem auch in der function vom $reduce() machen, der läuft ja sowieso über alle Elemente des array.
Aaaber, dabei kann es Probleme geben. Im Beispiel mit dem or würde es Probleme geben, weil der erste Wert ja direkt im $i landet, bevor er negiert werden kann.
Deshalb kennt der $reduce() den Startwert, den du zusätzlich übergeben kannst.$reduce(payload.*, function($i, $j){($i or $not($j))}, false)Dieser $reduce() macht also genau das selbe, wobei die Negation direkt in der function erfolgt.
Natürlich kann man in diesem simplen or-Beispiel gleich das Ergebnis negieren, was aufs Selbe hinaus läuft.
$not($reduce(*,function($i, $j){($i or ($j))}))Aber das Beispiel sollte ja auch nur zeigen, dass man eigentlich alle Manipulationen an den Array-Werten auch direkt in der $reduce()-function machen kann.
-
@rewenode OK - das muss ich mir mal ansehen, wenn ich noch mehr geistige Kapazitäten hatte.
Soweit war ich
$reduce(payload.*, function($i, $j){$i or $not($j)}, false)Warum nochmal die Klammer was bringen soll? - Verstehe ich nicht.
Aber nach meinen Test funktioniert auch Deine beiden Varianten nicht.$reduce( $map(*,function($v){$not($v)}), function($i, $j){($i or $j)} )als auch
$reduce(payload.*, function($i, $j){($i or $not($j))}, false)liefert grundsätzlich true, auch wenn eine Eigenschaft true ist. Es soll ja nur true werden, wenn alle false sind. Es geht ja um die Manipulation des arrays (also vor Übergabe an die reduce Funktion).
sowohl{ "Büro Balkon": true, "Schlafzimmer Balkon": false, "Wohnzimmer Balkon": false, "Wohnzimmer rechtes Fenster": false, "Wohnzimmer linkes Fenster": false }liefert aber auch true - was ja nicht der Fall sein dürfte.
Das ODER einfach negieren - habe ich schon vorgeschlagen, da scheint bei Dir aber irgendwie ein Fehler in der letzten Zeile irgendwie vorzuliegen:
Ich habe es so und damit geht es:
$not($reduce(payload.*,function($i, $j){$i or $j}))===================================================================
So mit dem map geht es - da es aber umgedreht wird muss man eine logische AND Verknüpfung machen:
$reduce( $map(payload.*,function($v){$not($v)}), function($i, $j){$i and $j} )bei der anderen Version funktioniert es nicht.
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Es soll ja nur true werden, wenn alle false sind
Ja, da mußt du ein and nehmen. Wenn du jeden Array Wert negierst, heißt das ja, dass nur true rauskommen soll wenn alle true (weil negiert) sind. Und das ist eine einfache UND-Verknüpfung.
$reduce(payload.*, function($i, $j){$i and $not($j)})Oder halt das Ergebnis des OR negieren wie du es jetzt gemacht hast.
-
@rewenode sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
$reduce(payload.*, function($i, $j){$i and $not($j)})
Das tut nicht - kommt false raus, wenn alles false ist und true, wenn alle false aber einer true. Ich meine mit dem Mapping geht es ja.
Ist aber egal - mit dem maping geht es und mit dem map erzeugt ein Nicht-Objekt zumindest kein Error - sondern ein undefined. Die Funktionen die einen Fehler erzeugen oder nicht, sind da wohl sehr unterschiedlich. Wie gesagt mit dem mapping habe ich ja auch eine gute Lösung.
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Das tut nicht - kommt false raus, wenn alles false ist und true, wenn alle false aber einer true. Ich meine mit dem Mapping geht es ja.
Ja sorry, copy/paste Fehler. Habe den Start-Wert vergessen.
$reduce(payload.*, function($i, $j){$i and $not($j)}, true)Doch schon zu spät. Muss natürlich payload.* sein. ;-(
-
@rewenode sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
$reduce(payload.*, function($i, $j){$i and $not($j)}, true)
OK das tut - und der init- Wert ist quasi der 1.Wert mit dem $i quasi initialisiert ist.
Doch schon zu spät. Muss natürlich payload.* sein. ;-(
Das hatte ich schon korrigiert.
Dann bin ich auch schon auf die Lösung gekommen - hatte halt nur auch vergessen, dass ich alles mit logischem UND verknüpfen musste. Das heißt die Manipulation am Array kann man also über $j machen (bzw. dem 2. Parameter in der Funktion)
Danke Dir jedenfalls - habe doch noch zu früher Stunde einiges gelernt.
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Das heißt die Manipulation am Array kann man also über $j machen (bzw. dem 2. Parameter in der Funktion)
Ja. Beim Startwert (falls nötig) mußt du halt aufpassen.
Bei der AND Funktion muss der Start true sein, weil er den Gesamtwert dann nicht verändern kann, weil true AND irgendwas immer irgendwas ist.
Beim OR dann halt false.Die Falle mit dem * statt payload.* entsteht leicht, wenn man den test-Reiter in den nodes nimmt.
Als Testobjekt gibt man dann schnell mal sowas wie{ "Büro Balkon": false, "Schlafzimmer Balkon": false, "Wohnzimmer Balkon": false, "Wohnzimmer rechtes Fenster": false, "Wohnzimmer linkes Fenster": false }ein. Die Testfunktion weis natürlich nicht, dass das eigentlich das payload-Objekt sein soll, weshalb payload.* nicht klappt. Da nimmt man dann zum testen halt * . Und dann vergisst man den Ausdruck wieder auf payload.* zu ändern.
Besser man macht das Testobjekt gleich so:{ "payload": { "Büro Balkon": false, "Schlafzimmer Balkon": false, "Wohnzimmer Balkon": false, "Wohnzimmer rechtes Fenster": false, "Wohnzimmer linkes Fenster": false } }Dann klappt es auch wieder mit payload.*. Ein Fehler weniger
-
@rewenode Ja in dem Fenster kopiere ich immer das Objekt anstelle von "hello world" - jedenfalls habe ich heute wieder eine Menge mehr verstanden. Das wird wohl wieder mal ein Thread mit Lesezeichen.
So ich habe nun alle Node s (kommt nun auch kein Fehler wenn Objekte nicht initialisiert sind) - mit der kurzen Version versehen - ist also bei den logischen Nodes nur noch ein Einzeiler:
UND
$reduce(payload.*,function($i, $j){$i and $j})ODER
$reduce(payload.*,function($i, $j){$i or $j})Wer weitere optimierte JSONATA Switches und Change Nodes Beispiele ausprobieren will - hier ein Flow mit Beispielen:
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Wobei ich wohl dann besser eine ODER Node verwenden würde und einfach das Ergebnis verneinen. Das wäre logischer.
Oh mann, stimmt. Habe ich in dem moment gar nicht dran gedacht. Ist die Oder Bedingung nicht erfüllt, weil keine Nachricht true ist, sind ja alle false. Das nennt sich wohl Brett vorm Kopf.
Also wenn ich das jetzt nur per join Node erledigen will, müsste das für ein Oder so aussehen? Und die Menge der Nachrichten die ich mit der Join verarbeite wäre dann egal?
Wenn das so ist, schnalle ich es doch und es ist auch noch für mich nachvollziehbar. Hoffe das ist auch in ein paar Wochen noch in meinem Kopf drin.
Edit:
Hm, klappt leider doch nicht wie gedacht. Schalte ich eine Lampe ein kommt true raus, schalte ich ne andere Lampe aus kommt false raus, obwohl die andere Lampe noch an ist.
Ah, ok, habe gerade gesehen, das ich noch ne split Node brauche. Hm, dann ist für mich die frage split Node und Join Node oder wie ich es eh schon habe join Node und switch Node? Node Anzahl bleibt die gleiche, also was wäre der Vorteil mit split und join?
Muss ich mir mal anschauen, split Nodes habe ich bisher für so einen Fall noch nicht verwendet.
@mickym Bei mir ist es doch etwas anders als in deinem Beispiel. Du sendest per Injekt die komplette Nachricht oder Nachrichten. Bei mir ist es so das ich 5 Iobroker in Nodes habe, die nicht Zeitgleich senden, sondern jede einzelne Nachricht zu verschiedenen Zeitpunkten kommt. Je nach dem wann geschaltet wird. -
Habe nochmal eine Frage an Euch als Experten bzgl. einer Logik:
Ausgangslage:
Ich erhalte von Homekit Werte im Bereich hsv (Hue/Saturation/Brightness) und On/Off zum steuern einer Lampe.
Problem dabei ist, dass Homekit immer nur den sich ändernden Wert schickt (z.B. nur Brightness oder Hue oder eben On/Off).Problem:
Mein Empfängersystem benötigt im Ergebnis immer alle drei Werte also immer hsv.Idee:
Ich müsste also eine Art Zwischenspeicher schaffen, der sich immer den letzten Wert merkt und nur ersetzt falls sich der Wert ändert. Um beim Einschalten nicht auf der letzten Einstellung sondern beim Default zu landen wäre es zusätzlich wichtig, dass wenn sich On/Off ändert er die Werte hsv wieder auf einen fest vorgegebenen Wert zurück setzt.Ich hätte das rein instinktiv mit batch probiert, bin mir aber nicht sicher wie ich es hinbekomme, dass er sich die anderen Werte auch merkt und nicht dreimal einen geänderten Brightness Wert batcht..
Habt ihr da eine Idee wie ich das lösen könnte?
Danke und Gruß,
Claus
-
@claus1985-0 Hi, nur noch mal zum Verständniss. Du nutzt IObroker? Node Red läuft bei dir als Adapter im Iobroker? Du bekommst die Werte von Homekit per Adapter in den IObroker? Wenn das so ist, hast du ja die hsv Werte in den Datenpunkten (Objekten) im Iobroker, da sind sie ja im Prinzip schon gespeichert und kannst sie dann mit der IObroker Get Node in Node Red auslesen.
-
@frankyboy73 Leider nicht ganz. Ich habe es anfangs mit dem Adapter in ioBroker anbinden wollen. Die Doku ist für mich allerdings zu spärlich beschrieben so, dass ich damit die Hälfte meiner Funktionen nicht abbilden kann / nur per trial & error und enormem Zeitaufwand. Denn das Problem ist das der Adapter ganz spezifische Infos / Formate benötigt die ich so vom Loxone Adapter nicht bekomme.
Daher nutze ich ein Set an Homekit Nodes für node red (https://nrchkb.github.io/wiki/service/).
Die sind super dokumentiert und theoretisch kann ich damit alles abbilden was ich an Funktionen habe. Da arbeite ich mich nun Stückweise durch. -
@claus1985-0 Ok, du hast sonst noch die Möglichkeit Werte oder Zustände in flow Variablen oder globalen Variablen zu speichern. Flow Variablen kann man nur in der jeweilgen Flow Seite verwenden, Globale in allen Node Red Seiten. Dann kannst du sie später wieder in deinem Flow abfragen oder in die Nachricht einsetzen.
Das meine ich mit Flow Seiten.
Hier die Variable setzen
und dann wieder im flow verwenden
So im Prinzip könnte man Werte und Zustände speichern und wieder verwenden.
Mann müsste nun wissen wie deine Input Msg genau aussehen und was du ausgeben musst um dir genauer zu helfen.
@mickym kennt sich da noch besser aus.Da ich Node Red als Iobroker Adapter nutze speichere ich mir wichtige Zustände, die auch bei System neustart noch vorhanden sein sollen immer in selbst erstellten Datenpunkten im Iobroker ab und lese sie dann wieder per Iobroker in oder Iobroker Get aus.
-
@claus1985-0 Das geht alles mit einer JOIN Node. Wenn Du 3 verschiedene Topics hast werden alle Werte in einem Objekt gesammel und wenn Du direkt nach der 1. Antwort rausschicken willst. Der Rest ist wie Du es halt brauchst und musst halt ggf. selbst schicken - also initialisieren oder auf Standardwerte setzen.
Also wenn Du die Homekit Bridge Nodes schickst, musst Du nicht immer komplette Objekte schicken:
Mit einer split Node schreibst Du immer die Objekteigenschaft in das topic - das die JOIN Node nutzen kann.
Die Reset HSV InJect Nodes betätigst Du als erstes und kannst sie somit auch zur Initialisierung der JOIN Node nutzen. Hier also ein weiteres Beispiel wie man die Kombi split und join nutzen kann.
Grundsätzlich kannst Du dann natürlich wie @frankyboy73 sagte das Ganze in einer Flow Variable speichern und ggf. wo anders wieder verwenden.
Defaults setzt Du halt mit einem Objekt:
-
@frankyboy73 sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
@mickym Bei mir ist es doch etwas anders als in deinem Beispiel. Du sendest per Injekt die komplette Nachricht oder Nachrichten. Bei mir ist es so das ich 5 Iobroker in Nodes habe, die nicht Zeitgleich senden, sondern jede einzelne Nachricht zu verschiedenen Zeitpunkten kommt. Je nach dem wann geschaltet wird.
Nun dann sammelst Du die Nachrichten auch in einer JOIN Node - so mache ich generell meine Überwachung. Zum einen speichere ich das OBjekt mit den einzelnen Zuständen dann als JSON.
Hier mal meine Batterieüberwachung der Zigbeegeräte:
markiert habe ich die JOIN Node - die dann alle Zustände in einem JSON im iobroker abspeichert. Heute würde ich mit Wildcards mit iobroker in Nodes arbeiten - das ging bei mir damals aber nicht.
Das ganze sieht dann so aus:
{ "Präsenz Küche": true, "Thermometer Bad": true, "Präsenz Diele": true, "Thermometer Küche": true, "Präsenz Wohnzimmer Essbereich": true, "Präsenz Bad": true, "Würfel Wohnzimmer": true, "Präsenz Büro": true, "Präsenz Schlafzimmer": true, "Präsenz Flur": true, "Präsenz Wohnzimmer": true, "Würfel Schlafzimmer": true }Sobald sich dann ein Wert ändert wird mit dem Flow der String neu geschrieben, und triggert meine Auswertung.
Ich habe das Ganze zur Überwachung von Zuständen alles hier schon mal vorgestellt: https://forum.iobroker.net/topic/44765/gelöst-überwachung-eingeschaltete-verbraucher/7?_=1638381274770
Damals hatte ich statt der Auswertung mit JSONATA noch eine function Node gebastelt, die ich nun abgelöst habe.
Ah, ok, habe gerade gesehen, das ich noch ne split Node brauche. Hm, dann ist für mich die frage split Node und Join Node oder wie ich es eh schon habe join Node und switch Node? Node Anzahl bleibt die gleiche, also was wäre der Vorteil mit split und join?
Muss ich mir mal anschauen, split Nodes habe ich bisher für so einen Fall noch nicht verwendet.
Die Kombination split und join Node brauchst immer wenn Du ein vorhandenes Array oder Objekt analysieren oder modifizieren willst - dazu gibst den automatischen Mode der JOIN Nodes - da diese die msg.parts Informationen der split Node nutzt.
Neben der Reduktion (Du musst wie gesagt Deine 5 Punkte sammeln mit JOIN, dann split, dann JOIN mit Reduzierung).
Also sammeln, analysieren, ausgeben. Für den automatischen JOIN Modus - darfst Du nur keine Nodes aus dem split wegschmeissen - sonst blockiert der Flow - weil die JOIN Node auf Nachrichten wartet die nie kommen.Ein Beispiel wie man die Kombi Split-Join Node braucht ist also generell das Aufbrechen von Arrays oder Objekten, um etwas auszuwerten oder zu modifizieren:
-
@mickym Ok, danke, verstehe ich jetzt, denke ich.
Das heißt allerdings für meinen Fall, z.B. 5 Lampen im Wohnzimmer. Dash Board Button Hintergrund steuern. Ist mindestens eine Lampe an soll der Button Orange sein, sind alle Lampen aus soll der Button schwarz sein. Dann brauche ich ne Join, zum Sammeln, danach ne Split zum trennen und dann ne Join um das getrennte auszuwerten, danach ne Change um die Farben zu setzen.
Hab ich das so richtig verstanden?
Sorry, ich weiß das ist wahrscheinlich ein spezieller Fall.
Meine Umsetzung, ne Join zum Sammeln, ein Switch zum auswerten, ne Change zum Farben setzen.
Vielleicht sehe ich auch gerade den Wald vor lauter Bäumen nicht. Oder ich bin zu eingefahren auf meine Wege der Umsetzung.
Und Sorry an @Claus1985-0 das wir hier Deinen Post für unsere Diskusionsrunde missbrauchen. -
@frankyboy73 sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Das heißt allerdings für meinen Fall, z.B. 5 Lampen im Wohnzimmer. Dash Board Button Hintergrund steuern. Ist mindestens eine Lampe an soll der Button Orange sein, sind alle Lampen aus soll der Button schwarz sein. Dann brauche ich ne Join, zum Sammeln, danach ne Split zum trennen und dann ne Join um das getrennte auszuwerten, danach ne Change um die Farben zu setzen.
Perfekt.
- Der Kandidat hat 100% und mit summa cum laude bestanden. Hier einmal konventionell und mit meinen neuen JSONATA Nodes.
So funktioniert meine Lichtüberwachung übrigens auch in meiner Wohnung - also so ein außergewöhnlicher Fall ist das nicht.
Und in jedem Raum - habe ich meist mehr als eine Lampe.
Ich schreibs halt teilweise weg als JSON String - das kann man ggf. zur Initialisierung beim Flowneustart verwenden - aber das hat auch historische Gründe - habe ja in den 2 Jahren auch viel gelernt und würde heute einiges anders machen - aber Verbesserungen wird es immer geben.Wie gesagt - das ganze Überwachsungsthema - aber Schaltstatus oder Alarmzustände habe ich ja in dem unten zitierten Thread beschrieben.
