[QUESTION] Making a set of flows that trigger other flows quicker?

Nice to run such tests.
I did sort of the same with 6 flows, writing to the timeline
It takes here also about 0.5sec for the next flow to write a notification. I did several runs.

Also interesting maybe:
When I trigger 6 other flows at once by flow 0, there’s also a delay of ~ 0.5s, but not consistent.

Logged with Papertrails

1 Like

Cool! And very elegant way to do it. SIMPLE Log doesn’t log milliseconds, but I doubt I would’ve thought of using log anyway.

With regards to your test - I would have thought that running all flows from the first one would cut the needed time. But, scince your results show that elapsed time associated with executing a flow is quite regular, I think it’s safe to assume that measured flow execution time is at least ≈0.5s.

Now we know for sure. Do you have any similar flows using HOOP? How fast is that?
I still have to find a solution for my sensor triggered, time of the day depending, kitchen light temperature. What a monthful.

Thx :upside_down_face:
I was also surprised about the “starting all flows at once” outcome.
I’ve read on the forum all action cards are fired at once with no special order.
But the Papertrails log shows the opposite…

Triggering flows using the same changed variable for all flows, doesn’t make much difference, the order and delays are a like.
It’s similar to ‘start all flows at once’.

Odd side effect:
System memory use is going through the roof during the running of these flow sets

I’m afraid HOOP isn’t any quicker, and I’m not running it atm (I’ve only 512MB RAM).

Athom seems to have added some delays in between cards, possibly to prevent overloading the system. But they tend to keep quiet about stuff like this…

1 Like

So in theory we now can start 25 lights without adding delays? :grimacing:

Yeah, I’ve read it somewhere as well, and I think it was like that two years ago. After that I’ve noticed all tasks get run in order. Even calculating a variable value, and using it in the next task was going well every time. So yeah, I almost never use delays any more for allowing Homey to calculate.

This one is interesting! I haven’t done a test with the measurable results, like your log. But I have done something similar - a visual testing, triggering 1-5 flows with the same trigger, a 433 RF button press. This would trigger 1-5 hue spot lights to flash once. I’ve noticed that up to 3 flows, they would flash simultaneously, and when having more than 3 flows, it would start getting a slight delay. This is the main reason I use to enable/disable flows with common triggers when they are not used, to deload Homey and get better response time for the other flows. I’ve tried to get some views on that here.

If you haven’t deleted your test flows, you could check if running less than 6 flows makes them run faster. Or where the sweet spot is.

And if it’s so that HOOP only makes flows more compact, but doesn’t help speed the process up - it looks like I’ll have to start coding in HomeyScript. I’ve looked into it already. Writing script is not that difficult, you can find everything online, but Homey specific stuff is a whole different ball game for me. Calling in sensor values through the script:

Sorry to be a buzz-killer, but for flows (and for any processes in multiproc environment) it’s not only important, how the parallel processes are started, but also what they are doing (or which exact resources they are using).
If we have physical protocol able to switch (for rough example) one light per second, then there is no way to switch on all the individual lights in palace within the same second.
The same is widely valid also for memory, disks, semaphores…

Yes, in well developed system we may queue the 25 switch on commands in parallel and also finish the threads (flows) equally fast… but this not does The Real Thing faster, but vice versa - it may cause problems in operating system queue and also in timings… for example, if there is a “switch on” command in queue (still not executed), what answer we must then give, if someone asking the state of this switch? And more complex, what’s if the queue want to be smart and attempting to eliminate opposite requests?

About delays… i think, the best solution for that is to fix “operating environment” instead of messing with workarounds in end-user programs :wink:

That happens to be an example script in HomeyScript: “example-printSensorValues.js”

I ran some tests, this tends / tended to go wrong with zigbee devices.
But I only got wifi devices and this flow runs fine

-I can’t really discover much “0.5s” delays between the devices “Turned on” timestamps
-Some ‘Turned off’ timestamps weren’t available
-The “Turn all lights off” card however, seems to use some kind of delay
-“Lamp Overloop” Turned on" was delayed by 15s

"Lamp Aanrecht" / On 12:19.? / Off 12:19.33
"Lamp Bank R"     / On 12:19.00 / Off 12:19.31
"Lamp Berging B" / On 12:19.00 / Off 12:19.30
"Lamp Bijkeuken" / On 12:19.00 / Off 12:19.34
"Lamp Centraal K " / On 12:19.00 / Off 12:19.?
"Lamp Hal"      / On 12:19.00 / Off 12:19.32
"Lamp Overloop"  / On 12:19.15 / Off 12:19.?
"Lamp Staande "  / On 12:19.00 / Off 12:19.38
"Lamp Voorraam" / On 12:19.00 / Off 12:19.34
"Lamp Achtertuin" / On 12:19.00 / Off 12:19.34
"Lamp Lantaarn"   / On 12:19.01 / Off 12:19.?
"Lamp Spot L"        / On 12:19.01 / Off 12:19.38
"Lamp Spot M"      / On 12:19.01 / Off 12:19.30
"Lamp Spot R"       / On 12:19.01 / Off 12:19.34

2nd action card

Last action card

Yeah… I’ve seen it :smiley: I understood it even - it runs a sort of loop, going through all sensor class devices and pulling values assigned to them. What I haven’t figured out yet is how to get a specific value from a specific sensor. The same goes for the script to turn off all lights. No biggie. Turn off a specific one - weeeell… That’s where my limited knowledge steps in. :smiling_face_with_tear:
I’ll get to it eventually, I just don’t have the time to experiment with it now. shrug

But what puzzels me is that you guys who obviously do script (well?) don’t use HomeyScript for more advanced automations, and still rely on flows, or the sets of flows, to be more precise.

I’ve managed to filter on a sensor name

// Edited version of example-printSensorValues.js
// In this script we print a given sensor value.

// User input
// Enter sensor name between the " " signs
var sensorName = "My Sensorname"; 
// User input End

// Start of script, no user input required
// Get all devices
const devices = await Homey.devices.getDevices();

// Loop over all devices
for (const device of Object.values(devices)) {

  // Filter out your chosen sensor name 
  if (device.name == sensorName) {

  // If this device isn't available, skip it.
  if (!device.capabilitiesObj) continue;

    // If this device is a sensor (class)
    if (device.class === 'sensor') {
    log(`\n* ${device.name} * `);

      for (const capability of 
      Object.values(device.capabilitiesObj)) {
      log(`${capability.title}: ${capability.value}`)

That’s splendid, Peter! Thank you, once again!
It works!

Now, would you rather proceed with using this method of defining everything in the script, or defining all variables in the flow, prior to running the script from the same flow?


I’m not sure what you mean? Using a 'run script with an argument" flowcard?
And then enter the sensor name as argument in the flow card?

I like to play with it, but it’s too time consuming for me for creating automations (not enough knowledge), and I like to accomplish automations with the use of flows.

Yeah… I was thinking something along those lines, and I thought one could define more arguments, so that you could use those instead of finding them with the script… It gets frutrating when you get it enough to read it, but not to use it.

A few of my friends work actually with js, but I’m reluctant to bother them with my Homey self-inflicted problems lol. I feel it would be like showing a brick to a masoner. :smiley: So, I think I’ll stick to flows as well :smiley:

not running a loop would probably be faster, you need to call individual devices by their device ID.
The easiest way to get that would probably be this

let devices = await Homey.devices.getDevices();

   _.forEach(devices, device => {

     if (1==1){


         console.log(device.id + ", " +device.name + ", " + device.zoneName +", "+ device.class);



after that you can use await Homey.devices.GetDevice({id: "id here"})
edit: I guess you can use name too, I personally have a ton of lams called “lamp” :smiley:
get all conditionals, asign them to variables.

create your if and if else loops in this format

if(LuxSensorLiving < 10 && LuxSensorBathroom <10 && TimeVariable = 'Night'){
} else if(){} else if(){}....

Thanks Nick!
What I want to do is make my lights in kitchen turn on instantly (enough) following the criteria in the flow chart from the first post.
We found out that using flows is bound to use a few seconds, so next thing I want to do is learn to code over night :smiling_face_with_tear:

How do you define multiple arguments in a flow for HomeyScript to run? I’ve got only an option for one argument in THEN card.

I updated my answer to better help you on the way :wink:

1 Like

my guess is to comma seperate them :wink:

Tnx! :slight_smile:
I’ll look into it tomorrow!

EDIT (tommorow is now):
Thanks Nick. I was obviously long overdue for some sleep to get what I was doing wrong.

But this morning - Eureka time! The missing link (writing the whole process for reference for the others uneduceted like myself):

By using

const Devs = await Homey.devices.getDevices();

Find the capabilities in the log:

capabilities: [

And then, put the wanted capability to be read and stored in variable LuxSensorLiving (“the missing link” [Source]):

const LuxSensorLiving = device.makeCapabilityInstance('measure_luminance');

Okay. Now I think I have what I need to get all the needed criteria from the sensors, and I think I can manage if-statements on my own.

The next thing will be

  • Finding a logic/variable through HomeyScript, probably some getVariables thingy.
  • Finding how to activate hue scenes from the script.

I’ll keep the track of it in the post. Now, if you’ll excuse me, I need to go to work with what I’m getting payed for to do. Strike the last one.

let variables = await Homey.logic.getVariables();

    _.forEach(variables, variable => {



use this to discover the ID’s of your variables, call them the same way as devices but with var sensorliving = await Homey.logic.getVariable({id:""})

then call the value with sensorliving.value

Now we’re talking!


lux_sensor_kitchen: 49
lux_sensor_living: 34.83
dim_light_kitchen: 1
onoff_light_kitchen: false
state_shades_kitchen: up
onoff_guest_mode: false
onoff_sleep_mode: false
✅ Script Success
↩️ Returned: undefined

Thank you very much Nick!

Two general questions:
What’s the best practice for refering to devices - using IDs or names? I guess the latter can change, thus making maintenance a pain in the… and I could not get it to work either, but it would be easier…

Is there a way to refer to IDs quickly or do you always have to find it, copy it, and then use it?
And should IDs be hidden f.ex. when you take prnt-scrn to ask for help?

Okay, that was three. I’ll stop now. I’ll show my self out.