Scheduler card/custom component

I still try to start every time with an empty card but I can’t get it done… Is there a solution?

What do you mean?

1 Like

I would like to have multiple scheduler cards in various panels. Now i still have one which gets longer and longer…

With the help of your discussion in the thread I solved it (as it seems for now) I can make separate cards for various switches. Just the way I want it! Thanks!!

Thanks all for mentioning the bugs that came with the release (and sorry for these bugs!)
There is a new version available that should fix all of them.

I have a question to all of you regarding the standard configuration.
I noticed that some of you are struggling with adding and hiding entities, i would like to find a solution to improve this.

Please let me know preference:

  • It’s fine for me that the climate, light, cover, switch and fan entities are there by default. These are all I need. Keep it as it is.
  • Make all supported entities visible in the card by default, I will hide what I don’t want to see.
  • I prefer to start with an empty list. I will choose which entities show up.
  • I don’t like messing with YAML. Just make a UI editor where I can pick which entities are visible.
  • I have another idea. I will tell you below.

0 voters

Thanks!

1 Like

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 :slight_smile:

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 :wink: !

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.

Thanks @KTibow, but how do i figure out which switch id to look at, as they are auto generated?

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. :smile:
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