Scheduler card/custom component

Spiro · November 9, 2022, 9:57pm

Can’t seem to adjust any schedule.

If I click on add a new section appears and within the next few seconds it goes away again. Some times it lasts longer and I can press save but when I go back into it the added bit has gone again. If I adjust the time 9 times out of 10 it doesn’t persist. Has the component become corrupt or am I doing something wrong. Doesn’t matter if I use chrome, edge or samsung internet. Restart HA, reload scheduler nothing makes a difference.

No numbers appear in the boxes. I can type in numbers ( they are visible if I highlight the box, but they aren’t retained after saving and going back in.

neliss · November 10, 2022, 6:23am

Please check your browser logs and verify you’re on the latest version of the card (v2.3.7).
If not, update the card or clear your browser cache.
If this doesn’t help, create a bug report in GitHub.

manuel_R · November 10, 2022, 6:54am

hello I have the same problem. using firefox no problem.

DerekO · November 10, 2022, 9:05pm

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

neliss · November 11, 2022, 6:55am

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.

neliss · November 13, 2022, 8:13pm

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

Sddawson · November 14, 2022, 2:59am

Is there a downside?

h27rolf · November 14, 2022, 6:37pm

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?

neliss · November 17, 2022, 4:40am

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?

h27rolf · November 17, 2022, 1:01pm

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

Remco_Ploeg · November 17, 2022, 6:12pm

Same issue on Edge

h27rolf · November 17, 2022, 8:34pm

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

crlogic · November 18, 2022, 2:45pm

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

43F878C6-BD29-442F-AD83-5F62CA6E5600

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

neliss · November 18, 2022, 5:42pm

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?

crlogic · November 18, 2022, 6:05pm

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.

alessandro.bardi · November 19, 2022, 10:45am

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

What’s wrong?
Anyone has this issue?

Regards,

Alessandro

neliss · November 19, 2022, 11:18am

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

michapr · November 19, 2022, 3:45pm

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!

neliss · November 19, 2022, 5:11pm

In the card editor you can change it using this setting:

In YAML mode you can do it via display_options.

michapr · November 19, 2022, 5:28pm

I have set:

But do not see the marked detail more…
As wrote, this happen only after changing the “Name”