@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:
.
.OK, so removing the default switch: domain hides the network switch schedules. Manually adding my Kitchen light switches to the entities: makes them available.
However, now I am getting two automatically generated groups that were not there before. The two circled in red are unwanted.
I think you should add the entities to the groups. Something like
entities:
light.thing:
name: Thing
groups:
lights:
name: "Lighting"
icon: lightbulb
entities:
- light.thing
# or
entities:
light.thing:
Hmm, here is the code I was using. I was under the impression that domains: section was used to define defaults for a domain of entities (ie. all lights should turn on, turn off, or be set to 60% brightness). Then individual entities could be defined under entities: with any settings that needs to be different than the default defined in domains:.
I am starting to think domains: are only for catch-all groups. Even though they did not act as catch-alls previously.
Sorry about the confusion here.
Using the domains configuration will result in all entities you have in HA of a certain type (domain) to be displayed.
In addition to them being displayed you can also define actions that all should have in common.
Unfortunately, it currently does not work the other way around.
If you want to include only specific entities of a type entities: configuration is the way to go.
Even if all of these need the same actions, you will have to define them one by one.
Perhaps there is room for improvement here 
1 Like
Is it possible to divide my lights in two groups, All_lights for the light switch All_dimmer for the dimmer light switch. For now I have All_lights group and every lights are in. How can we tell which light goes in each group ?
You can use groups:
Thanks it work, but now I have my lights in one group and my dimmers in another one which is ok. I also have a light group that contain all lights and dimmers and I don’t need it. Is there a way to avoid this one ?
No, it will autocreate groups unless you remove them from domains I think.
About translation, is it possible to have a translation to other language. Now for example, week day names are in the code. Would it be possible to switch them to another language via parameter.
want to share what may be a bug, unless i’m overlooking something.
Once you create a schedule, if you go back later and change the time, it doesn’t change.
It will only respect the originally created time input.