Shellys ("Alt und Plus") über MQTT Adapter
-
***gelöscht
-
@dos1973 Ja müsste so gehen - aber moderner und einfacher ist es über command - dann würde ich lieber wenn Du es einheitlicher haben möchtest auch die switche über command steuern.
Schaffst Du es alleine die Switche über command zu steuern oder soll ich anpassen? Auch wenn die switche on/off verstehen - können wir das ja wenn Du willst auch in true/false über change Nodes umwandeln.
-
@mickym
Ich versuchs erstmal… und melde mich dann. Wird wohl erste Anfang nächster Woche -
Hallo Mickym,
ich hatte mal wieder eine Frage. Mir fällt dazu keine Lösung ein bisher.
Ich würde gerne zwei Werte miteinander vergleichen die ich aber beide einlese (einmal aus MQTT und einmal aus einem Objekt). Wenn der eine Werte kleiner ist als der andere soll in einem Flow eine Aktion stattfinden oder auch nicht. Im Schalter habe ich bisher nur gesehen das ich mit einem Wert, den ich eingebe im switch, vergleichen kann.
Danke schon mal für einen Tipp von Dir ;-).
-
@hotspot_2 Nun Du liest beide Werte in verschiedene Eigenschaften des Nachrichtenobjektes ein und kannst diese dann vergleichen.
Einlesen kannst Du entweder durch Trigger und holen des jeweilig anderen Wertes oder über Variablen im Kontext (Flow oder Global).
Einlesen kannst Du entweder durch Trigger und holen des jeweilig anderen Wertes oder über Variablen im Kontext (Flow oder Global).
Diese Behauptung habe ich mit dieser Switch Node widerlegt.
Du kannst die payload auch direkt mit einer flow oder globalen Kontextvariable vergleichen. je nachdem für welche Variante Du dich entscheidest oder wenn Du alle Varianten sehen möchtest, lass es mich wissen, falls Du noch weitere Hilfe brauchst, dann gehen wir das wieder an einem konkreten Beispiel durch.
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.
-
@mickym
Ich möchte wenn ein Bewegungsmelder Bewegung erkennt das Licht nur dann schalten wenn der Lux Wert (erkennt auch der Bewegungsmelder) unter einem bestimmten Wert ist. Den Wert habe ich einen ioBroker Objekt.Ich würde einfach zwei MQTT-in's machen (Bewegung und Lux-Wert) und dann den Lux-Wert mit dem Objekt vergleichen das ich vorher über iobroker-in geholt habe. Habe ich ja bei meinen Schaltern im Treppenhaus auch gemacht.
Stimmt, iobroker get hat ja einen Ein- und Ausgang. Ein MQTT-Get konnte ich nicht finden.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
Ich würde einfach zwei MQTT-in's machen (Bewegung und Lux-Wert) und dann den Lux-Wert mit dem Objekt vergleichen das ich vorher über iobroker-in geholt habe. Habe ich ja bei meinen Schaltern im Treppenhaus auch gemacht.
Nein das ist aus 2 Gründen verkehrt. Wenn Du 2 MQTT ins verwendest, dann triggern die zu unterschiedlichen Zeiten. Aber nun wirst Du den Vorteil von MQTT kennenlernen, wenn alle Informationen in einem Objekt sind, da ich davon ausgehe, dass in dem BWM Objekt auch die Lichtstärke ist.
Kannst Du mal das komplette Objekt des Bewegungsmelders posten?
MQTT-Get gibts nicht. Zeig das komplette Objekt des Bewegungsmelders und poste es bitte in CodeTags hier .
-
@mickym
Hallo! Ja, die Lichtstärke ist auch drin (lux). Motion holen wir ja schon raus.{ "motion": false, "timestamp": 1680969357, "active": true, "vibration": false, "lux": 0, "bat": 100, "tmp": { "value": 18.7, "units": "C", "is_valid": true } } -
@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.
