Climate scheduler

[alex-torregrosa]

Triggered from: home-assistant/home-assistant/pull/21017

It would be useful to add a scheduler to the climate component, specially for the generic_thermostat platform. You can actually do this by using automations in HA, but this way the ui would be more user-friendly.

It should enable the user to set rules triggering temperature changes at certain hours and days of the week. It could also be useful to add a sort of timer to manual temperature changes (making them last 1h for example), but that should be optional and enabled in the component configuration.

This could be done as a standalone componenent (see PR at the beggining) or integrate the functionality into the climate component. The standalone component approach would make sharing a single schedule between different climate entities easier.

[Misiu]

@b4dpxl can You send them to me via email or via PM on HA community? I don't want to spam this issue.

[Adminiuga]

They have time triggers, conditions (including for weekday

Is there a reason why time or time_pattern don't include weekday?

[ciB89]

Is there a plan to introduce a UI for managing scenes? Ofc all of this is already possible with the current methods, but implementing/chaning/editing a full-scaled schedule for multiple thermostats/rooms is just a pain in the a** doing it all in yaml

[bachya]

@ciB89 As you probably saw, 0.102.0 introduced a Scene Editor. 👍

I'm feeling the itch to start this, so I'm going to work on a back-end proof of concept. I think @balloob's idea – that a generic scheduler should focus on activating scenes – is a good MVP; we can always add other functionality (like activating automations, etc.) later on.

Here's what I'm thinking for back-end MVP:

• scheduler integration (we can always change the name)
• A schedule has three key properties: a scene ID, a start datetime, and an optional end datetime (not worrying about repeating schedules/etc. for now).
• The scene gets activated on the start datetime and, optionally, restored at the end datetime if it exists.
• Websocket endpoints for the front-end to talk to
• Services to create/delete schedules (so that automations can interact with the schedule)

Thoughts?

[Santobert]

@bachya that sounds great. I think this would be a good starting point. I'm not completely sure how to add things like conditions. Thinking about climates: when someone is at home and it's not weekend activate scene "heating" otherwise activate scene "heating_away".

I'm now asking myself what's the difference between schedules and automations 🙈

[bachya]

I'm now asking myself what's the difference between schedules and automations 🙈

Me too! 😆I think as we progress, it'll become clearer.

Conditions are absolutely valid and needed – I'll think on that after I have an MVP working.

[Santobert]

@bachya obviously. Let's get the first prototype running and see what's missing. I'll try to help as soon as I'm done with some other projects 😉

[Santobert]

I thought about this...

We already know that we want to apply scenes as soon as the scheduler triggers. That's fine, so far. Let's talk about conditions. We could build scenes depending on conditions.

For example: The climate climate.my_climate should change it's preset_mode according to a binary_sensor binary_sensor.someone_at_home. The resulting scene would look as follows:

name: my_climate_scheduler
entities:
  climate.my_climate:
    state: heat
    preset_mode: {%- if is_state('binary_sensor.someone_at_home', 'false') %} away {% else %} none {% endif -%}

As soon as some of the conditions change (binary_sensor.someone_at_home or start_datetime or end_datetime), the scene is rebuilt and applied.

I'm using Yaml and Jinja here because it's an easy way to express my thoughts. Of course we should build this in Python. I haven't finished thinking about it yet, but that would be a useful feature and it's something automation can't do right now (scene.create doesn't understand templates). Just an idea...

[bachya]

Started a draft: https://github.com/home-assistant/home-assistant/pull/28938 – nowhere near close to ready for anything, but has websocket endpoints to create/update/delete/clear scheduler entries. No feedback needed yet; just an FYI.

[bachya]

Alrighty, I have some more meat on the bone with home-assistant/home-assistant#28938. Lots of edge cases I'm missing, I'm sure, but let's see!

In preliminary testing (via the websocket API, since I'm not a front-end guy 😆), this seems to do what we want: I can schedule a scene activation to occur at a specific date/time and, optionally, schedule that scene to "unwind" at a different end date/time.

After successfully authenticating to the websocket API, you can perform these operations.

List Schedules

This endpoint lists all saved schedules.

Payload:

{
  "id": 123,
  "type": "scheduler/items"
}

Response:

{
  "id": 123,
  "type": "result",
  "success": true,
  "result": {
    "b88154e83f984f16bad3041a1bb069c4": {
      "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
      "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
      "entity_id": "scene.turn_on_bedroom_light_to_purple",
      "start_datetime": "2020-01-01T00:00:00",
      "end_datetime": null
    },
    "86000ebf4e7d486aa94f314e483bcd42": {
      "schedule_id": "86000ebf4e7d486aa94f314e483bcd42",
      "activation_context_id": "3956cfbe5d884010afd0cf0a6bd1de2e",
      "entity_id": "scene.goodnight",
      "start_datetime": "2020-01-01T00:00:00",
      "end_datetime": "2020-01-01T12:00:00"
    }
  }
}

Create Schedule

This endpoint creates a new schedule. The payload must include:

• entity_id: a scene entity ID
• start_datetime: the date/time for the scene to activate

...and can optionally include:

• end_datetime: the date/time for the scene to "deactivate" (i.e., for all of the entities affected by the scene to return to their previous state)

Payload:

{
  "id": 124,
  "type": "scheduler/items/create",
  "entity_id": "scene.turn_on_bedroom_light_to_purple",
  "start_datetime": "2020-01-01 00:00:00"
}

Response:

{
    "id": 124,
    "type": "result",
    "success": true,
    "result": {
        "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
        "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
        "entity_id": "scene.turn_on_bedroom_light_to_purple",
        "start_datetime": "2020-01-01T00:00:00",
        "end_datetime": null
    }
}

Update Schedule

This endpoint updates an existing schedule. The payload must include:

• schedule_id: the ID of the schedule to update

...and must include at least one of:

• entity_id: a scene entity ID
• start_datetime: the date/time for the scene to activate
• end_datetime: the date/time for the scene to "deactivate"

Payload:

{
  "id": 125,
  "type": "scheduler/items/update",
  "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
  "end_datetime": "2020-01-01 12:00:00"
}

Response:

{
    "id": 125,
    "type": "result",
    "success": true,
    "result": {
        "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
        "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
        "entity_id": "scene.turn_on_bedroom_light_to_purple",
        "start_datetime": "2020-01-01T00:00:00",
        "end_datetime": "2020-01-01T12:00:00"
    }
}

Delete Schedule

This endpoint deletes an existing schedule. The payload must include:

• schedule_id: the ID of the schedule to update

Payload:

{
  "id": 126,
  "type": "scheduler/items/delete",
  "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
}

Response:

{
    "id": 126,
    "type": "result",
    "success": true,
    "result": {
        "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
        "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
        "entity_id": "scene.turn_on_bedroom_light_to_purple",
        "start_datetime": "2020-01-01T00:00:00",
        "end_datetime": "2020-01-01T12:00:00"
    }
}

Clear Expired

This endpoint clears any expired schedules:

Payload:

{
  "id": 127,
  "type": "scheduler/items/clear_expired",
}

Response:

{
  "id": 127,
  "type": "result",
  "success": true,
  "result": {}
}

Other Items to Tinker On

Some other things I'm thinking about (in no particular order):

• It's easy to create a create_schedule service, but need to think on whether any of these other operations are useful as services.
• Right now, if an expired schedule exists in the JSON at HASS launch, an error will be logged. That shouldn't happen (since schedules get removed from the JSON when the complete), but need to think on that further.
• I need to complete tests, linting, and typing.

[Santobert]

Woho 🎉 great work. Just to understand you right: these are one-time schedules? It would be great if we could schedule things on a regular basis, i.e. weekly. Use case: turn on my climate every workday at 5pm. Is that currently possible?

[bachya]

From above:

• A schedule has three key properties: a scene ID, a start datetime, and an optional end datetime (not worrying about repeating schedules/etc. for now).

I definitely realize that repeating schedules are crucial to the eventual first release; wanting to get the MVP principles correct before I embark on that.

[Santobert]

Ohh sorry. I was too excited to read 🙈

[bachya]

No need to apologize! I'm excited, too. 👍

Going to get some sleep; hopefully I will dream of an elegant way to represent schedule recurrences. 😴

[Misiu]

@bachya that already looks awesome 🎉 Please also consider anacron times (as I described here https://github.com/home-assistant/architecture/issues/148#issuecomment-546864328). If you schedule a thermostat to set the temperature to 21 degrees as 5:00 PM but you lost the power or Raspberry rebooted at 4:59 PM and was offline at 5:00 PM then the temperature won't change. If you set the temperature to be 21 degrees between 5 and 9 PM then when the system starts it should check if there is a scheduler that had the start time before the system started and should activate it. I think this would be super useful.

[bachya]

@Misiu There are two separate (and equally valid) items to discuss in your suggestion: (1) how to ensure schedules are validated and (2) what format recurrence rules should take.

(1) is fairly straightforward: whenever HASS starts up, it should examine existing schedules and re-establish any active/valid ones. I need to test more, but in principle, that should already be in place.

(2) deserves some discussion. Using the cron format has some advantages – its "easy" to express complex schedules – but it’s more geared toward entry in a text file. We won’t be doing that here (not primarily, at least): we’ll be using some sort of UI to generate schedules and it may force the front-end to do an excess amount of translation work if cron is used.

[bachya]

After chatting with @balloob about (2), we’re going to go with representing recurrences via RFC5545 (https://tools.ietf.org/html/rfc5545), which is an already-established standard for representing this data structure.

This will require some rework of what I had previously, but it should make for more robust MVP.

More to come.

[Santobert]

I agree with @bachya. Cron it used to run a short running task multiple times per day/week/month. It would need some modifications to express time spans with it. A native calendar format should be more natural to use. Furthermore it would be easier to build a gui around it.

[bottiger]

@bachya Without knowing the internals of home assistant. Couldn't you (re)use triggers from automations for schedules, instead of time slots? This would make them much more flexibel.

Regarding, what to do at HA startup when using triggers. It is obviously not something that is easy to implement, by I think a good compromise would just be to implement an optional "coldStartup"/"boot" condition which the user could provide. If it evaluates to true the schedule is regarded as active on startup.

If you only start and end schedules with timeslots you can of course search for the correct state, but you will run into problems with this approach as soon as someone wants something more advanced. Like, don't turn the heat on when I'm not home.

Personally I like the trigger approach because it should be familiar to the user (and developers!). And if the user does not provide any "coldStartup" condition the schedular will just adjust itself within a cycle.

[bottiger]

@bachya One more thing. I took a look at you initial implementation. It seems like at the end of a schedule go back to the state before the scheduler started. While it's a good initial approach this can be a problem is there are more than two states of the entity.

I know that this probably isn't something one should focus on initially, but it's worth keeping in mind

[bob1de]

If you only start and end schedules with timeslots you can of course search for the correct state, but you will run into problems with this approach as soon as someone wants something more advanced. Like, don't turn the heat on when I'm not home.

The correct concept for making schedules depend on entity states would be conditions, not triggers. They can be checked anytime, both on startup and when one of the participating entities changes its state. At least this is something I learned during the development of Schedy and what users have to understand first.

[bottiger]

@efficiosoft Really? The main use case I have in my head is that I want my lights/heating/etc to be on during the evening and turn off during the night.

• I want it to turn on at a specific time, or when I arrive home early.
• I want it to turn off at 22:00, or when I push my "goodnight button" to shut off everything

If I represent "I'm home" as a condition I guess the system would need to poll for that all the time, in contrast to if you define it as a trigger. If it's a trigger it will be "triggered" once whenever the state of "I'm home" state changes.

And I'm not sure how you represent "I have pushed the goodnight button" as a condition either. I guess you could set a boolean value which then resets during the night, but it feels like hack.

[bob1de]

If I represent "I'm home" as a condition I guess the system would need to poll for that all the time, in contrast to if you define it as a trigger. If it's a trigger it will be "triggered" once whenever the state of "I'm home" state changes.

The condition would only need to be reevaluated when the home state changes as well. The issue with using triggers is that their purpose is to react to events that happen at some point (I'm not talking about events as on the HA event bus). However, a schedule needs to be able to determine whether it should be active at any time, not just be activated in response to some event. Otherwise, it wouldn't be able to be activated at startup and we could just use automations as we have them today.

[bachya]

For MVP, the scheduler is going to focus on scheduling scenes (activating them and optionally unwinding them).

Automations and scripts aren’t a great fit:

1. Automations and scripts can be infinitely complex; if we want to “unwind” an automation, HASS would have to understand all possible unwinding scenarios, which is a huge undertaking.
2. Automations aren’t great candidates to be scheduled because, as already pointed out, their triggers and conditions already form a sort of “schedule.“ Want to turn on your lights when you get home? Create an automation.

I see a world where people can use all of these simultaneously. In my case, my house has:

1. scenes that will benefit from the scheduler (allowing me to remove extraneous automations that exist just to trigger/unwind those scenes)
2. automations that don’t need to be “scheduled” and can be left as-is
3. Schedy instances to handle the hyper-complex cases not covered by (1) and (2)

I can see a v2 of the scheduler that includes support for conditions (in which I will definitely attempt to make use of the existing condition support for automations), but that will be after the MVP.

I’m closing in on a v1 of recurrences (allowing for more complicated repetitions of schedules). Will hopefully share today.

[bob1de]

I can see a v2 of the scheduler that includes support for conditions (in which I will definitely attempt to make use of the existing condition support for automations), but that will be after the MVP.

With that in place, the schedules could have functionality similar to that of Schedy, but with the known semantics of HA conditions. Can't wait to see something like that.

[bob1de]

@bachya Just something that came to my mind: Isn't solely relying on conditions, even for start and end time and repititions an option as well? A quick glance at the docs of the time condition show that it could benefit from some more options, e.g. for month or year, but actually the time condition is something users are already familiar with and that way, a schedule could be activated by anything we have a condition for (esp. cool for sun or state) without any extra work or new syntax.

EDIT: Of course I'm not against the idea of such a schedule activating a scene, just to make that clear.

[bottiger]

I'm going to try to recap how I understand this:

@efficiosoft As I understand it, the main property you would like a system to have is: Be able to have a deterministic starts & stops so you can determine if it should be running without knowing the current state. i.e. after reboot/at startup. I think this is a reasonable property to pursue, albeit I don't feel I need it.

The property I am pursuing is instead: I really would like to transition my devices to the state they should be in now. The typical example is when you want to enable scene A for 5 minutes. You store the current scene B, transition to scene A, and after 5 minutes you can go back to scene B. However, depending on the circumstances this may or may not be correct.

In other words: I would like to write an automation which says: "Turn the light green for 5 minutes, and the go back to whatever state the scheduler thinks you should be in". Today the automation needs to keep track of every possible state the light could be in after 5 minutes have past.

@bachya Regarding "unwinding", I don't understand why it's so complex. Obviously you cannot unwind to something you don't know, but you can unwind to an active schedule - which is exactly the property I am looking for.

Admittedly there are some limitations, for instance: What happens if there are multiple active schedules ? (Why I would like to give them an optional priority)

Want to turn on your lights when you get home? Create an automation.

I think the statement above is a bit misunderstood. I can of course create an automation which turns on the correct scene when I come home, but if I ever change that scene I may have trouble coming back (unless the scheduler has started in the meantime). That said, I really think this is a minor issue for now.

[bob1de]

I'm going to try to recap how I understand this:

Thanks, that's great since I sometimes am not sure whether I can clearly express what I want to in English.

@efficiosoft As I understand it, the main property you would like a system to have is: Be able to have a deterministic starts & stops so you can determine if it should be running without knowing the current state. i.e. after reboot/at startup. I think this is a reasonable property to pursue, albeit I don't feel I need it.

Exactly, I think it's crucial for a schedule to be applicable solely based on current time/state/whatever and not on a trigger.

The property I am pursuing is instead: I really would like to transition my devices to the state they should be in now. The typical example is when you want to enable scene A for 5 minutes. You store the current scene B, transition to scene A, and after 5 minutes you can go back to scene B. However, depending on the circumstances this may or may not be correct.

In other words: I would like to write an automation which says: "Turn the light green for 5 minutes, and the go back to whatever state the scheduler thinks you should be in". Today the automation needs to keep track of every possible state the light could be in after 5 minutes have past.

That's an important feature imho, however I would say it's not strictly related to schedules, it's rather a manual intervention. The reverting of a scene activation could get its own service call (maybe scene.rollback or something) which would then execute the unwinding logic @bachya implemented. Your automation could then activate a scene, delay for five minutes and finally call the rollback service. It then wouldn't matter whether the previous state was achieved by a schedule or not.

Does this make sense?

[bachya]

@efficiosoft:

@bachya Just something that came to my mind: Isn't solely relying on conditions, even for start and end time and repititions an option as well? A quick glance at the docs of the time condition show that it could benefit from some more options, e.g. for month or year, but actually the time condition is something users are already familiar with and that way, a schedule could be activated by anything we have a condition for (esp. cool for sun or state) without any extra work or new syntax.

The only challenge is that this syntax doesn't handle recurrences (9-10am every other Thursday). Additionally, we're envisioning some sort of calendar UI for this (using RFC5545 as the standard), so schedules won't be created through YAML. That doesn't mean we can't look at using the concept for dynamic times – like sunset – post-MVP.

[bachya]

Alrighty, round 2 has just been pushed to the PR – this is my first attempt at recurrences (using RFC5545 as the standard).

After successfully authenticating to the websocket API, you can perform these operations.

List Schedules

This endpoint lists all saved schedules.

Payload:

{
  "id": 123,
  "type": "scheduler/schedules"
}

Response:

{
  "id": 123,
  "type": "result",
  "success": true,
  "result": {
    "b88154e83f984f16bad3041a1bb069c4": {
      "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
      "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
      "entity_id": "scene.turn_on_bedroom_light_to_purple",
      "start_datetime": "2020-01-01T00:00:00",
      "duration": null,
      "rrule": null
    },
    "86000ebf4e7d486aa94f314e483bcd42": {
      "schedule_id": "86000ebf4e7d486aa94f314e483bcd42",
      "activation_context_id": "3956cfbe5d884010afd0cf0a6bd1de2e",
      "entity_id": "scene.goodnight",
      "start_datetime": "2020-01-01T00:00:00",
      "duration": null,
      "rrule": null
    }
  }
}

Create Schedule

This endpoint creates a new schedule. The payload must include:

• entity_id: a scene entity ID
• start_datetime: the date/time for the scene to activate

...and can optionally include:

• duration: the length of time (in seconds) that the schedule lasts for. Including it will reverse the scene activation when that duration is hit; omitting it will leave reversal out.
• rrule: an RFC5545-compliant recurrence string

Let's look at some examples.

Turn on a scene this Christmas at noon

Payload:

{
  "id": 124,
  "type": "scheduler/schedules/create",
  "entity_id": "scene.turn_on_bedroom_light_to_purple",
  "start_datetime": "2019-12-25 12:00:00"
}

Response:

{
    "id": 124,
    "type": "result",
    "success": true,
    "result": {
        "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
        "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
        "entity_id": "scene.turn_on_bedroom_light_to_purple",
        "start_datetime": "2019-12-25 12:00:00"
        "duration": null,
        "rrule": null
    }
}

Turn on a scene this Christmas at noon and reverse/undo it 1 hour later

Payload:

{
  "id": 124,
  "type": "scheduler/schedules/create",
  "entity_id": "scene.turn_on_bedroom_light_to_purple",
  "start_datetime": "2019-12-25 12:00:00"
  "duration": 3600,
}

Response:

{
    "id": 124,
    "type": "result",
    "success": true,
    "result": {
        "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
        "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
        "entity_id": "scene.turn_on_bedroom_light_to_purple",
        "start_datetime": "2019-12-25 12:00:00"
        "duration": 3600,
        "rrule": null
    }
}

Turn on a scene this Christmas at noon, reverse/undo it 1 hour later, and repeat that every 2 days

Payload:

{
  "id": 124,
  "type": "scheduler/schedules/create",
  "entity_id": "scene.turn_on_bedroom_light_to_purple",
  "start_datetime": "2019-12-25 12:00:00"
  "duration": 3600,
  "rrule": "FREQ=DAILY;INTERVAL=2"
}

Response:

{
    "id": 124,
    "type": "result",
    "success": true,
    "result": {
        "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
        "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
        "entity_id": "scene.turn_on_bedroom_light_to_purple",
        "start_datetime": "2019-12-25 12:00:00"
        "duration": 3600,
        "rrule": "FREQ=DAILY;INTERVAL=2"
    }
}

Note that the rrule format is defined by RFC5545; in our case, we'd anticipate that it would be created by some sort of calendar UI.

Update Schedule

This endpoint updates an existing schedule. The payload must include:

• schedule_id: the ID of the schedule to update

...and must include at least one of:

• entity_id: a scene entity ID
• start_datetime: the date/time for the scene to activate
• duration: the length of time (in seconds) that the schedule lasts for. Including it will reverse the scene activation when that duration is hit; omitting it will leave reversal out.
• rrule: an RFC5545-compliant recurrence string

Payload:

{
  "id": 125,
  "type": "scheduler/schedules/update",
  "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
  "duration": 7200
}

Response:

{
    "id": 125,
    "type": "result",
    "success": true,
    "result": {
        "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
        "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
        "entity_id": "scene.turn_on_bedroom_light_to_purple",
        "start_datetime": "2019-12-25 12:00:00"
        "duration": 7200,
        "rrule": "FREQ=DAILY;INTERVAL=2"
    }
}

Delete Schedule

This endpoint deletes an existing schedule. The payload must include:

• schedule_id: the ID of the schedule to update

Payload:

{
  "id": 126,
  "type": "scheduler/schedules/delete",
  "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
}

Response:

{
    "id": 126,
    "type": "result",
    "success": true,
    "result": {
        "schedule_id": "b88154e83f984f16bad3041a1bb069c4",
        "activation_context_id": "6f9991fea5c24d6f9fd5489ed104c808",
        "entity_id": "scene.turn_on_bedroom_light_to_purple",
        "start_datetime": "2020-01-01T00:00:00",
        "duration": 7200,
        "rrule": "FREQ=DAILY;INTERVAL=2"
    }
}

Things I'm still chewing on:

• Need to cancel an instance
• Still thinking on what to do if HASS reboots in the middle of a schedule

[Santobert]

That looks really great! Thanks @bachya

[Misiu]

• Still thinking on what to do if HASS reboots in the middle of a schedule

And what in situation when HASS reboots just before schedule should start and starts after schedule should start (power off at 4:58 PM, start at 5:10 PM, the schedule should start at 5:00 PM)?

[bottiger]

@efficiosoft is of the (reasonable) oppinion that you should be able to test if the schedule should be running at any time. i.e. at 5:10 PM - when HASS has started - it can test all the defined schedules so see if they should be running or not.

[bob1de]

The only challenge is that this syntax doesn't handle recurrences (9-10am every other Thursday). Additionally, we're envisioning some sort of calendar UI for this (using RFC5545 as the standard), so schedules won't be created through YAML. That doesn't mean we can't look at using the concept for dynamic times – like sunset – post-MVP.

Well, the time condition syntax could be extended to handle this (automations would benefit from it as well), but I see that the RFC5545 syntax may be easier to parse for using it in a GUI. It seems like the general direction of Hass goes away from YAML and towards JSON and GUI-only management (which I personally don't like at all), but that's another story.

[electrofloat]

It seems like the general direction of Hass goes away from YAML and towards JSON and GUI-only management (which I personally don't like at all), but that's another story.

The exact opposite: https://www.home-assistant.io/blog/2019/10/10/release-100/#goodbye-json-

[bob1de]

The exact opposite: https://www.home-assistant.io/blog/2019/10/10/release-100/#goodbye-json-

Ah, good to know. But I was not talking about the particular serialization format used to enter data in the GUI, rather about the general fact that there are things you can only manage using the GUI (like these schedules or the ZWave config imported from YAML into JSON storage).

[bachya]

@efficiosoft Appreciate the feedback. We'll keep an eye on things; post-MVP, if there's a need for some other entry method (services, a YAML file, etc.), we'll certainly take a look.

[balloob]

As we did with the person integration etc, we can allow schedules to be defined in YAML.

[Ambidexter211]

Keep in mind that an ideal, generic schedule feature would be able to work with any integration. Turn on / dim / off my lights at certain times, and when certain events happen. Turn up the volume on my media player when there are 10 people shopping in my store, etc.

But then we end up with regular automations, more or less.

I suppose it would be useful if automations could be...nested or atomic, that is, separate pieces of automations that are either subroutines/functions or macros. Once I get a function that turns on a lamp and sets the brightness to 70% brightness (or +20% brightness), I could call that atomic routine from any automation by passing the light or other entity, and the brightness value, and get a return of the current brightness of the entity.

This is certainly easy to do in Python, but maybe we need a library of such Python primitives that are callable by YAML automations?

Anyway, thanks for all your work folks!

Cheers,

Ambi

[Misiu]

@bachya awesome piece of work! what's the status of this PR? Any plans to move this forward? No pressure at all, just wondering when this might be added. I think that many users will be happy to have Scheduler in Home Assistant 🙂

[bachya]

@Misiu It will be a bit; appreciate your patience. @balloob wanted to review the use case architecture before we proceeded further and he has a lot on his plate.

[antonverburg]

Maybe I miss something, but did somebody already think about the fact that some processes take a lot of time? For example, if heating a room, a user preferably wants to tell the system when the room has to be on temperature. This means that the scheduler has to start long time before this time with heating the room, so that it is on temperature in time. I actually wrote a script that reads a google-calendar via the calendar integration, and that can predict how long to heat before it is on temperature (depending on outer temperature, and in future I also want to add wind speed & direction). Did we already take this prediction-features in account for the design of the scheduler?

[bachya]

@antonverburg Prediction is way outside of an MVP. On day 1, I would expect people to use the scheduler with these predictions implied (e.g., if you know that it takes your house an hour to heat up to where you want it by 5pm, add a schedule that starts at 4pm).

[Misiu]

@bachya what's left to do. The API looks almost complete. With backend ready work on front end could be started.

[bachya]

@Misiu I've paused on this after discussion with @balloob – it needs more consideration before we can say the back- end is “done.”

[fjufju]

@bachya any updates/decisions about this? I really hope scheduler will be added in near future releases. This would be an awesome feature!

[bachya]

Given the pause on this, I’ve moved on to other projects.

[fjufju]

thank you for info. I hope this will be added soon :)

[Misiu]

There is an alternative for now: https://github.com/nielsfaber/scheduler-component https://github.com/nielsfaber/scheduler-card

Detailed description here

[virgilm]

This is absolutely needed in HA! How can you have a home automation system without a scheduler?

Options I found:

• Scheduler component above: nice, actively developed, but still not fully functional for my needs.
• Schedy - really nice and flexible, but no front end. Also, appdaemon, not HA.