If I have a “for” time period in an automation is there any way to make where it is in this time period? For instance This automation
requires a condition to be true for 1 hour before the action is taken. Is there anything I can add to show on a dashboard where it is in this 1 hour “countdown” at the moment?
Thanks in advance guys.
No. That information is inaccessible (before the trigger fires).
If you want to see progress, use a timer helper instead of a for. You can show timers on the dashboard, cancel or prolong them at will. You’ll have lots more control at the expense of a but more complexity in the automations.
Can you post some code demonstrating how a timer can be used instead of a Numeric State Trigger’s for option? Or even how it can be used together with a Numeric State Trigger.
A timer simply decrements its duration every second.
A Numeric State Trigger fires when the entity’s state value goes above/below a threshold value and remains there for a given period of time. Should the entity’s value re-cross the threshold before the countdown expires, whatever elapsed time had been recorded is reset to zero.
Had not posted samples because it is a pain on an ipad, but here you go:
There are multiple ways. For a numeric state trigger is slightly harder because you want to know how long the numeric state is in the desired state, while states may change. Personally I like to create a threshold sensor to have a binary sensor to react to, but it is not needed.
You could start a timer when the state goes above and cancel the timer when the state goes below.
Because the code is a screenshot instead of formatted code I cannot copy paste, so I’ll use an arbitrary other sensor. Create a timer in the helper section, then use automations like this:
Start timer when state high:
triggers:
- trigger: numeric_state
entity_id: sensor.temperature
above: 20.0
conditions: []
actions:
- action: timer.start
data: {}
target:
entity_id: timer.hightemp
Cancel timer if high temperature does not hold:
triggers:
- trigger: numeric_state
entity_id: sensor.temperature
below: 20.0
conditions: []
actions:
- action: timer.cancel
data: {}
target:
entity_id: timer.hightemp
Do something when timer reaches duration:
triggers:
- trigger: event
event_type: timer.finished
event_data:
entity_id: timer.hightemp
conditions: []
actions:
- action: script.dosomething
You can show the timer on the dashboard.
It’s undeniably a bit of overhead to mimic the countdown of a for option.
To refine the mimicry, ensure the timer is reset by a restart because a for is not resumed like a timer.
True, it takes more work, and there are other ways too, also requiring a bit more work. As in life, nothing comes for free. I’m not sure that mimicking a for exactly - including its faults when restarting - is the point here. A for not surviving a restart is probably not what is intended. But the timer allows for both options. You can set it to forget its state on restart or remember it as you wish.
And if you want to be precise: a timer is not a duration decrementing every second as you implied. It is a timestamp at which point something should happen. Look at the developer tools on a running timer. No duration there. Edit: I see a remaining attribute now, not counting down though. I’m positive that was not always there. A timer is displayed as a countdown by the default entity card. But there are also custom cards to show it as a progress bar.
Two ways to look at it:
Home Assistant’s automations aren’t designed to resume operation from the point where they were terminated by a restart (everything is reset).
The for option’s internal timer serves a specific role compared to a general purpose timer entity. It’s part of a monitoring system. After a restart, it’s unknown how long the monitored entity’s state remained above/below the threshold or if it momentarily crossed it (because Home Assistant was non-functional during the restart period). Rather than make assumptions, the internal timer is reset.
On startup, the state value of a sensor entity (typically an entity whose value isn’t stored/restored but acquired from its integration) undergoes a change from unavailable to whatever value is supplied by its integration.
Unless I’m mistaken, that brief state-change on startup can trigger a Numeric State Trigger if the new value is above/below the threshold. The implication for your proposal is that the timer entity is likely to be reset on startup.
It was a generalization of how a timer operates.
I have never examined the underlying python code to see how it’s actually implemented in Home Assistant. Nevertheless it’s safe to say something internally monitors the system clock, ostensibly in 1-second intervals, to detect the time when the timer should expire.
That’s done by the card itself.
A timer entity doesn’t report its actual countdown value because it would be recorded in the database. Instead, it simply reports when it will be finished in the finishes_at attribute.
I believe an entity card can have a secondary information that is last changed time
We’re going further and further away off topic. But one last observation: I was surprised to see a remaining time attribute on the timer. It should not be there for the reasons explained above. On top of that, it is correct for exactly one second, and after that is is plain wrong. I do not know where it came from, but it is a mistake.
Or keep the for on the automation’s “actual” trigger, and run a timer in parallell purely for show (on the dashboard), something like…
alias: Bathroom master fan/heater auto off v2
triggers:
- trigger: numeric_state
entity_id: sensor.plug_bathroom_master_fan_heater_electric_consumtion_a_2
above: 0.4
for:
hours: 1
- id: timer.start
trigger: numeric_state
entity_id: sensor.plug_bathroom_master_fan_heater_electric_consumtion_a_2
above: 0.4
- id: timer.cancel
trigger: numeric_state
entity_id: sensor.plug_bathroom_master_fan_heater_electric_consumtion_a_2
below: 0.4
actions:
- if: "{{ trigger.id.startswith('timer.') }}"
then:
- action: "{{ trigger.id }}"
target:
entity_id: timer.plug_bathroom_master_fan_heater_electric_consumtion_a_2
else:
...
Sidetrack: How does the above/below conditions work, I assume they are simply the equivalent of > and <? Kind of limiting that numeric_state triggers/conditions does not also have equivalents of >= and <=…?
If you see how long ago the state has changed then that is more or less what OP is asking for
True. I also considered that. But for demonstration purposes I tried to stick to the basics.
The remaining attribute has been part of the timer entity for a long time (at least as long as I started using Home Assistant in 2018). Its value is not updated in real-time; it’s updated when the timer is paused.
The finishes_at attribute is a more recent addition (almost 3 years ago). Its value is not updated in real-time; it’s updated when the timer is paused. However, unlike remaining, it makes it easier to compute the actual remaining time with a template.
There’s also a finished_at attribute indicating the datetime when the timer finished (produced when the timer.finished event fires). It can be useful after a restart to determine if the timer expired while Home Assistant was restarting.