I’ve downloaded your code. If you want I can create PR with the changes.
1 Like
For everyone who want to know it: Feature request: Color/Light temperature · Issue #115 · nielsfaber/scheduler-card · GitHub
With an action, is a good solution. Thx 
@snoopy1492 @neliss I’ve created PR with generic thermostat changes: https://github.com/home-assistant/core/pull/43308
Anyone interested, please add “+1” on it 
All credits go to @snoopy1492
2 Likes
Oh great !
Thank you, I hope it gets integrated in HA.
1 Like
Hello, everyone!
I am having trouble implementing display_option change from standard, {entity}:{action} to custom, {action} patern. I have tested a dozen of syntax variations which I encountered at this forum with no success. Below is the latest version of the code which I’ve stopped at before applying here. What’s wrong with that:
` - type: 'custom:scheduler-card' `
` title: 'T1' `
` discover_existing: false `
` standard_configuration: true `
` include: `
` - input_number.climate_set_temp_livingroom `
` customize: `
` input_number.climate_set_temp_livingroom: `
` display_options: `
` primary_info: `
` - '{action}' `
` name: t1 `
` icon: thermometer `
` actions: `
` - service: input_number.set_value `
` name: n1 `
display_options applies to the whole card, not to one entitiy.
So it shouldn’t be placed within customize.
This is also documented.
Thanks! That works now.
Another question: is there any way to set an order of shedules in the display list?
The items are ordered based on the time until they trigger.
You cannot define your own order.
This is also because the list is dynamic, they are discovered from your HA entities database.
I see. That’s also fine. I have 2 parmeters to shedule and was wondering if it is possible to have the shedules for type A placed togather and same stuff for type B so that they would not mix with eachother… I could have two cards for each type or keep it as it is for now, maybe it is not that confusing after all…
@neliss would it be possible to only update the temperature setpoint without changing the HVAC_MODE ?
If I manually turn the thermostat off, to be kept that way when the schedule triggers?
I made a PR for extending the eQ-3 integration but I deliberately not set the HVAC_MODE together with the setpoint because I don’t want the Scheduler to always turn on the thermostat.
You can add the legacy set_temperature action to the card, for the time being.
I want to add the multiple entity/multiple action support ASAP, to give the user the choice to change only the setpoint or also the HVAC mode.
Personally I don’t ever set the temperature if i don’t want my thermostat to heat, but everyone can have their own taste and i want to facilitate that.
2 Likes
For some reason, my climate schedule isn’t working. I have everything updated to most recent update. It’ snot turning on ever for my attic mini split:
E.g. one of the time segments is setup like this:
How do I begin to debug this?
Actually, you don’t. There’s an update you don’t have (i can see it from the pictures), but it won’t change anything regarding your problem.
A lot of users reported such problems.
The recipe for debugging is to monitor the history of the schedule + the climate entity.
The schedule should to go triggered state once the timer is due. The thermostat should ofcourse change the temperature setpoint + the operation mode at this time.
In 9/10 cases the thermostat does change its setpoint but does not change the operation mode. So it will stay off. This is even the case for the generic thermostat.
The scheduler sets the hvac_mode when calling the set_temperature service, it is often ignored by integrations.
If this is the case, don’t bother to ask for a fix here. The problem is with your thermostat integration.
File a bug report or create a PR to solve it. For the generic thermostat this is already in progress.
As a workaround you could try to never switch modes (so only change temperature setpoint).
One question. can i use a temperature sensor value as a condition option inside a schema?
i add the sensor as included entities but i cannot see it
It was your own idea 
And credits go to @Misiu for proposing to hide the markers until you select a timeslot.
1 Like
I remember seeing this screenshot somewhere
@neliss your component is betting better and better. This topic is almost 1000 messages long, that only confirms how such component (functionality) is needed in Home Assistant. I hope that maybe someday this will become part of the core.
1 Like
@neliss what do you think about this: ability to provide custom schedule entity id (or at least custom postfix - eg. switch.schedule_myfancyname).
I know you said you need the entity_id to be able to keep track of the schedules. But maybe you can instead use the unique_id attribute.
My use case:
Have two distinct scenes:
- regular
- have lights turn on in certain rooms at dusk;
- have scheduler set thermostats to a lower temp on certain rooms that are not used;
- guest mode
- have lights in guest room turned on at dusk too;
- disable the “regular schedule” and enable the “guest schedule” which uses a different timetable and temperature setpoints, to better suit the guests.
I can do this now too, but I need to know the exact schedule ID. And if I delete it or create it again, the schedule ID changes, so the previous automations will be broken.
Does this make any sense? If yes, I can create a feature request.
Maybe you haven’t noticed, but I have been holding off from making changes in the scheduler-component for a while.
There is quite a big change pending, which will take care of this, but also some other (much more important) restrictions.
Ideally, the entity ID is just a ‘slug’ of the friendly name, and you are free to set anything you want.
I don’t really want to put effort in anything else in the mean time (your proposal seems more of a quick-fix to me), it seems a distraction from what really needs to be done.
I haven’t found the time (or volunteer) to work on this yet…
Great! Indeed I’ve noticed the rather non-existing scheduler-component changes, but that just meant to me that it’s that stable and working good that it doesn’t need changes 
Anyway, good to hear that it’ll be there at some point, so I’ll wait until it is. You know your plans best.
What kind of volunteer you need? If you need Python experienced developer, I’m not your man. Othewise I’d be glad to help as far as the time permits.