Sind die Flows logisch korrekt aufgebaut? Küchengeräte auf Basis von Bewegung ein-/ausschalten

Hallo!
Ich möchte bestimmte Küchengeräte wie z.B. ein Wasserkocher mit LCD Display, Mikrowelle, Toaster usw. gerne auf Basis von Bewegungen ein- oder ausschalten (mit Strom versorgen) und nach einer Stunde die Smart Plug Steckdose wieder von selbst ausschalten. Jede neue Bewegung, soll den Countdown bis zum Ausschalten automatisch verlängern.

Hierzu habe ich folgende Flows erstellt:

Da dies meine ersten Flows in Homey sind, wollte ich einmal fragen ob dies korrekt wäre? Ist es zudem überhaupt erforderlich immer die Abfrage mit aufzunehmen, ob das Smart Plug eingeschaltet oder ausgeschaltet ist, um pot. mehrfach unnötig gesendet Signale zu vermeiden oder kriegt Homey dies automatisch hin? Denn derzeit würde der Countdown im eingeschalteten Zustand nicht erneut verlängert. Dies müsste ich vermutlich noch mit einem dritten Flow abbilden.

Ist für ein Szenario wie das meine immer zwingend die Thematik mit dem Countdown erforderlich? Homey bietet ja soweit ich weiß auch an, einen Delay zu hinterlegen. Wenn ich jedoch z.B. bei der Einschaltroutine auch eine Aktion Ausschalten mit für den Test kurzen Delay von 20 Sekunden hinterlege, wird das Gerät im Anschluss auch ausgeschaltet, ohne dass es durch Bewegungen in der Zwischenzeit verlängert werden würde. Daher wurde ich mit etwas Recherche auf die CountDown App aufmerksam.

Ich danke euch!

Hi,

sieht so schön ganz gut aus. Du brauchst aber nicht immer abzufragen beim “und” Teil.

Tu dir gleich den Gefallen und Tausch die App Countdown gegen die App Chronograph aus. Da ist das was du vor hast und auch für alles andere in der Zukunft um einiges komfortabler. Schon allein desswegen, weil du die timer, countdowns usw direkt in der Flow config erstellen kannst.

Ich häng dir hier mal mein Flurlicht mit Bewegungssteuerung ran. Dann kannst auch mal vergleichen.

2 Likes

Hi @Markus_F,

vielen Dank für die Chronograph Empfehlung. Das ist ja noch besser und unkomplizierter :slight_smile:.

Den Geräten Smart Plugs, Lampen usw. macht das also nichts, wenn sie ggf. mehrmals ein Einschaltsignal bekommen?

Braucht man nicht, das stimmt.

Da bin ich mir auch nicht sicher. Ich füge auch gerne die Zustandsbedingung bei UND mit ein um ein unnötiges Schalten bzw. Senden von Signalen zu vermeiden. Der aktuelle Zustand eines Gerätes, ob ein- oder ausgeschaltet, müsste Homey ja bekannt sein und so vermeidet man zumindest Traffic.
Aber vielleicht können ein paar erfahrenere User dazu was sagen? @PhilS

Also ich habe Bewegungsmelder in Verbindung mit Licht (z.B. im Treppenhaus) mit der Countdown App realisiert. Die neue App Chronograph habe ich mir nicht angeschaut.

Momentan mache ich weniger was mit Homey, da alle Flows und Dinge, die ich gerne gesteuert haben will, einfach seit langem funktionieren.

Vorteil: voll zufrieden mit Homey.
Nachteil: man beschäftigt sich nicht mehr so intensiv mit Homey.

Wenn man dann noch wenig Zeit hat, ist man nicht mehr so richtig auf der Höhe hier im Forum, was ich aber stark bedaure!

Zurück zur Frage: ich habe also drei flows.

Erstens: Licht einschalten bei Bewegung und Countdown stoppen
Zweitens: Countdown starten bei Bewegung aus
Drittens: Countdown erreicht 0 , dann Licht aus.

Ihr seht, dass ich den Countdown erst bei Bewegungsmelder aus starte!

Ich habe das jetzt aus dem Kopf schnell geschrieben ohne nachzuschauen.

Ich hatte auch mal den Bewegungsmelder eigenen Zeit des Alarms genutzt.
Man konnte einstellen wie lange der Alarm hielt ohne weiter Bewegung (weiß nicht mehr welcher Parameter in den verschiedenen Brands wie Coolcam und fibaro es war).
Dann brauchte man nur die Zeit des Alarms verlängern und wenn ausgeht auch die Lichter ausgehen lassen. Dann braucht man gar keinen Timer. So habe ich es im Bad mit einem coolcam Sensor. Der Bewegungsalarm geht immer Bach 2 Minuten aus, wenn nicht neue Bewegung erkannt. Dann lasse ich das Licht auch ausgehen.
Wollte gerade nachschauen wo ich die 129 Sekunden eingestellt habe. Da muss sich seit ein paar firmware und App Updates einiges geändert haben. Auf alle Fälle kamen mir die Einstellungen dort fremd vor. Sag ja lange nicht mehr mich damit beschäftigt, weil alles läuft.

So wie @PhilS es macht, ist es natürlich auch möglich und mit der Countdown App Abe ich damals das genauso mit drei Flows gelöst.
Da man allerdings mit der Chronograph App direkt sagen soll, was nach erneuter Bewegumgaerkennung passieren soll, kann man sich hier den dritten Flow locker sparen. Habe ich nirgends mehr und funktioniert auch top.

Ob ein erneuter Schaltbefehl an ein Gerät etwas bewirkt, halte ich für unwahrscheinlich. Habe zumindest nirgends eine Zustand Überprüfung drin und bis jetzt noch nie ein Problem gehabt.
Ein Lichtschalter wenn eingeschaltet ist, ist er ja auch einfach eingeschaltet und kann nicht nochmal eingeschaltet werden.
Das einzige, was man sich spart ist der traffic, das stimmt allerdings.

Na dann werde ich die chronoapp mir auch mal über die Weihnachtstage ansehen und eventuell ein paar flows so optimieren.

Ja, lohnt sich definitiv…

1 Like

@PhilS, die Flows von @Markus_F sind soweit ok, deshalb hatte ich Dich auch nicht erwähnt.

Die Frage von @Dominik und mir war, ob es Sinn macht in der UND-Kategorie den aktuellen Schaltzustand des Aktors zu berücksichtigen.
Beispiel:

Im Beispiel „Mit Zustandsabfrage“ wird der Befehl bei DANN ja nur ausgeführt wenn sichergestellt ist, dass die Lampe aus ist.

Im Beispiel „Ohne Zustandsabfrage“ wird immer der Befehl zum einschalten gesendet, egal ob die Lampe an oder aus ist.

Was ist für Homey und den Aktor ressourcenschonender? Oder spielt es keine Rolle und man kann sich die Zustandsabfrage bei der UND-Kategorie sparen?

Ich habe auch immer die „und“-Abfrage drin, ob an oder nicht, um nicht unnötig einen Flow abzufeuern.

Aber ich habe auch ein zwei flows wo es nicht abgefragt wird und einfach auf an gesetzt wird, egal ob schon an oder nicht. Ich glaube nicht, dass es einen großen Unterschied macht.

Ich mache es lieber mit der „und“-Abfrage, da es mir logischer erscheint.

Aber es ist wirklich egal, wie du es erstellst. Gibt deswegen keine unangenehmen Nebeneffekte.

2 Likes

Hallo @Markus_F, @DirkG & @PhilS,

so schaut es bei mir derzeit mit der Chronograph App aus:

Nur wenn man den Gerätezustand aufnimmt, kommt man auch hier nicht ohne 3 Flows aus, da in diesem Falle bei Betätigung des Bewegungsalarms, nicht der Timer zurückgesetzt wird.

An sich weiß Homey ja ob ein Gerät eingeschaltet oder ausgeschaltet ist und sollte es einen Befehl bekommen wie Gerät xyz einschalten, wäre es aus meiner Sicht nur logisch diese Prüfung entwicklungstechnisch abzubilden um Funksignale zu sparen und dies nicht jeweils über Flows abbilden zu müssen, da man sonst in der Tat eben immer einen mehr bräuchte oder verzweigte Konditionen.

2 Likes

Ich habe das über Zonenaktivität gelöst, haben die gleich Funktion wie die Chronograph App


Zum anschalten.


Nach einer bestimmten Zeit und wenn in der Zeit keine Bewegung registriert wird ausschalten, ansonsten Zeit verlängert sich die Zeit.

Da bin ich bei Dir. Meiner Meinung nach ist das aber von den Richtlinien der Funkstandards abhängig und Athom wird dann auch keinen Einfluss darauf haben. Bei Z-Wave wird mMn nämlich trotzdem z.B. ein „An“ Befehl gesendet, obwohl der Aktor bereits an ist.
ACHTUNG: Das ist aktuell „gefährliches“ Halbwissen von mir und ich muss mich noch mal recherchieren und mich schlau machen.

Wobei ich dann aber auch der Meinung bin, daß außer erzeugter Traffic nichts weiter passiert. Warum sollte auch? Wenn an, dann an. Ein zweites Mal anschalten funktioniert ja nicht…

Allerdings wäre hier wirklich mal interessant, was bei einem erneuten Befehl an ein Gerät im Gerät selbst passiert (Datentechnisch).

Zumindest für Z-Wave kannst Du Dir das in den Logs anschauen. Sieht man schön wie dann eine Befehl gesendet wird und auch wieder ein neuer Status empfangen wird.
Somit macht es durchaus Sinn den Status als Bedingung einzusetzen um das Netzwerk nicht sinnlos mit Traffic zu belasten.

Okay… Da ich kein einziges Z-wave Gerät in Betrieb hab, wird das schwierig. Ich muss mir direkt mal die Shelly Geräte näher anschauen. Evtl. sieht man das Verhalten da auch iwo. Zigbee sind meistens nur EndDevices die eh nur einen Zustand liefern aber nicht erhalten.

Das wollte ich auch sagen. Es ist ja ständig Traffic vorhanden. Sämtliche Sensoren schicken bei Änderungen von Temp., Lux, RH, Bewegung usw. Daten ans Gateway. Aktoren schicken und empfangen auch ständig Daten wovon man nichts mitbekommt.
Je nach Anzahl an Geräten kann somit schon ordentlich Traffic entstehen. Wenn man Abends z.B. diverse Geräte per Flow auf einmal ausschaltet, kann es zu Verzögerungen einzelner Geräte kommen. Deshalb gehen einige hin und verzögern jeden Befehl um 0,5 - 1 Sekunde.
Dies bezieht sich auf Z-Wave.

Das verstehe ich ehrlich gesagt nicht ganz :slight_smile:: Homey weiß doch je Gerät ob es derzeit aktiviert oder deaktiviert ist z.B. bei einem Smart Plug (wird ja auch in der App entsprechend dargestellt). Somit müsste eigentlich kein erneuter Befehl rausgehen, um etwas einzuschalten, wenn Homey weiß, dass dieses Gerät schon aktiv ist - unabhängig vom Funkstandard. Oder übersehe ich da was?

Ich denke aber vllt. ist Homey schon so schlau. Ich habe heute z.B. noch Folgendes eingerichtet, um die Steckdose meines Akku Staubsaugers nach 5 h automatisch zu deaktivieren:

Hier habe ich extra einen Sprachbefehl eingebaut, damit ich mitbekomme, ob es häufiger aktiviert wird und in diesem Fall passiert es auch nur einmal bei Klick auf die Steckdose (an) oder eben wenn via Homey App eingeschaltet wird. Ich nutze dafür die OSRAM Smart+ Plugs (ZigBee).

Ich habe jemanden gefragt, der aktuell im technischen Support von Aeotec arbeitet und davor bei Z-Wave Europe beschäftigt war. Er hat mir mitgeteilt, dass trotz bereits eingeschaltetem SmartPlug ein „An“ Befehl geschickt wird (Z-Wave).
Warum das gemacht wird, kann ich nicht sagen, hatte ich ihn aber auch nicht gefragt. Fakt ist jedenfalls, dass zwischen Gateway und Device immer wieder Daten ausgetauscht werden. Erstens bei Änderungen der physikalischen Größen (Temp. / RH / Lux usw.) und zweitens zu Überprüfung, ob die Devices noch erreichbar sind oder nicht. Vermutlich werden auch Daten bzgl. des Routings übermittelt, schließlich wird das Routing selbstständig optimiert. Der mit großem Abstand meiste Traffic fließt allerdings von den Devices zum Gateway. Dies kann man gut hier erkennen: https://developer.athom.com/

Ob es jetzt Sinn macht den Zustand des Devices als Bedingung bei DANN mit einzubinden, kann ich nach wie vor nicht bestimmt sagen, was aber vermutlich von diversen Faktoren abhängig ist. Wie z.B. Größe des Mesh bzw. Anzahl der Devices, Häufigkeit der möglichen Schaltvorgänge, usw.
Bei mir werden aktuell unter den derzeitigen Bedingungen (11 strombetriebene Devices, 4 batteriebetriebene Devices) im Schnitt ca. 20 Mal/Minute Daten ausgetauscht (errechnet aus den „Tx sent“ und „Rx“ Daten seit dem letzten Homey Neustart). Wobei ich dazu sagen muss, dass 2 SmartPlugs 6 von Aeotec mehr als 90 % ausmachen. Warum? :man_shrugging:t3:

Mit Zigbee oder WLAN im SmartHome-Bereich hatte ich noch nicht viel zutun, deshalb könnte ich zu Deinem Staubsauger-Flow auch nur mutmaßen, was aber nicht wirklich zielführend wäre.

Homey kennt nur den letzten empfangenen Status.
Es findet leider kein polling der Geräte statt! Wie es andere Z-Wave Gateways praktizieren. Geht also in der Kommunikation zwischen Gerät und Homey was schief, wird auch ein falscher Status in der App angezeigt. Die Werte werden nur bei App oder homey Neustart abgefragt (Netzbetriebenen Geräte) aber nicht regelmäßig!

1 Like