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.
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:
The card itself takes a considerable amount of time to complete
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?
All cards that fetch or post data through an https request.
Cards that start another flow.
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:
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.
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.
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.