Scheduler card/custom component

[gagga]

Great. Will this be installed by HACS as well?

UPDATE: Yes. It gets updated by HACS as well and works perfectly fine for me. Thanks for all your great work!

[123 (Taras)]

Thank you! That eliminated the error message and the card is now displayed correctly.

[123 (Taras)]

I’m unable to install the custom_component; it doesn’t appear in the list of available integrations.

I followed the manual installation instructions: download zip file, extract all files into custom_components/scheduler, restart Home Assistant. I know Home Assistant is aware of the scheduler component because the log reports the boilerplate message about custom components:

You are using a custom integration for scheduler which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.

Using:
Configuration > Integration > +
I typed sched and there’s no matching integration available.

I tried installing it on another instance of Home Assistant and got the same result. There’s nothing in the log beyond the message shown above. What did I do wrong? Alternately, what additional information do you require to help debug this issue?

[KTibow (Kendell R)]

Try clearing your cache and refreshing.

[123 (Taras)]

Arrgh! That was it!

Thank you!

[neliss]

Ooff, you are very unlucky with all these issues
Glad you got it running finally, hopefully you won’t face more disappointments.
I’ll try to keep improving the user experience, but it might take a bit more of your patience

[123 (Taras)]

The manual installation instructions for scheduler-card indicate the following:

Add a reference to the card in the resources section of ui-lovelace.yaml:

resources:
 - url: /local/scheduler-card/scheduler-card.js?v=0
  type: module

However, since version 0.107, the resources section moved to configuration.yaml.

If you put it in ui-lovelace.yaml, you get this warning in the log:

Resources need to be specified in your configuration.yaml. Please see the docs

[123 (Taras)]

@neliss

you are very unlucky with all these issues

Very unlucky indeed. Now the scheduler-card is no longer working.

The resources are defined in configuration.yaml:

Duplicating the same definition in ui-lovelace.yaml (and then restarting) doesn’t help Home Assistant find the card (nor does clearing the browser cache). On a positive note, the Scheduler integration is installed:

I’ve also had no luck getting the scheduler-card to be found on a second instance of Home Assistant. That one doesn’t use Lovelace in YAML mode so I defined the resource in Configuration > Lovelace Dashboards > Resources.

If I follow steps 6-9 of BrianHanifin’s instructions (posted above) to add a custom card, the search fails to find anything starting with “Sched”. If I try using Manual to add the card, it also fails to find
- type: custom:scheduler-card

---

EDIT

I can’t be certain if that error message in the screenshot posted above is related to the scheduler card. I tried it again and this time there’s no message in the browser console.

[KTibow (Kendell R)]

It shows you used
/local/scheduler-card/scheduler-card?v=0
but it wants
/local/scheduler-card/scheduler-card.js?v=0

[123 (Taras)]

I followed the instructions provided by neliss in this post. I guess that was a typo.

I can confirm that adding .js fixed the problem for the first instance (the one using Lovelace in YAML mode; plus it’s entered in configuration.yaml, not ui-lovelace.yaml) and it now displays the scheduler card. As for the second instance, it doesn’t quite work the way BrianHanifin’s instructions describe. Searching for a Scheduler card produces nothing. I have to select ‘Manual’ and fill in the type value:

Hopefully, everything that can go wrong has already gone wrong and now it’s smooth sailing.

[KTibow (Kendell R)]

I contributed that ability, when @neliss switched to typescript he forgot to add it back.
Here’s the commit:

Update scheduler-card.js

[juan11perez (Juan)]

@neliss
Just wanted to say thank you for this great component. I’ve been using HA for over 3 years and this simplified functionality is very welcome.

[guims78 (guims)]

Hello, i’m trying to setup a scheduler with a generic thermostat, but it seems to be not well defined.
I setup 2 action with the service climate.set_temperature but what’s wrong ?

domains:
  climate:
    actions:
      - icon: icon-heat
        service: climate_set_temperature
        data_template:
          temperature: '{{ states.input_number.consigne_confort.state }}'
      - icon: icon-off
        service: climate_set_temperature
        data_template:
          temperature: '{{ states.input_number.consigne_eco.state }}'
    icon: thermometer
type: 'custom:scheduler-card'

Maybe you can add an example of thermostat setup in the doc in gitub ?

[neliss]

@123

I followed the instructions provided by neliss in this post. I guess that was a typo.

I can confirm that adding .js fixed the problem for the first instance (the one using Lovelace in YAML mode; plus it’s entered in configuration.yaml, not ui-lovelace.yaml) and it now displays the scheduler card. As for the second instance, it doesn’t quite work the way BrianHanifin’s instructions describe. Searching for a Scheduler card produces nothing. I have to select ‘Manual’ and fill in the type value:

Hopefully, everything that can go wrong has already gone wrong and now it’s smooth sailing.

Sorry about the typo, my bad

Little bit of a positive note about the frustrations: by finding these f*ckups improvement points and sharing these, you are helping with the development of this card/component.
I would like give all of you a good experience setting it up and working with it, but it will take some time to get everything right.

Making the card configurable through UI (no yaml skills required) is on the roadmap, but currently there are more pressing matters. I hope you can work with it in the mean time

[Misiu]

@guims78

Maybe you can add an example of thermostat setup in the doc in gitub ?

@neliss that would be very helpful. I have 6 generic thermostats (DS18B20 + relay as a thermostat) so finally having a way to replace all the automation with a proper scheduler would be awesome!

[neliss]

@guims78

Hello, i’m trying to setup a scheduler with a generic thermostat, but it seems to be not well defined.
I setup 2 action with the service climate.set_temperature but what’s next ?

Hey there!
Thermostat is not a simple component since (i presume) you want to control it with temperature setpoint instead of on/off.
Best way to do this is indeed to add entities configuration, for example:

entities:
  climate.my_thermostat:
    actions:
      - service: set_temperature
        service_data: { temperature: 10 }
        name: "Set to 10C"
      - service: set_temperature
        service_data: { temperature: 22 }
        "name": "Set to 22C"

The above example is almost identical to the functionality you will get when you define any configuration.
This should give you 2 actions, so you could create a schedule that goes to the high setpoint in the morning, and a second schedule that goes to low setpoint in the evening.

I’m working on a way to enter the temperature value through the card, so you don’t have to define these in the configuration. Also it would be nice if you can define multiple actions in a single view/schedule, this is future material

PS: templates are not supported at this point, so any attempts with curly brackets and references to other entities will probably result in undesired behaviour.

[guims78 (guims)]

Thank you.
I begin to understand more the configuration.
But , if i well understand, you need to configure temp for each thermostat, as entity is requiered.

[Bart1992]

Hey,

I’m also using the Scheduler card since a couple of days with a thermostat entity, and solved it like this :

1. Build a script ( and input boolean ) :
   ( There are also some calculations in the template, but this is due to the ESPhome thermostat ( bang/bang controller ), which require an upper and lower bound ).

floorheating_bathroom_on:
  alias: "Badkamer Vloerverwarming Aan"
  sequence:
  - service: climate.set_temperature
    data_template:
      entity_id: climate.vloerverwarming_badkamer
      target_temp_high: "{{ states.input_number.bathroom_on.state | float + 0.5 | float | round(1, half) }}"    
      target_temp_low: "{{ states.input_number.bathroom_on.state | float - 0.5 | float  | round(1, half) }}"    
  - service: script.turn_off
    data_template:
      entity_id: floorheating_bathroom_on

floorheating_bathroom_off:
  alias: "Badkamer Vloerverwarming Uit"
  sequence:
  - service: climate.set_temperature
    data_template:
      entity_id: climate.vloerverwarming_badkamer
      target_temp_high: "{{ states.input_number.bathroom_off.state | float + 0.5 | float | round(1, half) }}"    
      target_temp_low: "{{ states.input_number.bathroom_off.state | float - 0.5 | float  | round(1, half) }}"    
  - service: script.turn_off
    data_template:
      entity_id: floorheating_bathroom_off     

2. Trigger the script with the Scheduler card :

entities:
 script.floorheating_bathroom_off:
   actions:
     - service: script.turn_on
 script.floorheating_bathroom_on:
   actions:
     - service: script.turn_on
type: 'custom:scheduler-card'

The scheduler component is working like a charm ;)!

[KTibow (Kendell R)]

UI parts you could do:

1. Add your card to the card picker
2. Prefill the card’s values (done internally, not externally right now)
3. Make a UI configurator

[123 (Taras)]

@neliss

Making the card configurable through UI (no yaml skills required) is on the roadmap

I think this will be key to wider adoption. The goal is to simplify scheduling via the UI yet, in its current state, it requires the user to pre-select what they wish to expose to the UI via YAML. That impinges on the convenience of having a UI-based scheduler because it involves a YAML-based pre-selection process.

FWIW, my interest in this scheduler is purely academic. I’m comfortable with creating automation-based schedules. However, I do recognize that a UI-based scheduler would be a great convenience to many users. That’s why I wanted to try this scheduler, to see how it works.

There was an effort to implement a scheduler but it was discontinued. It would have worked with scenes as opposed to directly calling services itself. That’s how the scheduler works in another home automation software that I’ve used for over a decade. If you’re interested, I described its operation to balloob (includes screenshots) in this post:

Condition: day [was "Schedule" Trigger type]

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 automat…