Hi,
Is it possible for a (non-admin) user to modify a schedule (not create one, just modify what exists)?
Unfortunately not.
There is a limitation in HA that causes the refreshing of the card to fail and the logs to be flooded with errors if non-admin users try to edit or create (thereās not really a difference) schedules.
There is an active issue about this.
Thank you @neliss , it seemed to me that I had seen something on this subject. But I think the core developers are working on itā¦
This project is awesome! Really like how it all works.
1 Like
How do you know they are working on this?
I brought the issue to their attention a couple of weeks ago (and then another time again), but they didnāt seem to care for compatibility with custom_components.
From what I know this will remain a problem for scheduler for quite a whileā¦
I canāt remember where I read thatā¦
Thanks for this great job.
I ask if it is possible to have a very useful feature in the Netamo thermostat. I have set the daily programs on this thermostat. If I decide to manually set a temperature, the application allows me to decide until what time I want to leave it active. Once the time has elapsed, the programming automatically returns.
Which one? Do you mean HA?
No, the application of Netatmo.
@splinter
The scheduler does not handle any component-specific configuration.
You can add custom actions to the card using customize. Seems like youāre looking for this action.
To all users who are missing schedule modification capability in the card for non-admin users:
Please vote on this request: https://github.com/home-assistant/architecture/issues/488 to have HA extended for providing this functionality.
Thanks 
Unfortunately I donāt speak English well and Iām using the translator but in this way I canāt explain myself well.
Iām ditching the Netatmo thermostat to switch to a sonoff snzb-02 temperature sensor with an always sonoff switch. I used the generic_thermostat platform. I would like to understand if it is possible to have the function present on Netatmo described above, with the new solution I have adopted.
On the scheduler I have already created the schedule to turn on the heating daily. Sometimes, I wish I could turn the heat on manually for a selected time. At the end of this time, the programming on the scheduler should return.
My climate schedulers were working perfectly fine until I updated Scheduler Component+Card and Home Assistant to the newest versions (I canāt recall which versions I used before). Now these climate schedulers do not do anything anymore. Other schedulers (lights etc) still work perfectly fine.
My Climates are KNX Climates and I only need to set presets (no heating/cooling, no set temperature). Has anything changed that would make these schedulers not work anymore?
1 Like
Hmm, thatās very strange. I didnāt make any (intentional) changes here in the past months.
Possibly something went wrong in the conversion from old to new storage, and they got corrupted.
Could you open an issue on GitHub (with some more info) to follow up on this?
That sounds just like what I experience here too. Climate entities are no longer affected by the scheduler, while other entities work just fine.
Debugging gives me this:
2021-01-17 08:15:00 DEBUG (MainThread) [custom_components.scheduler.switch] timer for switch.schedule_d96bcd is triggered
2021-01-17 08:15:00 DEBUG (MainThread) [custom_components.scheduler.switch] start of executing actions for switch.schedule_d96bcd
2021-01-17 08:15:00 DEBUG (MainThread) [custom_components.scheduler.switch] Entity climate.danfoss_devolo_home_control_radiator_thermostat_heating_1_2 is not available right now, action climate.set_temperature will be queued.
2021-01-17 08:16:00 DEBUG (MainThread) [custom_components.scheduler.switch] Rescheduling timer for switch.schedule_d96bcd
2021-01-17 08:16:00 DEBUG (MainThread) [custom_components.scheduler.switch] The next timer is set for 2021-01-18T09:15:00+01:00
2021-01-17 08:17:20 DEBUG (MainThread) [custom_components.scheduler.switch] Entity climate.danfoss_devolo_home_control_radiator_thermostat_heating_1_2 was updated to state=unknown, re-evaluating queued action.
2021-01-17 08:17:20 DEBUG (MainThread) [custom_components.scheduler.switch] Entity climate.danfoss_devolo_home_control_radiator_thermostat_heating_1_2 was updated to state=unknown, re-evaluating queued action.
Youāre having an entirely different problem.
Your entities have state unavailable or unknown when the schedule triggers.
In this situation the scheduler cannot run its action, and it will be postponed.
This is actually a feature.
Ok, it presents in the same way though and started when I updated everything two days ago. Manually changing climate entities still works just fine, so this error is only when the scheduler tries to change the temperature of a climate entity (also true for climate groups).
Any suggestion how I can figure out what is wrong?
Please check your climate entities.
If they actually go to unavailable or unknown state occasionally, the problem is caused there.
The history of the entities should give you insight.
Iām not saying that a bug in the scheduler is impossible, but this check for entity availability has been there since the timeslots are supported (3 months +).
Youāre right, all my zwave climate entities have state āunknownā. The only values I can see in history is ācurrent tempā and ātarget tempā so Iām not sure what state they had before the update. So I suspect the issue is not with scheduler but with the āstateā value of zwave climate entities. The climate groups that are reported with state unknown all contain at least one zwave entity, so that explains that.
This might still be the same issue that āgaggaā reported above.
Ok thats useful info.
From what I know, quite some things are being renovated in the HA Z-Wave integration(s), so the breaking could be the result of a recent update.
There are also these āsleepingā devices in Z-Wave, which only wake up every X hours.
Maybe after restarting HA they show up as unknown until they woke up.
AFAIK the unknown and unavailable states are reserved in HA for dysfunctional entities, hence these are checked by the scheduler.
Upon starting HA all entities start in unknown state until their integrations have started.
Scheduler waits for this to be completed, otherwise the actions would fail (in most cases).