Scheduler card/custom component

@Gromy, Merci !
As I’ve already explained, if I take notes on what I’m doing, I often can’t manage to read it, so when I write to share I have to write a little more clearly. In everything I’ve written about HA there are some obsolete things, and I’m happy because this Scheduler will make some of my articles totally obsolete.

Of course, I’ve planned an article about Niels’ scheduler, but I’m waiting a little bit to do something complete, in particular to see what it will do for the conditions and also to see how to activate/deactivate them (it will take the FriendlyNames) according to the lifestyles…

Not sure if I’m missing anything here, but more user friendly names for input numbers would be good.

Also, template support.

My config:

    cards:
      - type: custom:scheduler-card
        standard_configuration: False
        am_pm: True
        include:
              - input_number.tariff
        groups:
          - name: "Utility Tariff"
            icon: power-plug
            include:
              - input_number.tariff
        customize:
          input_number.tariff:
            actions:
              - service: input_number.set_value
                service_data:
                  value: 0.13
# state: {{input_number.peak_tariff_utility}}
                name: "Peak"
                icon: mdi:cash-100
              - service: input_number.set_value
                service_data:
                  value: 0.04
# state: {{input_number.partial_peak_tariff_utility}}
                name: "Partial Peak"
                icon: mdi:cash-multiple
              - service: input_number.set_value
                service_data:
                  value: 0.01
# state: {{input_number.off_peak_tariff_utility}}
                name: "Off Peak"
                icon: mdi:cash

Also, I really need to know the time periods configured, I started something very crude here:

Please let me know if I’m on the right track or there is a better place to do this.

Great work overall!

What happens when a time scheme enters an “undefined” slot? does the entity return to the previous state? or do i have to explicitly define that for the slot following the activation slot? So I have a slot to turn on the light from 6am to 8am then an “undefined” slot" then a slot to turn on the light from 6pm to 8pm, then an undefined slot. Is the light shutoff at the end of it’s designated slot? or do I need to define “turn off” in the in between slots?

It just doesn’t do any actions, if it has a state set already from a previous schedule and it wasn’t changed since it’ll keep that state.

Great, thanks, I will add the “off” action to the in between slots. As an aside, it seems the slot ending at midnight and the slot starting at midnight are different slots? it seems these should be the same slot?

I thought a bit about how it could be improved by keeping the current layout. I’m no way a UI designer unfortunatelly.
But a solution that could solve some of the issue would be to change a bit the alignment of the time slot start/end boxes, something like this:

I know, this does not solve making visible the set state for the small timeslot, nor the case where small timeslots are one after another.

3 Likes

Hello,

I am new to HA. I am very happy to find after two weeks of research scheduler card which for me will solve a lot of problem. I have a problem with the schedules: in my schedules I have a delay of 2 hours. I am in France. Is it possible to change UTC? If so where?
Thank you for your work !

Go to ‘configuration’ and then choose ‘general’.
Here you can point your location on the map and click save.
After restarting HA, you should see that the timezone on this page has changed.
Its very important to configure your location. It is also used for detecting sunrise/sunset times.

Yes ! It’s ok for me. Thanks you very much for your Amazing work

@neliss I have a timeslot configured (the one I posted above) for a climate entity and one slot should set the target temperature to 22degrees from 6:00 to 6:30. That did not happen however, the climate history graph shows the target temperature flatline since midnight.
I created another timeslot that would trigger in 10 minutes. That one triggered and set the target correctly.
How do we troubleshoot problems like this?

@clau-bucur If i understand your time scheme correctly:

  1. from 00:00 to 06:00 heater at 20.5C
  2. from 06:00 to 06:30 heater at 22C
  3. from 06:30 to 15:00 heater at 20.5C

And time slot 2 is missed you say.
To troubleshoot this, please share:

  • The attributes of this schedule entity
  • History graph of the schedule entity (should show the ‘triggered’ minutes)
  • History graph of the climate entity

Another good clue would be to create a template sensor that stores the next_trigger property of the schedule. Same for the climate setpoint (theoretically it could be a problem of this entity as well)
But then we would have to wait for the next night where the problem occurs.

Ofcourse the behaviour of the scheduler-component should be the same for each timeslot (no matter how short). So I don’t see a straight-forward cause for this.

Hello, moved my support request here :slight_smile:
I have implemented my own “turn off” function and for that, I need to define the list of actions on my own. My code is below and issue is explained below the code:

                        type: 'custom:scheduler-card'
                        title: false
                        discover_existing: false
                        standard_configuration: false
                        include:
                          - '[[my_climate_entity]]'
                        customize:
                          '[[my_climate_entity]]':
                            actions:
                              - service: climate.set_preset_mode
                                name: Turn AC Off
                                icon: 'mdi:hvac-off'
                                service_data:
                                  preset_mode: timeroff
                              - service: climate.set_hvac_mode
                                name: Set mode
                                icon: 'mdi:cog-outline'
                                variable:
                                  field: hvac_mode
                                  name: Operation mode
                                  options:
                                    - value: heat
                                      icon: fire
                                    - value: cool
                                      icon: snowflake
                              - service: climate.set_temperature
                                name: Set Temperature
                                icon: 'mdi:coolant-temperature'
                                variable:
                                  field: temperature
                                  name: Temperature
                                  min: 16
                                  max: 30

My questions:

  1. Is that the correct way (and actions definitions) to define this?
  2. I set some timers using that setup and the list of times is displayed not formatted correctly:
    image
    See how the mode/temp settings are displayed (not in separate lines as they should)
    Thanks for your help!

This is how it should look. I decided to combine entity + action in one line, because I received a lot of requests to make the overview page more compact.

Your code looks fine, but I don’t recommend disabling the standard_configuration.
The actions that you use should be available for selecting when using the standard configuration (so only including your climate entity should be sufficient!).

If you have a problem with additional actions/options showing up in the card, perhaps I could add a feature to hide unwanted stuff.
Personally it doesn’t bother me, but if you have reasons for it, there is always a way.
I think the code should become more easy this way.

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.
image

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).
image

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:

  1. hide all options from set preset mode except for timeroff and have it selected by default (such that this set preset mode becomes your new turn off action)
  2. you want off to be removed from set hvac mode options.
  3. And then you want the turn off action to be removed as well.

It sounds like a lot of trouble to go through :confused:

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 :slight_smile:
What is needed:

  1. Ability to configure/define the list of action options
  2. Ability to display a preset mode as one of the actions (instead of asking the user to select the “preset” option and then the required operation)
  3. Ability to configure/define the list of hvac modes to display (following selection of “set mode”)
    Will this be possible?
    What am I losing by using “standard_configuration: false”? Any risk?

In continuation to the above text:
Using the “standard_configuration: false” I get the actions:
image
And the displayed hvac modes are:
image

I’m curious is your climate device a z-wave device?