NEWS
Shellys ("Alt und Plus") über MQTT Adapter
-
@hotspot_2 Node Red ist einfach genial ;-). Na da rennst Du bei mir offene Türen ein. Leider beschäftigen sich die meisten erst gar nicht damit. Die, die auf den Geschmack gekommen sind, habe ich noch nie wieder auf Blockly zurück migrieren sehen.;)
Was Du halt noch machen kannst, wenn Du willst, deswegen habe ich Dir den anderen Thread verlinkt, dass Du selbst Objekte baust und mit true und false arbeitest. Aber mach erst mal - zur Optimierung und weiteren Idee ist ja immer noch Zeit.
Und wie Du siehst, wenn man einmal gelernt hat, mit Objekten umzugehen, dann ist das eigentlich ganz easy und lernt die Vorteile von Objekten kennen.
@mickym Ich hätte noch mal eine Frage dazu wie Du sowas angehen würdest.
Ich habe im Garten eine elektrische Klingel die ich über einen Shelly ansteuere. Klingelt jemand an der Haustüre dann mache ich seither über einen Blockly die Klingel zweimal an und wieder aus mit kurzen Pausen dazwischen.
Wenn ich sowas jetzt in Node-Red machen möchte wie würde ich das angehen? Gibt es da sowas wie eine Schleife oder so?
Trigger wäre ein Ansatz gewesen aber der macht halt nur einmal an und wieder aus.
-
@mickym Ich hätte noch mal eine Frage dazu wie Du sowas angehen würdest.
Ich habe im Garten eine elektrische Klingel die ich über einen Shelly ansteuere. Klingelt jemand an der Haustüre dann mache ich seither über einen Blockly die Klingel zweimal an und wieder aus mit kurzen Pausen dazwischen.
Wenn ich sowas jetzt in Node-Red machen möchte wie würde ich das angehen? Gibt es da sowas wie eine Schleife oder so?
Trigger wäre ein Ansatz gewesen aber der macht halt nur einmal an und wieder aus.
@hotspot_2 Nein die Trigger Node kann auch unendlich oft in bestimmten Abständen triggern. Aber natürlich kannst Du auch Schleifen bauen - du musst ja nun den Ausgang mit dem Eingang verbinden.
Das macht sie solange, bis Du die Trigger Node zurücksetzt.
Wenn die Klingel zwischendrin wieder ausschalten musst, dann kannst auch wie bisher den trigger nehmen und über den 2.Ausgang die Schleife antriggern.
Du kannst dann über eine Flow-variable zählen oder in dem Fall auch über eine function-Node und JS - wenn Dir für einen stupiden Zähler die Variable im FlowKontext zu viel ist.
Hier mal 2 Varianten.Hier mal eine Variante mit Flow-Kontext:
Hier das gleiche mit einer function node und node context, falls Du lieber mit Javascript programmieren willst.
Falls nicht zwischen true und false gewechselt werden muss, kannst Du einfach eine function Node nehmen und eine Delay node:
So und hier nochmal das Gleiche ohne Javascript Programmierung und nur mit Change Node und Flow Kontext.
So keine Schleife - aber noch ein ganz anderer Lösungsansatz ist, Du machst Dir zum Beispiel ein Array mit Nachrichten die Du schicken möchtest und splittest die einfach auf . Später wirst Du die split Node mal kennenlernen, die eine Schleife der herkömmlichen Programmierung ersetzt.
Nehmen wir mal Du möchstest verschiedene Nachrichten einfach mit einer delay Node verschicken, dann geht zum Beispiel auch so was.
Du siehst die Möglichkeiten sind vielfältig.
Und natürlich kannst Du auch alles in JS programmieren mit einer function Node.
- falls Du einfach codieren willst. -
@hotspot_2 Nein die Trigger Node kann auch unendlich oft in bestimmten Abständen triggern. Aber natürlich kannst Du auch Schleifen bauen - du musst ja nun den Ausgang mit dem Eingang verbinden.
Das macht sie solange, bis Du die Trigger Node zurücksetzt.
Wenn die Klingel zwischendrin wieder ausschalten musst, dann kannst auch wie bisher den trigger nehmen und über den 2.Ausgang die Schleife antriggern.
Du kannst dann über eine Flow-variable zählen oder in dem Fall auch über eine function-Node und JS - wenn Dir für einen stupiden Zähler die Variable im FlowKontext zu viel ist.
Hier mal 2 Varianten.Hier mal eine Variante mit Flow-Kontext:
Hier das gleiche mit einer function node und node context, falls Du lieber mit Javascript programmieren willst.
Falls nicht zwischen true und false gewechselt werden muss, kannst Du einfach eine function Node nehmen und eine Delay node:
So und hier nochmal das Gleiche ohne Javascript Programmierung und nur mit Change Node und Flow Kontext.
So keine Schleife - aber noch ein ganz anderer Lösungsansatz ist, Du machst Dir zum Beispiel ein Array mit Nachrichten die Du schicken möchtest und splittest die einfach auf . Später wirst Du die split Node mal kennenlernen, die eine Schleife der herkömmlichen Programmierung ersetzt.
Nehmen wir mal Du möchstest verschiedene Nachrichten einfach mit einer delay Node verschicken, dann geht zum Beispiel auch so was.
Du siehst die Möglichkeiten sind vielfältig.
Und natürlich kannst Du auch alles in JS programmieren mit einer function Node.
- falls Du einfach codieren willst. -
Node Red ist schon cool - aber ich finde sauschwer, daran liegts vielleicht. blockly bist schnell drin und lässt sich irgendwie leichter lesen.
@dos1973 Na ich finde es ganz und gar nicht schwer und eigentlich viel einfacher zu lesen, weil Du Dich nur an den Kabeln entlang hangeln musst. Blockly ist viel zu starr an die herkömmliche Programmierlogik angelehnt und du kannst keine Funktionsblöcke bilden.
-
@dos1973 Na ich finde es ganz und gar nicht schwer und eigentlich viel einfacher zu lesen, weil Du Dich nur an den Kabeln entlang hangeln musst. Blockly ist viel zu starr an die herkömmliche Programmierlogik angelehnt und du kannst keine Funktionsblöcke bilden.
-
@mickym
Du … bist ja von flows umschwungen
Bei dir sieht das immer so easy und logisch aus.@dos1973 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym
Du … bist ja von flows umschwungen
Bei dir sieht das immer so easy und logisch aus.Na Du musst Dir doch nur vorstellen, wie ein Nachrichtenobjekt durch die Kabel flutscht und Dir dann jede Node betrachtest, was diese mit dem Nachrichtenobjekt anstellt.
- Das schöne ist - Du kannst über Inject Nodes - Zwischenergebnisse in Deinen Flow injizieren, über debug Nodes Dich versichern, dass die Nachrichtenobjekte noch so aussehen, wie Du es erwartest. Mal ein Kabel kappen, um die Hardware nicht unnötig zu belasten und wie gesagt es gibt auch Nodes, die ganze Adapter ersetzen, wenn die mal nicht so wollen, wie man sich das vorstellt.Du musst nur etwas Vorstellungskraft entwickeln - so ein Nachrichtenobjekt zu sein und durch die Kabel zu fließen.
-
@dos1973 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym
Du … bist ja von flows umschwungen
Bei dir sieht das immer so easy und logisch aus.Na Du musst Dir doch nur vorstellen, wie ein Nachrichtenobjekt durch die Kabel flutscht und Dir dann jede Node betrachtest, was diese mit dem Nachrichtenobjekt anstellt.
- Das schöne ist - Du kannst über Inject Nodes - Zwischenergebnisse in Deinen Flow injizieren, über debug Nodes Dich versichern, dass die Nachrichtenobjekte noch so aussehen, wie Du es erwartest. Mal ein Kabel kappen, um die Hardware nicht unnötig zu belasten und wie gesagt es gibt auch Nodes, die ganze Adapter ersetzen, wenn die mal nicht so wollen, wie man sich das vorstellt.Du musst nur etwas Vorstellungskraft entwickeln - so ein Nachrichtenobjekt zu sein und durch die Kabel zu fließen.
Diese Variante:
Ist mir sehr sympatisch.
Würde ich damit auch so eine Folge hinbekommen:
True - 2 Sekunken Pause - False - 2 Sekunden Pause - True 2 Sekundnen Pause- False
Also quasi 2 mal klingeln mit Pause dazwischen? Im Moment wird ja wieder direkt nach false true geschickt.
-
Diese Variante:
Ist mir sehr sympatisch.
Würde ich damit auch so eine Folge hinbekommen:
True - 2 Sekunken Pause - False - 2 Sekunden Pause - True 2 Sekundnen Pause- False
Also quasi 2 mal klingeln mit Pause dazwischen? Im Moment wird ja wieder direkt nach false true geschickt.
@hotspot_2 dann nimm doch lieber die letzte Variante mit dem Array, da kommst auch ohne Variable und Flow Kontext aus. Das Array definierst einfach in einer Change-Node. Damit steuerst Du über ein Array einfach die Nachrichtenfolge und begrenzt die Nachrichtenrate über die delay Node.
Du siehst an den Zeitstempeln alle 2 s eine Nachricht. Außerdem siehst du an der Delay Node im Status gleich, wieviele Nachrichten noch kommen.
Bei der Variante unten von dir müsstest Du noch eine delay Node mit 2s in die Schleife einfügen, da finde ich das ohne Flowkontext viel einfacher und intuitiver.
-
@hotspot_2 dann nimm doch lieber die letzte Variante mit dem Array, da kommst auch ohne Variable und Flow Kontext aus. Das Array definierst einfach in einer Change-Node. Damit steuerst Du über ein Array einfach die Nachrichtenfolge und begrenzt die Nachrichtenrate über die delay Node.
Du siehst an den Zeitstempeln alle 2 s eine Nachricht. Außerdem siehst du an der Delay Node im Status gleich, wieviele Nachrichten noch kommen.
Bei der Variante unten von dir müsstest Du noch eine delay Node mit 2s in die Schleife einfügen, da finde ich das ohne Flowkontext viel einfacher und intuitiver.
-
@mickym Funktioniert perfekt!
Hast Du mir noch einen Tipp wie ich den Eingang entprellen kann (Klingeltaster). So dass z.B. alle 2 Sekunden nur eine Meldung durchgeht?
@hotspot_2 Ja mit der tollen Trigger Node
oder ebenfalls mit der Delay Node
und Begrenzung der Nachrichtenrate 
hier dann halt die Zwischennachrichten löschen.
Bei der Delay Node kommt in jedem Fall eine Nachricht durch nach 2s. Bei der Trigger Node kannst Du entscheiden, ob nach 2 Sekunden eine Nachricht kommt (also Haken bei Verzögerung verlängern deaktivieren) oder ob Du den Dauerklingler solange ignorierst, bis er den Finger für 2s von der Klingel nimmt ;). (also Haken bei Verzögerung verlängern aktivieren)
-
@hotspot_2 Ja mit der tollen Trigger Node
oder ebenfalls mit der Delay Node
und Begrenzung der Nachrichtenrate hier dann halt die Zwischennachrichten löschen.
Bei der Delay Node kommt in jedem Fall eine Nachricht durch nach 2s. Bei der Trigger Node kannst Du entscheiden, ob nach 2 Sekunden eine Nachricht kommt (also Haken bei Verzögerung verlängern deaktivieren) oder ob Du den Dauerklingler solange ignorierst, bis er den Finger für 2s von der Klingel nimmt ;). (also Haken bei Verzögerung verlängern aktivieren)
@mickym Hallo!
Ich habe noch mal eine Verständnisfrage zu dem hier:
Wenn in dem obigen Flow jetzt der Bewegsungsmelder keller und nicht der wk auslöst dann wird der Wert für den aktuellen Lux-Wert in der Waschküche nicht ermittelt und d.h. das vermutlich das Licht nicht angeht bzw. dem Zufall überlassen ist am Ende des Flows da vergleiche ja dann lux_wk wert mit einem Limit und wenn größer dann geht das Licht nicht an.
Wie wäre es denn machbar den Lux wert von WK immer abzrufen? Zum Beispiel auch wenn es noch mehr Bewegungsmelder sind.
Danek für einen TIpp dazu.
-
@mickym Hallo!
Ich habe noch mal eine Verständnisfrage zu dem hier:
Wenn in dem obigen Flow jetzt der Bewegsungsmelder keller und nicht der wk auslöst dann wird der Wert für den aktuellen Lux-Wert in der Waschküche nicht ermittelt und d.h. das vermutlich das Licht nicht angeht bzw. dem Zufall überlassen ist am Ende des Flows da vergleiche ja dann lux_wk wert mit einem Limit und wenn größer dann geht das Licht nicht an.
Wie wäre es denn machbar den Lux wert von WK immer abzrufen? Zum Beispiel auch wenn es noch mehr Bewegungsmelder sind.
Danek für einen TIpp dazu.
@hotspot_2 Dann nimm halt über eine iobroker-Get Node direkt den Wert aus dem mqtt-Adapter.
-
@hotspot_2 Dann nimm halt über eine iobroker-Get Node direkt den Wert aus dem mqtt-Adapter.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Danke, da bin ich jetzt irgendwie nicht darauf gekommen.
Kann aber sein, dass Du keinen Gewinn davon hast, da der BWM oft nur lux aktualisiert bei BEwegung oder vielleicht im Stundenrhythmus. Da das aber in einem Objekt ist - hast Du trotzdem wahrscheinlich den aktuellsten Wert.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Danke, da bin ich jetzt irgendwie nicht darauf gekommen.
Kann aber sein, dass Du keinen Gewinn davon hast, da der BWM oft nur lux aktualisiert bei BEwegung oder vielleicht im Stundenrhythmus. Da das aber in einem Objekt ist - hast Du trotzdem wahrscheinlich den aktuellsten Wert.
@mickym Hallo mivkym, oder andere ;-),
Ich habe mal wieder eine kleine Verständnisfrage da ich den Eindruck habe das was nicht ganz so abläuft wie ich mir das gedacht habe.
Ich habe bei zwei Lichtsteuerungen quasi das gleiche gemacht:
Nummer 1:
Nummer 2:
Ich habe den Eindruck das es nicht funktioniert und der eingestellte Wert vom ioBroker Objekt nicht eingelesen wird wenn der Trigger über MQTT kommt.
Kann das sein? Müsste ich den iobroker in in den Flow einbinden damit es korrekt funktioniert?
Danke für eine Rückinfo dazu.
-
@mickym Hallo mivkym, oder andere ;-),
Ich habe mal wieder eine kleine Verständnisfrage da ich den Eindruck habe das was nicht ganz so abläuft wie ich mir das gedacht habe.
Ich habe bei zwei Lichtsteuerungen quasi das gleiche gemacht:
Nummer 1:
Nummer 2:
Ich habe den Eindruck das es nicht funktioniert und der eingestellte Wert vom ioBroker Objekt nicht eingelesen wird wenn der Trigger über MQTT kommt.
Kann das sein? Müsste ich den iobroker in in den Flow einbinden damit es korrekt funktioniert?
Danke für eine Rückinfo dazu.
@hotspot_2 Ich verstehe die Frage nicht. Laut status werden doch die iobroker-In Nodes eingelesen. Was hast Du in msg.delay - ist Dir klar dass der Wert in ms angegeben wird?
-
@hotspot_2 Ich verstehe die Frage nicht. Laut status werden doch die iobroker-In Nodes eingelesen. Was hast Du in msg.delay - ist Dir klar dass der Wert in ms angegeben wird?
@mickym Ja, das ist mir klar. Vielleicht liegt es auch an meiner Denkweise.
Wird der Wert in Trigger überhaupt aktuell angezogen wenn der eigentliche Trigger für die Schaltung von einem anderen Strang / Zweig kommt? Das ist eigentlich meine Frage. Ich denke mir im Moment das dadurch das der Trigger nicht vom iobroker in kommt beim Schaltvorgang der Werte nicht aktuell eingelesen wird durch den oberen Strang oder unteren im zweiten Flow.
-
@mickym Ja, das ist mir klar. Vielleicht liegt es auch an meiner Denkweise.
Wird der Wert in Trigger überhaupt aktuell angezogen wenn der eigentliche Trigger für die Schaltung von einem anderen Strang / Zweig kommt? Das ist eigentlich meine Frage. Ich denke mir im Moment das dadurch das der Trigger nicht vom iobroker in kommt beim Schaltvorgang der Werte nicht aktuell eingelesen wird durch den oberen Strang oder unteren im zweiten Flow.
@hotspot_2 Wenn Du über die rosa mqtt-Nodes gehst gehst Du nicht über den iobroker, wenn Du über die iobroker Node gehst schon. Ich weiss gerade nicht ob du mosquitto als Broker nutzt oder den mqtt-Adapter.
-
@hotspot_2 Wenn Du über die rosa mqtt-Nodes gehst gehst Du nicht über den iobroker, wenn Du über die iobroker Node gehst schon. Ich weiss gerade nicht ob du mosquitto als Broker nutzt oder den mqtt-Adapter.
-
Wenn jetzt über die rosa Mqtt-Nodes ein Event kommt und der Flow startet. Wird dann zu dem Zeitpunkt auch der dann im iobroker objekt stehende Wert ausgelesen?
@hotspot_2 Nein!! - Dieser Wert wird nur ausgelesen wenn Du den änderst. Wenn Du innerhalb eines Flows einen Wert auslesen willst dann musst Du die GET Node verwenden. Achte aber darauf, dass Du Dir die payload nicht überschreibst. Also müsstest Du die delay Nachrichteneigenschaft bereits in der Get Node setzen:
Also mit einer GetNode die Verzögerung holen und in den Flow einbauen, in dem Du es hiner die mqtt-In Node schaltest:
487
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge