You don’t have any actions in the repeat sequence. If all you want to do is wait for a condition to be true, use a wait template.
Thanks for the hint.
Apparently the “only” method is to specify it as an expression in a ‘wait_template’ as ‘wait_for_trigger’ does not accept an ‘or’ condition (to define the two original conditions in an or condition), while it does accept those two conditions individually.
The repeat method could be improved by avoiding that this “eats” up all the resources: by requiring a sequence, and/or by setting a minimum delay between repeats.
It doesn’t accept any conditions. It accepts triggers, wait_for_trigger.
Show what you are attempting.
This illustrates what I meant:
- wait_for_trigger:
- platform: numeric_state
entity_id: sensor.sdb_dewpoint
below: '13.8'
- platform: numeric_state
entity_id: sensor.exterieur_dewpoint
above: '10.5'
which was written (in the repeat structure) as:
while:
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.sdb_dewpoint
above: '13.8'
- condition: numeric_state
entity_id: sensor.exterieur_dewpoint
below: '10.5'
I think that this “wait_for_trigger” means that if either condition occurs, move to the delay.
Even if technically this is a trigger, it is a lot like how a condition is defined. In my case, the ‘or’ nature of events is fine, but the “and” nature of a condition can not be defined with such triggers, but it was possible with the repeat…while method.
Here is the full new definition (untested):
alias: Ventilation SDB (Example)
description: Ventilation SDB
mode: restart
trigger:
- platform: numeric_state
entity_id: sensor.sdb_dewpoint
above: '14'
for:
hours: 0
minutes: 0
seconds: 0
- platform: numeric_state
entity_id: sensor.exterieur_dewpoint
below: '10'
- platform: event
event_type: homeassistant_start
condition:
- condition: or
conditions:
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.exterieur_dewpoint
below: '10'
- condition: numeric_state
entity_id: sensor.sdb_dewpoint
above: '14'
- condition: state
entity_id: light.sonoff_01minizb_4febc024_on_off
state: 'on'
action:
- type: turn_on
device_id: 3c3d6f675c5d59e015c83cfd7d4282ed
entity_id: light.sonoff_01minizb_4febc024_on_off
domain: light
- wait_for_trigger:
- platform: numeric_state
entity_id: sensor.sdb_dewpoint
below: '13.8'
- platform: numeric_state
entity_id: sensor.exterieur_dewpoint
above: '10.5'
- delay:
hours: 0
minutes: 1
seconds: 0
milliseconds: 0
- type: turn_off
device_id: 3c3d6f675c5d59e015c83cfd7d4282ed
entity_id: light.sonoff_01minizb_4febc024_on_off
domain: light
That wont work. Triggers are OR logic by default. You will have to use a template trigger:
- wait_for_trigger:
- platform: template
value_template: "{{ states('sensor.sdb_dewpoint')|float(20) < 13.8 and states('sensor.exterieur_dewpoint')|float(0) > 10.5 }}"
I have set the default values if the float filters cant convert the sensor states to numbers (if the are unavailable for example) so that it will not trigger. If you would prefer that it did trigger in the fault state use this template instead:
- wait_for_trigger:
- platform: template
value_template: "{{ states('sensor.sdb_dewpoint')|float(0) < 13.8 and states('sensor.exterieur_dewpoint')|float(20) > 10.5 }}"
1 Like
@tom_l Thank you for the template.
You confirm that the wait_for_trigger is a kind of or function on the events (only one event has to happen), which in my case is fine as its a condition to exit the loop.
Your comment also suggests that the current ui (and yaml?) implementations for “numeric_state” (condition/platform) do not cope with cases where the state is not a valid value.
Further, the automations seem to have difficulty to survive restarts - I have at least the impression that an automation does not continue where it stopped after a restart.
So I trigger my automation on ha restart so that the automation condition is evaluated in order to turn the fan off when needed.
That’s not what you had here:
You required both conditions to be true to exit the loop (AND logic).
Nope. I did not say that. Template functions and filters must have a default defined. e.g. at the moment you will get a warning that a |float filter could not convert a state to a number. In the future the template will fail to load if a default is not provided.
No automation survives a restart. They are all stopped. This is why long delays and waits are a bad idea. The longer the delay the more likely the automation will be interrupted by a restart.
The best way around this is to avoid delays and write state or event triggered automations.
It’s a repeat…while - so when one of the conditions is false, it exits the loop. Both have to be true to stay in it.
With the trigger we wait until one of the conditions (events) is true.
When you use a “template” ({{ code }}) you can specify a default but when using this (generated from the UI), you can’t define a default (at least not from the UI):
# Extract 1
- condition: numeric_state
entity_id: sensor.exterieur_dewpoint
below: '10.5'
# Extract 2
- platform: numeric_state
entity_id: sensor.sdb_dewpoint
above: '14'
for:
hours: 0
minutes: 0
seconds: 0
As you mentioned the definition of a default value by using the template your comment (not you) implicitally suggests (reminds me) that this can not be done by the above.
The best way around this is to avoid delays and write state or event triggered automations.
Converting delays to state & event triggered automations is not so easy - does HA has provisioning for that?
There could be some kind of alarm table such that a delay can be easily converted to a trigger occuring at a later time, stored in the database. As they are in the database, they would be triggered after a restart. I do not know if that exists.
And defining 10 automations to do 1 functions is not making things more readable, so it should all be manageable in 1 automation possibly based on states.
If that already exists, there are not many examples around, or they are not used enough in blueprints, etc. I believe there is the equivalent of a switch/case which allows the use of a state, I do not remember an example implementing a state machine in an automation - I mean: where the automation explicitly defines the state itself, and uses it to determine the next state.
The sooner you stop using the word “conditions” to refer to triggers, the sooner it will become clearer.
Earlier, tom_I stated:
It’s vital you understand the distinction. Triggers are listeners that listen for the state-changes you requested. Conditions are filters that listen for nothing and simply process the values given to them.
- An automation’s
triggersection supports multiple triggers that are logically OR. - An automation’s
conditionsection supports multiple conditions that can be logically OR, AND, NOT as well as combinations of the three.
If you need to logically AND multiple triggers then they must be combined in a Template Trigger (tom_l demonstrated this).
A restart, or even just a Reload Automations, will cancel any automation that is in the process of executing its action. The reason for this is because restart/reload initializes all automations (it doesn’t skip initializing an automation that is in progress).
I understand the difference between a condition, a trigger and an event.
Both the conditions and the triggers use the name “numeric_state”.
‘wait_for_trigger’ is kind of incorrect as it’s waiting for an event. And in the development tools the events are fired (not triggered) and we listen for events.
As far as a wait_for_trigger based on a numeric_state is the that fact that there is an implicit event that is fired when the expressed condition changes from false to true, we are using the outcome of a condition to determine if there is a reason to trigger an event.
So it would have been more generic to allow defining that pivot condition to be expressed in the same way as the automation condition so that and/or operations were possible.
Regarding the delay, is there anything already available in Home Assistant to implement long running delays that survive restarts?
Interesting you say that because the words you use to explain the differences suggest you don’t.
Like when you use fabricated terms like “implicit event” and saying wait_for_trigger is “waiting for an event”. The word “event” has special meaning in Home Assistant and shouldn’t be used loosely when describing the operation of triggers (or conditions).
There’s the active-timer restoration method, in the link tom_l shared, or a design pattern that employs a an input_datetime (set to a future time) and Time Trigger. Personally, I use both; the input_datetime/Time Trigger method tends to be the one I use most for durations exceeding 15 minutes.
The way I understood the observations “difference between conditions and events” is the general use of those words.
I fact, what the author meant was “HA Condtiions and HA Events” and we add to that “HA Triggers”.
That’s where the danger is - “HA triggers” are not always what we generally refer to as a trigger,
“implicit event”:
- because a ‘wait_for_trigger’ with the numeric_static platform asks the user to define a condition (below or above refers to a condition, not an event, not a trigger).
- Names such as ‘crosses_below’ and ‘crosses_above’ would have been more representative of what they are.
- In general wording, a trigger leads to an action following an event, but in HA the word “event” is apparently reserved the event signals.
I had a quick look at the method to store/restore timers - I think there should be integrated functionnality for that. An action to (re)start/stop delays - maybe a service to do that.
Nope. It refers to a state.
As 123 keeps telling you, you are misusing the term ‘condition’ as it applies to home assistant.
If you have the skill you can submit a PR to include it. Otherwise search the Feature Requests category. There’s probably already a request for something like this. If not you can submit one.
You say that and then your subsequent explanations reveal you still misunderstand and/or misuse Home Assistant’s terminology (as pointed out by tom_l above).
There was a PR for it a long time ago but it was never completed.
Even if HA would call a cat a dog, a cat still is a cat. And even if HA doesn’t label something a condition, it is still a condition.
When the yaml says:
wait_for_trigger:
- platform: numeric_state
entity_id: sensor.sdb_dewpoint
above: '14'
for:
hours: 0
minutes: 0
seconds: 0
Then I read this as (regular wording, not HA wording):
- A wait step,
- with a trigger ending it,
- Upon observing a real event (not HA event):
- That the condition that a state value is above 14 (not a “HA condition”),
for a duration of exactly 0s since it was below or equal to 14 (or undefined?);
- That the condition that a state value is above 14 (not a “HA condition”),
- Upon observing a real event (not HA event):
- with a trigger ending it,
So OK:
- it’s not a HA condition (because we did not write condition),
- it’s not a HA event (because it’s not on the HA event bus),
- it’s also not a HA state (there is no state representing the crossing of the value of 14 + the delay, at best that could be a trigger id representing that),
- but it requests to compare the HA state value against a numeric value;
- and in HA terms, the whole is called a (HA) action and it is said that to use a “numeric_state” trigger (HA).
i’ll surely start with an implementation of delay management in a component because HA integration is much more work regarding integration procedures.
Words matter. If you want to be understood in this community forum, using Home Assistant’s terminology (correctly) is an asset.
Failing to use the terminology, or using it incorrectly, or substituting terms, results in long-winded threads like this one where the fundamentals have to be explained repeatedly; like condition is a reserved word with special meaning and cannot be used loosely when discussing how triggers operate.
1 Like
I agree that wording is important, but we can’t all be HA experts using the exact HA wording when this is essentially a on the side occupation.
I also agree that it is preferable that this kind of discussion can be avoided.
Personnaly, even while looking into these HA wordings, I did not find a single page defining these specific wordings clearly. It’s only by becoming an expert on HA that these specific working become apparent, and visitors of this forum can’t be expected to know all that.
A simple page where this is listed/explained can help. It could explain the wordings that are should be used when communicating in relation with HA. And it could be pointed to in case a forum user is seemingly not familiar with them. It could also be part of the documention, especially in the introduction.
Something like (not perfect, not optimised, without links):
- condition: a condition explicitally labeled as a condition or conditions in an automation, choose action, repeat action, … . The term “condition” does not refer to “state below 14” as part of a trigger specification, or anywhere else.
- event: refers to an event available on the HA event bus. It has a name on the event bus, and it does not refer to anything else such a the real time even of an expired delay, it does not refer to a trigger and not all triggers depend on Home Assistant events.
- trigger: refers to automation triggers (link) that can an item for the ‘trigger’ field of an automation, or the “wait_for_trigger” action step of an automation or script,
- automation: automation script consisting of triggers, conditions, and (a sequence of) actions .
- script: the script defining a sequence of actions
- state: a main state value, and a set of attributes generally representing an entity,
- entity:
- device:
- service:
- custom component:
- add on:
- … .
- … .
One would hope they would know after it was explained to them, like it was explained to you in this thread, several times.