For instance, if you want to override a countdown timer with a specific end time. Instead of having o calculate the exact seconds until that future timestamp to pass in duration, it would be nice to be able to pass at: 02:00:00 into timer.start to specify timer should finish at 2am.
Example timer that auto-arms alarm 45 minutes after nobody is present…or at 2am daily. Sharing the same timer allows in Lovelace to show countdown until the next automatic arming (otherwise this logic is fairly easy as two separate automations).
timer:
security_auto_arm:
name: "Security Auto Arm"
duration: "00:45:00"
restore: true
automation:
- alias: "Auto arm countdown START"
trigger:
- platform: state
entity_id: binary_sensor.home_presence
to: 'off'
action:
- service: timer.start
data:
entity_id: timer.security_auto_arm
- alias: "Auto arm countdown STOP"
trigger:
- platform: state
entity_id: binary_sensor.home_presence
to: 'on'
- platform: state
entity_id: alarm_control_panel.security_panel
to: 'disarmed'
action:
- service: timer.cancel
data:
entity_id: timer.security_auto_arm
- service: timer.start
data:
entity_id: timer.security_auto_arm
at: "02:00:00"
How is this different from just adding a time trigger?
You need an automation when the timer has ended anyways so adding one more trigger to that automation is all that is needed.
Because in Lovelace now you have to display to users two different entities. That is the problem. Yes, your solution is simple if only considering the configuration files, not the UI representations.
Example, here is the timer displayed in Lovelace:
type: custom:timer-bar-card
entities:
- entity: timer.considered_away
name: Auto Off
- entity: timer.security_auto_arm
This shows when the next auto arm timer will finish (and security alarm activated at that time). However, to now show another time when this would also “magically” happen a separate entity would need to be created to show the time trigger time that the same event will occur. Does that make more sense now? PLUS the UI for that card has to show BOTH times when auto alarming will happen, instead of just a single countdown to next auto alarm.
Since timer.start service already takes a duration in seconds…taking a fixed timestamp (even if you simplify to just allowing within next 24 hours) makes sense on that service.