How to simulate "not" (else) in advanced flows?

In any case - I would still like to, like the subject says, simulate it in some way.

Chaining two conditions creates logical an AND but the lines and the ALL are not the AND function

Outputs in Homey AF are not True or False, they Trigger a connecting card but have no other state than “trigger”. The ELSE output of Condition isn’t True nor is it False, it triggers on the equation of the condition defined in that card. (and usually triggers on the outcome of the Condition is False )

Like what is the RED Line? It isn’t True, nor False, nor Error, it just Triggers the next step when the execution of the condition produces an Error.

Please show your compete Flow!

The Conditions have no Start, you need an Trigger to start evaluating these conditions.
The moment you trigger all these conditions if any is false ANY will immediately continue, ALL isn;t waiting anymore and just the flow quits after the ANY is executed.

So with a Trigger on the Left connecting to all 5 conditions, ALL or ANY will trigger almost immediately after the trigger.

I haven’t made the flow yet, because I’m looking for a way to (easily) create a way to do something else if the “all” doesn’t trigger. This means all the flows leading to the all must have executed (which is why I cannot use the “any” function).

I understand what you wrote in the previous post, but I want it to be synchronous. The any function isn’t. It’ll fire as soon as the first yellow line activates.

Also, it adds stupid amounts of extra “circuitry” to have to make two different tests.

And on exact that moment it is decided the Other can never happen
If you want it in logic:

X AND Y AND Z => ALL

As soon as X OR Y OR Z is False => ANY … If I know one of these to be False I don’t evaluate the two others as that doesn’t matter anymore. Therefore Why should it be “synchronous”,

But the X Y and Z are not the lines in your flow, they are the conditions in the left column.
The lines are the triggers, just in cat you execute multiple conditions in parallel and one is faster evaluated than another condition, ALL makes the asynchronous execution of your parallel started conditions follow up in a synchronous ALL or in direct ANY (if any condition is not met).

Please start a flow with creating a Trigger. and link it to the conditions.

By why wait?
If one of the condition cards runs down the false route, the ANY card will run and you can infer from this that one of the inputs to the AND card would be False, e.g. !ALL

The ALL card will never know that an input was False as the flow will complete once all the routes from the trigger have reached the end. The inputs to the AND card are never True / False but just triggered and only evaluated when an input is triggered. So, when an input is triggered, the ALL function will run, it will probably set an internal flag to show the input has been triggered and then check all the other input flags to see if they have been triggered. If they have all been triggered then the card(s) connected to the output will be run else nothing happens.

Remember, these are called Flows because the trigger signal flows through the connections to cards, which can steer the flow of the trigger. When you run a flow from the editor this is beautifully illustrated.

1 Like

Well, I guess it just boils down to preference, then - and maybe I should rather go the scripting route? I, and it seems I’m pretty much alone in that position, miss something like AND/!AND or if/else - but that’s probably just the programmer in me.

I understand the arguments people have for why it’s not there. I understand the flow of things, but what I don’t understand is why there has to be a limitation :slight_smile:

So the programmer in you should know that !(a AND b) == (!a OR !b), therefore the solution in your image is the correct one and simple to implement.
Also, if you understand the flow of things, you should understand the limitation of why it’s not possible to have the !AND card.

The scripting route is always there if you feel it is belter suited to you but I think overall it is a lot more complex than the Flow.

1 Like

Actually, it’s not impossible to implement. It would, how ever, require some logic to get both outputs of the card connect ed to it. And I know the logic impøementation, but like I’ve said - it will be uneccassarily complicated to maintain. But - it seems I’m the only one missing the functionality, so I’ll get by :+1: