Shellys ("Alt und Plus") über MQTT Adapter
-
@hotspot_2 Also dann kannst Du doch (also UND verknüpfung) einfach beide Eigenschaften nutzen. Denke immer daran an
Nun kannst Du Dir noch überlegen, ob der BMW automatisch ausschalten soll oder nicht. Also Du kannst mit MQTT- einfach dieses Objekt nutzen und musst weder was auslesen noch zwischenspeichern und das ist eben der RIESESNVORTEIL von mqtt - das alle Informationen auf einmal liefert.
Schau mal wie einfach:
Wenn Du nicht über den BWM ausschalten willst - dann lässt Du an dem 1. Switch den 2. Ausgang weg:
Also mit 3 Nodes und einem Objekt ist die gesamte Logik implementiert. Statt der Inject node, die MQTT-IN Node dran. Nun siehst Du was es für ein Vorteil ist, nicht alle Informationen des Objektes auseinander zu fieseln.
Das kapieren aber die wenigsten.Da das motion-signal direkt true und false liefert können wir das auch direkt nutzen.
Da Du ja über rpc Dein Licht schaltest könntest Du die hintere Change NOde auch wie folgt anpassen:
Wir nutzen also die motion Eigenschaft (true/false) um direkt die Lampe über Rpc zu schalten:
Also kommen wir ohne irgendwelche Datenpunkte aus dem iobroker aus, da uns der Bewegungsmelder bereits alle aktuellen Informationen liefert.
Es ist auch wichtig - dass Du nicht einfach alles triggern lässt. Triggern wird immer die Bewegung. Ob eine Bewegung nun das Licht einschaltet wird in der 2. Bedingung festgelegt. Das LICHT wird aber NIE triggern. Deshalb musst Du hier Deine Logik immer wieder auf die Prüfschale legen.
Falls Du mqtt mit einem iobroker DP vergleichen willst, dann musst Du den mqtt-Wert entweder in einer Variablen speichern oder Du holst wenn die mqtt-Node triggert via iobroker get den Punkt aus dem iobroker. Du schreibst leider nicht, welcher trigger den Vergleich auslösen soll.
Das ist also aus 2 Gründen falsch:
- Wenn Du 2 DP hättest, dann würde die Trigger immer unterschiedlich sein - und Du müsstest sie sowieso in ein Objekt überführen.
- Das Licht triggert nicht, sondern die Bewegung. Das Licht stellt nur eine Bedinung für eine Bewegung dar.
Was Du hier auch sehen kannst: Die Switch Nodes legen nur die Bedingung fest unter der eine Nachricht an einen Ausgang weitergeleitet wird. Das Nachrichtenobjekt selbst wird aber nicht modifziert, so dass Du auch ganz hinten im Flow (also in der letzten Change Node), alle Eigenschaften des Nachrichtenobjektes zu Verfügung hast. Es besteht also gar keinen Notwendigkeit einzelne Eigenschaften des Nachrichtenobjektes zu selektieren oder auszufiltern.
Generell siehst Du hier auch den grafischen Vorteil von NodeRed gegenüber Blockly oder JS-Code - Du kannst Dir genau vorstellen, wie ein Nachrichtenobjekt durch die Nodes flutscht bzw. wo und wie es modifiziert wird. Und wenn mal was nicht tut - einfach die nachfolgende Node deaktivieren, dann bleibt der Flow da stehen und man kann via debug NOde immer sehen, was aus dem Flow rauskommt. Außerdem siehst Du wie einfach Du aus einem Nachrichtenobjekt oder einer payload - eine komplett neues Objekt erstellst.
Du kannst auch mehrere Regeln in der ChangeNode definieren. Falls Du unterschiedliche Eigenschaften zum Schalten des Lichts verwenden willst. Diese werden auch immer von oben nach unten abgearbeitet, so dass die Change Nodes manchmal sogar schon ein Miniprogramm enthalten können.
-
Sehr schön! Danke für die Erklärung.
Ich habe das jetzt mal in meinen Flow eingebaut. Ein Trigger ist der Startpunkt der einmal den Payload true und bei ausschalten false mitgibt. Das wird dann in ein JSON eingebaut zum aus- und einschalten. Ich habe jetzt mal auch true und false abgefangen um zu verhindern dass das Licht nicht mehr ausgeht sollte es dunkel werden zwischen Ein- und Ausschaltzeitpunkt ;-).
Wert wird eingelesen, verglichen und dann nur eingeschaltet wenn es passt.
Hab gerade noch ein Fehler gefunden. Jetzt sollte es passen.
-
@hotspot_2 Na gut - musst Du wissen . ich halte davon nichts - weil diese Logik mE nur komplex und fehleranfällig ist. Ich würde den Bewegungsmelder für die Waschküche lieber selber triggern lassen als von irgendwelchen anderen Schaltungen abhängig zu machen. Deshalb würde ich lieber meinen Flow nutzen. Solche Konstrukte sind einfach nicht gut.
-
Das wäre ja fast Perlen vor die Säue wenn man mit Node Red keine komplexen Dinge machen würde. Alles was wir gemeinsam gebaut haben oder ich jetzt gebaut habe funktioniert so einwandfrei das ich einfach gar nichts mehr anderes will. Und im Vergleich zu meinen Blocklys ist das hier immer noch sehr, sehr einfach gehalten ;-).
-
@hotspot_2 Wie gesagt - ein Bewegungsmelder sollte lieber selbst trigger und dann kann man Bedingungen formulieren. Einen Bewegungsmelder von einer eingeschalteten Lampe abhängig zu machen ist in meinen Augen unsinnig. Wenn nach 2 Minuten das Licht ausgeht - dann sitzt Du im Dunkeln.
Ausserdem weiß ich nicht was das soll?
Wenn Du das setzt und vorne seit Du msg.status_licht setzt. Ausserdem setzt Du status_licht so nicht auf true oder false.
da Du hier die payload auf ein Objekt setzt. Ich würde Dir empfehlen, dass Du mit debug Nodes arbeitest. So wird das nicht funktionieren.
Auch das ist verkehrt:
Die get Node kann nur Eigenschaften auf root Ebene des msg.Objektes setzen. Du frägst hier aber eine Eigenschaft der payload ab.
Hier hast Du reines Glück, dass das payload Objekt aus der Change Node nach dem trigger bis zur waschküchenlampe durchgereicht wird und der switch immer durchlässt, weil der switch immer false liefert.
Also leider stimmt der Flow hinten und vorne nicht.
Arbeite mit debug Nodes - dann siehst Du dass das was Du konfiguriert hast, nicht viel mit der Realität zu tun hat.
-
Ich möchte eigentlich den Bewegungsmelder von nix abhängig machen. Ich möchte nur verhindern das der Trigger das Licht in der Waschküche anschaltet wenn es dort hell genug ist (da dort ein Fenster eingebaut ist) in den Räumen mit den anderen Lampen nicht. Die Bewegungsmelder oder die Schalter triggern den Trigger oder starten den Flow. Und hinten soll dann eben nur das Licht in der Waschküche angehen wenn es nicht hell genug ist. So ist der Plan.
Das mit dem Status_Licht war der Ansatz das ich mitnehmen kann ob der Trigger nun das Licht ein oder ausschaltet. Sollte er einschalten prüfe ich ob es hell genug ist, sollte er aussschalten geht es so durch.
Aber mit payload.params.on müsste ich das doch auch abfragen können im switch, oder? Also true oder false?
-
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.
