Could you please share ur config for that cards?
I chose I will tell below:
So what I would really like is an empty card, but the way group/domains work a little more streamlined and similar to how auto-entities card works. The filter option there is really powerful and letās you include lot of specific entities with just a few filters. Like only including (or excluding!) entities from light domain that start with light.woonkamer_*
My suggestion/idea would be to set a group (with a custom name and icon) and there just use a filter exactly like auto-entities. This opens a lot of possibilities and maybe even helps preventing the card to become too bloated. This works great if you want to use multiple schedular cards as well.
For instance: with this filtering method you can create groups that each automatically contains several entities from a room. That way you can have each group represent a room and auto populate entities you filtered in. When you install a new light, it will be automatically added if you follow the same naming scheme in the filters you have set up. Just one of the possibilities 
And keep individual entity customization for name/icon like you already have.
Cheers!
3 Likes
if I wanted to schedule an action on a group of entities (for example all the air conditioners on a floor of the house) which is the best method?
Would there be the possibility of selecting more than one entity? Or use HA groups?
I done this for now:
type: 'custom:scheduler-card'
title: Programmazione
discover_existing: true
domains:
climate: true
cover: false
fan: false
switch: false
light: false
group: true
entities:
group.clima_floor_1:
name: Clima floor 1
actions:
- service: climate.set_temperature
name: set temperature
variable:
field: temperature
name: Temperature
min: 10
max: 30
The group integration in HA is a bit of a special case.
I had troubles integrating it in the standard configuration, because there are no actions to define for it.
It basically accepts any action/service call, and the calls are forwarded to each of the contained entities (if they support it).
The only possible solution i see, is to scan which (type of) entities are in the group, and show the actions of these types. But this is not in place yet.
If this would help you, then please make a feature request for it.
There is an open feature request for selecting multiple entities for a schedule. It saves you the trouble of setting up a group, especially if you only did this for schedules.
It should become available in a while.
Bottom line is that your solution seems fine to me. It is currently the only possibility.
But I would prefer if you didnāt have to write all these lines.
Wow! Multiple-entity selection for me is best solution.
Thanks!!
I think everyone can do some yaml code, especially copy/paste, to define what a card will containā¦ The simplest way for those who donāt like it would be to have several examplesā¦
For me the important things to add would beā¦
- Workday
- Conditions
- Friendly Names (it would allow easy access to it in an automation to disable the schedule)
- Sorting by hours in the cards
- Time slots with overflow on the following day, very useful for climate
This scheduller is so promising that we want to have it right away! But Niels is doing a great job and we will try not to put too much pressure on himā¦
This is the code I used to make separate cards based on the info in the thread:
Card 1: the battery charger
type: 'custom:scheduler-card'
discover_existing: false
standard_configuration: true
title: Battery Charger
domains:
switch:
include:
- switch.sonoff_10007b3427
and this is card 2:
type: 'custom:scheduler-card'
discover_existing: false
standard_configuration: true
title: Reserve Switch
domains:
switch:
include:
- switch.sonoff_1000918341_4
Seems straightforward. And I thought I had my wish accomplished. Separate cards. This is the view I got:
It looked fine and so I did a test with multiple schedules. Then 2 issues became apparent:
-first of all sometimes the view doesnāt come up as expected. I get 2 times the last card but with a different title:
which after a refresh of the page restores itself to the correct one (prev. picture).
-second issues is that the schedule doesnāt run. For the reserve switch I made a multiple schedule but it only run the first one. I have an history graph underneath it to control if its working. I wanted to test if both cards where doing indeed different schedules and now I am not sure so I will to some more testing.
This was done with version 15.1. This morning I upgraded to 15.2.
Edit: I have tested the cards again. I can fully edit, change and deleted the schedules in the cards. Also it correctly triggers the switch. Also no issues with the incorrect representations of the cards anymoreā¦ So the issues reported earlier seems to be resolved.!!
Awsome, thankās gonna try this!
Hello, can you share your config for managing transparency ?
Or what is the theme you use ?
Itās very cool 
!
Any theme with something like
card-background-color: "#FFFFFF22"
The last two digits are transparency. Or for rgba:
card-background-color: rgba(255, 255, 255, 0.1)
1 Like
Still struggling to get the schedules after being setā¦ Is there a way to associate the switch.schedule_<id> with the entity that is controlled by this scheduler/switch?
So, I guess what Iām asking is:
- can I figure out the ID based on the entity it controls?
- can I read the schedule after itās been set?
My use case is as follows: I want to build a front end that lets the user adjust a utility rate schedule (e.g. peak rate from 9am to 3pm, etcā¦) and then use that schedule programmatically (I need to know for how long the peak rate lasts and when does it start today for example). All dynamic based on user input.
Look at the attributes of the switch.
Just list all switches. In jinja2 states.switch
Help for thermostatsā¦
The results from the poll were not quite unanimous.
- Some people would like to define which entities they see
- The same amount of people would like all entities in HA to show up
- Then again, there was a big group who would like to see a UI editor.
But a clear result was that few people like it the way it is now. 
And i got some nice idea from @ASNNetworks.
So, I decided to stir things up.
V1.6.0 of the card works a bit differently:
entities and domains configuration is removed completely.
Yes, your card will be broken once you update. And iām sorry about that.
The card is empty by default (no domains enabled by default).
You can use the include: configuration to list which entities and domains you want to show up.
On top of that you can exclude: individual entities.
Basically, all items you have before in entities and domains should move to the include section.
Groups are defined slightly different as well.
They have include: and exclude: configuration to decide what ends up in the group.
All configuration (names, icons, actions) now goes to customize:. Apart from that it works pretty much the same as before.
You can read all about it in the revised manual.
But there is also good news!
The card also has a little UI editor now:
Isnāt cute?
It doesnāt support all the features of the card, but it should help you setting up the card in a way that you can work with it.
7 Likes
This looks very very promising, loving the new filters 
!
Nice work for the customization of the cards !
When i add fan to the include list, the card disappears.
All other ādomainsā work fine.
my card config:
- title: Scheduler
icon: 'mdi:calendar-clock'
cards:
- type: 'custom:scheduler-card'
title: Klokschakelaars
discover_existing: true
standard_configuration: true
time_step: 1
include:
# - fan
- input_boolean
- automation
- media_player
- climate
- switch
- light
- scene
Is this a bug or is my config wrong?
btw iām in YAML-mode.
