I struggle a bit with the behaviour of my flows in Homey Pro.
I want to set a specific configuration of lights. Regardless, what lights were on before. For that reason I start with the global command to turn of all the lights managed by Homey and then turning on my specific configuration of lights.
The problem is, Homey Pro is not execute the commands as set in the order of my flow. That means, while turning my specific lights on for the scene there is still the global off command executed. That results, that lights don’t get turned on as they get right after the off execution.
How can that be? Are not all the commands executed in that order in the flow?
Yes, unfortunately all action cards are fired kind of asynchronous, but not always (read this interesting thread )
An idea is, consider starting separating some flows and flowcards.
Your shared flow I call Flow1 in this example.
Then you can split that flow up to:
this flow is started
logic [fun] is No
switch off all lights
start Flow1B after 1s
set logic [fun] to Yes
turn all lights off
turn all plugs off
set logic [fun] to No
this flow is started
turn all Wohnzimmer Stehlampen on
Dim all Stehlampe to 65% after 1s
start flow 1c after 2s
this flow is started
… the rest of the other action cards
set logic [fun] to Yes
We’ve been told for years by Athom that “they know what users want”, so we can only assume that the majority of users don’t want flows to work as expected (a typical user would expect that flows are run in order, but Athom decided against that).
In fact, flows used to be executed in order (somewhat, see below) but that was changed years ago with firmware v2. From that point on, action cards were started in parallel instead of sequentially, which introduced a whole host of issues that remain until today. Adding delays between cards nowadays is the only official way of working around some of those issues. And from what I understand from the experiments that @Peter_Kawa links to, even Athom has introduced some internals delays to make it somewhat bearable
As for “execution in order”: action cards can conceptually be synchronous or asynchronous. The former type will do their thing and be done (for instance, logic cards that perform a calculation and set a variable with the result), the latter will start a command that may take some time (like turning on a light or performing a web request). Even when running the cards in order, Homey didn’t wait for the command to finish before continuing to the next card, which makes sense because Homey’s core doesn’t always know when a command has finished.
You’re welcome, Sebastian. I found out (the hard way ) grouping flows in folders and starting flownames with ‘codes’, makes it managable.
Flownames, if 3 flows are needed for 1 “function”:
L1-3 livingroom lights
L2-3 livingroom lights
L3-3 livingroom lights
For every card there set a option “wait for result”
Doable, but yes, i also think, is this the “user friendly”? This smells to be “so complex, i do not handle all the options…” So, for advanced users may-be The Script There it’s possible to do a “action” and also wait/check for results before next steps.
PS. About “strong execution order” - actually for Joe Average this is a “order of results”, BUT does Joe really want to wait also all the possible communication issues (re-re-re-…try); And what happens, if device is really unreachable?
So, may-be the current simple modus is better than the one, described above
What’s “user friendly” is to do what most users expect: actions cards are executed sequentially, in the order that the user put them.
Users don’t care about synchronous or asynchronous, although you can explain to them that certain cards (the ones dealing with external devices/services) will not wait for a result (because, like I said, Homey’s core doesn’t always know if there is a result, and some protocols, like 433Mhz, are send-and-forget so there’s never a direct result).
Even better, Home Assistant has an action “card” that can be used in the latter situation, where you can tell it to wait for a particular event to happen (so for instance, one action cards turns on a light and the following card waits for that light to report it has been turned on before continuing).
It doesn’t make sense to probably 99% of users that if you have an action card that sets the value of a variable and use that variable in a subsequent card, you can get the previous version of the variable instead.
And… actually it seems that the same 99% of users also do not care about exact order of execution. Khmm, and probably they do not know about possibility to set the variable in cards, like me - yes, know, but right now do not have any use of this functionality in my own system, but have some nice scripts.
It seems, authors of current system had to do research, and found, that most of users care more about the fastest execution of all the tasks. So, we, who know to wait such edge conditions, let’s just take, as it is - a little drollery with good (khmm, or may-be not - at least attempted to explain) reasoning.
PS. As topic is solved - i do not post here anymore. If… then in next topic
Yes, that’s what they probably thought. And now there are big issues with Homey being overwhelmed if you have more than about 3 action cards, especially when those cards send commands to devices. A lot of the time, one or more commands get lost and people have to resort to adding delays between cards to get it working.
I’m on the fence with this one. On the one hand, it is nice that all my devices act simultaneously, and personally I haven’t had an issue with that, but I can see there are times when it would be good to wait.
I haven’t had to add delays to my flows for a long time, even the ones that control lots of devices, like closing all my window covers when it gets dark or switching everything off when everyone has left home.
When I write my apps I try to return ASAP, e.g. as soon as the command is acknowledge, not when an action is complete. So when closing a window cover, I don’t wait for the cover to close (with RTS that is not known anyway), I just wait for the API to acknowledge receipt of the command. I know that is not always possible though.
One instance where it would have been nice to wait is when capturing an image from a camera that you then want to send to a phone. To get around that, I had to create an trigger card for “Image ready” so the user can use the capture action card in one flow and then send the image in another flow. I also cheated a bit and created a condition card “when image is ready”, that captures an image and then waits for the image to be recorded before returning true.
As I’m used to event driven programming, the asynchronous flow cards seem logical, but for someone new to programming I guess it can be confusing if they don’t know that is what happens.
That’s why I mentioned the distinction between synchronous and asynchronous cards: it makes most sense to me that Homey executes sequentially, in order. But if a card is asynchronous, it should not wait for the result before continuing to the next card.
I’m quite sure that you wouldn’t notice any difference between that method and the current method of executing each card in parallel (which, under the hood, will still be sequential at some point because Node.js is single-threaded), with the added bonus that things like setting variables and using them in a subsequent card actually works as expected.
Which is sort of the way it works?
The system runs each card in “parallel” (as best as a single-threaded system can). So each card can wait for a result to determine if it works without blocking the other cards. Hence in the flow editor, when the flow is tested, ticks or crosses can appear on the later cards before the previous cards. So I guess it is a subtle difference of the card being asynchronous (not blocking the system) and being run asynchronously (in parallel by the system). Obviously the card has to be friendly to the system with the way that it waits so that other cards get some processing time.
But there are no synchronous action cards in Homey. Every card is run asynchronously. So this is your perception of what should be a synchronous action.
I’m not denying it can be confusing, but if you consider every action card to be asynchronous then it is a bit less so.
In some ways it could do with an option on each card “Don’t run any more actions until this one completes”, but that text might be a bit long:-)
Well yes, but that’s by choice. Before firmware v2, cards were started sequentially, and I’m pretty sure that it wasn’t required to update apps between v1 and v2 to suddenly account for how they got started internally.