Indeed, time slot 2 was missed.
I’m attaching the schedule attributes and climate graph. I don’t have history for the schedule as it was not included in the recorder.
I have created now those two new sensors, and included the schedules and these sensors in recorder. Will monitor them in the upcoming days, and get back.
Without using the “standard_configuration: false”, I get all possible actions listed but I only want part of them (would like to remove “set preset” and “turn off”) displayed for selection.
In addition, after selecting “set mode”, the possible hvac modes are listed for selection but I do not want to display all of them (I want to remove the “off” option).
BTW, the reason for taking all this effort was due to the reason that I need the “off” command coming from the timer to be different than the “off” command coming from the climate device UI (I am using Simple Thermostat). Only way I found to support that is to use your suggestion and add an “hold” command to my device (I called it “timeroff”) and it works but then, the “turn off” action option and the “off” option in the hvac commands list should be removed so that the user will only use the new “turn ac off” command that I created through the preset action option.
If instead of taking this route you can add config options to select what actions will be displayed and select what hvac operation modes will be displayed, this will be great, thanks!
@Motti_Bazar
By adding your timeroff option to the hold modes, it should show up as an extra preset, and the action you need to use is set preset mode. This is HA behaviour.
Ofcourse you could rename set preset mode to whatever name you want to give to the action, but that will always remain customization (its a matter of taste).
If I understand you correctly you want to:
It sounds like a lot of trouble to go through 
You’re not the first person who asked for hiding actions from an entity, so maybe I will add some easy way to configure this. But for you, it would only solve item 3.
Items 1+2 require functionality for hiding items from the action variables list. I wonder if this has added value for other users as well. I don’t know yet how to make this easy to configure this in the card.
Maybe its better to keep using it as it is now (if I understand you correctly, you know have it configured in the way you want it, right?).
Hi, using “standard_configuration: false”, I was able to configure what I need (I did not yet test if it actually works, only what is displayed). But, you recommend not using this setup parameter 
What is needed:
In continuation to the above text:
Using the “standard_configuration: false” I get the actions:
And the displayed hvac modes are:
I’m curious is your climate device a z-wave device?
Hello,
for three days I have been trying to adjust my Danfoss LC13 (Z-wave) thermostats. They work well with the basic “thermostat” board in Lovelace. They are recognized in “Scheduler Card” but do not trigger when I set a schedule.
When I program my Qubino (Z-Wave) in “Scheduler Card” they are ordered correctly and it works.
I reinstalled “Scheduler component” and reintégrated a Dansfoss LC13 thermostat but still nothing.
Could you help me please ?
Thank you
Are you using a translator? You might want to speak your native language and see if it helps. Clues:
It’s a card, some people put just one card on a view though
No accent mark needed
Je continue en Français alors…
Je viens de tester mon thermostat Danfoss LC13 dans “outil de développement” puis appel de service avec :
entity_id: climate.danfoss_z_thermostat_014g0013_heating_1_2
temperature: 21
Mon thermostat est bien sur 21°C mais je ne sais pas pourquoi sur Scheduler Component ça ne fonctionne pas.
C’est comme si dans Scheduler Component le service n’était pas appelé ou pas de lien entre Scheduler Component et Scheduler Card.
Auriez-vous une idée.
Merci.
I removed the scheduler component and the card. I then looked at both /config/.storage/core.config_entries, /config/.storage/core.entity_registry and /config/.storage/core.device_registry and can’t find anything for a search on “scheduler”.
Update: In fact, even after I remove both the scheduler component and card, then restart HA, and reinstall both, there are no matches for “scheduler” in any of the 3 above files either. However, I do see them listed as installed in HACS after I install them.
I don’t know the answer to @Xavier_Pous’s issue, but I did just do a google translate of his post in case it helps someone else answer 
I have just tested my Danfoss LC13 thermostat in “development tool” then a service call with:
entity_id: climate.danfoss_z_thermostat_014g0013_heating_1_2
temperature: 21
My thermostat is of course 21 ° C but I don’t know why on Scheduler Component it does not work.
It is as if in Scheduler Component the service is not called or no link between Scheduler Component and Scheduler Card.
Do you have an idea.
Thank you.
HACS only takes care of storing the files.
So if it is installed according to HACS, this doesn’t say much.
If all traces of the component are removed as you say, the next step is to add the ‘scheduler integration’ in HA → Configuration → Integrations.
If it doesn’t show up here, it is due to browser caching. So do a hard refresh or open private tab.
If it does show up and its added to your integrations, there should be services ‘scheduler/add’ and ‘scheduler/edit’ etc. (see developer tools → services).
If the last step failed, the component has crashed, and this will be in the error log.
I really cannot think of another scenario, but then again, HA is full of surprises 
Please keep the discussion in English. Else we cannot help you.
How did you configure the card? Are you using YAML mode or UI mode?
Can you share your card configuration?
It should be enough to just include all climate devices.
Your thermostat should show up and all available actions will be shown based on the capabilities of the device.
Simple test would be to just schedule a ‘set temperature’ action for 10 minutes from now.
You should see in the card when it will trigger, and on the display of the thermostat you should see the increased temperature.
Perhaps you need to change the operation mode of the device before it allows you to send a temperature setpoint command?
Ok, I reinstalled both then checked HA → Configuration → Integrations and it’s not listed. I even checked in an Incognito chrome window.
In my home-assistant.log, I searched for scheduler and found this single entry which I think is just the standard warning.
2020-10-09 20:11:13 WARNING (MainThread) [homeassistant.loader] 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.
I also checked services, and there’s not scheduler/add nor scheduler/edit services in Developer Tools → Services.
I have no idea what’s going on and if it was indeed crashing, I would expect to see something mentioned in logs.
Non it’s doesn’t work when I change de temperature.
My Dansfoss LC13 work perfectly in Lovelace with Thermostat when I edit live temperature.
No. It’s a EQ3 Bluetooth radiator thermostat to which I’ve attached an external temperature sensor.
I’ve modified the built-in HA integration and added support for an external sensor. Will make a pull request once I’m confident the changes work ok.
I programed scheduler card at 11:30 with 9°C. I saw declenchement on scheduler card but it doesn’t work on my Danfoss lc13. It works with Qubino (lightning).
It’s very strange.
I dont have MQTT on HA. Do you think it’s a problème ?
Release v1.7.5 
This release adds some new features that you have been asking for.
So this one is entirely made for you 
A new button is added to the ‘edit’ view.
It is (very discretely) placed on the bottom right of the card, and looks like this:
It brings you to the new ‘options’ view containing some extra (but powerful) settings you can set up for your schedules.
Note that the settings you will find here are not mandatory, they are only extra’s
New feature: conditions editor
Yes, they have arrived. You can now set up conditions for your schedules.
With conditions you can define rules, which are validated before the action is executed.
If the rules fail, the actions will be skipped.
You can choose if you want any or all conditions to be passed before proceeding.
Currently, conditions will be limited to checking entity states only.
Out of the box, types binary_sensor, person, input_boolean, switch, cover, alarm_control_panel are supported.
All you have to do is add these entities to your include list, and they will show up in the conditions view (provided you use the standard configuration).
Numeric states (such as sensor entities) are also supported, but you need to define a min/max value for the entity. I will add instructions to the readme when I have time for this.
I tried to keep things rather minimalistic so maybe it requires a bit of puzzling to figure out how things work. Just keep in mind that colored stuff is clickable
Small preview of the conditions editor:
New feature: friendly name option
You can now give your schedule a friendly (or unfriendly, it’s entirely up to you) name.
If you want this, just fill in the name in the options view.
When you have configured a friendly name, it will also show up in the overview list.
So it might help you to figure out which is which.
New feature: run once option
I received requests from users who liked to have their schedules to trigger only once, instead of repeating every X days.
You will find the option to automatically disable a schedule after triggering.
Afterwards, this schedule will stay in your schedule list, so if you want to run it again, you can just re-enable it (which is a matter of tap+hold).
You can still set up days in combination with the run once option, they will still be taken into account for setting the timer.
PS:
The newly added features are not done, but they provide a usable starting point.
As always, I appreciate your feedback for further improvement.
