Condition: day [was "Schedule" Trigger type]

I suspect many newbies imagine creating automation turn on/off lights on a schedule. I’d like to see a “Schedule” Trigger type that provides some kind of day/time picker.

UPDATE: For simplicity sake, the automation trigger should be a time which triggers every day.

However, the day could be selected in the condition. Currently this can be done with a template condition (See my reply to @balloob below for more detail), but it should be simpler.

I am proposing the following condition:

condition: day
  - monday
  - tuesday
  - wednesday
  - thursday
  - friday

It would be nice if something like this scheduler could be integrated to be used easily by everyone.

1 Like

I like the alternate solutions, but I believe a Schedule trigger added to the Automations UI would be better so we don’t have automatons managed in multiple locations.

That being said, I am going to take a look at this Supervisor Addon.

I agree. I miss it very much.

@bachya and I have explored a schedule integration. The biggest problem that you run into is what happens when something else interrupts your schedule (ie turns the light off early, changes brightness etc). If you look at thermostats you get a couple of options (permanent override, override till next change, override for X time etc). Anyway, all those options make it very complicated very fast and in the end we decided that with all those options, it would not add any value compared to what is possible today.

I think It can just be better UI for many newbies. It’s easier to understand and set up a schedule than creating many automatitions with the same result.

You know what. I just had a hard rethink on how this could be hard-coded. It really does get fairly simple.

  platform: time
  at: '06:30:00'

  - condition: template
    template: "{{ now().strftime('%A')|lower in ['monday','tuesday','wednesday','thursday','friday']" }}

The trickiest part for newbies would be the condition template. Maybe a “Day Picker Template” Condition type could create this template for the user? Or even better, a “Day” Condition type that would work like this:

  - condition: day
      - monday
      - tuesday
      - wednesday
      - thursday
      - friday

@kukulich What do you think about this simplified solution?

I agree this could be nice addition.

Take a look at my architecture issue:
I’ve even created a PR for the backend and for the frontend that applied that change.

I also think that we should be able to pick days and time as a separate conditions.

1 Like

I think I’m missing something here…this is already possible with the time condition:

You only need one of after, before, or weekday. I understand that there is currently no day picker in the automation editor though.


Along with what I said above, this is already possible with using condition: or and two time conditions, one with a time range and one with days.

1 Like

It’s a shame the initiative was discontinued because it seemed to have much promise. It would have simplified the procedure to create a scheduled task.

If I understood it correctly, it was based on the use of scenes where, at the appointed time, a particular scene was turned on. As for the scene itself, I assume it was automatically created when the user specified which entities should be controlled at the appointed time.

FWIW, this is precisely how the scheduler works in Premise (home automation software I have been using for the past 13 years).

First you specify the basics about the scheduled task like the Times when it starts/stops, based on the clock or sun-based with optional offsets.

Scheduled Task - Times

Then you set its Recurrence which is its time pattern, Daily or Weekly. Daily recurrence can be refined to be weekday, weekend, or every Nth weekday. You can optionally limit its Range which is either indefinite (default) or a specific date.

Scheduled Task - Recurrence - Daily

For Weekly you can specify which day of the week and optionally every Nth week.

Scheduled Task - Recurrence - Weekly

Upon saving the scheduled task it appears in a calendar view (the default name is simply “Task”). It achieves nothing yet because all it knows is when to run but not what to do. Now you proceed to add entities to it and indicate their desired states. Here I’ve added three entities:

Scheduled Task - Calendar View

I’ve also set their states to the desired values.

Foyer Light:
Scheduled Task - Foyer Light

Scheduled Task - Thermostat

Scheduling in Home Assistant is equally capable but currently involves considerably more work with automations, templating, and a knowledge of the available time triggers (a lot more knowledge if you want something like ‘run every second Wednesday’). A scheduler, at least as functionally capable as the one in Premise, would be a valuable addition to Home Assistant.

For people who may believe a Scheduler is “for newbies”, I have extensive experience with scripting in Premise but typically rely on its Scheduler as opposed to using its cron-like timers:
Cron-like Timer

1 Like

So with this schedule in Premise, what happens if you would change the brightness via the button or whatever?


I’m laughing because I can give you a very practical example of what happens. I created that scheduled task so I could provide demo screenshots to post here. What I forgot to do was either disable or delete that task!

This morning, at 07:35, we woke up to the sound of our forced-air furnace operating (the windows were open last night so the interior temperature dropped to 21). The scheduled task had started at 07:30. Sleepily, I manually set the thermostat’s mode from heat to off. In other words, my actions served to override what the task had done at 07:30.

In Premise’s UI, the task is still highlighted in green (because it’s scheduled to run until 09:30). Rather than let the task complete, I simply disabled it (I didn’t delete it in case I need to use it again as a demo). Upon disabling it, the task behaved like it had finished normally, at 09:30, and automatically restored the thermostat’s heating setpoint (back to its normal value of 17.5) and turned off the lights (because they were off before the task started). It also set hvac_mode back to off but that’s less readily confirmable because I had already done that manually at 07:36-ish.

In the following screenshot, you can see the Task is now disabled (in the calendar view the task’s background is now dark gray). You can also see how its associated scene is configured (the one it silently created in the background when I added the three entities). It currently indicates Play is enabled. That means, if the Task was not disabled, the scene would be playing right now because it falls within the scheduled time-range.

It also indicates the scene’s Behavior which is ‘Set-Restore’. In Premise, a scene’s behavior is either ‘Set-Restore’ (restore entity states after finishing) or ‘Set’ (do not restore entity states; leave them in whatever state specified by the scene). As you already know, in Home Assistant, ‘Set’ is the default way scenes behave and there’s a different process involved to restore entity states. This is all just a modal setting (Behavior) in Premise’s scenes and ‘Set-Restore’ is the default.

Scheduled Task - Disabled

FWIW, lighting and HVAC continue to be controlled by Premise and the entities (called “objects” in Premise) are exposed to Home Assistant as MQTT HVAC and MQTT Lights. The marriage of the two systems will be celebrating its 2-year anniversary this October. :slight_smile:

Historical trivia:

Are you familiar with the Magic Cap device from General Magic? It was a device released in 1994 which was, effectively, the forefather of the modern smartphone. However, it was very expensive to own (~US$1500 in 1994 dollars) and operate and, given the technological landscape of the mid-90’s, a product too far ahead for its time.

That’s how I view Premise. Perhaps not the forefather of home automation, but a product too far ahead for its time. Started in 1998 by Premise Home Systems, the company changed hands twice, and the product was ultimately discontinued by Motorola in 2006. Even the hobbyist version sold for the eye-watering price of US$1000 (in the early 2000’s).

In 2007 it was released for free (but never open-sourced) and that’s when I first started using it. Think about that for a moment. A closed-source product, unchanged for 14 years, yet has an architecture and feature-set sufficiently advanced and flexible (and with only about 2-3 minor bugs that I know of) to continue to be viable in 2020.


All home (and industrial) automation solutions that I have used myself over the last 2 decades typically had some sort of timeslots as part of their schedulers where something happens at the beginning of the timeslot and something happens at the end of the timeslot. Everything in between is not handled by the scheduler i.e. will be overruled with whatever people might do manually in the meantime (Example: Switch the light off with a button ahead of the end of the timeslot).
Some scheduler even visualize this nicely (see the little black dots in the detail view here: [NEW ADDON] Simple Scheduler ). BTW, the approach in my proposal in the linked post iis actually a scene based approch in Home Assistant speaking.