Scheduler card/custom component

Hi Lionel :slight_smile:
I have to ask you, once again, for your patience.
There are some bugs in the conditions, I’m making some big changes to fix them.
In the mean time, you can try to follow these steps to define the options to choose from. It should work with input_select.

Nothing urgent, I’ll wait for the next update and I’ll tell you…

Overall bravo, everything works pretty well. There may be a few cosmetic points or tweaks, but here again we’ll wait for the next version.

You have it written in the error it reports. Install the scheduler component and add it in the integrations. A few posts above.

Remove the resources part in configuration, and go to configuration in the sidebar > lovelace dashboards > resources on the top of the page > click the plus on the bottom right > add the link to the scheduler card.


The Add button is not visible for a non-admin user. On the other hand button yes, and it would be interesting to hide it…


Migration to websockets is in progress, which I believe will allow non-admin users.

I’m having a hard time to provide backwards compatibility between the upcoming release of the scheduler-component and the current version.
It looks like I am not able to transfer the existing schedules to the new format, implying that updating would result into a one-time loss of all schedules.

I only have like 15 rules myself, so it would take me 1 or 2 minutes and some screenshots to transfer them, but I have no idea how much annoyance this would be for you.
Is it acceptable for you to manually recreate your schedules after updating?

How about automatically creating a human-friendly backup text file if it detects that the schedules are from an older version, and showing a notification that you need to recreate your schedules?

Fine for me. Will take just a few minutes

I don’t really want to start a technical discussion here.
Spent quite some time trying to create a smooth transition, but I don’t see a way.

Got it. Hopefully no one gets surprised when they lose their schedules.

Nope for me :slight_smile:
It is easy and anyway some new ideas pop up…
Best, JR

Thank you so much for such an AWESOME custom component!!!
Is there a way to remove all schedules with an automation?
My use case: after leaving the house for more than x hours, I assume I won’t come back before weeks so I want to remove all the schedulers which I use for my radiators. To make it simpler, today I use this custom component only for my radiators.

The schedules are stored as switch entities in HA.
As far as I know there is not really a way to delete entities using an automation.
Why wouldn’t you just disable them while you’re on holidays?
This is exactly intended for such use-case.

I see there is a service attached to the scheduler component to remove a switch entity. I guess I could use that with a loop on all switch which respect a certain name format. What do you think? But I am not sure I am good enough in yaml to write this loop…

My goal is to automate it so that it prevents people from forgetting to shut down the radiators. :slight_smile:

The easier option is to just set up an automation to call switch.turn_off on each schedule entity.

If you want to turn off a set of schedules, add them to a group and use homeassistant.turn_off on the group.

Hello all,
I just created beta releases of the new versions:

  • scheduler-component v3.0.0b
  • scheduler-card v.2.0.0b

These updates will lift the scheduler integration to the next level! :rocket:

The scheduler-component has been completely restructurized for allowing the configuration of schedules to be stored in a (json) file.
This file is called “” which will live in the .storage folder of your HA config directory.
This storage method is in-line with modern HA integrations and hopefully future-proof.

Previously all configuration was stored as attributes (in a compact way) in the switch.schedule entities, and was read from these entities by both the scheduler-component and the scheduler-card.
This imposed quite some limitations and made it difficult to add new features in the component without causing compatibility issues.

The .storage folder is also included in the HA snapshots, so this change also provides a backup+restore function, which was previously non-existent.

Another big change is the migrations to the Websocket API, which allows back-and-forth communication between the scheduler-component and the scheduler-card.
Previously, the scheduler-component hosted some services which were used by the scheduler-card as one-directional communication channel.
The new method makes it much easier (and quicker) to show and update schedule configuration in the card, but also provides diagnostics: i.e. you will be notified if something went wrong or the component is not installed.

New features
Some other changes which don’t need a lot of story-telling, but are maybe more noticeable for you:

  • You can now select multiple entities (of the same type) when creating a schedule.
  • The entity_ID of a schedule is now no longer limited to switch.schedule_123456 etc. The xxxxxx will be automatically replaced by the friendly-name if you provide it in the card, to make it easier for you to identify your schedules (and use them in automations if desired).
  • I made some changes to the way conditions are created. It is no longer needed to define the ‘states’ configuration. I’m planning to extend the support in the some future updates, so WIP.
  • You can now choose to delete a schedule automatically after it triggers. So you can now use scheduler for planning a one-time task.

Last but not least
The new version is a beta release, which implies that installing it comes with some risk.
Transferring your existing schedules to the new version is a bit tricky.
I tried to find a way to migrate the old entities to the new format (which literally means copy-pasting them), but it is a bit experimental.
I would like to ask for a couple of brave heroes to try out updating to the new release (please read the release notes), and let me know if the updating went without issues.
In case your schedules are precious to you: I recommend to take some screenshots of your schedule config before updating, so you could re-create them if needed.


Ok understood.

  1. is it possible for an HA user who is not an admin to add a new schedule from the card? I do not see the Add option from the HA user account.

  2. let’s say 1. is solved and any user can add a schedule. I might not know the switch entity id so is there a way with wildcard maybe to switch all of them?

I upgraded to beta and all my plans and features seem to remain. I only have a few lights to test, but everything still works fine. Maybe I just missed it, but what is the multiple button?

I already understand. It is about adding more entities.

I installed the beta and it’s all gone smoothly for me - so smoothly that I went back to double-check that I had updated it properly!

I haven’t had time to look at the new features in-depth but so far everything seems to be working well.

ETA: I’ve managed to produce an error:

Something went wrong!
Message format incorrect: extra keys not allowed @ data['timeslots'][0]['type']

Response error: 400

Here’s my schedule:

                "schedule_id": "d71fc5",
                "timeslots": [
                        "start": "22:00:00",
                        "stop": null,
                        "conditions": [
                                "entity_id": "sensor.bedroom_curtemp",
                                "attribute": "state",
                                "value": 20,
                                "match_type": "below"
                        "condition_type": "or",
                        "actions": [
                                "service": "light.turn_on",
                                "entity_id": "light.bed_blanket_switch_rgb_switch",
                                "service_data": {}
                "weekdays": [
                "repeat_type": "repeat",
                "name": "Bed Blanket On",
                "enabled": true

I received the error after trying to add a condition to test if binary_sensor.anyone_home is on, in “all” mode. If I switch to “any” mode I don’t receive an error.