I’m sure this is not a new request, but it would be great if we could use a bit more logic in flows.
Also allow OR in WHEN Statement: e.g. WHEN time is 08:00 OR MyButtonPressed OR MotionDetected THEN TurnOnLight
Prevent Concurrent Flows: prevent new flows from starting when another instance of it is still running
Allow setting delay per 0.1s instead of 1s. In some cases 1s is just too much and 0.1s may be enough.
Synchronous Execution: start cards one after the other as defined in the flow (in order to make flows more predictable)
Allow one additional nested THEN level: … THEN (IF Time >20:00 THEN DimLevel=20 ELSE DimLevel=80)
Especially 1. would be extremely useful and should not be too complicated to implement (I guess effectively the same as multiple identical flows triggering on a different WHEN event).
BTW: The concept of cards and “AND” not being shown as part of the “WHEN” condition is something you need to get used at (to me “AND” belongs to the “WHEN” statement).
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.
Its a personal thing… I prefer creating multiple flows.
An advantage of creating multiple identical flows is:
It makes your flows much easier to understand and prevent entanglements.
Troubleshooting is easier.
(On the other hand, making it available does not mean you have to use it )
@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…
+10
)
)