NEWS
Vergleich von zwei Eingangswerten um Wert festzulegen
-
@claus1985-0
Mit OneNote? Das kenn ich nur als Notizbuch von Microsoft.
Oder meintest Du doch NodeRed?Und falls Du NodeRed meinst, sind das Eingangswerte von NodeRed oder kommen die woanders her?
-
@claus1985-0
Hast du 1 und 0 als Nummer oder als Text?
Hier mal als Nummern. Da gibts wie immer viele Lösungsansätze.
Klassich kann man die beiden Eingangs Nodes als Trigger verwenden und dann die beiden Nodes abfragen, per Switch, sind beide 0 dann per Change auf 3 setzen.
Oder per Join Node, in deinem Fall, senden der Nachricht nach 2 Nachrichtenteilen, dann Abrage mit Switch ob einer 1 ist, oder sonst per Change auf 3 setzen.
Ist eine der Node auf 1 kannst du noch ne andere Ausgabe über den anderen Ausgang der Switch Node per Change generieren.
Bei der Join Node, müssen allerdings auch beide Eingänge mindestens ein mal was gesendet haben.
Sorry, musste noch mal editieren, irgendwie klappt heute die verbindung zum Forum nicht so richtig. -
@mickym ja genau meinte Node Red
Die Werte kommen von Loxone per Adapter in ioBroker an. Das hab ich per Node in Node Red eingebunden.
Ich verwende dazu zwei Control In Notes von Loxone. Der eine zeigt 0/1 (im Grunde true/false) für "Rolladen fährt gerade runter" und der zweite für "Rolladen fährt gerade hoch". In Homekit sind diese beiden Werte allerdings in einem Wert "PositionState" zusammengefasst der drei Zustände haben kann (Decreasing=0, Increasing=1 und Stopped=2).falsefrankyboy73
Vielen Dank für Deine Lösungsansätze! Leider hatte ich einen Denkfehler drin..
Die beiden Eingänge setzen immer dann 0 oder eins wenn der Rolladen etwas macht ansonsten kommt da nichts an.
Wenn ich also den Rolladen hoch fahren lasse, kommt eine Nachricht für "Rollanden fährt gerade hoch" mit Payload=1. Sobald der Rolladen sich nicht mehr bewegt kommt eine Nachricht mit 0. Genau das gleiche Prinzip auch bei Rolladen fährt gerade runter.Im Grunde genommen bräuchte ich also eine Logik die auf 2 springt, sobald von beiden Bausteinen je einmal die Nachricht 0 kam. Wenn dann einer der Eingänge auf 1 springt muss der Wert entweder 0 oder 1 haben bis der Eingang dann wieder auf 0 springt.
Hab glaube ich eine recht einfache Lösung gefunden:
[ { "id": "e5f902fb.6d7a1", "type": "change", "z": "f3f0ca0.5f2f538", "name": "1 zu 0", "rules": [ { "t": "change", "p": "payload", "pt": "msg", "from": "1", "fromt": "num", "to": "0", "tot": "num" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 350, "y": 200, "wires": [ [ "30a9685d.fa1428" ] ] }, { "id": "4202ff1.72b9d", "type": "switch", "z": "f3f0ca0.5f2f538", "name": "", "property": "payload", "propertyType": "msg", "rules": [ { "t": "eq", "v": "1", "vt": "num" }, { "t": "eq", "v": "0", "vt": "num" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 210, "y": 240, "wires": [ [ "e5f902fb.6d7a1" ], [ "b535d0ce.27bef" ] ] }, { "id": "b535d0ce.27bef", "type": "change", "z": "f3f0ca0.5f2f538", "name": "0 zu 2", "rules": [ { "t": "change", "p": "payload", "pt": "msg", "from": "0", "fromt": "num", "to": "2", "tot": "num" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 350, "y": 260, "wires": [ [ "30a9685d.fa1428" ] ] }, { "id": "dbf5a55a.0173e8", "type": "switch", "z": "f3f0ca0.5f2f538", "name": "", "property": "payload", "propertyType": "msg", "rules": [ { "t": "eq", "v": "0", "vt": "num" }, { "t": "eq", "v": "1", "vt": "num" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 210, "y": 300, "wires": [ [ "b535d0ce.27bef" ], [ "30a9685d.fa1428" ] ] } ]
Danke und Gruß,
Claus
-
@claus1985-0 Das wird nicht funktionieren - zum einen hast Du ja nun die gleiche Node als Eingang verwendet - und selbst wenn Du unterschiedliche Nodes nimmst, wird immer gerade die, die gerade 0 sendet eine 2 ausspuken und das random - da beide Nachrichten nicht gleichzeitig ausgewertet werden.
-
@mickym da hast Du leider recht, optimal ist die Lösung nicht. Das wird nur funktionieren, wenn der Rolladen "langsam" bedient wird. Also wenn schnell verschiedene Kommandos kommen passt es nicht mehr..
-
@claus1985-0 Ich bastel noch etwas - jedenfalls kannst Du es nur mit der von @frankyboy73 vorgeschlagenen JOIN Lösung machen, wobei man halt ggf. nochmal die Bedingungen prüft. Ich bastel auch gerade mal.
Im Prinzip sollte die Lösung von @frankyboy73 funktionieren, musst halt nur eine 2 anstelle einer 3 in die Change NOde machen. Was geht denn nicht?Du kannst den Zähler in der JOIN Node zur Initialisierung entweder auf 1 runter setzen oder Du initialisierst die Join-Node einmalig mit einer Inject Node.
So habe ich es nun aus Deiner Beschreibung verstanden:
Hab also erst hoch fahren lassen - dann stopp - dann runter fahren lassen - dann stop.
-
@frankyboy73 Na habe ich von Dir heute wieder was gelernt und das hat mich motiviert mal bisschen JSONATA in der Tiefe auszuprobieren.
Ich wußte gar nicht, dass das geht - komischerweise aber nur mit enthält - wenn ich mit == versuche zu vergleichen - dann tut es nicht.
Aber ich hab mich dann mit variablen Parameter mal JSONATA beschäftigt - sowohl im switch Node oder auch Change Node, wie man durch so ein Objekt sich durchhangelt. Wieder eine Möglichkeit sich von function Nodes zu verzichten. Allerdings ist die Performance etwas schlechter mit JSONATA - also mit Javascript.
Hier mal meine erfolgreichen JSONATA Switches - der letzte Flow - ist der gerade gepostete und der vorletzte war Deiner mit dem Wildcard und enthält.
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Ich wußte gar nicht, dass das geht - komischerweise aber nur mit enthält - wenn ich mit == versuche zu vergleichen - dann tut es nicht.
Der
payload.* (oder einfach $.*)
gibt nach dem Join ein Array mit 2 Werten zurück, das kannst du nicht mit einem Number vergleichen. Wohl aber fragen, ob ein bestimmter Wert enthalten ist.
Gruß
Reiner -
@mickym Vielen Dank für Deine Lösung, sieht elegant aus!
Aktuell hänge ich leider noch etwas am Join:Die beiden Eingangsnachrichten kommen zwar an aber aus Join kommt danach nichts raus.
Kann das daran liegen, dass die beiden Eingänge nicht gleichzeitig Nachrichten senden?Danke und Gruß,
Claus
-
@claus1985-0 sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Die beiden Eingangsnachrichten kommen zwar an aber aus Join kommt danach nichts raus.
Kann das daran liegen, dass die beiden Eingänge nicht gleichzeitig Nachrichten senden?Nun am Anfang wird abgewartet bis jede Nachricht gesendet wurde - es liegt eher daran, wenn ich mir Dein Log anschaue, dass beide Nodes das gleiche Topic haben. Somit kann die JOIN Node nicht unterscheiden, dass die Nachricht von 2 verschiedenen Nodes stammt. Setze mal zwischen die JOIN Node und den Loxone Teilen explizit das Topic. (Einmal hoch und einmal runter)
Den Haken in der JOIN Node ist ja gesetzt:
Sprich: die JOIN Node beginnt erst zu senden, wenn einmal beide Nodes mit unterschiedlichen Topics gesendet haben, dann aber sofort immer - also hat nichts mit gleichzeitig zu tun.
-
@rewenode sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Ich wußte gar nicht, dass das geht - komischerweise aber nur mit enthält - wenn ich mit == versuche zu vergleichen - dann tut es nicht.
Der
payload.* (oder einfach $.*)
gibt nach dem Join ein Array mit 2 Werten zurück, das kannst du nicht mit einem Number vergleichen. Wohl aber fragen, ob ein bestimmter Wert enthalten ist.
Gruß
ReinerHerzlichen Dank! - Schön, wenn Du mir auch immer wieder hilfst mit Deinem Wissen.
Im Prinzip wird also mit $* einfach so ein Array gebildet, dass ich mit dem $each nochmal auseinander fummle? und dann wohl für den Vergleich nur ein match ala regEx gemacht.
OK sehe ich - allerdings muss man es dann für die Vergleiche trotzdem auseinander fummeln.
$each( $.*, function($v) {$v=0 ? true: false} );
Insofern hilft mir die Schreibweise ja eigentlich nichts. Ob ich jetzt payload oder $.* schreibe, da ist dann payload beschreibender.
-
Habe meinen vorhergehenden Post überarbeitet. Die topics müssen zwingend hoch und runter heißen - da sonst ja der Flow nicht mehr passt.
Ansonsten musst Du halt alle Nodes an die neuen Topics anpassen.
So hier nochmal der komplette Flow - direkt zum Anflanschen der Loxone Nodes:
Mit aufgenommen wurde das Ausfiltern, dass beide Nodes 1 liefern:
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Ob ich jetzt payload oder $.* schreibe, da ist dann payload beschreibender.
Ja, da hast du recht. $ steht in JSONata für das komplette Eingabedocument (siehe ganz unten)
In Node-Red steht das $ dann für das, dem JSONata-Ausdruck, vorgesetzte Eingabeobjekt. Im konkreten Falle also payload.
$$ bezeichnet dagegen immer das Top level Object wie hier ganz gut beschrieben .Gruß
Reiner -
Danke schön. Die UK - Seite kannte ich noch nicht. Die andere war bislang schon meine Referenz.
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Hier mal meine erfolgreichen JSONATA Switches - der letzte Flow - ist der gerade gepostete und der vorletzte war Deiner mit dem Wildcard und enthält.
Hi, da muss ich ganz ehrlich sagen, das ich das für mich für zu unübersichtlich halte, wenn ich nach Wochen mal schauen will was ich da umgestezt habe, auch kenne ich mich da ehrlich gesagt nicht genug mit Json bzw. Java aus um das aus dem Stehgreif nachvollziehen zu können. Da passiert mir zu viel versteckt in der Change Node. Wenn ich wirklich nur 2 verschiedene Status überwachen will, z,B. true oder false bzw. 1 oder 0 finde ich meine Lösung mit dem Switch und danach die Change Node zum payload setzen nachvollziehbarer. In meinem Fall nutze ich das z.B. um mir in der Vis anzeigen zu lassen ob in einem bestimmten Raum Licht an ist. Ist einer der Datenpunkte true, ist das Icon Gelb, andernfalls ist es schwarz.
Wenn man natürlich mehrere verschiedene Werte z.B. 0-100 bekommt, vereinfacht deine Version mit der Change Node die ganze Sache sehr, wenn ich nur ne Ausgabe, wenn alle 0 sind oder bei nem anderen bestimmten Wert haben will. -
@frankyboy73 Ich habe jetzt meine function Nodes - die alle Objekteigenschaften überprüft haben durch folgende logische Nodes ersetzt:
Geht halt nur bei true und false - aber dann ist das sehr einfach nun.
-
@mickym Ok, das ist jetzt auch für mich nachvollziehbarer. Du hast ja sogar nen Hilfe Text zu den Switches geschrieben. Vielleicht sollte ich sowas, bei meinen Umsetzungen auch mal öfter machen, dann weiß man später auch wofür man das gemacht hat. Tolle Idee.
@mickym
Aber durch das was da in Json drin steht steige ich nicht durch, ich sehe bei dem "and" switch nicht wie abgefragt wird ob alle true sind. Könntest du mir das noch als switch wo alle false sein müssen zu Verfügung stellen? -
@mickym hat funktioniert, besten Dank!
Eine Frage habe ich noch. Gibt es eine Möglichkeit mehrere Blöcke welche in Summe eine zusammenhängende Funktion bilden irgendwie zusammen zu fassen?
Hintergrund: Wenn ich die Funktion öfter benötige wäre es ja cool wenn ich sie nur einmal erstellen muss und dann quasi an mehreren Stellen darauf verlinken könnte. -
@claus1985-0 Hier als Gruppe und einer eigenen Node für die Zukunft.
Wenn Du nur die Node benutzt - musst halt immer Bedenken, dass den topic hoch und topic runter setzt bevor Du die Node fütterst. Kannst Dir ja auch einen Hilfetext dazu schreiben.
-
@mickym sagte in Vergleich von zwei Eingangswerten um Wert festzulegen:
Ich habe jetzt meine function Nodes - die alle Objekteigenschaften überprüft haben durch folgende logische Nodes ersetzt:
Super
Du kannst die Ausdrücke noch um Einiges vereinfachen. Hier mal am Beispiel der OR mit den 2 Augängen:
( $withOR := function($i, $j){$i or $j}; $reduce( $each( payload, function($v) {$v} ),$withOR ); )
kannst du ersetzen durch:
$reduce(payload.*, function($i, $j){$i or $j})
Gruß
Reiner