Good point. I definitely only want to trigger on an “off” to “on” state transition.
Thus, the tweaking 
I don’t actually have a reliable binary sensor to test this with, but I assume adding a == 'on' would fix things?
Why from “off”?
Why not just to “on”?
What if it’s “unavailable” to “on”?
Ditto for your first post which duplicates what I had posted earlier but your time range is too wide because it logically ORs the two tests thereby letting it accept an hour greater than 17:00.
now().hour >= 9 or now().hour <= 17
It’ll definitely help.
{{ is_state('binary_sensor.front_door_contact', 'on') and
9 < states.binary_sensor.front_door_contact.last_changed.astimezone().hour < 17 }}
1 Like
For example, for my irrigation automation.
I want you to water every morning, in the afternoon only if the temperature is above 28º and at night if the temperature is above 15º.
Currently I have 3 triggers and then a choose to decide whether or not I have to water depending on what trigger has been triggered and the current temperature.
If in the same trigger I could specify the condition, it would be quite simplified and you can see directly that this trigger only fires with that specific condition.
The templates are fine, you can do impressive things on a single line, but this would only be available to a certain group of people. I could do it, but my parents couldn’t, and I understand that Home Assistant should be thought of for everyone.
1 Like
I don’t think so.
Home Assistant has very a narrow group of people that can and should use it.
The day that it is for everyone is the day that it will start to loose the advanced users, since you can’t have advanced features and be for everyone in my opinion.
But I agree that it would be nice to have trigger id in the conditions too.
Not sure that it will help readability more than just a choose in the actions.
I think it could be confusing with multiple conditions that does not apply to all triggers. I don’t know. Perhaps this is just something you need to get used to.
That’s where you’re mistaken because it’s not. It has traditionally been a system created for home automation hobbyists. Very little of it is understandable to the average consumer unless they invest time and effort to learn it.
If you want to attract the attention of a software developer to implement your Feature Request, you’ll have to think of a better justification than it’s too hard for your parents.
In each new version of Home Assistant, more configuration options are added directly from the UI, both in the integrations and in the automations.
Why spend resources to configure the Tuya / Google / Xiaomi account from a UI, which you will do only once, if your target audience is people capable of creating complex templates?
I understand that the main reason for this is to simplify its use to reach more people.
As long as you keep in mind that Home Assistant is only for “geeks”, the majority manufacturers will not support it because “they will figure it out.”
If something can be simplified without losing potential, it should be simplified.
1 Like
The majority of manufacturers don’t support anything other than their own ecosystems anyway.
You continue to justify this Feature Request on the basis that it simplifies the status quo. Moving a condition into a trigger doesn’t simplify anything. Defining a condition inside or outside of a trigger makes no difference from the perspective of task simplification.
In fact, allowing for conditions inside a trigger, as opposed to outside, is a conceptual subtlety that is unlikely to be grasped by the very people you believe would benefit from it (i.e. the technically challenged).
The current arrangement employs a clear separation of responsibilities between listening for events (trigger) and filtering them (conditions). The two work together to determine if the automation’s action should be executed.
1 Like
I think you have misunderstood, or I have.
I believe the request is to add trigger ID as an option in the condition.
Just like today you can set a trigger ID in triggers then in actions you can specify this trigger do this, and this trigger do this.
But in conditions you don’t have the trigger ID option
EDIT:
I believe I misunderstood.
Because trigger ID is in the conditions list…
The request is to add conditions in each trigger. So, the triggers would be:
- Trigger1: When A1 = B1
Condition: C1 = D1 - Trigger2: When A2 = B2
Condition: C1 > D1 - Trigger3: When A3> C3
Instead of doing the three triggers and then the conditions
-
Trigger1: When A1 = B1
-
Trigger2: When A2 = B2
-
Trigger3: When A3> C3
-
Conditions,
- OR
- Trigger3
- AND
- Trigger1
- C1 = D1
- AND
- Trigger2
- C1 > D1
- OR
1 Like
Why not use a real-world example, instead of pseudo-code, to demonstrate how a consolidated trigger and condition simplifies a triggering situation that is more complex to implement as separate trigger and condition.
Actual:
alias: Riego
description: ''
trigger:
- platform: sun
event: sunset
id: Anochecer
- platform: sun
event: sunrise
id: Amanecer
- platform: time
id: Medio día
at: '15:00'
- platform: device
type: turned_on
device_id: 450f501fcd88df3f26bff4d965bcda07
entity_id: switch.riego
domain: switch
id: Apagar
for:
hours: 0
minutes: 10
seconds: 0
milliseconds: 0
condition:
- condition: or
conditions:
- condition: trigger
id: Apagar
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.aemet_rain_probability
below: '20'
- condition: or
conditions:
- condition: and
conditions:
- condition: trigger
id: Amanecer
- condition: numeric_state
entity_id: sensor.aemet_temperature
above: '20'
- condition: and
conditions:
- condition: trigger
id: Medio día
- condition: numeric_state
entity_id: sensor.aemet_temperature
above: '28'
- condition: trigger
id: Anochecer
action:
- choose:
- conditions:
- condition: trigger
id: Apagar
sequence:
- type: turn_off
device_id: 450f501fcd88df3f26bff4d965bcda07
entity_id: switch.riego
domain: switch
default:
- service: script.regar
mode: single
Feature request:
alias: Riego
description: ''
trigger:
- platform: sun
event: sunset
id: Anochecer
conditions:
- condition: numeric_state
entity_id: sensor.aemet_rain_probability
below: '20'
- platform: sun
event: sunrise
id: Amanecer
- condition: numeric_state
entity_id: sensor.aemet_rain_probability
below: '20'
- condition: numeric_state
entity_id: sensor.aemet_temperature
above: '20'
- platform: time
id: Medio día
at: '15:00'
- condition: numeric_state
entity_id: sensor.aemet_rain_probability
below: '20'
- condition: numeric_state
entity_id: sensor.aemet_temperature
above: '28'
- platform: device
type: turned_on
device_id: 450f501fcd88df3f26bff4d965bcda07
entity_id: switch.riego
domain: switch
id: Apagar
for:
hours: 0
minutes: 10
seconds: 0
milliseconds: 0
action:
- choose:
- conditions:
- condition: trigger
id: Apagar
sequence:
- type: turn_off
device_id: 450f501fcd88df3f26bff4d965bcda07
entity_id: switch.riego
domain: switch
default:
- service: script.regar
mode: single
10 lines less. And this example is a “bad” example because I need repeat the condition of rain < 20…
You get a more readable automation. You can see when each trigger will be triggered.
1 Like
You can get 8 less lines (and greater readability) without using a single template, by using the “Choose” action instead of trying to define such a convoluted group of “global” conditions and by not using the super-verbose Device triggers and conditions…
Ok…
alias: Riego
description: ''
trigger:
- platform: sun
event: sunset
id: Anochecer
- platform: sun
event: sunrise
id: Amanecer
- platform: time
id: Medio día
at: '15:00'
- platform: state
entity_id: switch.riego
to: "on"
id: Apagar
for: "00:10:00"
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: Apagar
sequence:
- service: switch.turn_off
entity_id: switch.riego
- conditions:
- condition: trigger
id: Anochecer
- condition: numeric_state
entity_id: sensor.aemet_rain_probability
below: '20'
sequence:
- service: script.regar
- conditions:
- condition: trigger
id: Amanecer
- condition: numeric_state
entity_id: sensor.aemet_rain_probability
below: '20'
- condition: numeric_state
entity_id: sensor.aemet_temperature
above: '20'
sequence:
- service: script.regar
- conditions:
- condition: trigger
id: Medio día
- condition: numeric_state
entity_id: sensor.aemet_rain_probability
below: '20'
- condition: numeric_state
entity_id: sensor.aemet_temperature
above: '28'
sequence:
- service: script.regar
default: []
mode: single
And you could get rid of the repeating rain probability sensor issue and remove another 4 lines by nesting “Choose” actions, but I think it makes it a little less readable for “everyone”…
With Nested Choose Actions
alias: Riego
description: ''
trigger:
- platform: sun
event: sunset
id: Anochecer
- platform: sun
event: sunrise
id: Amanecer
- platform: time
id: Medio día
at: '15:00'
- platform: state
entity_id: switch.riego
to: "on"
id: Apagar
for: "00:10:00"
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: Apagar
sequence:
- service: switch.turn_off
entity_id: switch.riego
- conditions:
- condition: numeric_state
entity_id: sensor.aemet_rain_probability
below: '20'
sequence:
- choose:
- conditions:
- condition: trigger
id: Amanecer
- condition: numeric_state
entity_id: sensor.aemet_temperature
above: '20'
sequence:
- service: script.regar
- conditions:
- condition: trigger
id: Medio día
- condition: numeric_state
entity_id: sensor.aemet_temperature
above: '28'
sequence:
- service: script.regar
default:
- service: script.regar
default: []
mode: single
There are already 3 “types” of conditions in the automation editor… “global” conditions, “Condition” actions, and “Choose” conditions. All of these can be 'AND’ed, 'OR’ed, and 'NOT’ed into confusion. Personally, I think creating another place to add conditions will likely cause more confusion for new users rather than less.
EDIT: Addressed OP’s correct assertion about “Apagar” trigger
1 Like
I actually wish they would remove “Trigger ID” as an option in the UI “global” conditions section. It makes very little sense to have it there and it may be actively confusing people, like the OP, who try to use it there instead of in a “Choose” action.
With you code, in the sunrise, if the temperature is below 20, the choose execute the default… In that example, turn_off the irrigation is not a problem, but, in others can be, so you need add another case with Apagar trigger. Is this el problem, is more complex and you can make a mistake.
And, by other hand, the automation is executed always, but it does nothing.
I see what you are saying about the “Apagar” trigger in the non-nested version, and have corrected it above.
However, my point is that you are claiming that adding conditions to the trigger section of the UI will make it:
But you are trying to support that claim using an example that ignores existing methods that make things less verbose and “cleaner”.
It’s a fine line between this:
Trigger fires, condition is evaluated to false; nothing happens.
and this:
Trigger fires, condition within action is evaluated to false; nothing happens.
1 Like
It’s a fine line yes but one that could confuse someone.
If you see the last triggered time to be today when it was raining then it would cause you to dig through the config to see what was wrong. (Choose method)
If the condition makes the automation fail then there wouldn’t be a last triggered time.
I’m not saying one is right and one is wrong, I’m just saying there is definitely a difference.