Home Assistant has become irresponsive and I think it’s because of the repeat that I added to the following automation.
This is an automation for a Forced Air Extraction and the algorithm is the following:
Trigger on changes that might start the automation, or stop the automation (ha startup).
Condition to start the automation when: dew point levels are met, or when the venting fan is already running (to handle ‘ha core restart’).
Start the fan;
Wait until one of the dew point conditions should stop the fan (internal dew point “low” or external dew point “high”);
Wait 1 minute;
Stop the fan .
My HAOS has been irresponsive 4 or 5 times already and I think it’s related to this automation and specifically the repeat. Irresponsive= impossible to access the UI, impossible to start a new ssh session.
Special cases:
I had an open ssh session which stayed open the last time, and I was able to restart ha from the CLI).
I had an open ssh session which was closed (probably when the repeat step was running quite a while already).
I expected the repeat condition to be evaluated “sparsely” when the tested values change, but I now suspect that is not the case.
I wonder if I should file this as a “bug” and if filing it as a bug is usefull because I filed several ones and I do not have the impression that they are really treated (I had one that was going to be closed by a bot).
The on and off logic is in a single automation as I do not like to have two separate “software functions” to handle a single user function (have the fan on when there is too m
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.
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.
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:
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.
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):
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 trigger section supports multiple triggers that are logically OR.
An automation’s condition section 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.
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).
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?);
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.