I’m trying to create flows were many things happen in a series and for that I would like to create small delays in between every card. I can only manage 1 second delays and above. But I would like the delays to be at 100 millisecond increments instead. It this possible.
I really don’t want to create a series of flows just to achieve this.
Any suggestions?
The minimum is 1 second delay. With homeyscript it is possible, but you have to understand some JavaScript
It would be really cool to see this implemented. It is a small improvement and will definitely increase the usability.
E.g. I have 10 rolling shutters. I have a master button that controls all of them at the same time. In the flow, I need to put 1 second delay because if I don’t put any delay some rolling shutters will not receive the signal (probably too fast). This means that 10th rolling shutter only starts moving 10 seconds after I press the button. By accepting values smaller than a second (or decimals at all), I could probably reduce to to a total of 1 second delay on the 10th rolling shutter.
And then the “triggered more then 10 times a second” “feature “ kicks in!
Adding the 1-second delay is a hack around shortcomings inside Homey’s core. Instead of asking Athom to allow for sub-second delays, you could also ask them to fix these shortcomings.
I appreciate your reply, all attention helps this request so thank you.
Though, if I had any confidence that Homey would solve these core issues within the foreseeable future, I would have peace with not having the sub-second delays. I already gave up on that, and now would just like to make my workaround faster…
Maybe with homeyscript. In that case you can add a wait function between your commands. It is possible with milliseconds. If it works is just trial and error. But it could be a solution
Might work. For example, to wait 500 ms (= ½ second):
await wait(500);
Here a little script as a starting point. This script accepts a json string as input. Witch contains a list of flow names to call. This is only a starting point. In case of duplicate flows with the same name it wil pick the first flow found.
The code:
'use strict';
async function triggerFlow(id) {
await Homey.flow.runFlowCardAction({
uri: 'homey:manager:flow',
uriObj: { type: 'manager', id: 'flow', name: 'Flow', iconObj: null },
id: 'programmatic_trigger',
args: {
flow: {
id: id,
},
group: 'then'
},
});
}
const list = JSON.parse(args[0])
const flowsDic = await Homey.flow.getFlows();
const flows = Object.values(flowsDic)
for( const name of list ) {
const flow = flows.find(f => f.name === name)
if (flow) {
await triggerFlow(flow.id)
await wait(100)
}
}
To call this script add a homyscript with params card to the then section of a flow and in the params textbox type the list of flows to call between brackets. For example:
["flow1", "flow2"]
Delays in ms are also possible using the h.o.o.p. app (advanced flow editor)
It can add ‘wait’ cards with values in in ms AND can run all flow cards synchronously if wanted/needed
Perhaps using HOOP you won’t even need delays?
If you need it to run synchronised, you can just choose that as a argument from a HOOP trigger.
I realized it just now, when I wrote it down, Arie 
, and I used the synchronised option in the argument of this flow trigger.
For now it was a quick example of using delays < 1s.
But true that, if run synchronized Homey can’t “machine gun” all action cards with the problems that can cause.
True that, but I guess we’ll have to wait for the newly designed Homey Very Pro 3.07 
Maybe it’s possible with the < group > app.
There is an option “Time delay in microseconds between transmission to each device in the group.”
But I haven’t tried it myself yet.
That works with < group> . Microseconds is a typo in the app, the value is in milliseconds.
If you enter 100 f.i., all group members are switched one by one with 0,1s pause between each.
Indeed, instead of trying to find workarounds (could be fine for a short period of time) perhaps more people should be asking Athom to fix the problem itself.
The more people that use workarounds, the less pressure Athom feels to solve the real issue.
