Scheduling in home assistant

Do I understand it correctly: in ha there is no powerful scheduler out of the box?
Scheduled tasks are in my opinion one of the most important points for home automation.
What is the best way to control Eurotronic Spirit Z-Wave thermostats in a time and week schedule?
Schedy seems to be a possible solution. But I haven’t found a nice GUI integration for lovelace to edit schedules graphically. Is there a solution?

Correct; there’s no officially-supported scheduler. However, there are community-supported schedulers such as Schedy. Here are a few others:

4 Likes

Thank you Taras for guiding me. Have seen Scheduler card of Nellis already which seems to be a smart aproach. What is you favorate?
Pros and cons Schedy and Scheduler card/custom component?

1 Like

None only because I don’t use any of them. All of my schedules are implemented as Time Triggers in automations.

And there is also google calendar integration that can help you in scheduling recurring meeting

For something like am alarm clock I use time triggers as well. And for something like garbage or vacation I have added them into different google calendars.

This sounds like exactly what I came here looking for, I’m going to have to play with a few of these and see which one I like. I too found it hard to believe that there is not a default out of the box scheduling system. Having discovered it only a few weeks ago Home Assistant is fantastic and has HUGE potential but the out-of-box experience is far more frustrating than it needs to be and the learning curve is quite steep, I cannot currently see myself recommending it to non-technical people who could benefit from the lack of cloud dependence but do not wish to spend hours perusing forums and tinkering with yaml files. It would be great if we could come up with 5-10 common user scenarios and make sure that they are as painless as possible to set up out of the box. Just off the top of my head I can think of a few things that I would expect 90% of home automation users are going to want to implement.

  • Turn a light (or whatever) on/off at set times/days, this should include sunrise/sunset triggers and the ability to specify a random +/- offset to create an impression that someone may be home turning the light on and off. For many years I have had a number of lights on standalone timers that do just this and it is probably the single most common thing that a vast majority of people are going to want to do with any kind of home automation.

  • Turn a light on at dusk and off at dawn, classic photocontrol behavior, probably nearly as common (domestically) as timers.

  • Turn a light on for a set amount of time when motion is detected, also extremely common this is already reasonably well supported by an automation blueprint.

  • Vacation mode, add a collection of lights and switches to a group and have them turn on and off at various intervals to roughly simulate somebody being home and moving about the house. A single switch to turn this behavior on and off could be manually flipped or automated by other events by more advanced users.

  • Sunrise/sunset light support, for example my partner has an alarm clock that slowly turns a light on to simulate a sunrise leading up to the set time and it also has a sunset mode that will gradually dim the light over a set period.

Just those five use cases ought to cover a vast range of needs, particularly the first four, making that super easy out of the box would make Home Assistant far more approachable, for many less technically inclined folks it might be all they ever need.

We have to take into account here that we are in a non-commercial environment. Most developers solve things that are a problem for themselves, which is understandable. Simple configuration via gui is probably not the first priority for a programmer. On the other hand, there are obviously many web designers who come up with really nice solutions for a successful Lovelace frontend.
Sometimes, however, there seems to be a bit of a crunch at the interface between program code and frontend integration.
So it’s nice to see that people like neliss make life easy by creating great GUI integrated solutions.
Of course it is true that even a free project should take into account what normal users need. This certainly includes a scheduler that is easily configurable graphically.

James for presence simulation you can simply create automations via the GUI, right?

switch light x or light group Y on at a certain time and off at a certain time…
Timers are also possible

I don’t think you have tried the Scheduler Card yet. You configure the card’s appearance (the GUI) using YAML.

Scheduler Card Configuration

Since its very beginning, it’s designed for use by hobbyists. People looking for a consumer-oriented experience (SmartThings, Wink, Philips Hue, etc) have come to the wrong place. They expect X but discover it is Y. This mismatch causes frustration and the common complaint “It’s too difficult.” That’s just another way of saying “I didn’t expect to have to learn so much to use it.”

Home Assistant continues to evolve with the goal of making it more approachable for non-hobbyists. However, it’s a slow process, complicated by the fact there’s no published roadmap managed by a central authority (it’s a community-run project and the core development team vets users’ contributions). Many improvements are introduced by volunteers and are based on what they feel is important.

You should know that there once was a plan to implement a Scheduler function that was led by members of the core development team. It would be the foundation upon which a GUI could expose its scheduling abilities. Long story short, they encountered an intractable architectural problem and the project was abandoned. Since then, community members have introduced their own solutions but none of the scope that was to be the ‘official’ Scheduler.

2 Likes

Hi Taras,
absolutely clear that HA is not a simpe solution like some commercial stuff. Configuration in .YAML configs is O. K. as long as there are some templates for configuration as well as help in this community. What I have done so far in the yaml config was not that complicatet. I have HA installed on an Intel NUC based on Ubuntu and Docker containers. OpenZwave works cleanly and AppDaemon runs as well…
But besides the IT level there is also the user level. In other words, home automation will probably only be accepted by everyone in a building if there are no disadvantages for the normal user. Ideally, for example, my wife could change schedules for heating in a graphical interface after the structure is configured accordingly under the hood.

At the moment I wonder if I should continue with Schedy or if there is a solution that is stable and relliable and at the same time offers a reasonable GUI.
What experiences have you made what runs stable? What offers the best possibilities?

Then the Scheduler Card might be a good choice. You configure the card (in YAML) so that others can use it (in the UI).

Yes I understand this, and my comment was not meant as criticism. It’s just that I see HUGE potential and some relatively minor improvements that could greatly improve usability. The project could benefit greatly from having a lot more users and to get those users it’s necessary to look beyond the hardcore tinkerers. Almost all existing consumer home automation solutions are fatally flawed in that they are completely dependent on the cloud infrastructure they are locked into. There is a significant gap between these garbage walled garden consumer products and something aimed purely at engineers, lacking any sort of effort on usability. There is an elitist attitude among some in the open source community that spending hours learning the nuts and bolts is some kind of rite of passage and that anyone who is not sufficiently technical is not worthy of using it and should just go buy from Apple and I happen to disagree with that. It is a worthy if not always achievable for practical reasons goal of any project to be accessible to as wide a range of people as possible. It is IMHO far preferable for people to have a positive first impression with a gentle learning curve to get some basic stuff up and running at which point those who wish to dig in deeper can do so, rather than “this thing sucks, it doesn’t work at all, I give up” and the journey ends there. I have worked professionally as a software QA engineer for many years so I tend to focus on the faults and deficiencies, and a significant part of my work is trying to look at software from the perspective of a user. It’s difficult to just turn this off, I find bugs and problems in nearly all software I touch.

Again, I was not intending to criticize, I completely understand the challenges of achieving a polished user experience. I have developed a few open source projects myself that are far, far less complex than Home Assistant and I’ll be the first to admit that my documentation sucks. As with many engineers, once I solve the difficult technical problems I’ve been obsessing over I often have trouble finding motivation to tie up the loose ends and fix the stuff I planned to fix “later”.

Anyway I think it would be beneficial if at some point a scheduler was deemed “official” and became part of of the project. It would stand a better chance of maturing than half a dozen separate community ad-ons that duplicate a lot of each other’s goals.

1 Like