Why the heck can’t I figure out how to simply automate a single light to turn on and off at a prescribed time?
I want to my light to turn on at 07:00 and off at 18:00.
That’s it.
In a single automation that I can toggle on or off. This shouldn’t require conditional testing or template formatting, or sensors, or scripts, or delays, or solar elevations, or multiple automations, or be concerned with server restarts or anything. At time XX:XX send service call light.turn_on, at time ZZ:ZZ send service call light.turn_off.
I have been trying since 0.76 and still haven’t figured it out…
I mean, I can make the light do what I want, but not in what I consider an obvious and logical way.
I’ll concede the problem is likely between the keyboard and the monitor, it just seems like such a canonical automation that’s always forced me to resort to less explicit/declarative/obvious implementations. I invariably end up with conditional templates, or scripts, or delays; which are all powerful in their own right, but seem needlessly excessive.
The alternative is separate automations for on and off, which doubles the number of automations, which need to be toggled on or off at the same time anyway… Am I just missing something fundamental here?
In the “Action” space, you could also pick “Call Service” and pick “light.turn_on” then choose your light entity.
Another way, in only YAML would be this:
- alias: timed_light_turn_on
description: 'turn on light at 5pm'
trigger:
- platform: time
at: '17:00:00'
condition: []
action:
- service: light.turn_on
entity_id: light.bedroom_nightstand
mode: single
And you are right, an automation like this would require two per schedule (one to turn on and one to turn off)! Now, if you just wanted to turn on multiple lights at the same time, this could still be done in the same automation, since you are allowed to have a list of things to do under the action: section.
But if you wanted many lights to turn on and off all at different times, then they would all require separate automation.
The examples I gave require two automatons, one to turn the light(s) on, and one to turn the light(s) off.
You could combine this into one automation by either placing a delay in the action (or other methods), so it delays for 3 hours, then turns the lights off again. However if you reboot HomeAssistant while the light is still on, the state of the automation and the timer isnt saved, so the light will never turn itself off.
It’s best to just use two automatons, one for on and one for off, for this. It keeps things simpler.
Just to update this with some hope. We do have plans to offer templates of very common automation in the future. Things like this will become super simple to do via the UI
Why do you have this fear of using two very simple automatiions?
It makes the code clear and easy to read and understand and modify.
And regarding turning the automation on and off - the “lights off” won’t really do anything if the lights are already off, so just turning off the “lights on” automation will probably do.
And if not - it is pretty easy to turn on and off more than one automation in one go, using either the gui or a script or another automation.
So tbh, if you’ve been here since 0.76 and haven’t been able to work it out, it kinda seems like during that time you could’ve either followed the documentation to get this result, or asked here and someone could’ve helped you achieve it
Perhaps my original post was a bit misleading, I have been able to accomplish the desired automation in several different ways, just not in a way that seemed obvious to me. And I was unsure that I was correct in my assumption of not being able to accomplish this as desired.
I guess what I was trying express in the spirit of “WTH” was my frustration with the inability to explicitly declare something so simple as time-on, time-off. It always strikes me as anti-pythonic, and non-obvious for a casual user to either need to use separate automations or templating to achieve what is ostensibly ‘my first automation’, as evidenced by numerous and re-occuring posts of similar content.
I feel that were such a logical construct possible, it would have a cascading effect in the simplicity of automations and the reduction of required code as automations grow in complexity. TBH, I’ve always had digging into the source to attempt to develop this on my to-do list, but… life.
Another option is to use the new choose: functionality, avoiding templates and staying within YAML constructs, but as Zack mentioned, the goal is to make things like this easier to construct from the UI. That should lower the bar for folks who just want to get started with something simple.
If the goal is to ‘lower the bar’ for newcomers, then we should be directing them to use a Scheduler as opposed to composing an automation.
A lot of home automation revolves around scheduled activities. A Scheduler is the ideal way to compose and present schedules. It’s the one major piece of functionality (found in some other products) that is missing here (there was an official attempt to include it but it was shelved).
To be fair, there are unofficial Schedulers but the hurdle is that the new user must:
Thanks all for a very interesting discussion. I learned a few tricks I’ll be using myself.
That said, I want to add my vote of support for a concept I think all here will agree: The goal for “version 1” of HA should be to make it as easy to use as the other options out there.
I think every smart device I’ve ever purchased, from my first Christmas tree light mechanical timer to my three smart thermostats, and all the smart plugs in between, come out of the box with a simple way for a non-techie to set a schedule for turning them on and off.
I agree with Taras that this is a core functionality. To me, it would be prioritized ahead of more complex concepts like occupancy sensors. As cool as it may be to have your home “welcome” you by turning things on when you arrive, beginners need to learn to walk before they can run.
@anon43302295 That is the most concise template I’ve seen to date. I will update my current automations with the trigger attribute template, thanks!
@123 Yes, I think the scheduler functionality should be core to the home automation experience. Time is really the one universal state that exists across all installations
I don’t think that reducing complexity is ‘lowering the bar’, though it would have the side effect of increasing inclusion amongst the less technically savvy.
It seems to me that the state engine has to have a scheduler of sorts built into the time platform already, such that we can instruct it to schedule a trigger at a certain time. In the automation UI, a simple solution would be to allow:
Trigger
(Condition)
Action
Trigger
(Condition)
Action
Which is essentially permitting a trigger call at any point in the automation control flow. What always gets me about using the templating is it makes me feel like I’m unnecessarily testing:
vars = [x, y, z]
for var in vars:
if var == x:
return f(x)
else:
pass
