Allow functional self contained automations

Feature Requests
1

I can create a basic automation such as if switch is turned on turn it off after 2 hours.

However Home Assistant is not well suited to this task. If the server is rebooted or even an unrelated configuration is edited (and then obviously reloaded) the automation fails to complete the simple tasks.

There are work around to this such as creating timers, input_datetime, etc. However these work around will make the automation more complex and litter your configuration with various new entities that will make long term maintenance of the configuration more complex and confusing.

There should be some sort of method to make an automation self contained either by allowing it to retain state across reboots and configuration reloads, or simply allowing you to define other entities such as your timer or input_datetime within the automation.

2

According to your user profile, you joined this community forum an hour ago. That’s interesting to me because when I first read your Feature Request I had assumed it was written by someone who is new to Home Assistant.

There are existing techniques to make automations survive restarts and, depending on the application, they don’t necessarily require helpers, timers, etc.

Nevertheless, even if a given technique does require the use of another entity, that’s hardly a “workaround”; automations normally involve monitoring and controlling entities, so relying on one more isn’t a departure from the status quo.

Regardless of where it’s defined (under the timer domain in configuration.yaml or via the UI as a timer helper, or via the proposed “within the automation”) it would still exist as a timer entity. Its behavior would remain the same regardless of where it was defined.

It’s important to keep in mind that a restart causes everything to be reloaded. Automations can be designed to trigger on startup and perform checks to determine if any actions should be performed. Here’s an example:

1 Like
3

I would point out here that it doesn’t have to be this way but it depends on you implemented it. In my experience the problem is when people make an automation like this they think about it this way first:

trigger:
  platform: state
  entity_id: switch.my_switch
  to: 'on'
  for:
    hours: 2
action:
  service: switch.turn_off
  data:
    entity_id: switch.my_switch

Which is can basically be paraphrased as:

  1. When the switch turns on
  2. If its still on 2 hours later
  3. Turn it off

This does not work well for the reasons you noted. The problem is the automation is actually running for 2 hours. Two hours is a long time considering an automation reload or system restart will stop it in its tracks.

Which is why in general its almost always a good idea to refactor out a long for on a state trigger or a long delay/wait in the automation. Like its fine to start there but once its working, refactor that bit out. In this case you can do by switching to a time pattern (which I don’t normally recommend but fits this case well):

trigger:
  platform: time_pattern
  minutes: '/5'
condition:
  condition: state
  entity_id: switch.my_switch
  state: 'on'
  for:
    hours: 2
action:
  service: switch.turn_off
  data:
    entity_id: switch.my_switch

Now this one will always turn your switch off no matter what occurred in those two hours. It may take a bit longer then 2 hours (or significantly longer if an HA restart did actually occur since that resets last_changed) but it won’t ever forget about it since its not continuously running.

The only downside of this approach is the automation is actually running (and generating a trace) every 5 minutes. If you’re comfortable with templates though you can even eliminate that by doing this instead:

trigger:
  platform: template
  value_template: >-
    {{ now().minute % 5 == 0 and is_state('switch.my_switch', 'on')
      and states.switch.my_switch.last_changed < now() - timedelta(hours=2) }}
action:
  service: switch.turn_off
  data:
    entity_id: switch.my_switch

Exactly the same thing but now it only runs when the switch is actually on.

2 Likes
4

Sure, but the issue is they sit around completely separate from the integration (or other entities) they interact with. Then when you go on to manage things 6 months or a year later it leaves you scratching your head especially when you have various of these helpers around.

Furthermore even if you know exactly what all the related bits are you still have to look around for them. Was that a 1 hour or 2 two hour timer I created for this automation? Which automation reacts to the end of that timer?

Would it not be better when you open the automation everything related is right there?

5

If it’s used in the automation, like a datetime helper, then it will be in the automation when you open it.

6

I don’t see how to define it in the automation. Sure if you use one in the automation it will obviously show it is used, but it is not defined and configured there as far as I cal tell.

7

Did you mean to say automation? Because the word ‘integration’ has a specific meaning in Home Assistant and all entities are based on some type of integration.

You’re making a distinction that doesn’t exist in Home Assistant. The word “helpers” is just a term to describe a certain collection of entities. A typical automation will monitor entities in its trigger, check the state of entities in its condition, and act on entities in its action. If one or more of those entities happens to be a helper is a moot point.

That’s the case for all entities employed by an automation, not just the ones designated as helpers.

Check the timer’s “Related” view.

Respectfully, what I suggest your Feature Request should focus on is provide examples of how to improve the appearance of the Automation Editor so that it offers convenient access to an entity’s details. For example if you select a switch entity for a State Trigger, there would be a way to display more information about the selected entity. This would apply for any entity used in the automation (whether designated a helper or otherwise).

This is far more feasible than re-designing Home Assistant to support the notion of automation-specific entities.

8

You don’t define/declare sensors added from an integration either in the automation.
This is no different.
I would even argue that it would be worse if you had to define/declare them in each automation.

Imagine the mess if each automation had each sensors and helpers. Would be impossible to find anything.