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

Hi guys!

I remembered one thing while chatting with @Peter_Kawa in a different thread, that I wanted to check with you with more knowledge than me. :slight_smile:

Is it possible to streamline, optimize and make quicker the following set of flows, without use of HomeyScript scince I canā€™t script (yet?), nor with the use of HOOP.

I have an old flow chart doodled by hand at work when I was making automation for the kitchen light.

Briefly, I want the sensor to turn ON the light to dimmed if dark in the house and outside; white light if day and dark enough inside; or warm light if dark outside and the other lights are ON inside.
And this could apply to the other flow sets as well.

It looks something like this in the Homey app. (The flows today are a bit different than the chart)

What happens now is that it uses anywhere from 1 to 4 sec to turn on the light.

Is this how it is, or can it be optimized when running a flow after flow? Is the best way actually to script this? Or using the HOOP app? (And question for guys who are using the HOOP for such things - is it quicker than the ā€œregularā€ flow after flow method?)

Between what two point are you measuring the 3 seconds?

Thatā€™d be between 1.1 and 1.4. The whole set in another words.

Update - Case study

Intro
Iā€™ve run a test to see what happens with a set of 6 flows, that run the adjacent flow.

Test method

The flow 1a starts 6 stopwatches, Test1, Test2,ā€¦ Test6. Each flow stops its respective stopwatch (i.e. Flow 3a stops stopwatch Test3.)

Flow 1a starts stopwatches, starting with Test1, and pausing the Test1 stopwatch in the end to see how long it takes to run all tasks in the forst flow.

Results
The total amount of run time for the whole set was around 2.50s (Test6). This was a recurring result (see pictures).

Furthermore, each flow seems to take around exactly 0.50s except the first flow 1a. Reason is probably that it only measured tasks in THEN, without WHEN and AND.

Edit: Even running all flows from the first one, doesnā€™t seem to change the measured elapsed time for executing a single flow (see next post).

Adding AND criteria, as well as additional THEN tasks does not seem to increase the time. However, this probably isnā€™t the case scince my original set of flows only has 4 flows and total time was around 3+ seconds.



Conclusion
If you want to run an instant respond automation, doing so with a set of flows that reference to each other may not be the quickest method to accomplish that.

Side note
This would perhaps be better to do in HomeyScript. I will test this in HOOP app once I install it.
Another fun test would be to see how increasing the number of the same triggers effect the time needed to start, and execute the flows.

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

Logs:
-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?

YW!

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