Advanced flow - Advice to make flow simpler

I made an advanced flow to control my screens and sunscreen. It works quite as I wanted, just need some finetuning with the actual parameters.
However, the flow contains a lot of different conditions, making the flow barely readable.

Do you have an advice how to make the flow more readable / easier?

To me the flow is hard to read because lines are crossing and sometimes run behind cards.

I see on the right 3 ‘any’ cards and behind that 3 groups of ‘then’ cards. You could replace the any cards with ‘start flow with tag’-cards

At the bottom left you use the trigger : ‘this flow is started with a tag’. You move all the ‘then’-cards behind this trigger . This way you have created a lot of space at the right which you can use to rearrange the condition cards.

To me it is not a problem to have more the one of the same ‘start flow with tag if that reduces the number of crossing lines.

My suggestion is not to reuse cards, but just copy them as many times as needed. So you will have less lines crossing and you can just read from left to right.

My idea was that it saves CPU, as it otherwise has to perform the same calculations. I understand your advice, will think about it

Good advice, wasnt aware of this possibility. Will integratie this

For making a flow more readable (the way the lines cross) I “abuse” the ANY card and use it with a single in single (or more) out.

That way you can “redirect” a line so iits not disappearing below flowcards

Update: ah I see you are also doing that on the right site of your flow

This part of the flow will never run!

The ALL card always check past on events started by one and the same trigger.

It is not a “Wait” until all conditions are true.

2 Likes

Totally true, don’t know how I missed that one.

Thanks.

Only when it is a really CPU intensive calculation, you can store the result in a parameter and read it when required. When the card is just a condition, the extra CPU time is neclectable. I would’nt care about CPU or memory load until it really shows the load is too much.

oh, I am definitely interested to read the updated version as I am in need of one myself. I intend to use it with a HUE Outdoor sensor (it can measure Lux and Temp) and Fibaro Shutters. Also the new “Aanhoudende waardes & Multi-select” (I don’t know the name in English version) flow card could be of use here.

In activity diagrams (that’s basically what advanced flows are) you can have crossing lines because of two reasons. 1. Sloppy arrangement of cards 2. No matter how you arrange your cards, some lines are always crossed.

General rule of thumb, situation 2 almost always means that you have a bug.

So I always learned that you should first try to rearrange your cards so that you won’t have any crossing lines. If at one point you fail to get rid of all crossing lines, try to arrange them with the least amount of crossing lines. Then focus your refactoring effort on the parts where the lines cross.

Another thing that I see is that you try to do a lot of things in parallel, which is sometimes good. But it’s good to understand that there are pros and cons to running things in parallel and to running things in sequence. Understanding these can help you make better decisions on when to use one over the other.

Running cards in parallel can significantly speed up your flows, but only in specific conditions. These conditions are:

  1. The card itself takes a considerable amount of time to complete
  2. The process can be offloaded to a separate thread.

You see, most cards in homey operate in the same thread, which means that they are run on the same cpu core. So even if it looks as though the cards are run in parallel, the cpu still handles them after each other.

So which cards could benefit form running in parallel?

  1. All cards that fetch or post data through an https request.
  2. Cards that start another flow.
  3. Cards that start a homey script which accesses system internals or also performs https requests.

All other cards don’t benefit much from running them in parallel. In fact, are also considerable downsides of running them in parallel so it might be better just running them in sequence. These downsides are:

  1. The “All” card itself adds overhead as it needs to await the responses of all the cards that are connected to it and verify that the result is true.
  2. If one of the responses is false, it is actually not worth it to perform the rest of the cards. Running these cards in sequence allows you to escape the flow early.

For instance, the “Calculate trend for Helderheid” and the “Median is groter dan 275” cards can be run first, if that is false, All the other cards under “Algemene Voorwaarden” and under “Voorwaarden voor screens” can be skipped.

1 Like

Another factor to consider when running parts of the flow in parallel is the use of variables. Especially when you update those in those parts of the flow that run in parallel. This might result in unexpected results: one part of the flow might change the value of a variable, while a part running in parallel is still expecting the prior value. In such cases it is better to run the flow in serial manner.