Scheduler card/custom component

Are variable time schedule through input_datetime or datetime entity supported?
I could not find any options in the card or any examples.

For example, one use case could be to use the next alarm from the companion app to define a time slot.

Thanks for this great custom component!

Hey all! Sorry for repost but I will ask this again. Is it possible to create a schedule that is period based rather than time based? What I mean by that is that sometimes (a lot of times) I want to turn on my AC unit just for let’s say an hour starting now. With my current knowledge of the extension I would have to create a schedule (or use one I st up for this use-case) and adjust start and finish of it. I know I can do it with automation but my goal is to have all schedule related entities, rules, triggers in one place one component. Is something like that possible?

1 Like

Currently not, but I am planning to add support for a date picker.
It is mostly meant for defining a date range as a condition, but it would also be useful for input_datetime.

No, this is not in scope for scheduler.
I do understand it could be practical, but the main issue is that I don’t see how it can fit in the GUI without introducing extra complexity.
If you have a nice idea on how it should look like in the card, please open a feature request on GitHub to share and discuss it.

1 Like

Hi Neliss, Thanks for clarification. I’ll think about how I see this feature and if it can be fit nicely to the card. Thanks again for all your work.

Hello,

I use scheduler card with climate. I use a schedule for heating. I would like to use weather forcast for modify timeslot (edit start of timeslot). It is possible modify timeslots in automation/script? How to reload schedule if it is modified the scheduler.storage file without restart HA? Thank you.

Hello,

How to install all dependecies and build files from repository? Thankyou.

I would like to use weather forcast for modify timeslot (edit start of timeslot).
It is possible modify timeslots in automation/script?

It is not easy to change the start of a timeslot depending on weather conditions.
The only supported function is to have scheduler skip a timeslot in case of some weather condition.
The weather entities of HA currently are not showing up in the card for using with conditions, but this could be added if you want that.

If you really want to modify a schedule on-the-fly, you need to use the scheduler.edit service.
You will need to give the entire schedule configuration (not just your changes) to this function though.

How to reload schedule if it is modified the scheduler.storage file without restart HA? Thank you.

This is not possible, storage files are only read on startup (this is true for all integrations).

How to install all dependecies and build files from repository? Thankyou.

For scheduler-card you can install dependencies using:

npm i

and then you can compile it (to scheduler-card.js in the dist folder) using:

npm start

For the scheduler-component dependencies / building are not applicable, just run it as component in HA.

I just want to thank the maker of this scheduler card for his effort to make this card. I started yesterday
to use this card and I think it has to integrated in HA itself because it is a basic function for home automation.
This Scheduler card is easy to install and easy to use.
Thanks.

2 Likes

Thank you very much.
It is possible reload a selected time scheme for loading of new data? I was looking into init.py, there is function async_service_edit_schedule. It is possible call this function from other python script and reload data the selected time scheme, I use Appdaemon, (It is possible use it? Or listen changing of state other component (input boolean, input text, …) and reload selected time scheme?). Thank you.

I am trying to get started with npm so that I can compile the card in an attempt to fix this issue. I cloned the repository, installed npm and ran npm i. I am stuck with an error, would appreciate any guidance.

First npm i complains:

npm WARN [email protected] requires a peer of rollup@>=0.66.0 <2 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

audited 346 packages in 3.184s

54 packages are looking for funding
  run `npm fund` for details

found 1 high severity vulnerability
  run `npm audit fix` to fix them, or `npm audit` for details

I tried dealing with the “requires a peer of” warning and wound up in a cycle of:

$ npm install --save-dev "rollup@>=0.66.0 <2"

npm WARN @rollup/[email protected] requires a peer of rollup@^2.22.0 but none is installed. You must install peer dependencies yourself.

$ npm install --save-dev "rollup@^2.22.0"

npm WARN [email protected] requires a peer of rollup@>=0.66.0 <2 but none is installed. You must install peer dependencies yourself.

So then I tried ignoring that warning and just running npm start, which produces:

rollup v2.56.2
bundles src/scheduler-card.ts → dist...
[!] (plugin rpt2) Error: /home/moshe/git/scheduler-card/src/standard-configuration/cover.ts(106,82): semantic error TS2345: Argument of type 'string' is not assignable to parameter of type 'FrontendTranslationData'.
src/standard-configuration/cover.ts
Error: /home/moshe/git/scheduler-card/src/standard-configuration/cover.ts(106,82): semantic error TS2345: Argument of type 'string' is not assignable to parameter of type 'FrontendTranslationData'.
    at error (/home/moshe/git/scheduler-card/node_modules/rollup/dist/shared/rollup.js:151:30)
    at throwPluginError (/home/moshe/git/scheduler-card/node_modules/rollup/dist/shared/rollup.js:19344:12)
    at Object.error (/home/moshe/git/scheduler-card/node_modules/rollup/dist/shared/rollup.js:19994:20)
    at Object.error (/home/moshe/git/scheduler-card/node_modules/rollup/dist/shared/rollup.js:19520:38)
    at RollupContext.error (/home/moshe/git/scheduler-card/node_modules/rollup-plugin-typescript2/src/rollupcontext.ts:37:18)
    at lodash_3 (/home/moshe/git/scheduler-card/node_modules/rollup-plugin-typescript2/src/print-diagnostics.ts:41:11)
    at arrayEach (/home/moshe/git/scheduler-card/node_modules/rollup-plugin-typescript2/node_modules/lodash/lodash.js:516:11)
    at _.each (/home/moshe/git/scheduler-card/node_modules/rollup-plugin-typescript2/node_modules/lodash/lodash.js:9342:14)
    at printDiagnostics (/home/moshe/git/scheduler-card/node_modules/rollup-plugin-typescript2/src/print-diagnostics.ts:9:2)
    at Object.transform (/home/moshe/git/scheduler-card/node_modules/rollup-plugin-typescript2/src/index.ts:234:5)

help?

Just use the service scheduler.edit. It calls the service async_service_edit_schedule.
Can also be done via Appdaemon.

I’m also seeing those warnings and have been ignoring them for a while to be honest.
I haven’t found the time yet to dive into this, but as long as they are warnings only this is not critical.

The custom-card-helpers repo is poorly maintained and the last version contains a bug.
You can roll back via:

npm uninstall custom-card-helpers
npm install [email protected]

This should do the job!
Please comment out terser in the rollup.config file while working, it speeds up compilation.
Make sure that the /dist/scheduler-card.js is being used by HA.
Thanks in advance for helping out, it is much appreciated :+1:

I discovered this card today after looking for something similar a while ago.
It really beats me how something like this is not being implemented by default by home assistant. This is basic automation that ANYBODY with home automation will have to use sooner or later, and put in a beautiful, simple and powerful interface.

2 Likes

I’m also mainly interested in the “single run” use case. Right now achieving it by using time scheduling + “Delete” optional behavior after triggering, but it’s a bit cumbersome.

Do you think adding a scheduling option, something like an “Only once” option to the “Daily”, “Workdays”, “Weekend”, “Custom” list, could work? “Daily” could still be the default option. This would make things easier for us.

As a plus, if “Only once” is selected, an option to select between period or time based scheduling could appear. This would keep main use cases untouched, while making the tool more powerful.

I can open a more detailed feature request if useful.

Thanks for the great work!

I’m planning on adding to option to define a specific date + time, indeed next to daily/weekend etc modes.
With a specific date set, repeating the task is not very logical, so in this case the execute once+delete option would be set automatically.
It could take a while before I can get to this though…

1 Like

There is something wrong with my configuration.
A long time ago I was able to set the brightness value in the scheduler. Now it is not possible anymore for all my deCONZ dimmable devices.

Inside the scheduler.storage file I can see that it was possible to configure via GUI.

            {
                "schedule_id": "d35ddd",
                "timeslots": [
                    {
                        "start": "sunset+00:06:00",
                        "stop": null,
                        "conditions": [],
                        "condition_type": null,
                        "actions": [
                            {
                                "service": "light.turn_on",
                                "entity_id": "light.gartenspots",
                                "service_data": {
                                    "brightness": 51
                                }
                            }
                        ]
                    }
                ],
                "weekdays": [
                    "daily"
                ],
                "repeat_type": "repeat",
                "name": "Gartenspots Licht",
                "enabled": true
            },

Just for your information. It seems to be that only deCONZ devices are affected.

I can see that the attribute supported_color_modes don’t contains the value “brightness”. Just the value “color_temp”.

Does anyone have any idea why this is suddenly the case? Did I skip a changelog?

The card checks for SUPPORT_BRIGHTNESS property in the entity.
It can be seen by checking in developer tools → entities the properties of your affected light entity (e.g. light.gartenspots).
There should be a supported_features property, which should be an odd number if it supports dimming.
See also: developer docs and light entity.
Note that the supported_features will be replaced by the supported_color_modes soon. I still need to update the card for this.
Perhaps your deconz integration is already ahead of this replacement?

Thank you for your explanation.
It looks like that deCONZ was updated in July: History for homeassistant/components/deconz - home-assistant/core ¡ GitHub

But I don’t understand why the supported_features are wrong. There should be odd numbers, because the bulbs are dimmable (and much more).

min_mireds: 140
max_mireds: 650
effect_list:
  - colorloop
supported_color_modes:
  - color_temp
  - hs
  - xy
is_deconz_group: false
supported_features: 44

It looks like there is a problem on the side of Deconz.
The supported_features lacks the brightness option, and also the supported_color_modes lacks brightness.
So scheduler-card has no way to see that this light can be dimmable.

I’m guessing you also don’t see a brightness slider like this in Home assistant:
image

If so, please make a report of this problem in the core repo.
Since it might take a while before this is picked up, I suggest to add this to scheduler-card to add the action manually in the meantime:

type: custom:scheduler-card
# rest of configuration...
customize:
  light.gartenspots:
    actions:
      - service: light.turn_on
        name: "Turn on with brightness"
        variables:
          brightness:
            min: 0
            max: 100
            scale_factor: 2.55
            unit: '%'

I don’t have problems in the GUI. I am having the brightness slider anywhere.

But thanks for your help. I will make an issue in the core repo.

@neliss my automations are based on scheduler component 2.1.1 where each time slot was defined with ending time at the schedule -entity like this:

entries: 0DT0100T0800A0, 0DT1400T2000A0

Now my problem is that I can’t update home assistant anymore without changing to newer scheduler component.

Is there any way to activate the old 2.1.1 style of showing the timeslots on the entity with the newer versions of scheduler component?

Longer explanation/reasoning for this:
It is much easier to build custom node-red automations on the old timeslot style. I use scheduler following way to build node-red automation:

  • I define timeslot for my input_number.water_heater from 00:00 to 07:00 to set value 2
  • Node-red automation fetches nordpool electricity prices and looks for the 2 cheapest hours between 00:00 and 07:00 and triggers heating on these hours.

With new 3.0.0 and newer method to show only the start time, I would need to define every slot between heating “zones” to 0 and make the automation to seek the end time much more complicate way by the 0 value.