If the driving force for this idea is convenience (i.e. minimize the “mental load” of selecting options in a UI), for executing simple “one-time” tasks, then it seems like it would be most convenient if one could simply type, or speak, the command such as “Turn off kitchen light at 8:00 PM” or “Start vacuum at 2:00 PM”. In other words, it sounds like a task for the Conversation agent.
Then the mental load will be replaced by the mental load of figuring out whether the conversation agent got it right, not to mention that it will be extremely hard to pass in multiple parameters.
As I mentioned earlier - “[conversation agent support] would go hand-in-hand with having that ability in service calls.”
Yes, there are many ways to achieve this, the question is how friendly do we want this to be. I think that scheduling actions is a pretty basic requirement from a home automation system, so it makes sense for there to be a really friendly way to do it.
2 Likes
It can be designed to echo back the command, like Alexa does when you, for example, tell it to set a 5 minute timer.
not to mention that it will be extremely hard to pass in multiple parameters.
It appears that you’re suggesting it will need to be more sophisticated than merely turning something on/off at a specific time. In other words, its ultimate functionality will approach what automations can already do (duplicating an existing feature).
Regarding “additional mental load”, the average user will have created at least one automation (conceivably far more) so they are already familiar with the process and can simply leverage their existing expertise. What’s missing is a “delete automation” action.
FWIW, I doubt the development team will approve a proposal to create what is effectively a stunted automation.
“It’s like an automation, with a similar UI, but to reduce mental load it has no name or conditions and fewer choices of triggers and actions and deletes itself after running.”
1 Like
That’s not what I’m suggesting at all. It could be as simple as a service call (think of the UI for calling scripts from dashboards), but with a way to control timing.
Very similar to my WTH
Can you elaborate on this? I can’t picture where this is in the UI.
Are you referring to a card, like a Button Card that can be configured to run a script? Or do you mean
Developer Tools → Actions?
I mean the pop-up for a script. There are various ways to get to it (e.g. clicking on “Information” in the context menu for a script, clicking on a script entity in a card, etc…)
It displays the last time the script ran and “Run Actions”. There’s not much there.
I’m not following how that’s an example of the UI for what you’re proposing.
What about something like this? It’s a script with fields defined for action, duration,and time. It requires one or more actions using an action selector, then it has optional selectors for both time and duration. Duration works like a timer (ie, perform the actions in 20 minutes). If both time and duration are provided, then it waits until time, then continues to wait for the duration given. If neither are provided, it would immediately run the action(s) (might be good for testing).
Note: I’m just doodling here while waiting for my partner to wrap the last of her presents. I haven’t used this in production or tested it beyond the most basic of checks.
alias: Timed actions
sequence:
- choose:
- conditions:
- condition: template
value_template: "{{timer_field is defined and time_field is defined}}"
alias: "Wait until a specific time, then delay for a given duration"
sequence:
- wait_for_trigger:
- trigger: time
at: "{{ time_field }}"
- delay: "{{ timer_field }}"
- repeat:
for_each: "{{ action_field }}"
sequence:
- choose:
- conditions:
- condition: template
value_template: >-
{{ repeat.item.target is defined and
repeat.item.data is defined }}
sequence:
- target: "{{ repeat.item.target }}"
data: "{{ repeat.item.data }}"
action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ repeat.item.target is defined }}"
sequence:
- target: "{{ repeat.item.target }}"
action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ repeat.item.data is defined }}"
sequence:
- data: "{{ repeat.item.data }}"
action: "{{ repeat.item.action }}"
default:
- action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ timer_field is defined }}"
alias: "Wait for a given duration"
sequence:
- delay: "{{ timer_field }}"
- repeat:
for_each: "{{ action_field }}"
sequence:
- choose:
- conditions:
- condition: template
value_template: >-
{{ repeat.item.target is defined and
repeat.item.data is defined }}
sequence:
- target: "{{ repeat.item.target }}"
data: "{{ repeat.item.data }}"
action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ repeat.item.target is defined }}"
sequence:
- target: "{{ repeat.item.target }}"
action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ repeat.item.data is defined }}"
sequence:
- data: "{{ repeat.item.data }}"
action: "{{ repeat.item.action }}"
default:
- action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ time_field is defined }}"
alias: "Wait until a specific time"
sequence:
- wait_for_trigger:
- trigger: time
at: "{{ time_field }}"
- repeat:
for_each: "{{ action_field }}"
sequence:
- choose:
- conditions:
- condition: template
value_template: >-
{{ repeat.item.target is defined and
repeat.item.data is defined }}
sequence:
- target: "{{ repeat.item.target }}"
data: "{{ repeat.item.data }}"
action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ repeat.item.target is defined }}"
sequence:
- target: "{{ repeat.item.target }}"
action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ repeat.item.data is defined }}"
sequence:
- data: "{{ repeat.item.data }}"
action: "{{ repeat.item.action }}"
default:
- action: "{{ repeat.item.action }}"
default:
- repeat:
for_each: "{{ action_field }}"
sequence:
- choose:
- conditions:
- condition: template
value_template: >-
{{ repeat.item.target is defined and repeat.item.data is
defined }}
sequence:
- target: "{{ repeat.item.target }}"
data: "{{ repeat.item.data }}"
action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ repeat.item.target is defined }}"
sequence:
- target: "{{ repeat.item.target }}"
action: "{{ repeat.item.action }}"
- conditions:
- condition: template
value_template: "{{ repeat.item.data is defined }}"
sequence:
- data: "{{ repeat.item.data }}"
action: "{{ repeat.item.action }}"
default:
- action: "{{ repeat.item.action }}"
alias: >-
Wait for a specific time, a duration, both (waits for time, then adds
duration), or neither(immediately run actions).
fields:
action_field:
selector:
action: {}
name: Action
required: true
timer_field:
selector:
duration: {}
name: Timer
time_field:
selector:
time: {}
name: Time
description: ""
A datetime helper has a date and a time. You can make an input for it on your dashboard. If you set that, and you make an automation once, that uses the datetime helper as it’s trigger, and a configurable action, you’re more or less there, no?
This is what I do to temporarily override my heating schedule. I use a custom card for a datetime picker.
If you’re scripts have fields it will let you select values for them, and look somewhat similar to the relevant section in developer tools. Give it a try, it’s really cool.
Really interesting direction, but unlike a native feature, it won’t survive a restart.
Same as the one above…
I haven’t actually tried it out as far as I remember, but why would it not survive a restart? The automation is saved, and the input helper won’t change value. I can see how it would not work if the scheduled time is during a restart, or during downtime of the system. But other than that I think it should work, no? Or am I missing something?
Delay doesn’t survive restart. However making that an input daytime to survive restarts would be really easy.
I don’t use a delay. I use the input daytime. Hence the question.
Yes but you asked why he said it wouldn’t survive restarts, when he was replying to a script that used delays. The answer to that question is: because delays don’t survive restarts.
I was replying to “Same as the one above…” which was a reply to my post in which I explicitly mentioned I was using a helper
True! And I believe this WTH is definitely worth being a core feature, assuming that something can be done about restarts. There have been some creative and somewhat robust workarounds presented for automations to survive restarts, but it’d be really great not have to go to those lengths.
I believe the biggest issue is for implementing this is what happens when triggers would fire in the middle of the restart. Obviously you wouldn’t get the actions that were supposed to happen right then, but what should HA do once it’s fully started up? Drop those actions, run them as soon as possible (which could be significantly later than they should have), notify somehow that they were missed? I think the last time I saw any developers comment about it, the feeling was it was best to drop them and set expectations that automations can’t survive restarts.
FWIW, I only intentionally restart once or twice a month at most for updates, and with a UPS on my server, unintentional restarts happen much less frequently than that. So, for me, my script (or some better coded version of the concept) is a ‘good enough’/90% solution.