I think I understood, that a flow can not be re-started before it is completed.
To see if my understanding is correct, I thought I verify this with a simple flow (picture 1), that starts with
1* when I push a button
2* send a notification “aan” to my time line
3* wait 10 sec.
4* send a notification “flow beëindigd” to my time line
I thought - that pushing the button again before 4* is completed, would be ignored.
My time line tells me other wise (see picture 2)
It shows “aan” → the flow is started"
it shows another “aan” → when I push the button again within 10 sec.
it shows “flow beëindigd” - the first instance of the flow is completed
it shows “flow beëindigd” again → the 2nd instance of the flow is completed.
Is this correct? (a flow can be started again before it is completed)?
Am I overseeing something?
Thanks a lot!!!
Ruud
1 Like
Yes this is very well possible.
You can trigger a flow every second, and have the action card delayed by an hour.
Homey even has a built-in sensor which disables flows with more than 60 running instances. Meaning, when a flow is triggered over 60 times, and 60 ‘copy’ flows were not finished yet.
2 Likes
Thanks for confirming Peter. 
1 Like
Flows are run in seperate instanses for every trigger.
If you want to avoid that you may use Advanced Triggers app and set the execution to sequential.
1 Like
Thanks Anders,
I understand that is available for Homey Pro only? (I have the Homey bridge + cloud version)
But good to know for future upgrade 
Ruud
I guess it is only available for Pro, but check whether the app is possible to install or not.
I do not have the bridge, never tested.
Another option is to set a logic variable like “Flow_Is_Running” to true once you start the flow the first time and set it to false once it has finished. And at the beginning of the flow stop execution if the logic variable is already set to true. So all additional triggers will be ignored.
1 Like
bit late ( scrolling thru topics )
but for this the easy part is ( on pro ) the app coundown
CountDown | Homey
for example :
if push on switch , start countdown 1 with 300 sec
if the countdown is at 30 sec do B
if the countdown is empty , do C
if push on switch again , reset countdown to 300 sec
if push on other swich.. stop countdown…
i have made several lightning plans with countdown
for example bathroom
if sensor is active – countdown A start with 300 sec
if Sensor is ative again , and lights are on , reset countdown to 300
if countdown is empty , turn off light
so wen i am in the bathroom for 10 min and leave then , at least after 300 sec the lights will go out
wen i am in the shower, lights remain on , because of the continues reste of the countdown till sensor is off and countdown is empty …
I have a flow that I don’t want to start if a copy is already running. For this, I have created a busy-variable (boolean) which gets set (TRUE) as soon as the work starts and reset (FALSE) when the work finishes or there’s an error, and I test for FALSE every time the flow starts (every 10 seconds).
However, I have observed that the variable doesn’t always get reset even though I have attached a reset to every error branch in the flow. I suspect this has to do with timing: the reset happens very quickly after the set and therefore the order isn’t always what you would expect (reset before set or vice versa).
I am now trying if BLL booleans behave any better than Homey booleans. I have a sort of workaround using a stopwatch but that’s rather ugly.
Has anyone else observed the same behaviour?
1 Like
I am using a similar setup in one of my flows that updates a status widget - with custom HTML code - from the Enhanced Device Capabilities on my dashboard, to prevent flickering when some triggers occur very frequently. I haven’t run into any issues yet with this mechanism.
I assume the route your flow cards are using between setting the boolean to True and resetting it to False, is serial (after each other)?
I did note in a different (unrelated) flow that sometimes it takes some time for a tag to get updated after the trigger occurred (in this case the track name of my Sonos speaker). The delay (in my case) was somewhere between 0 and 1 second. So I added a delay of 1 sec after the trigger, allowing Homey to update the tags related to the trigger flowcard.
Maybe a similar situation applies to your boolean variable. You could add a delay after the reset flowcard, so the flow runs for another second.
Yeah I’ve put a lot of effort into making my flow single-threaded/non-concurrent. So I set the boolean lock as soon as it starts, then reset it when it finishes. I test for the lock when the flow starts, preventing it from running when the lock is set. I have now added a 1-second delay before resetting and that seems to do the trick, adding to my conviction that what’s on the screen is not the actual reality. It may appear sequential on-screen but in reality some things will happen concurrently.
I have also tried Advanced Triggers with non-concurrency set and that seems to work (not tested thoroughly though) but I’d like to avoid extra apps if I can, I only have 2Gb. Maybe if you have a 2026 Homey Pro or SHS then you can add apps like there’s no tomorrow but I run out of mem already sometimes.
My flow triggers every 10 secs, it runs about 1-1.5 secs so adding a second at the end is no big deal for me. It’s to avoid rate limit errors when I log to Google Sheets, one of my most complex flows to date. I log every sensor, event and a lot of other stuff so there’s a lot of logging going on. My FIFO queue gets filled at an uncontrolled rate by different logging flows but the actual logging to Google Sheets is perfectly controlled at 10 second intervals. It’s unreliable at a 5 second interval with plenty of rate limit errors. 10 seconds seems reliable, I only get a rate limit error once a week or so and it’s able to keep up with the inflow.
If Athom would allow a variable in the tab name (like they do in the sheet name, I have done a feature request a long time ago), I could simplify my flow a lot but unfortunately now I have a lot of cards for every tab on a sheet (every tab is a category of logging) and I have multiple sheets due to size constraints. So it’s 24 sets of 3 cards… and that may be where some of the processing time comes from.
1 Like
I understand you have a complex flow that runs every 10 seconds. I just recently learned that a ‘start a flow (with a tag)’-card continues not untill the ‘subflow’ is finished.
Maybe this helps avoiding:
Not really. Logging can be very lumpy at times. So the system I designed with a FIFO queue being filled at one end by a lot of logging flows (at any speed) and being emptied at the other end by the single Google Sheets flow (at controlled speed) works very well and makes for an independent system of logging. I can easily add new logging if I want to without having to think about all the other logging going on (except maybe building a new category: an extra tab in Sheets and 3 more cards to handle the new category).
If I had the Sheets flow as a sub flow of the logging flow then I couldn’t control the timing nor concurrency. The current setup with a boolean lock for controlling concurrency and a boolean lock for error back-off (1 minute pause) works very reliably (now that I added the 1 second wait).
But thanks, I didn’t know it waits. Maybe I can use that in one of my flows.
