I’d say most of us have set up automations that were intended to be run once. For example, for a particular date or occasion. Once the automation has run, we usually have to turn off or delete the automation manually before it triggers again.
Perhaps your automation list is full of automations that triggered once ages ago and are now sitting around doing nothing. Perhaps you go in to delete the automations manually. Or sometimes you forget about them until the lights randomly turn on at 5AM for no apparent reason.
To implement a run-once logic, I think it could be done in one of two ways:
Give each automation an attribute that the user can choose when editing it: run perpetually, run once then turn off, or run once then delete.
Introduce an additional action to the automation that can allow it to be turned off or deleted. This might be achieved now by templating but it’s not very clear.
If you’re looking for a simple task to run at certain time, you could take a look at my scheduler integration:
It offers exactly the run once + delete / disable after execution options which you’re looking for.
I think it might take a while before such feature will be available for standard automations.
I recently had a similar requirement. But in a much simpler setting. The task was simply to turn off a switch with a delay of ~15 minutes.
For that I wished the switch element in the UI had a simple scheduler included. By that I don’t mean the main toggle in the overview. That one of course should stay the way it is. But when clicking the entity we already get some more information, along with the same toggle. If there was just an additional time-input below that, this could - if set to something other than the default - schedule whatever the click on the toggle would have done regularily to be executed according to the selected time.
For me this wasn’t worth creating an automation, so I just set a timer on my smartphone and did it manually.
Essentially this would be like telling you voice assistant “turn the light in the kitchen off in 30 minutes”. At least if voice assistants can do that sort of thing. But I assume they can.
If the automation is written correctly, it will trigger for that “particular date or occasion” and never trigger again. Therefore there’s no need to manage it any further. Feel free to have it turn itself off but even that isn’t needed because it was designed to only execute once.
I think that is a more useful FR than the OP’s FR.
I’d vote for that if someone was to add one (hint, hint )
But to the OP’s point…
I can see the concern that they are pointing out.
It’s not just getting the automation to only run once - ever - it’s that once the automation is run it’s one time it’s still in the system hanging around cluttering things up and collecting cobwebs. So you need to go back and manually delete it.
But TBH, I don’t know how to solve that.
If you only ever create your automation via the UI editor it would likely be possible to select a “run once and then delete” check box.
But for YAML written automations that wouldn’t be possible since the editor never modifies those automations.
I never use the automation UI to create automations but I might be persuaded to use it for that very rare use case where I only ever needed an automation to run once and never again.
The way I see it, many people have automations that only run on holidays or birthdays or similar “once a year” events. Basically these automations sit around doing nothing for most of the year. A “once and done” automation is just a close cousin of these “once a year” automations. There’s no great burden to have automations that spend 99% of their time doing nothing.
One way to handle them now is to use tom_I’s suggestion (make the automation disable itself with a call to automation.turn_off) and, I would suggest, to send a notification to the user “Hello, this is automation.run_once_44. I’m done; please delete me.”
Optimally, there would be an automation.delete service but I imagine it would only work for automations bearing unique identifiers and located exclusively in automations.yaml (basically, whatever is composed using the Automation Editor). Nothing wrong with requesting this new service but I doubt it would be a high priority for implementation.
This is a good way of achieving this, but you have to create/save the automation first before you can obtain the entity ID. A variable for this automation that later populates could work.
It takes less than a minute to compose those two automations and even less time to delete them afterwards.
The use-cases for an automation.delete service are so narrow and limited that it will be challenging to attract a developer to implement it. Nevertheless, good luck.
)
