4.4: Simplification, beautification, great flexibility through Blueprints

!!! Please read - there are breaking changes !!!

Table of Content:

• Summary
• Breaking changes
• Other changes
• Bugfixes
  • 4.4.1: #342 bug when configuring frequency for every-n-days.
  • 4.4.2 #344 translation did not translate (so theat the state displayed in all lowercase)

Summary

Earlier this year, I have released version 4.0, which is changing the overall direction this integration is taking. In the past, I added a number of different options to configure the schedule. But as I kept adding more and more options, it started to make the whole thing hard to configure. People were confused. And it was also making it quite fragile - the configuration had to be right, and adding a new thing often broke other things. So I decided to stop adding more and more features and started rejecting them. But having the thing "frozen" was not really sustainable - there must be a better way!

So the theme for 4.0 is, to simplify the integration, but to allow it to configure more flavors at the same time. And the way this will work is, it will remove the exception from the integration, and move that to automations, supported by blueprints. First, I created a number of services, that would be called by automation triggered by an entity update event, and allow customizing the schedule. Then, I started creating blueprints to replace the earlier functionality and to address some of the feature requests you had in the past. Also, it allowed for anyone to contribute and share their blueprint with the others (and we already have the first one on the list).

And I am pleased to say this strategy works - the blueprints already have more flavors than the integration allowed before. There are 10 different blueprints, often allowing a slightly different treatment for the same situation - such as public holidays.

To allow going through the changes, I decided to stop the support of configuration in configuration.yaml. This will not only allow simplifying the configuration, but I also needed to have version management with automatic migration.

With all this prep work done, I am excited to finally introduce this release. As planned, it brings a major simplification of the configuration, as well as refactoring and code simplification. Before, the configuration had a different number of steps for each flavor, and it was quite confusing. Often, I got bug reports that some configuration options are missing, because people were confused. It is now much simpler - the configuration has 2 steps: in the first step, you configure the frequency and common parameters, in the second the parameters that depend on the frequency. The interface is has been cleaned up to be more clear, and the documentation has been updated.

Go and check out the new configuration experience. I hope you'll love it.

One of the downsides of moving the config into the GUI workflow was, that it was not so easy to share the configuration. Not anymore. This release supports the DOWNLOAD DIAGNOSTICS feature, that was introduced in HA in the February release. And I will ask you to add these diagnostics to all tickets you log from now on. Quite neat.

I think it goes in hand with the overall Home Assistant topic for this year - Streamlining Experiences. It is actually quite funny that we arrived at the same point at the same time. So here is what is coming:

Breaking change

• Removal of the obsolete parameters (see documentation - also shows as errors in the log file after the first start, if you still use them). This is for offset, include/exclude dates, and Public Holidays - that are now replaced by Blueprints.

Other changes

• Fix #342 (unable to configure frequency for every-n-days)
• Major simplification of the configuration. It is now (always) in two steps - in the first one you select the frequency and parameters that are always the same. In the second step, the parameters that depend on the frequency. I think I made the GUI crisper and cleaner.
• For the parameters requiring a list of values, I no longer require a comma-separated list but provide a checkbox-style list. I hope you'll appreciate it.
• Automatic migration of the configuration parameters (possible thanks to the move from YAML to Config Flow). Much simpler and more reliable.
• Major simplification of the configuration code (thanks to depreciation of the parameters, and YAML config).
• Registering it properly as a device
• Added DOWNLOAD DISGNOSTICS to the device page. This gives a nice overview of all configuration parameters and simplifies bug reporting. Please use it when reporting a bug.

Simplification, beautification, great flexibility through Blueprints

!!! Please read - there are breaking changes !!!

Summary

This fixes a bug #342, that made it impossible to configure frequency for every-n-days. I include the full change log for 4.4 as thsi is coming up few hours after the release.

Earlier this year, I have released version 4.0, which is changing the overall direction this integration is taking. In the past, I added a number of different options to configure the schedule. But as I kept adding more and more options, it started to make the whole thing hard to configure. People were confused. And it was also making it quite fragile - the configuration had to be right, and adding a new thing often broke other things. So I decided to stop adding more and more features and started rejecting them. But having the thing "frozen" was not really sustainable - there must be a better way!

So the theme for 4.0 is, to simplify the integration, but to allow it to configure more flavors at the same time. And the way this will work is, it will remove the exception from the integration, and move that to automations, supported by blueprints. First, I created a number of services, that would be called by automation triggered by an entity update event, and allow customizing the schedule. Then, I started creating blueprints to replace the earlier functionality and to address some of the feature requests you had in the past. Also, it allowed for anyone to contribute and share their blueprint with the others (and we already have the first one on the list).

And I am pleased to say this strategy works - the blueprints already have more flavors than the integration allowed before. There are 10 different blueprints, often allowing a slightly different treatment for the same situation - such as public holidays.

To allow going through the changes, I decided to stop the support of configuration in configuration.yaml. This will not only allow simplifying the configuration, but I also needed to have version management with automatic migration.

With all this prep work done, I am excited to finally introduce this release. As planned, it brings a major simplification of the configuration, as well as refactoring and code simplification. Before, the configuration had a different number of steps for each flavor, and it was quite confusing. Often, I got bug reports that some configuration options are missing, because people were confused. It is now much simpler - the configuration has 2 steps: in the first step, you configure the frequency and common parameters, in the second the parameters that depend on the frequency. The interface is has been cleaned up to be more clear, and the documentation has been updated.

Go and check out the new configuration experience. I hope you'll love it.

One of the downsides of moving the config into the GUI workflow was, that it was not so easy to share the configuration. Not anymore. This release supports the DOWNLOAD DIAGNOSTICS feature, that was introduced in HA in the February release. And I will ask you to add these diagnostics to all tickets you log from now on. Quite neat.

I think it goes in hand with the overall Home Assistant topic for this year - Streamlining Experiences. It is actually quite funny that we arrived at the same point at the same time. So here is what is coming:

Breaking change

• Removal of the obsolete parameters (see documentation - also shows as errors in the log file after the first start, if you still use them). This is for offset, include/exclude dates, and Public Holidays - that are now replaced by Blueprints.

Other changes

• Fix #342 (unable to configure frequency for every-n-days)
• Major simplification of the configuration. It is now (always) in two steps - in the first one you select the frequency and parameters that are always the same. In the second step, the parameters that depend on the frequency. I think I made the GUI crisper and cleaner.
• For the parameters requiring a list of values, I no longer require a comma-separated list but provide a checkbox-style list. I hope you'll appreciate it.
• Automatic migration of the configuration parameters (possible thanks to the move from YAML to Config Flow). Much simpler and more reliable.
• Major simplification of the configuration code (thanks to depreciation of the parameters, and YAML config).
• Registering it properly as a device
• Added DOWNLOAD DISGNOSTICS to the device page. This gives a nice overview of all configuration parameters and simplifies bug reporting. Please use it when reporting a bug.

Simplification, beautification, great flexibility through Blueprints

!!! Please read - there are breaking changes !!!

Summary

Earlier this year, I have released version 4.0, which is changing the overall direction this integration is taking. In the past, I added a number of different options to configure the schedule. But as I kept adding more and more options, it started to make the whole thing hard to configure. People were confused. And it was also making it quite fragile - the configuration had to be right, and adding a new thing often broke other things. So I decided to stop adding more and more features and started rejecting them. But having the thing "frozen" was not really sustainable - there must be a better way!

So the theme for 4.0 is, to simplify the integration, but to allow it to configure more flavors at the same time. And the way this will work is, it will remove the exception from the integration, and move that to automations, supported by blueprints. First, I created a number of services, that would be called by automation triggered by an entity update event, and allow customizing the schedule. Then, I started creating blueprints to replace the earlier functionality and to address some of the feature requests you had in the past. Also, it allowed for anyone to contribute and share their blueprint with the others (and we already have the first one on the list).

And I am pleased to say this strategy works - the blueprints already have more flavors than the integration allowed before. There are 10 different blueprints, often allowing a slightly different treatment for the same situation - such as public holidays.

To allow going through the changes, I decided to stop the support of configuration in configuration.yaml. This will not only allow simplifying the configuration, but I also needed to have version management with automatic migration.

With all this prep work done, I am excited to finally introduce this release. As planned, it brings a major simplification of the configuration, as well as refactoring and code simplification. Before, the configuration had a different number of steps for each flavor, and it was quite confusing. Often, I got bug reports that some configuration options are missing, because people were confused. It is now much simpler - the configuration has 2 steps: in the first step, you configure the frequency and common parameters, in the second the parameters that depend on the frequency. The interface is has been cleaned up to be more clear, and the documentation has been updated.

Go and check out the new configuration experience. I hope you'll love it.

One of the downsides of moving the config into the GUI workflow was, that it was not so easy to share the configuration. Not anymore. This release supports the DOWNLOAD DIAGNOSTICS feature, that was introduced in HA in the February release. And I will ask you to add these diagnostics to all tickets you log from now on. Quite neat.

I think it goes in hand with the overall Home Assistant topic for this year - Streamlining Experiences. It is actually quite funny that we arrived at the same point at the same time. So here is what is coming:

Breaking change

• Removal of the obsolete parameters (see documentation - also shows as errors in the log file after the first start, if you still use them). This is for offset, include/exclude dates, and Public Holidays - that are now replaced by Blueprints.

Other changes

• Major simplification of the configuration. It is now (always) in two steps - in the first one you select the frequency and parameters that are always the same. In the second step, the parameters that depend on the frequency. I think I made the GUI crisper and cleaner.
• For the parameters requiring a list of values, I no longer require a comma-separated list but provide a checkbox-style list. I hope you'll appreciate it.
• Automatic migration of the configuration parameters (possible thanks to the move from YAML to Config Flow). Much simpler and more reliable.
• Major simplification of the configuration code (thanks to depreciation of the parameters, and YAML config).
• Registering it properly as a device
• Added DOWNLOAD DISGNOSTICS to the device page. This gives a nice overview of all configuration parameters and simplifies bug reporting. Please use it when reporting a bug.

BETA: Simplified configuration

This is a beta of the next release. I have been testing it myself for a couple of days, and I'd appreciate more testing before I make it an official release. Thanks for your help.

A revision of the translations is welcome. I made some changes to the config, so I had to edit the translations. It is kind of hard for the languages I do not understand.

Breaking change

• Removal of the obsolete parameters (see documentation - also shows as errors in the log file after the first start, if you still use them). This is for offset, include/exclude dates, and Public Holidays - that are now replaced by Blueprints.

Changes

• Major simplification of the configuration. It is now (always) in two steps - in the first one you select the frequency and parameters that are always the same. In the second step, the parameters depending on the frequency. I think I made the GUI crisper and cleaner.
• For the parameters requiring a list of values, I no longer require a comma separated list, but provide a checkbox-style list. I hope you'll appreciate it.
• Automatic migration of the configuration parameters (possible thanks to the move from YAML to Config Flow). Much simpler and more reliable (hopefully).
• Major simplification of the configuration code (thanks to depreciation of the parameters, and YAML config).
• Registering it properly as a device
• Added DOWNLOAD DISGNOSTICS to the device page. This gives a nice overview of all configuration parameters and simplifies bug reporting. Please use it when reporting a bug.

Fix monthly frequency import to config flow

Bugfix

Fixing import of some monthly frequency configuration options to config-flow

Getting ready for Holiday blueprints

Summary

With this change, I am making a few parameters obsolete. Review the documentation. In the next release, I will simplify the integration to focus on the calculation of the collection schedule, and leave all exception handling to the blueprints using the manual_update.

For the public Holidays, this is using the integration "Holidays", which has just been included in HACS as well (I've been waiting for that with this release). So you will need to install that to use the holidays.

I think I have created the blueprints with equal functionality and made them available in the README - check the video about how to import and use them. More importantly, I'd like to encourage you to create your own blueprints and share them with others - in the past, there were many requests to these custom exception scenarios that I had to reject - now it is possible.

!!If you use any of these parameters, please migrate them to the blueprints, so that the next update will be non-breaking!!

I am also simplifying the configuration. The YAML config is not supported anymore. If you have the integration configured in YAML, it will be automatically imported on the first restart, and you will be able to remove the YAML config after that. This will not only simplify it again but also allow for automatic conversion going forward.

Breaking Change

Migrating the config from configuration.yaml (so not really a breaking change - it is automatic)
The only thing you need to do, after the restart, check it has been imported to the Configuration/Devices & Services and remove it from the yaml file.

Updates

• Documentation updates
• New blueprints

configuration.yaml migration to ConfigFlow

Breaking Change

Migrating the config from configuration.yaml.
After the restart, check it has been imported to the Configuration/Devices & Services and remove it from the yaml file.

Updates

• Documentation updates
• New blueprints

Check the video about how to import and use the manual update blueprints and automations.

Slovenian translation, Bugfix for group schedule, Empty schedule

New features

Added Slovenian translation. Thanks to @Protoncek for their first contribution.
Added a blank frequency, for those you want to generate schedule completely by manual_update
Added two first blueprints. Getting ready to move exception handling (holidays) to blueprints and to simplify the integration.

Bugfixes

Fixed #313 - group schedule did not work after the refactoring.

Documentation updates

Group schedule hotfix

Fixing #313

(Also includes not yet documented blank frequency)

MAJOR RELEASE: Setting the collection schedule by automation

The integration now allows configuring parameter manual_update: true. Then, after calculating the collection schedule, it will not automatically update the entity state. Instead, it will fire an event garbage_collection_loaded, which will allow you to programmatically add and/or remove dates based on whatever custom logic (e.g. based on values from external API sensor, comparing the dates with a list of holidays, calculating custom offsets based on the day of the week etc.), and then manually trigger the update of the entity state and attributes by calling the service garbage_collection.update_state.

Check the example HERE

I will appreciate very much your feedback and suggestions. Samples of automation you created that could be helpful for others would be great. You can send them as comments to the "idea" #287. Thank you!

Yes, this is an advanced feature, but if you do not configure it, the core functionality should work unchanged for now.
But it should address requests implementing different specific patterns or exceptions, so I can address these requests through that.

Said that going forward, I might make some very specific and confusing parameters obsolete and simplify the configuration, and leave some of the specific scenarios for automation templates (with your help). I am even thinking of creating a separate integration for holidays and addressing the exceptions through a set of blueprints. And I am thinking of adding a blank frequency option, in case you want to generate the schedule entirely by automation. Now, this is a big change, and I have no effective way of getting your feedback. So please send me your suggestions or comments.

This is the result of refactoring described in #287. There were a number of feature-request for very specific custom collection schedules, that should be now doable with this. (including #305)

This also fixes bug #311