nielsfaber / scheduler-component

Custom component for HA that enables the creation of scheduler entities
GNU General Public License v3.0
638 stars 41 forks source link

Cannot remove unavailable schedule #318

Closed esciara closed 9 months ago

esciara commented 9 months ago

Checklist

Expected behavior

When a schedule entity is deemed defective, one should be able to repair it or remove it.

Actual behavior

I created a new schedule entity, which immediatly appeared as being defective on the schedule card. When looking in the list of entities, it appears as unavailable, and I cannot manage to delete it.

image

Logs show me the following error:

2024-01-04 11:44:36.607 WARNING (MainThread) [custom_components.scheduler.timer] failed to calculate next timeslot for schedule b541fb
2024-01-04 11:44:36.613 WARNING (MainThread) [custom_components.scheduler.timer] failed to calculate next timeslot for schedule b541fb

Steps to Reproduce

=> the Defective error appears on the card, and it is impossible to delete/remove the entity as it becomes unavailable.

esciara commented 9 months ago

Following the potential workarounds I found with Google, each time I try to remove the entity directly from the /config/.storage/core.entity_registry file and its corresponding item in the /config/.storage/scheduler.storage file, when I reboot HA, the entity reappears.

nielsfaber commented 9 months ago

You should always be able to delete schedules via the service 'scheduler.remove'. Modifying files in the .storage folder can be dangerous.

Regarding your configuration:

For days, choose Sunday In the options tab, for "Period", choose the following wednesday => this makes that the next timeslot cannot be calculated

I agree with scheduler that this is an incomputable combination, so I am not surprised it is marked as defective. This is your own responsibility and not a bug.

esciara commented 9 months ago

I agree with scheduler that this is an incomputable combination, so I am not surprised it is marked as defective. This is your own responsibility and not a bug.

Thanks for your reply.

Could the code be improved to handle this case more gracefully rather than putting the user in a hard to recover state ? It could be having a clearer message saying how to recover from it, as despite my best efforts I could not find a solution, hence this issue got created.

It is easy to make this kind of mistake and I find getting a "punishment" like this for an involuntary mistake is a bit harsh...

nielsfaber commented 9 months ago

I agree the code can be improved to handle this better. But personally I don't have time to do so. You are invited to submit a PR for this.

esciara commented 9 months ago

Yes of course. And I am willing to look into the code and opened the issue in case someone else was interested in improving it.

Is it ok to reopen the issue then? And would you have some guidance on how you think this should be handled best?