Just upgraded to 2.0.0b and no issues!
I had a problem on my brotherās installation and I had to restore a backup from the day before.
Everything went well, except for the schedules.
I lost some of them and some are no longer correct.
Where is this information stored and how can I verify that it is properly backed up?
Now I have to check everything, but it would be interesting to open the backup and check if it was saved correctly.
PS : not the beta, but last stable
I was curious en so tried the beta wich all went well!
Great work!!!
Only minor issue is that i still have the pre-beta switches.
The one with _2 is the converted one.
How can i remove those?
My post only applies to the beta (v3.0.0b)ā¦
Storage location is mentioned in my post as well.
If you have trouble updating between stable releases, this is completely unrelated.
The migration process literally makes a duplicate of the old schedules.
After restarting HA the old ones should disappear for good (I didnāt know how to do this automatically).
1 Like
Iām sorry to tell that after a restart of home assistant (core 2020.12.0) i no longer see them in my card.
The old ones are gone, the converted entities are still there (state is unknown) but donāt show in the cardā¦
The new feature that deletes the schedule after execution works.
I got my schedules back by changing the state manualy from unkown to on.
So now they visable in the card again.
And the are gone again, will revert to previous version.
I hadnāt seen your post on the beta when I wrote. But my problem is after a restoration or for example schedules planned to work on Sunday have ended up on weekdays etcā¦
Anyway, Iām in the process of taking it all back.
At the same time the new version with the schedules stored in a separate json should solve this kind of problem.
We will say that this incident did not take place at the right time !!!
Try deleting everything related to the scheduler and make a fresh install.
1 Like
@neliss I have been using this component for a few months now, and I just realized that it is now an integral part of my Home Automations! Thank you for all of the hard work you have put into this!
I am using it to turn on the Holiday lights, and make sure the downstairs fans and printer is turned off every night, and that my wife has warm water at her sink in the mornings. Also, I have a separate scheduler for managing my boys computer network access. (They are allowed only a few hours of game time during the school week.)
1 Like
I try to create a heating activation program ā¦ it happens that if I create an ignition with temperature settings ā¦ it sends the new setpoint data to the climate entity but does not activate on ā¦ while if I create a switch-off program it works ā¦ clarifications?
Really nice but it would be useful if it was possible to make different schedules for different days. For example: turn off the lights at 11 pm on weekdays and in the weekend at 1 am.
Sofar when I try to set it, itās the same for all days no matter what I choose.
You can make 2 schedules in the meantime.
Tnx, will try!
Which climate integration do you use?
It could be that it does not support setting temperature + mode together in 1 action.
You would have to create separate actions (or keep it in heating and only change the temperature).
I will improve this soonā¦
climate entity in home assistant ā¦ combined with switch esphome firmware on the node
as soon as I add heating in the programming it automatically selects the temp. setpoint ā¦ so I canāt just turn ON the heating
To make things logical I think it would be necessary that when in a shema :
-
if we pass a switch to on over a range from 1:00 to 2:00 this switch will turn off at the end of the range without having to program the following rangeā¦
-
as well as in the case of a thermostat if at 01:00 it is set to 21Ā°, memorize the previous set temperature to restore it at the end of the range.
In the same way we could imagine using predefined temperatures (in input_number) for climate, and instead of adjusting temperatures, apply these predefined valuesā¦
Again @neliss these are just ideasā¦ Merci again for your work!
Before the scheduler I applied predefined instructionsā¦
Please check out this post. Someone took the effort to improve the generic_thermostat component to fix this limitation.
Why would this be necessary?
I think the current functionality is OK already, many people are able to use it as it is without problems.
I think not in all cases it would be desirable/intuitive to revert to the state before the timeslot, I rather let the user choose what to do after. What would be wrong about that?
it would require quite some code to add the intelligence for reverting the state of an entity.
HA uses service calls to set the state (which I called actions in this card), so the component would need to know which service calls to make to set a device to a certain state.
For a climate entity it may already be difficult, because some thermostats (including my own), would automatically go to hvac_mode=heat and cancel an active preset_mode when you change the temperature setpoint. So how would the component be able to know what to do for bringing it back to previous point?
Also consider scenarioās like an initially unavailable entity or restarting HA during a timeslot. In such events the scheduler wouldnāt be able to revert to the original state.
Long story short: I donāt see it that bad to ask the user to fill in the last timeslot. It saves a lot of trouble.
Nice work @neliss !!
Did you had versioning into the storage files so if one day you have to publish a new major version you could easily detect old version and provider auto-migration to the new format?
(Also no version can be seen has v0 and versioning can be added later)
Another possibility, which seems to me even more interesting and which would be in your logic without needing to know the previous range, would be, on a range, to define a start action and an end action, this would avoid having to define the next actionā¦