I would like the ability to DISABLE automations for a higher level of control of automations, similar to integrations. I had an automation accidentally turned on and it started back up my kids school alarms in the morning. I turned it off, but I really want to artificially delete it until next school year.
I do this the old skool way. Copy the automation to a text file, save on my HDD, delete automation. When I need it back, make new automation, copy/paste.
I do support your request, it will make it easier.
I can offer another suggestion. There is a HACS integration call Garbage collection That allows you to set a date sensor in the calendar. You can create a start-of-school and end-of-school sensor that you can use as a condition in your automations. I use mine for irrigation et. al.
Here is a sample from my configuration.yaml
# Use garbage collection to set events and holidays
- name: Watering Days #summer months
Hope this helps
Basically, you can disable automations under settings —> entities.
But I too would prefer a less cumbersome way.
How? It can be turned on manually via the UI or via a service call.
Can you explain the difference between the existing ability to turn off an automation, which effectively disables it, and your proposed ability to disable an automation? What do you see as the difference between “turning off” and “disabling”?
Given that you accidentally turned on an automation (i.e. you enabled it), how do you propose this won’t happen with your disabling feature?
I’m still trying to figure it out, because it just says “turned on” in logbook. Doesn’t say by user or automation, etc.
Disable would effectively place it in a “disabled” state like an integration where it is hidden from the UI. Any calls to turn on would not work (maybe log an error, etc.).
I’ve turned on/off automations for years without issue, I just think it would be an additional level of protection besides permanent deletion/taking offline and equal in functionality to an integration. I disable and enable integrations plenty in testing since that functionality has rolled out.
It’s an additional level of complexity that’s largely unnecessary. I’ve never had an automation, that I’ve turned off, inexplicably turn itself back on.
Does the automation (that was turned on) use the
initial_state: true option? If it does then it will always turn on at startup. If its not that and you can’t determine the cause (only one of two possibilities), then the exact same mystery could occur if there was a “disable” feature. What then? Request a third level of disabling?