Just search this forum for “motion and timer” and you will find plenty examples, solutions, misfits etc…
As a starter you can use this nice clean example, that shows the principle how to keep the lights on when motion is detected again:
Is that really the way to work with flows? So many people rave these flows are the top selling point for Homey Pro… but actually that simple flow should be as a one flow… What do you think?
Because you think of a loop, you might be thinking in term of one computer program for your one use case. And in one computer program you can loop and test for something to happen, like motion detected, timer ended, motion not detected. Then that one computer program waits for 3 events. Loping for something to happen is a waist of CPU power. It is better the CPU just waits for an event to happen, in computer terms “wait for interrupt”, in Homey flows the WHEN something happens card. And then the accompanying code is executed, the THEN part.
So in Homey all flows of all your use cases are just one program, no need to group flows per use case. But maybe you can group advanced flows, I still don’t use them, because why use advanced tools for simple solutions? It takes more time to learn and understand. I also don’t like the swinging curves, I prefer straight lines for easier reading this flows.
My conclusion: a flow is an interrupt routine, just a part of a computer program. And in Homey you can write an interrupt routine as a simple or advanced flow. For most people easier than writing program statements, like Homey script or C, or whatever computer language.
Homey’s flows are very simple, for anything a bit more complex you need to use external apps and multiple flows. Some people like it like that, other people don’t.
Personally I think Homey’s flows could benefit greatly from some features that, for example, Home Assistant’s automations provide:
When a certain condition has been true for a certain amount of time
The ability to wait for a certain amount of time for a certain event or condition to become true as part of an action
The ability to configure what to do when an automation is already running and it gets triggered again
Those would probably cover 90% of the use case of apps like Chronograph.
What is the problem to have three flows?
In Homey flows are very simple that mostly everyone can do simple tasks.
Flows in Homey are event triggered.
If you do it in Advanced Flow, you may use just one Advanced Flow with different trigger points.
If you insist to do it as one closed task, you may start doing Homey Script. I have now clue about Homey Script, but maybe you can it there in one script with different objects, which I guess is quite close to the different starting triggers in Advanced Flow.
It is indeed basic but can easily be tweaked. In your example, if the initial motion lasts for 14 seconds, then 11s later it turns off the lights which may be too early (I assume you want the lights off 10s after the start of inactivity). This requires an extra flow.
You are right that in your case many flows are needed to do seemingly simple stuff. You may tweak your demands to keep your flows simple or do it the hard way with more cards, complexity and headache.
Keep in mind the earlier comments by @Rmb and @DirkH in this thread that more flows is not an issue, when they are just waiting for an event to happen.
I am in favor of using built-in flows and capabilities to reduce cards as much as possible to keep it readable and maintainable.
With built-in timers (minimum is 1m) I get to 2 flows.
Note: the fixed 10s wait is not perfect when the motion duration of the sensor < 10s. It cannot be cancelled. Eg If after a 1 minute inactivity there was renewed movement and the device motion duration is 3s, then at 10s there is no movement and it turns off the light.
Options to solve:
Change motion duration:
Change minimum motion duration of the motion device to 10s (if possible)
or use the motion trigger to activate a virtual motion device with a motion duration of 10s
or reduce the 10s wait to the current minimum motion duration.
Use a lights off Countdown timer (3 flows, one external app)
Use a card for “The zone has been inactive for 2m” (increases the 10s wait->1m, 3 flows)
Use the flow card in the Device Capabilities app as mentioned (3 flows, 2 external apps)
The more you use (external) Countdown timers, the more cards you need and the more headache.
For 1 countdown timer (10s) I get to 3 flows (below).
For 2 countdown timers (15s, 10s) I get to 4 flows.
I like your first example, and I use a variation of this for my setup. It has worked really well to get a flash of the lights before they turn off from inactivity.
