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.
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.
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?)
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.
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
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ā.
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ā¦
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 TheRealThing 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
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
Yeahā¦ Iāve seen it 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.
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.
// 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. So, I think Iāll stick to flows as well
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
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ā
get all conditionals, asign them to variables.
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
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 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. 
