hello I have the same problem. using firefox no problem.
Hi @neliss - loving Scheduler card & component - very useful.
Is this possible?
I want to have a schedule that does the following:
- During the daytime, say 09:00 - sunset, turn on and enable an automation (which turns a light on/off according to PIR status).
- At sunset, disable the automation and turn on a specific set of lights
- At midnight, turn off those lights.
I’m trying to figure out if this could be done in one schedule, which contains different domains/entities and some of which need to be turned on/enabled and others need to be turned off/disabled.
Thanks
Thanks for your enthusiasm for this project 
Unfortunately, you would need 1 schedule for controlling the automation, another for the lights.
I wish it was possible in HA to configure an action to be triggered when turning on/off an automation, it would be a very powerful feature.
Unfortunately you can only trigger on changes in other entities (not itself) in an automation.
As a hack/workaround, you could add a custom action to a light entity (or group) in the card (via customize in yaml), for turning on/off the automation.
Theoretically this way you could create a schedule where in one timeslot the light is controlled, in the other the automation.
But this is definitely not how scheduler is intended to be used.
Hello all,
I am thinking of moving the editor of the scheduler (the pages for picking entities, time, etc) to a dialog rather than keeping it inside the card.
The main advantage is that a dialog is not limited to the column width assigned to cards, so on PC/tablet there will be more space for placing the time bar, perhaps also more guidance text to make things more easy to understand.
Before getting into this I’d like to collect your opinions, since there will be no way back 
Moving the scheduler editor to a dialog
- Good idea, can’t wait to see this happen!
- I prefer the card as it works now, don’t change it.
- I don’t mind, as long as things keep working.
0 voters
Is there a downside?
Good evening, I started exploring this scheduler component a few days back and it seemed a perfect match for scheduling my thermostats.
But I am facing an issue with my Tuya TV02 thermostats: whenever I am switching them with turn_on, they fallback to preset state=auto.
In that state the scheduler conflicts with the devices’ builtin scheduler, i.e. both schedulers fire events. That’s why I tried to configure them preset_state=manual
Next thought was, instead of binding scheduler to climate entities, bind to proxy switches instead and script some automation.
But I can’t see how I could enrich the time slots with temperature values - which is supported for climate entities.
Any other approaches you suggest?
But I am facing an issue with my Tuya TV02 thermostats: whenever I am switching them with turn_on, they fallback to preset state=auto.
Why do you use the ‘turn on’ action, instead of switching the operation mode (to heat) and providing a setpoint?
What do you mean exactly by preset state? A climate device has a state and a preset mode, preset state seems a mix of both terms.
Can you share the properties of the entity as shown in Developer Tools → States?
Why do you use the ‘turn on’ action, instead of switching the operation mode (to heat) and providing a setpoint?
That’s done by another (Node red) automation: turn off thermostat if window is open for a while, turn on when closed. But following your advice, I could modify that to heat/setpoint to a frost protection value, thus permanently remain in reset mode =manual.
What do you mean exactly by preset state?
Preset mode seems better term. Values are “off”, “manual”, “auto”, “holiday”. In auto mode the thermostator runs it’s own schedule.
Meanwhile I built some support for modifying the builtin schedules (per weekday, thermostator) via HA dashboard, but I really like the comfortable user interface of your scheduler component.
Maybe bet on “Better Thermostat”, which integrates with your scheduler and comes with “open window” support. Here, I am missing the option to configure a delay, to avoid battery consumption on every short window open.
Many ways to Rome 
Same issue on Edge
hvac_modes:
- 'off'
- heat
min_temp: 5
max_temp: 30
target_temp_step: 0.5
preset_modes:
- none
- auto
- manual
- holiday
current_temperature: 20.4
temperature: 20
preset_mode: manual
friendly_name: Thermostat xxx
supported_features: 17
[Question]: is the “Re-evaluate when conditions change” option supposed to make it impossible to manually/temporarily change the temperature on a climate entity?
[Goal]: automatically select between two climate schedules based on room presence. Differentiated by conditions.
[Expected behavior]:
- the schedule is chosen based on the conditions using the “Re-evaluate when conditions change” checkbox.
- the ability to manually change the temperature
[Actual behavior]:
- the correct schedule is chosen based on the conditions using the “Re-evaluate when conditions change” checkbox. This works as expected when checked.
- the ability to manually change the temperature - this DOES NOT WORK when checked. The temperature setpoint reverts to the scheduled schema ‘bracket’ even though setpoint is not in my condition list.
I would think that “Re-evaluate when conditions change” only re-evaluates on the listed conditions, and not setpoint. Am I expecting incorrectly or is this a bug?
Scheduler Component: v3.2.12
Scheduler Card: v2.3.8
Home Assistant: 2022.11.1
1 Like
Hi @crlogic
Specifically this setting makes the scheduler ‘watch’ for any change in the entities used in the conditions. Every time the conditions are met the action of the (current) timeslot is executed.
So it does not actively block making manual changes to a climate entity. But it can override the manually made changes, in case the conditions become valid after making those changes.
I suppose the conflict is caused by the ‘livingroom thermostat is heat’ condition. I am guessing that if you (manually) change the setpoint of this thermostat, HA will fire an event that the thermostat state has changed, even though only the setpoint attribute has changed.
Scheduler has no intelligence built-in to evaluate the difference between previous and current state, so a state change from ‘heat’ to ‘heat’ will not be ignored.
To pinpoint whether this is the case, you could enable debug logging for scheduler.
For example by adding to configuration.yaml:
logger:
default: warning
logs:
custom_components.scheduler: debug
This should print a logging every time the conditions change, scheduler should tell you exactly what caused the action to be triggered.
You can also listen for the state_changed event via developer Tools → events. I suppose you will see the same information as scheduler will receive when changing your thermostat setpoint.
As a workaround, perhaps you could make a template sensor based on the state of your thermostat, and using this in the conditions for scheduler. I am guessing this sensor will be ‘immune’ for changes in the setpoint, so not cause the (undesired) re-evaluation.
Of course you’re free to open a bug report or propose a change in this behaviour.
PS (little bit off topic): Couple days ago I came across a nice (and thorough) research of yours.
Question back to you: which do you recommend, SEN0395 or LD2410? Any advise for a reliable PIR as well?
2 Likes
Hi @neliss - thanks for the detailed reply and great component!
Confirmed by removing it.
Ahh, the lightbulb clicked…
This works perfectly for the intended goal, mmWave-based-presence for individual room heating
SEN0395/Leapmmw 24Ghz series all the way.
While the LD2410 is far less expensive and it is not nearly as reliable in my testing to date (sleeping). The LD2410 may be suited better for near-field applications only (aka, just a desk).
I prefer room-based applications. I have had these side-by-side for ~3 months and have recently unplugged the LD2410 as it has never matched the performance of the SEN. I have a link in one of my threads for an AliExpress buyer who can get these reliably (the Leapmmw version).
I have fiddled w/ the AliExpress cheapo’s and come to the same conclusion as the LD2410… …reliability is worth the price and a Panasonic PaPir are worth their weight in reliability. You plug them in and they just work. No EMI problems, excellent datasheets to select power vs sensitivity vs latency etc… The only change I have made in my PaPir deployment is to use the highest power consumption model. I find that it responds fractionally faster than the energy saving variety. All my applications are wired.
2 Likes
Hi to all,
i use scheduler custom component from about one year.
All work as it should except re-evaluated option when condiction change.
Example:
I’ve set home temperature to 18.5 when family is home but i’ve changed it to 17.5 if family goes out (time slot 0.00 - 8pm)
If during afternoon family goes out scheduler component doesn’t set to 17.5 but it remains to 18.5.
I’ve set it like the image below.
What’s wrong?
Anyone has this issue?
Regards,
Alessandro
You can debug the issue by enabling log output for scheduler.
For example by adding to configuration.yaml:
logger:
default: warning
logs:
custom_components.scheduler: debug
When any entity used in the conditions changes, you will see:
State of (…) has changed, re-evaluating actions
And then you should see either:
Conditions have failed, skipping execution of actions
In case the conditions are not (all) met.
Or:
Executing service (…) on entity (…)
In case the conditions are met and the action is executed.
You can also check the history or logbook of the entities used in the conditions, to compare the states with your conditions (and verify whether you agree if the conditions are met or not).
1 Like
Hi,
If I change the Name of the Thermostat the view will be changed, so that I cannot see the details for next task more.
Standard view:
with changed “Name” in options:
How can I add this again (“Heating to 17°C”)?
Thanks!
In the card editor you can change it using this setting:
In YAML mode you can do it via display_options.
I have set:
But do not see the marked detail more…
As wrote, this happen only after changing the “Name”
Additional - in display-options I can set only
- “{entity}: {action}”
but not the “Name” - right?
You can define it as you wish, all combinations of the properties listed in the table in the documentation are possible. But make sure to set it under primary_info.
The only problem is that assigning a name to a schedule is considered optional, so the card uses the entity+action as fallback for {name} (otherwise you would have a blank space).
1 Like