include is not part of customize, you can define it directly on the top level of the card (same level as type: scheduler-card).
See documentation for an overview of the structure.
yeah thatās why i tried this:
type: 'custom:scheduler-card'
include:
- light.lg_buiten
customize:
light:
actions:
- service: turn_on_with_transition
name: Turn on with transition
icon: lightbulb-on-outline
variable:
field: transition
name: Transition (in seconds)
min: 0
max: 3600
step: 60
title: Lichten Buiten
but it still shows all lightsā¦
You got a point there.
On request, I added the functionality that all entries in customize are automatically included to the card as well.
You are now experiencing an unforeseen side-effect of this āimprovementā: you cannot apply customization on a full domain, while including only specific entities of this domain.
I could add an extra āruleā that if you apply customization for a full domain (say light) but you have only a subset of this domain in the include list, the subset will be used.
This seems like a best-of-both-worlds solution.
Unfortunately this is something I would have to addā¦
For the time being you can either:
- apply customize to specific light entities (or use a wildcard filter) that you also want to show up
- use
excludeto filter out the entities that you want to hide - accept that all your lights show up
for now iāll stick to 3:)
this component is absolutely dope!!! 
1 Like
Just tried the new climate changes and they seem to work fine for me now - no more having to create a scene to set the hvac_mode and temp! Thank you.
Also, can now use a light in the conditions. Thanks again!!
1 Like
Hello,
is it possible to randomize schedules? So for example shut off lights somewhere between 23:00-23:00.
Thats much better against thiefs, at least dat is wat de politie zegt;)
Just tried it as well and the only thing I can say: THANK YOU! It works great. That makes it so much better for me now.
1 Like
Just playing around and thinking about how to manage my heating automation with presence detection. So when leaving turn climate to 17 degrees, when arriving heat up to 21 degrees etc.
otherwise use schedule.
Anyone already working with this?
This has been discussed a couple of times before.
Some users wanted to go even further and have some āpresence simulationā running, where a light randomly turns on for a while and then off, repeating this cycle randomly.
In my opinion itās better to keep the scheduler simple, so I chose not to include this.
As alternative you could make the scheduler trigger a script, which implements this randomization.
You could keep things flexible by passing the entity_id of the light, as well as the randomize interval(s) as variables.
My advise is to disable the schedule when leaving (using an automation), and turning it back on when arriving.
For schedules with timeslots, you can make use of the fact that the schedule figures out in which timeslot it should start after turning on, and will execute the action of this timeslot directly (instead of waiting for the next timeslot to start).
Well, this is not intended 
I must admit I made some changes to that part with the last update.
I guess you have an entity that the card cannot process and it gives an error.
Could you check the browser logs for clues?
Preferably can you open an issue in github with the results, so we can follow-up on this?
1 Like
@neliss wow awesome!!! This component should be going to be an official integration!!! 
Iām sure thatās something, ppl was looking for a long time! thatās really a game changer!
1 Like
Hi @neliss,
I have some issues with the updated version ( component V3.03, and Card V2.03 ).
Before the update there was the ability to perform āset temperatureā action ( just like climate.set_temperature )
Since the update, this is gone? My valves only work with this option ( I cannot use the āheatā, and set the temperature there actionā¦ since these valves just donāt work with this command).
See attachment
Before update :
after update:
Is there anything I can do about it?
Thanks!
Hello Bart.
From which version did you upgrade?
As far as I can see, nothing has been changed in the available actions for climate entities in the last 2 months (since v2.0.3).
If your climate entity supports HVAC_MODE=heat you should see the action āheatā, otherwise you should see the action āset temperatureā.
Having both actions showing up does not match with the implementation.
Maybe it is due to:
- Configuration of the card (
customize) you applied to add the extra action? - An old schedule, which has outdated action configuration (when you edit an existing schedule, the card will automatically add the actions that are stored in the schedule)?
The āheatā action should work for all thermostats, provided they have HVAC_MODE=heat.
Why wouldnāt it work for yours?
I know that some climate integrations failed to switch to the HVAC_MODE (in other words, they would ignore the temperature setpoint if they are in HVAC_MODE=off).
But this issue should be solved now, there is a workaround added for this.
HI @neliss,
Thanks for your fast responce!
Iāve reverted back to V3.02 and V2.02, and found out that the issue persists.I think this issue is not related to the scheduler, but to the Zigbee converters from the valve ( which also have been updated since yesterday ). Iām sorry for the inconvenience!
They implemented the HVAC_MODE āheatā in the latest Zigbee (Zigbee2MQTT ) update for this valve. So as you allready mention, then the set_temperature will dissapear ;)! But for some old schedules I allready made before the zigbee update, the set_temperature remained available.
However, unfortunatelly this valve is pretty complicated :
Since the last zigbee2mqtt update it has 3 HVAC modes
- Heat = valve fully open ( without valve regulation )
- Off = valve fully closed ( without valve regulation )
- Auto ( presets : none, away, schedule, manual, boost, complex, comfort, eco )
Where in auto modes, the valve uses itās internal PID regulation to control the temperature. So in some cases it would be nice to be able ( for example ) to set:
- HVAC_mode : Auto
- Preset_mode: Manual
- Temperature: 20.5 deg
and all this in 1 action.
Probably this valve does not comply to the āclimateā standards as described by home assistant, so I will look for another solution!
again, thanks for responding and this great component:)!
This seems to be the case indeed, maybe itās good to let the developer(s) know of the issues youāre having.
Check here: Climate Entity | Home Assistant Developer Docs
HVAC_MODE_HEATThe device is set to heat to a target temperature.
This is really the (only) mode where the TRV should allow you to set a target temperature, and it should use its PID to regulate heat flow to achieve this.
HVAC_MODE_AUTOThe device is set to a schedule, learned behavior, AI.
This is the mode where the device controls temperature, so the provided setpoint is not being followed.
Unfortunately for you, I follow the HA definition.
In 9 out of 10 cases this should work smoothly, in your case you have a problem, since the two parts donāt connect.
You should be able to change things using customize to make it compatible, in the worst-case disable the standard configuration.
The āheatā action previously controlled temperature + HVAC_mode together in a single action (since the set_temperature service has the option to provide an hvac_mode parameter).
Unfortunately I got a lot of complaints, and it turns out that more than half of the climate integrations out there ignore this parameter and only set the temperature setpoint (so the thermostat stays off if it was previously disabled).
For the same reason Iām very reluctant in extending the actions with more combined stuff.
It may be helpful to some, cause headaches to others.
The preset_mode: manual is actually not part of the list of presets that HA has defined, so it seems to be exotic (and you will probably donāt see a translation or icon of it in the card).
Maybe you could create an automation that automatically sets the preset_mode once the temperature setpoint is updated (either by scheduler or by the thermostat card)?
Is it not possible to have Conditions on a scheduled entry using a Scheme rather than a specify time? I can create and add conditions to a schedule that is specifically time based. If I try using a Scheme though I can add the conditions, click save, but when I go back in they are gone???
(Running latest versions of scheduler integration and lovelace card).
Thanks
Thank you very much for your project. I use it very often.
I want to ask you something. Besides āmake schemeā are you going to develop a time countdown in future versions?
That shouldnāt happen. Something seems to be wrong.
The conditions can be added for both, only with time schemes they cannot be defined per timeslot but only for all.
Could you try it again (maybe with another schedule or another condition entity)?
This is not really planned, no.
You can make a schedule that triggers in 10 minutes from now, and then removes itself.
Would that be sufficient?
Or you want to be able to enter the duration, rather than a time?
Iāve tried that. No matter what I do, as soon as I try to use a scheme it doesnāt save the Conditions. It doesnāt complain - but the conditions donāt appear when I go back into that schedule.