Arrgh! That was it! 
Thank you!
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 
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
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.
It shows you used
/local/scheduler-card/scheduler-card?v=0
but it wants
/local/scheduler-card/scheduler-card.js?v=0
1 Like
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.
I contributed that ability, when @neliss switched to typescript he forgot to add it back.
Here’s the commit:
@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.
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 ?
1 Like
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 
@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!
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.
1 Like
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.
Hey,
I’m also using the Scheduler card since a couple of days with a thermostat entity, and solved it like this :
- 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
- 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 ;)!
3 Likes
UI parts you could do:
Add your card to the card picker- Prefill the card’s values (done internally, not externally right now)
- Make a UI configurator
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:
I would like to allow anyone in the house to schedule a light to turn on at a certain time. However, I need to hide my Network Access schedules in a card only I can manage.
I created a duplicate of the card, removed the network access switches, but the Network Access schedules appear on the new card anyway. Is the intention of discoverExisting: false to hide schedules not created by this card? If not, could you add a way to manage multiple schedule cards?
All it does is looks at the switch.schedule entities.
when I posted this, I didn’t read the docs for a while, and didn’t know what discoverExisting: false was.
Hi Brian,
The idea behind this discoverExisting option was that:
- if you have previously-created schedules that don’t pass the filters of your current configuration (so the entities/domains and actions that you set up for the card)
- they will show up anyway (both in the overview of current schedules as the available entities/actions for new items) if
discoverExisting=true - they will not show up in either view if
discoverExisting=false
Indeed this should be exactly the kind of functionality you are looking for if you want to split up into multiple scheduler-cards.
However, this is a new addition that i made last morning, and i cannot say it was extensively tested. So perhaps theory and practise may differ here 
Since it is a new addition, could you check if you run latest-greatest version (v1.2.x)?
If the behaviour is different than expected I would like to invite you to create an issue in github and add some background info, so I can reproduce it and follow-up on the issue.
Feature requests are always welcome as well 
According to HACS I have 1.2.1 installed. I have discovered the problem. discoverExisting appears to filter by domain. Removing the switch: section from my domains: section hides my network related schedules. However I would like to leave the switch domain for other switch related schedules. For example: simple on/off switches (my Kitchen Lights), and smart plugs (for my floor/table fans).
Removing the switch: section from the following hides the network switch schedules.
discoverExisting: false
domains:
.
.
switch:
actions:
- icon: toggle-switch
service: turn_on
- icon: toggle-switch-off-outline
service: turn_off
icon: light-switch
entities:
.
.
groups:
.
.