NEWS
Shellys ("Alt und Plus") über MQTT Adapter
-
Na gut - ich lass Dir Deine Logik wie Du es willst - ich ändere mal den Flow nicht. Du musst selbst wissen, wie komplex Du das machen willst und ich will Dir auch nicht irgendwas aufzwingen. Trotzdem wird er so nicht funktionieren. Die Nodes sind einfach verkehrt.
Also erkläre mal Schritt für Schritt was Du machen wolltest?
Fang ab der Change Node hier an:
-
Den Flow für den Flur haben wir ja schon zusammen erstellt. Vorne sind drei Lichtschalter und zwei Bewegungsmelder die den Trigger aktivieren können. Das bleibt auch alles so wie es ist. der Trigger sendet ja ein true wenn er aktiviert wurde und wenn 2 Minuten lang nix mehr passiert dann sendet er ja ein false. Dieses True oder false wird in eine JSON gepackt (JSONata) und dann an die drei Lampen geschickt die dann entweder ein oder ausgehen. Funktioniert alles perfekt!
Ich wollte nun eine der drei Lampen abhängig von der Helligkeit im Raum einschalten. Ist es hell geht die Lampe nicht an, ist es dunkel geht sie an. Ausgehen habe ich mir gedacht kann sie ja immer. Und das habe ich gehofft zu bauen. Mit dem zusätzlichen payload einfügen geht nicht, das passt.
Ich hätte nun einfach in dem hinteren Switch (switch im Bild oben unten nach dem Change. Der Change hat mittlerweile wieder nur noch 1 Regel ) abgefragt ob payload.params.on true oder false ist und bei true denn Helligkeitswert abgeglichen und bei false das einfach durchgelassen. So die Idee.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
Den Flow für den Flur haben wir ja schon zusammen erstellt. Vorne sind drei Lichtschalter und zwei Bewegungsmelder die den Trigger aktivieren können. Das bleibt auch alles so wie es ist. der Trigger sendet ja ein true wenn er aktiviert wurde und wenn 2 Minuten lang nix mehr passiert dann sendet er ja ein false. Dieses True oder false wird in eine JSON gepackt (JSONata) und dann an die drei Lampen geschickt die dann entweder ein oder ausgehen. Funktioniert alles perfekt!
Ich wollte nun eine der drei Lampen abhängig von der Helligkeit im Raum einschalten. Ist es hell geht die Lampe nicht an, ist es dunkel geht sie an. Ausgehen habe ich mir gedacht kann sie ja immer. Und das habe ich gehofft zu bauen. Mit dem zusätzlichen payload einfügen geht nicht, das passt.
Ich hätte nun einfach in dem hinteren Switch abgefragt ob payload.params.on true oder false ist und bei true denn Helligkeitswert abgeglichen und bei false das einfach durchgelassen. So die Idee.
Das habe ich schon verstanden - aber fang doch bitte an mir zu erklären, was Du machst?
Welche Regel hat die Change Node noch und wie schaut die switch NOde aus?
-
@mickym Habs jetzt oben mal eingestellt den aktuellen Stand. Den switch habe ich nur deswegen drin um sicherzustellen daß das Licht immer ausgeht, auch wenn sich eventuell der Helligkeitswert verändert hat.
-
@hotspot_2 Gut was steht in dem iobroker - Datenpunkt drin? Was machst Du mit der get Node?
Was soll das?Ich empfehle Dir mal folgendes - damit auch das debuggen lernst. Deaktivere einfach mal die mqtt-out Nodes und mach eine debug NOde - hinten hin. Und dann schau mal was rauskommt?
-
@mickym Damit wollte ich den Wert den ich einlese über Get (lux_wk) mit dem Wert im Bewegungsmelder (lux) vergleichen wenn kleiner dann soll das licht eingeschaltet werden. Wenn der Wert im Bewegungsmelder kleiner ist als der Wert aus dem ioBroker Objekt dann geht das Licht mit an.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Damit wollte ich den Wert den ich einlese über Get (lux_wk) mit dem Wert im Bewegungsmelder (lux) vergleichen wenn kleiner dann soll das licht eingeschaltet werden (also wder wert im Bewegungsmelder).
Ok - dann ist in der iobroker-Get Node ein Wert der aus Deiner vis kommt. Trotzdem kommt von dem mqtt-Objekt 0,0 an - weil wir das Objekt komplett neu in der Change node machen. Es gibt also keine lux Eigenschaft mehr in deinem payload Objekt. Deswegen mach mal eine Debug Node hinter Deine Change Node und dann siehst Du was Deine payload für Eigenschaften besitzt.
-
@mickym Ok, das habe ich befürchtet, wir überschreiben nach dem Trigger die Payload komplett. Gäbe es eine Möglichkeit den Lux Wert mitzunehmen? Falls ja, müsste ja dann mein Konstrukt funktionieren.
Aber ja, das mit den Debugs mach ich.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Ok, das habe ich befürchtet, wir überschreiben nach dem Trigger die Payload komplett.
Na wenn Du schon so was befürchtest, wieso ignorierst du das dann?
Aber es gibt ja einen Ausweg - wir können ja den Wert in einer Variablen speichern
-
@mickym Da wir im Prinzip mit der Trigger Node alles wegschmeissen - kannst Du mit einer Inject Node vor der Trigger Node den Flow testen.
Ich habe mir übrigens zum Aktiveren und Deaktivieren von Nodes eine kleine Tastenkombination gebastelt - solltest Du vielleicht auch tun.
So kannst Du also Deinen Flow triggern und dann die debug Node immer weiter nach hinten schieben, um zu testen, wie es aussieht:
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Ok, das habe ich befürchtet, wir überschreiben nach dem Trigger die Payload komplett. Gäbe es eine Möglichkeit den Lux Wert mitzunehmen? Falls ja, müsste ja dann mein Konstrukt funktionieren.
Aber ja, das mit den Debugs mach ich.
Die Möglichkeit den Lux Wert abzuspeichern - wäre es direkt in eine Flow-Variable zu schreiben.
-
Jupp, passt. Ich seh's schon ;-).
-
@hotspot_2 Gut also siehst Du wenn Du Deine Debug Nodes anschaust, dass Deine payload keine Eigenschaft lux mehr besitzt - und ausserdem willst Du ja die lux nur aus dem Waschküchenbewegungsmelder oder?
-
@mickym Ja, nur aus dem Waschküchenbewegungsmelder.
-
@hotspot_2 Also dann speichere direkt hinter dem Bewegungsmelderobjekt den Wert in einer Flowvariablen.
Am Besten Du simulierst dann die Ausgabe des Bewegungsmelder objektes der Waschküche - also setze deine Inject-Node dorthin mit einem Objekt was aus dem Bewegungsmelder kommt.
-
@mickym
Das geht mit Function und etwas JavaScript, oder?flow.set("lux_wk", msg.payload.lux);
-
@mickym Nein KEINE function Nodes. Das machst Du alles mit einer Change Node. Du solltest die Variable aber anders nennen - als die Eigenschaft, die Du ihr in der get-Node zuweist.
Also nichts programmieren - wir arbeiten mit NodeRed.
Mach das erst mal so, dass Du Dein Objekt in eine Inject Node verfrachtest und die mqtt-Node simulierst. Du musst die Methodik lernen.
Du hast mir ja so ein Objekt vorher geliefert. Wollen wir das nehmen?
{ "motion": false, "timestamp": 1680969357, "active": true, "vibration": false, "lux": 0, "bat": 100, "tmp": { "value": 18.7, "units": "C", "is_valid": true } }
-
@mickym Stimmt, das ist ja das gewesen. Hab gerade ein Debug Node dran gemacht und bin extra in den Keller gelaufen ;-).
-
@hotspot_2 Nein du sollst nicht mehr in den Keller laufen - wir simulieren direkt in Node Red und Du nutzt eine Inject Node mit diesem Objekt.
-
@mickym Alles gut, ich war nur im Keller da ich eine komplette Meldung vom Bewegungsmelder haben wollte. das mit den Debugs, den Nodes deaktivieren usw. sitzt jetzt komplett bei mir.
Wie kann ich die flow Variabel debuggen? Geht das auch? Ob sie da ist und einen Wert hat wäre interessant zu wissen.