Perhaps a silly question: what is the use of the ANY operator in Advanced Flows.
Directly connecting cards to the next cards work just as well, I have tested.
What am I missing :
Kind regards
Theo
Kind regards
Theo
Nothing they are just for organizing the connections literally doing nothing.
Imagine it means âOrâ, same as without the ANY
Thanks, good to know.
Indeed it adds more structure to the flow.
Technically there is 1 situation where it can be useful (and donât want to put all the conditions behind each other, as in general I like the ALL card better then the cards behind each other, or snaking the wires), as example (though more useful if you have more conditions then the example 3):
Translated:
- Today is a sunday
- [OR] Today is a monday
- [AND] Nobody is home
But in the end, it is indeed just a structure thing.
5 Likes
its a bit older topic but I just wanted to contribute.
If I have several cards with the same type, like number, and I choose the ANY card to âaggregateâ into one following card, I would expect that the outtput of the ANY would realy be aggregating.
for example
I have three cards and that output type number, I want then all three to be processed by a logic card (>y). Now I have to choose ONE of the three number tags while I expect to see just ONE (any of the three) number tags.
Do you follow me? I can only pass ANY âtriggerâ event, but not the context.
I understand what you are saying. However, the Any-card does not work that way. It does not affect/change/combine values of prior flowcards. I just directs the flow. In a subsequent flowcard you would always need to refer to a specific variable/tag.
If you want to aggregate number values, then you need to add a Logic card before the Any card, that sums those numeric values and creates a new tag/variable with that sum.
The problem that I see is you can connect many different cards with different tag types to the input of the ANY card, so which one would be passed through, plus the ANY card âtriggersâ the following card as soon as âanyâ of the inputs become active, so there is no guarantees which of the preceding cards it will be. It would then be down to the user to manage race conditions that could make the Flow unpredictable.
When you are designing a Flow, it seems logical in that circumstance what should happen, but Athom have to think about endless possibilities of how that card could be used and what seems like a simple request soon becomes a massive range of ways it could go wrong.
I only see / use the ANY card as flow beautifier, make things clearer.
By using 1 or more in a line, you can force lines to be drawn a certain way. Like âconnecting the dotsâ.
And useful for uncluttering + less line drawing:
Hi,
yes well I know as Iâm using it for some years now and bumbed into this thread. I always had the feeling the ANY didnt really âdoâ something.
thanks for the clarification.
someone has a good advice on how to (pre) aggregate âanyâ incomming number tag into a new numbertag?
The any card not just makes things look more beautiful. It does way more than that. It is true that anything that can be done with the any card can also be achieved by tying all âwhenâ cards to all follow up cards, but only if the following two assumptions are true:
- Only one of the âwhenâ cards can be true in one flow.
This might not be true in all cases. When 2 âwhenâ cards will be true in a flow, not using the any card, and tying both âwhenâ cards to all follow up cards directly, will cause the entire follow up flow to be called twice. This might not be what you wanted.
- All conditions are resolved instantly.
Some âwhenâ or cards might actually be connected to cards that fetch or execute things asynchronously. This will cause the when card to be executed later. sometimes even seconds later. This might lead race conditions when the flow is triggered multiple times, or when the first assumption was wrong.
The âAnyâ card is basically a wrapper around the nodejs function âPromise.anyâ. As soon as one promise resolves true, the flow continues, but all other promises are not being followed up on. It solves situations where the above assumptions are actually not true.
This following example might make it more clear:
Likewise, the âAllâ card implements the nodejs function Promise.all. It awaits all promises and requires all of these to resolve true, before continuing. If one sub flow is taking longer than others, the âAllâ card will wait for it to be completed as well.
1 Like
Though this is correct in theory, in practice it is highly unlikely that multiple triggers occur at exactly the same time (to the milli/micro second level). Which means that the flow is initiated multiple times anyhow.
You can use the standard Logic card to add/sum numeric values via the:
- Create ⌠as Text tag
- Calculate variable as âŚ
Replace 1, 2 and 3 with your numeric tags.
The first one results in a text tag (âResultâ) that you can use in a following card.
The second one result in an update numeric variable that you have to create first.
Thatâs true. In Homey, all card basically return a promise, and even if all cards are triggered simultaneously, they will still resolve micro seconds after each other, so follow up cards are still triggered multiple times. However, it will be less of a problem if it is triggered almost instantly with exactly the same values. It becomes a bigger problem when it one card is resolved multiple seconds after the other one, as all kinds of unexpected behavior might be introduced.
Regardless, I think it should just be best practice to:
- always use the âanyâ card if applicable;
- prefer the use the âallâ card over connecting cards sequentially;
- only connect cards sequentially if youâre absolutely sure no cards runs anything asynchronously.
1 Like
I think your best practices are personal preferences.
I never use the ALL block, I prefer the daisy chain way, which to me is more clear (to quickly see whatâs happening).
And I only have to draw half the number of lines.
My best practices are not just personal preferences, and your example actually shows the importance of it. You actually made a mistake in your example. When you tie the cards sequential, the order in which you do them matter. Both scenarios are not doing the same thing. The first scenario already escapes the sequence when the first statement is false, meaning it wonât reach the any card when it is not after sunrise. And if the time is not between 6:00 and 23:30, it can not simultaniously be within 6:00 and 23:00 in order to reach the azimuth is between 200 and 300 card. So the any card will never be reached. The second scenario does reach the any card. This is exactly why in programming, you generally want to avoid situations where the order of operations changes the outcome.
Besides this, there are also situations where running the cards in parallel can actually be way faster. Especially when you dealing with asynchronous task that could take several seconds. I believe we discussed this issue in a separate thread before, but I hope the following example explains it more clearly:
Preferring the use of the All card, or in programming the use of Promise.all, is not just my preference. It is industry standard in almost every programming language in every agency I worked for in the past 2 decades. You run things in parallel when you can, and you run things in sequence when you have to. This prevents mistakes, and is faster in almost every case.
