Code refactoring - scheduling by automation

I plan to do a major rewrite of the integration, that will hopefully make this whole thing simpler and more flexible.

Over I added a number of exceptions to the holiday handling. The “holidays” feature was not meant to be the main function of the integration, but as there are many different ways to handle these, it grew quickly. As a result, it made the integration quite complicated, both for the configuration as well as the logic. And even then, there are more and more requests for handling different exceptions. So, I decided for a completely different approach.

I will pre-generate the collection schedule for year ahead (as I do for the calendar anyhow), as well as a list of holidays. But it will not automatically skip collections or move it to another day.

Instead, I will create two services - to remove_date and add_date to the calendar, allowing to adopt any logic anyone wants, including skipping specific dates, adding new ones etc. I also plan to add a new empty frequency where you can add the schedule by the automation based on whatever logic you want (e.g. take it from a list).

The schedule will be refreshed once a day (or you could trigger it by service) - after the refresh it will create an event. Then, you can have automation triggered by this event to handle the exceptions. At the end, it will search for the next collection date according to the new schedule. And I am thinking to create few blueprints to handle the basic exceptions, similar to what is done now by the automation (and with that, you will be able to create your own and share with the others).

I will also probably move completely to the config-flow configuration, as this is where HA is apparently moving anyhow.

I will use this issue to link all other related issues and I will close those. Feel free to discuss this below.

What do you think?

[rob51i03]

I can’t comment on the “how”, but the “what” seems to be all positive. I’m a huge fan of your component and this change can only make it better. It’s impossible to pre-empt all the different ways this component can be used, so adding the freedom you are suggesting to manipulate the calendar sounds like a real win, making the component more flexible and yet easier to maintain.

My only question is whether such a major code refactoring would require any existing garbage collection entities to be deleted and re-added? Not a show-stopper for me but it might affect any plans to add more entities in the interim.

Thank you for continuing to invest your considerable thought and effort into this custom component.

[bruxy70]

I created a couple of blueprints. You can check them out. I will be now creating a separate integration for holidays, then create more blueprints to fully replace this functionality, and then make these parameters obsolete, and eventually remove them.