Execution queue not in same order as in flow

Hello everyone!

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?

Thanks a lot for your help or ideas!


1 Like

The flows are not execute in order of the cards.
What you can try is to first turn of all the lights and then turn the rest on, but with a time-out of one ore two seconds.
Or maybe even more.

But then I have to put that delay to every following card. In my real flow I use almost 30 cards for several actions.
Can’t believe that the flow card order is being ignored…

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 :tired_face:

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.

1 Like

This is a great idea and I already tried it. It seems to work much better so far. I need to check it detailed but different flows seem to isolate the command queue “a bit”…

Thanks Peter!

1 Like

Yes Robert, thanks for your comment, I totally agree with you!

You’re welcome, Sebastian. I found out (the hard way :grimacing: ) 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

So literally converting cards to entire flows…?

No, that’s not what I meant.
For example, when I use the flownames of my 1st example, it can look like this
L1-3 Flow1A
L2-3 Flow1B
L3-3 Flow1C

Yeah, and if materialize that, then:

  • For every flow set a option “(a)-sync”
  • 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 :wink: 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 :wink:

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.

Yes, but cards that are synchronous, for instance Logic cards that modify/use variables, are also run in parallel.

Using a JS analogy:

let a = 0;

a = 1;
sendNotification(`The value of a is ${ a }`);

You’d expect the notification to be “The value of a is 2”. With Homey, it’s “The value of a is 0”.

I guess that makes sense for most people (I mean, why would Athom implement it like that?), but not to me.

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.

That’s true.