Emptied the cache, even switched from Chrome to Edge browser, works fine for all.
Could you maybe open the developer tools in your browser (ctrl-shift-i in chrome, F12 in edge) and check the source code of the area where the slider should be?
It should show something like this:
It would at least tell if the HA-slider is properly loaded.
Also, please double-check if version v1.3.3 is printed in the console log.
Could you also check if the same happens when you create a schedule to turn_on a light that is dimmable? Does it show the checkbox + slider, or both are missing?
Some more information:
Home assistant Core on docker version 0.115.2. My default browser is firefox version 80.0.1 (64-bits).
Iāve also tried Google Chrome with the same result, a missing slider.
kudos @neliss this couple card/custom_component is dope !! It just arrives at the right time before the winter, setting up my thermostats automation
I just have one question / request, joining what @LeadUr said above: could it be possible to trigger the right action when enabled again some schedule?
The use case I have for my heating automation is this one: I want to be able to switch from full auto / planned to manual or confort+, that will be a simple select mode that will toggle the thermostats related schedulers. But switching back to auto mode, enabling schedulers, should set the right temperature.
Do you think it would be possible to make the action not only trigger on time, but also on toggle, with time range as condition?
Sure, here is the story: imagine I have schedules so that temperature is set at 19Ā° before going from work to home, letās say at 18h00, then 17Ā° at 23h00.
If I have some guest at home, or if Misses wants to override it and go into manual mode she will set the input select I made from auto to manual and this would trigger a script that will deactivate the schedules and let us set the temperature (from a conditionally displayed card ) to letās say 20Ā°. Then if at 22h00 we set it back to auto this will just activate back the schedules but will not set the temperature back to 19Ā°. At 23h00 it will work fine and trigger the action though.
It is nearly the same feature request than @LeadUr to trigger the actions at HA restart.
Itās an issue the author of heaty / schedy already noticed and solve with another conception. But Iām not ready to go one with that much installation complexity. A gold solution would be a UI/UX friendly solution like you made with this catch on schedule feature like he has.
Having the ability to activate a scheduler after a restart would be awesome.
There are some cases when you have power loos. If a scheduler should trigger when the system was off, then you lose an action. Imagine you want to start a water heater at 4 PM, but the system was off from 3:50 PM to 4:05 PM. You come back home, want to take a shower and the water is cold
This is just a simple example, but ideally, there should be an option to enable scheduler after system starts.
I think that the hard part is that you only store the start time and not the duration or the end time.
But maybe there is a way to overcome that limitation
@Gromy Ah i get it.
Well, this is something that i have to deal with in my own house as well
The request of @LeadUr to have the scheduler (re)trigger an action that has been āmissedā, either due to HA downtime or downtime of the device, will be implemented.
The second part of the request, to have the scheduler āwatchingā for changes to a device during a certain timeslot, and act on changes, is still open for discussion.
Ofcourse you want to be able to override a schedule and manually change a temperature setpoint. The question is, if at some point, the scheduler should take back control and revert to the scheduled setpoint.
Honestly, iām not sure yet what is best here. Would like to look at the big players (Tado, Nest, etc.) see how they behave. Input is very welcome.
By the way, now that we are discussing the topic of timeslots.
I made some progress with the new timeslot editor.
It works quite well already, i just need to add some finishing touches.
The biggest open issue with it, is that while you are assigning actions to timeslots, in fact the actions are only executed on entering the timeslot. Hence the view is currently a bit misleading.
@KTibow I would say, only if you made a schedule for it with this new timeslot editor.
The way i see it, the timeslot editor and the (current) timepicker will both keep existing.
You create singular tasks with the timepicker, these will be of type āfire and forgetā.
Defining timeslots will be more reliable, you can assume that the schedule will ensure the device will be in the state that you want it to be.
The big question is how to deal with the manual overrides. Iām thinking of some sort of extra checkbox for adding āgraceā where you want it.
You miss-understand me on this. The goal would not be to watch changes on a device, but applying the same logic we would think about for catching up schedules on HA boot also on schedules toggle back on.
The same way a schedule wouldnt be missed on HA downtime, a schedule could be cought up on schedule back on. I really think it is the same shared logic.
@Gromy turning on a disabled schedule, will cause it to re-evaluate in which timeslot it needs to start. The behaviour would be the same as due to HA restart.
In the same way, if you create or edit a schedule, as soon as it is saved, it may also trigger an action immediately.
I chose the schedules to be switch entities exactly for the purpose of making them hackable for extra condition checks.
@Cadster@guims78 I just found out that the ādisappearing slider issueā is caused by updating to the latest version of HA (0.115.2 ābirthday editionā).
I will work on a fix, I expect it is a simple thing.
I keep you posted!
Also - as others have already mentioned - take a look at Schedy. It is a very versatile scheduling tool, but without a GUI.
It is - for example - capable of resending commands if somehow the device did not receive it. (eg.: Z-Wave devices often do not receive packets, so when it sends a setpoint command it waits for HA to confirm and if it cannot confirm, resends the setpoing command again for a couple of times, waiting inbetween, before giving up)
Hello, i have another question about Group management.
I donāt understand how and where to define group in scheduler card.
I created some groups in a folder (as i managed to split my configuration.yaml) by creating 2 files, one for climate and one for light.
How can i tell scheduler card to take into account my groups file ?