Scheduler card/custom component

robs23 · October 11, 2021, 10:43am

Well, you nailed it, I’m indeed using custom action. I created a custom action because I noticed that when thermostat was set with ‘Heat’ action, it was heating ok, but when the scheduler lowered the set temperature, my thermostat didn’t change anyting and was happily heating on I think it mabye something with my thermostat that reacts properly for settings from HA only in ‘Auto’ mode and not ‘Heat’ mode…

So you’re saying there’s a build-in ‘Set temperature’ action? By default I only saw ‘Heat’, ‘Preset’, ‘Set auto’ actions on your card, but only ‘Heat’ is letting me set the temperature with slider… Again, it’s probably something with my thermostat… Any chance to add accessing temperature parameter in display_options in any future release?

Nicko1 · October 13, 2021, 7:01am

Hi
I work one week on, one week off is there any way to add a fortnightly schedule.
Id like the entity to turn on every second week.
Thanks
Nick

neliss · October 13, 2021, 8:10am

Recommended way is to create a binary_sensor.workday_sensor entity and use some automation or template to have it represent your working day pattern (ON=workday).
If you create schedules which should repeat on ‘workday’, scheduler will automatically look for this binary_sensor.workday_sensor entity to determine whether it should be executed.

Note that this feature is designed to work with the workday integration (which is not suitable for your case as it only works for weekly patterns).
Your workday entity should have a workdays property with a list of days which normally comprise your working week, such that scheduler knows ahead of the current day when the next occurrence would be.

Example:

Nicko1 · October 13, 2021, 3:18pm

Hi @neliss thanks great thank you so much.

febalci · October 14, 2021, 7:50am

Sorry if it has been asked before; i have schedules for windows covers:

As you can see for the multi entity schedules i have titles like “5x covers”. Is there a way to show a friendly name there, like “Upper Floor Covers” instead of “2x covers” and “Lower Floor Covers” for the other “2x covers”? I tried to put a name under Options-Name but i guess it only works for schedule.name service calls…

tykeal · October 14, 2021, 9:20pm

I would love that too. I’ve got a schedule that handles 2 devices and it would be nice to have a friendly name for the schedule.

neliss · October 15, 2021, 6:12am

You can use the display_options setting to choose what is shown in the overview page.
By default the first row contains entity+action, but you could also change it for the friendly name of the schedule.
If you’re looking for something else, please open a feature request for it on GitHub.

febalci · October 15, 2021, 7:18am

Wow, @neliss you are a life saver. It works perfectly thank you very much …

@tykeal it works like this:

type: custom:scheduler-card
title: Panjurlar
discover_existing: false
time_step: 5
include:
  - cover
  - group
display_options:
  primary_info:
    - name
    - '{entity}: {action}'

binaryMind · October 15, 2021, 8:13am

Does anyone have any idea why I have multiple Set temperature options when editing schedule?

magicdude4eva · October 17, 2021, 10:21am

As winterseason is starting I thought I will move from Schedy to these components. I hope you can help me with the following questions:

Does this component re-evaluate the schedule? Or does it just change state at the given time? For example if my schedule sets the temperature to to a given value and then someone turns on the heater, will the component turn the heater back to this temperature?
Will I be able to only heat if for example a certain temperature (outside) is reached?

neliss · October 17, 2021, 6:22pm

No. The user may override the programmed setpoint. Next timeslot ofcourse will still be executed.
If you want such behaviour you could use additional automation to temporarily disable the schedule when user overrides the settings, and turn it back on after a while.
Upon enabling of a schedule, the current task will be re-executed.

It is possible to assign a condition (like temperature sensor value below X) for execution of the schedule.
It doesn’t mean that the sensor is continuously watched though, the condition is only evaluated on entering the timeslot.

neliss · October 17, 2021, 6:28pm

This is usually caused by schedules which were created at some point, and afterwards the card configuration was changed, due to which the action which was previously assigned to the schedule, couldn’t be matched with the actions known by the card.
Card configuration can be either updated by the user (customization) or by some update.

I would expect that the issue is solved by recreating the schedules which have the set_temperature action for the affected entity.
If not, you may open a bug report and we can have a closer look.

binaryMind · October 17, 2021, 7:13pm

That would actually make sense. I had Set Temperature configured for my TRVs because I didn;t have that option. But strangely…when it started to duplicate I removed it from card config (still was visible when selecting a timeslot).

When I create schedule from scratch I don’t see Set Temperature at all Bummer

neliss · October 17, 2021, 7:22pm

Action heat = set temperature including operation mode to heating.

Setting temperature without operation mode may lead to the thermostat completely ignoring the command (if it is in operation mode off).

binaryMind · October 18, 2021, 8:08am

Just tested this and it will not work in case of Moes HY368 (aka TuYa TS0601). I am using those on Auto and only setting the temperature. When I switch to Heat and specify let’s say 18 degrees, the valve stays open 100%, because well…it is in heat mode.

So to make it work I would either have to add custom Set temperature, like I had before, or make schedules so I do Heat and set value and then after 5 minutes switch to Auto. Though it will be killing my battery because the valve will have to fully open

neliss · October 18, 2021, 12:43pm

Sounds like something is wrongly configured on the integrations side of your climate device.
Heat mode should regulate to setpoint, auto mode should actually ignore setpoint.
See HA modes definition for info.
I suppose you would need to customize the card to make things work (add set temperature task which doesn’t set the mode), because the card is programmed to show appropriate actions based on the supported properties of the entity.

binaryMind · October 18, 2021, 1:05pm

Might be. But at the same time this climate device is coming from Zigbee2mqtt I’m running on external Pi. I’ll add custom Set Temperature like I had before for now and try to research more, thanks.

faster777 · October 21, 2021, 9:45pm

I recently came across this discussion thread and the scheduler component/integration. User feedback and screenshots are impressive! The initial discussions from Aug 2020 mentioned dependency on node.js and mqtt and the desire to eventually remove these pre-reqs.

Now github indicates this component is at v3.2.2 … is there an update on these dependency requirements? Is mqtt still required before using this scheduler-component/card in HA? Thanks.

neliss · October 22, 2021, 2:21pm

Nope, this has changed in the meantime.
Schedules are now completely stored and processed in HA, no dependencies.

GenGT · October 26, 2021, 11:34am

Hi all!

I would like to know if it is possible this scenario with the addon. I want to turn on a light 30 minutes before sunset (this is easy) and turn off the light at about 21h (this is easy too) but… Here in spain in summer sunset begins at 22h so the light will be on until next day at 21h In winter sunset begins at 17 or 18h so is fine for winter/autumn, but not for summer/spring.

Thanks