Mostly point 1) would be very very useful. Nested thens, well nice to have I guess but no difference to just launching the next flow. I would most likely go with just another flow being triggered to keep things organized. But that’s just me +10
Guess you can give your hope up on this,
has been a request from the first releases but as different flow triggers can have different tokens (Temperature changed has [Temperature], Someone came home has [name]) …
many combinations have no options to combine multiple triggers in a flow. That is against their design philosophy.
just create multiple flows triggering a executing flow.
Same for your last request.
That’s sort-of how firmware v1 and earlier worked (but see below for a caveat on why this isn’t as easy as it sounds). Starting with firmware v2, flow actions are started concurrently (at the same time).
The reason why synchronous execution sounds easier than it is, is because a lot of flow actions are asynchronous by nature, especially those that send commands to devices (over WiFi/Z-Wave/Zigbee). “Real” synchronous execution (at least how most users would expect it to work) would mean that a flow action card would send a command and wait for some sort of acknowledgement from the device before continuing to the next flow action card.
Since acknowledgements aren’t mandatory (or even available) in a lot of protocols, all Homey can do is send the command and hope it gets received.
Long story short: synchronous execution would only work for cards that are synchronous by nature. But I do agree that synchronous execution would make flows more predictable: it doesn’t really make sense to have, for instance, a card that calculates the value of a variable and a following card that uses that new value to be started concurrently, as they do now. But apparently, Athom thought that the perceived speed increase of starting cards concurrently would be better than starting them consecutively.
@Dijker, the comment of @robertklep makes sense to me. The reason i think that point 1 of @JeeHaa is not that difficult is because the when part of a flow is mostly event driven. Homey doesn’t need to ask for a value. When a state-change happend on a device, the new state will be send to Homey and based on that new value a flow will be triggered. That’s why i think adding multiple triggers for flows should’t be that difficult.
It’s not really that simple if you think about it: condition cards can depend on tags provided by trigger cards.
Consider the situation where you have two completely different trigger cards, with different tags: there’s (currently) no way for condition cards to handle such a situation. You’d need something like “if trigger was card “A user came home”, then if the user tag contains A, then continue; otherwise, if trigger was card “Temperature changed”, then if temperature tag was lower than B, then continue”.
The way flows work now is pretty much tied to having just a single trigger card.
@robertklep, I agree that would be difficult to implement, but thats not how i think multiple triggers should work. @JeeHaa has a good and simple explanation how it should work. His point 1 is exactly how i like to see it
Like I’m trying to explain, point 1 completely ignores the existence of condition cards.
Also, a bit later on in the post they elaborate point 1: “I guess effectively the same as multiple identical flows triggering on a different WHEN event”. For which I’ll refer back to my post and how condition cards will cause issues with this.
The reason i would like to see an option for multiple flow triggers is simplification. Currently I have more than 500 flows and 110 scripts on my Homey pro. And it happend to be even more. But i have moved Sonos, Samsung TV, Philips hue, climate control and other things to an old macmini. This way i could simplify flows considerably
Multiple triggers could limit that number of flows significant.
I tend to keep my flows as simple as possible. I have flows like: when triggerA then start flowB, and another flow: when triggerB then start flowB, and another flow…