Homey Community Forum

[REQUEST] Additional options for Flow logic


Its a personal thing… I prefer creating multiple flows.

An advantage of creating multiple identical flows is:
It makes your flows much easier to understand and prevent entanglements.
Troubleshooting is easier.

(On the other hand, making it available does not mean you have to use it :wink:)

@Dijker, the comment of @robertklep makes sense to me. The reason i think that point 1 of @JeeHaa is not that difficult is because the when part of a flow is mostly event driven. Homey doesn’t need to ask for a value. When a state-change happend on a device, the new state will be send to Homey and based on that new value a flow will be triggered. That’s why i think adding multiple triggers for flows should’t be that difficult.

It’s not really that simple if you think about it: condition cards can depend on tags provided by trigger cards.

Consider the situation where you have two completely different trigger cards, with different tags: there’s (currently) no way for condition cards to handle such a situation. You’d need something like “if trigger was card “A user came home”, then if the user tag contains A, then continue; otherwise, if trigger was card “Temperature changed”, then if temperature tag was lower than B, then continue”.

The way flows work now is pretty much tied to having just a single trigger card.

1 Like

@robertklep, I agree that would be difficult to implement, but thats not how i think multiple triggers should work. @JeeHaa has a good and simple explanation how it should work. His point 1 is exactly how i like to see it

For these situations I split up the flow
(I really like to split up flows :crazy_face:)

  1. Calculate the value of a variable
  2. When a variable has changed use that new value in the execution of the flow
1 Like

Like I’m trying to explain, point 1 completely ignores the existence of condition cards.

Also, a bit later on in the post they elaborate point 1: “I guess effectively the same as multiple identical flows triggering on a different WHEN event”. For which I’ll refer back to my post and how condition cards will cause issues with this.

Yeah, that’s how it works now, but I think that for most people (especially beginners) it’s counterintuitive to have to structure flows like that.

1 Like

The reason i would like to see an option for multiple flow triggers is simplification. Currently I have more than 500 flows and 110 scripts on my Homey pro. And it happend to be even more. But i have moved Sonos, Samsung TV, Philips hue, climate control and other things to an old macmini. This way i could simplify flows considerably

Multiple triggers could limit that number of flows significant.

I tend to keep my flows as simple as possible. I have flows like: when triggerA then start flowB, and another flow: when triggerB then start flowB, and another flow…

Thats what could be simplified

That works because the “This flow is started” trigger card doesn’t have any tags so condition cards cannot depend on it.

@robertklep, no thats not the point. Normally you create a flow:
when triggerA then do some action. That action can consist of multiple flowcards
If you have multiple triggers that should trigger the action then the way i do it is by moving the action another flow ‘flowB’ and create multiple trigger flows. If a flow can have multiple triggers then you don’t need to split it up. it’s not more complex than that.

It feels like I keep repeating myself :roll_eyes:

The issue is that flows aren’t always that simple, because you can also have conditions as part of the flow: “when triggerA AND some condition OR some other condition then do some action”

There’s an inherent incompatibility between how conditions are implemented in flows at the moment and having multiple triggers.

1 Like

I wil stop this discussion. We talk around each other. I’am only talking about the WHEN part

Flows don’t just have a WHEN part…

@robertklep, You’re wrong, in this discusion, flows ONLY have a WHEN. The rest is part of the black box. You make it too big. That’s why we don’t get any further.

So you don’t mind that the black box doesn’t work for the lack of required local tags? Of course you cannot act as if the other parts of the flows are irrelevant.

@Edwin_D, Don’t you really understand what i mean? I Doubt…
For the last time i will try to explain what i mean.
The black box contains the CONDITION and the ACTION part of the flow. A flow will be triggered in the WHEN part by an event. Let’s say a variable changed. If that event happens then the next step is the blackbox. What happens there is not of any interest for this discussion. Thats why i call it a black box.

In this discussion it’s only about the WHEN and how I and some others would like to have this extended with the possibility of multiple triggers.
When one or more events (or triggers, how you want to call it) triggers a flow, then the same blackbox wil be ‘executed’ that is, the same CONDITION and the same THEN part.

The CONDITION is independent of the triggers The triggers can be ‘a door is openend’ OR a window is opened the CONDITION is ‘the alarmstate == ARMED’ (Don’t say you can use ‘groups’ or ‘heimdall’ for that, it’s just an example). So if any of these two events happens, the same CONDITION part will handel the next step

I hope you understand now what i mean

Sorry to say for you,
I will not say someone is wrong, but I agree if we disagree. :wink:

I fully understand and Agree with @robertklep,
I except the last reply where i think he says you can’t see the WHEN apart from the AND (or) and THEN(else) part.
You can separate the WHEN and talk only about that without consequences for the rest of the flow but that part will break. The Condition is in the design of Homey Flows not separate of the triggers, it is part of it!

for example the following flow:

This is perfectly working, [name] is a local tag from the trigger Someone comes home. [Luminance is one of my other sensors]

If I would be able to add a WHEN card “The sun sets” and or a WHEN card “The time is 21:05”

What would the evaluation of the AND part be?
Guess something like this, but I doubt is would evaluate to a True as parts (TAGS / tokens) of the trigger come back in the condition.

Actually we can say Athom already implemented “multiple triggers” some time ago,
just not what you expect in multiple different trigger cards in the WHEN part. (You probably can’t imagine it wasn’t always available. We even started without OR ans ELSE in the early Firmware in february 2016 :wink: )

They added some time ago cards like this, disregarding the device type/brand it triggers for a battery value. Also available for all type of alarms. and a couple of others
It perfectly reports the [Zone], [Name] of the device and [Value] of the device that triggers.

and for Alarms:

Seeing the difficulty of explaining what you think “should not be too complicated to implement”
is why they don’t want to implement it as that is against the design philosophy of a simple to use product. (if I remember correct from earlier conversations with the developer/founder)

In my opinion: Worse to have a to complex product and users constantly asking why two certain trigger cards combined in the WHEN part don’t act the way they expect than to explain those users to create two flows for it.


@Dijker, Ok, you have a point (Or even two :slight_smile: ), I didn’t mean to be rude or disrespectful. My apologies for that.
I see your point with tags. That will complicate things but stil not make impossible.

If I would be able to add a WHEN card “The sun sets” and or a WHEN card “The time is 21:05”

that’s why the discussion from the start of the post was multiple triggers in the WHEN with an OR. an AND is more complex. I understand that.

1 Like

Not implemented by Athom, but “whichever comes first” multiple trigger flow functionality is out there:

As many triggers as you’d like:

Both have a learning curve though.

1 Like