As create more automations (and/or migrate from node-red) I find my self creating too many helpers just to be able to create pair of “if” and “if not” automations.
For example, lets say that I want to create this automation:
When I am not home, it is between 10pm and 5am, and the temperature is bellow 25 degrees the external fans should run at full blast. But If I am home, then just the Kitchen fan should do that.
To do that, I would need to create 2 automations, one for when the requirements are met, and another when not.
I am proposing to add a new step on the Automations so that instead of
When
And If (optional)
Then Do
We have
When
And If (optional)
Then Do
If not Do (optional)
So that when the When goes to true runs Then Do and when it goes to false runs If not Do.
What is wrong with the if / else or choose actions? They can handle things like these just fine. In the automation editor they are called building blocks. If you use trigger id’s you can also react differenly on which trigger fired.
To avoid this whole topic from being deleted because of the answers you already have, I’ll change it from a feature request to a configuration question…
If you strongly dissagre, change it back, but this in fact was more a a question on how to instead of a request to fundamentally change the way HA works, which isn’t going to happen…
In one automation you can have it triggered on the value changing at all, or only to something specific, and then you can have multiple nested conditions up the wazoo so what you are asking is already included. Even in the action you can put nested if-then conditions as well. And, you can have numerous different triggers for the same automation too.
The sky’s the limit, what you are alsking for is already there
Fair enough. I just got the idea from what I do on my phone (Android) with Tasker, there you have “enter and exit” automations for when one specific thing goes to true or false.
As I understand now, I have to listen to all changes of the entity or template and then in the building block do one or another thing.
Typically you do not have to add triggers for all changes - just list the property you want to trigger on and then put nothing for the value to trigger on - it wll trigger then on any change
Regarding If I follow the time and temperature, will the Last triggered date on the automations list will reflect the last time an action was called, or the last time a trigger emitted something?
I think this post sort of answers your question by way of example.
The op is trying to limit thier automation by restricting it to only if it has not fired within the last 12 hrs (which answers your vocabulary question…)
So this means I have to be sure that all the conditions are correctly set in the conditions (UI “Also IF)” instead that in the “Then Do” “If” parts. correct?
A big NO. It can be, but people make a big mistake of throwing everything into one big automation, which then makes it very difficult to troubleshoot - or if they want to change the way the automation works or what it does - then it’s a big headache. Use several automations instead, and keep each one as simple as possible. That way when you want to change the way it works or enhance it, it is very easy. Trying to keep the number of automations minimized is a big mistake and does not help performance of the system at all, in fact it’s the opposite. Keep that on top of mind
