NEWS
Vergleich von zwei Eingangswerten um Wert festzulegen
-
@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
893
Online32.5k
Benutzer81.9k
Themen1.3m
Beiträge