NEWS
Vergleich von zwei Eingangswerten um Wert festzulegen
-
@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.
-
@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.
-
@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. ;-(
-
@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. :):+1: :+1: :+1:
-
@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. :):+1: :+1: :+1:
@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 ;-)
-
@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:
-
@frankyboy73 sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
@rewenode Danke, ich glaube es wird klarer. Also wäre hier $i im Prinzip der Name der Nachricht und $j der jeweilige Wert.
Und mit $i or $j sage ich ist eine der Nachrichten true (bzw. nicht null) ist die Bedingung erfüllt. Bei „and“ dann $i and $j , sind alle Nachrichten True (bzw. nicht null) dann ist die Bedingung erfüllt.
Geht das auch umgekehrt? Also wenn alle Nachrichten false bzw. Null sind, dann ist die Bedingung erfüllt?Edit: Ok, ich hab da wohl doch noch nen Denkfehler, was i und j sind. Ich lese mich da wohl mal erst etwas ein.
In der Doku : https://docs.jsonata.org/higher-order-functions
Siehst Du das immer einfach der letzte mit dem vorletzen Element genutzt werden. In der Doku werden also 1. mit 0. Zahl multipliziert, dann 2. mit 1. Zahl, dann 3. Zahl mit Produkt aus 1 und 2. Zahl.
Geht das auch umgekehrt? Also wenn alle Nachrichten false bzw. Null sind, dann ist die Bedingung erfüllt
Das machst Du mit der Funktion, die auf einen Wert reduziert:
Für dieses Reduce definierst Du ja eine eigene Funktion:
( $withAND := function($i, $j){$i and $j}; $reduce( $each( payload, function($v) {$not($v)} ), $withAND ) )Du musst halt die Eingabe verneinen. Wobei ich wohl dann besser eine ODER Node verwenden würde und einfach das Ergebnis verneinen. Das wäre logischer.
Im Übrigen gibt es diese Reduce Funktion auch in der JOIN Node - das habe ich neulich ausprobiert. ;)
So hier mal die Reduce Funktion in der JOIN Node - funktioniert ähnlich wie die reduce Funktion in JSONATA - es wird immer mit dem Vorgänger verknüpft:
Hier mal die AND Node - dass alles true sein muss:
Eigentlich ist das auch schon kurz ;) - Insofern könnte man das auch anstelle JSONATA und der UND nutzen: ;)
Mit dieser Funktion der JOIN Node hat es auch gebraucht bis ich das kapiert habe - macht aber nichts anderes als die reduce Funktion unter JSONATA:
Hier mal mit dem Hilfetext der JOIN - Node - damit man das gleich vergleichen kann.
Das heißt die JSONATA Eingabe:
$A and payloadentspricht dem Funktionsaufruf der reduce Funktion in JSONATA.
@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. :grinning:
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.Schöne Grüße Frank
-
@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. :grinning:
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
-
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.
Schöne Grüße Frank
-
@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. -
@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.
-
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 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:
-
@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. :grinning:
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.@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:
-
@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.Schöne Grüße Frank
-
@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. :+1: :+1: :+1: - 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.
-
@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. :+1: :+1: :+1: - 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.
@mickym
& Wenn ich 3 True eingänge durchlassen möchte wenn erst alle anliegen? (ggf. auch bei false)
Also wenn alle 3 Trues anliegen lässt er einen True durch
Bei 3 false liegt false an
Hier geht es um den bewegungsmelder der erst auf EIN geschalten werden kann in der "Vis" wenn alle lampen AUS sind.
Der Bewegungsmelder dann auch AUS schaltet wenn eine lampe schon an ist.... sodass der Bewegungsmelder nicht funktioniert wenn eine Lampe per hand geschalten wurde
Ich hoffe das ist verständlich es zu verstehen .. :PSo sieht das ca aus
-
@mickym
& Wenn ich 3 True eingänge durchlassen möchte wenn erst alle anliegen? (ggf. auch bei false)
Also wenn alle 3 Trues anliegen lässt er einen True durch
Bei 3 false liegt false an
Hier geht es um den bewegungsmelder der erst auf EIN geschalten werden kann in der "Vis" wenn alle lampen AUS sind.
Der Bewegungsmelder dann auch AUS schaltet wenn eine lampe schon an ist.... sodass der Bewegungsmelder nicht funktioniert wenn eine Lampe per hand geschalten wurde
Ich hoffe das ist verständlich es zu verstehen .. :PSo sieht das ca aus
Support us
822
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge