[REQUEST] Additional options for Flow logic

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

Thanks for all the responses! I understand this might result in some challenging combinations, but IMO they should be able to come up with a workable solution, at least for common simple scenario’s? Maybe by disallowing certain THEN options depending on the triggers? I guess it’s up to AtHom to figure out what would work within their design philosophy (which to be honest I also struggled with quite a bit initially, expecting more standard programming IF/THEN/ELSE approach instead of the “Cards”). :wink:

IMO it does not make sense to have a bunch of disjoint flows to reach one functional goal, although I also understand others might have a different view on that (personal preference). For examle the simple scenario “Pull up screens” might require as much as 5 flows:

  1. Pull up screen
  2. At time xx:yy in evening
  3. At Press button
  4. When it starts to rain
  5. When there is High wind

That’s why I ended up with many non-time critical flows that just run every 1 or 5 minutes, evaluating several conditions (Every 5m AND X, Y, Z) and act accordingly (THEN Do Stuff). In the example above this combines: 2,4,5 to pull the screens up immediately when needed.

“We know what users want!”


I have not tried but expect it can be prevented with Semaphore App voor Homey | Homey

And of course I Tried: It works for One global Semaphore that can delay flows with a maximum of 3 seconds to acquire the Lock on the global Semaphore or return false executing the Else part of the Flow is configured.

1 Like