Fix garbage_collection.offset_date

Fixing #394 - offset date function did not read offset parameter

Change CalendarEventDevice to CalendarEntity

Changes

• #392 CalendarEventDevice is depreciated in Home Assistant 2022.5.0 and is replaced by a new class Calendar Entity. This release is therefore changing the base calendar class to avoid warning messages and ensure the integration works in the future releases.
• I took this opportunity for general code review and stability improvements, also linked to python minimal version supported in HA core.

Change CalendarEventDevice to CalendarEntity

General code improvements (to be tested before the release)

Change CalendarEventDevice to CalendarEntity

4.7.1

Typing

Change CalendarEventDevice to CalendarEntity

#392 CalendarEventDevice is deprecated in HA 2022.5

Better exception handling

Change

Improved exception handling for services. Targetting cases where multiple automation run in parallel and attempt to move events on dates, that were previously changed by other automation.

4.5: Bugfixes and stability improvements

Bugfixes

#364 show the second configuration screen for blank frequency if the verbose state is selected
Minor improvements in config-flow, general stability improvements (thanks to automated testing)

4.4: Simplification, beautification, great flexibility through Blueprints

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

(and this is why this text is longer, sorry - worth reading though)

• Bugfixes
  • 4.4.1: #342 bug when configuring frequency for every-n-days.
  • 4.4.2 #344 translation did not translate (so that the state displayed in all lowercase)
  • 4.4.3 #351 unable to configure the blank frequency
  • 4.4.4 #354 better handling import of obsolete legacy config
  • 4.4.5 #355 remove an error message (false-alarm, there was nothing wrong, but was generating an error)

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. In another world - TO MAKE IT REALLY EASY... BUT ALLOW YOU TO MAKE IT COMPLICATED IF YOU REALLY WANT TO.

And the way this works is, it simplifies the config (no comma-separated list of values). And it removes the exceptions from the integration, and moves that to automations, supported by blueprints.

So to allow this simplification and not lose any functionality, 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). Yes, this is a bit more complicated than before, but we are talking about very specific and complicated scenarions, in which you can use the blueprints if you want to. But it will keep it easy for everyone else. Before, it was complicated for everyone. And if you feel this is too complicated, then just do not use the blueprints, right?

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. We have finally cracked scenarios such as skipping holidays or overflow to the next week if there is more than one.

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.
• #342 bug when configuring frequency for every-n-days.
• #344 translation did not translate (so that the state displayed in all lowercase)
• #351 unable to configure the blank frequency
• #354 better handling import fo legacy config - converting list of weekdays to a list

4.4: Simplification, beautification, great flexibility through Blueprints

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

(and this is why this text is longer, sorry - worth reading though)

• 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)
  • 4.4.3 #351 unable to configure blank frequency
  • 4.4.4 #354 better handling import of obsolete legacy config

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. In another world - TO MAKE IT REALLY EASY... BUT ALLOW YOU TO MAKE IT COMPLICATED IF YOU REALLY WANT TO.

And the way this works is, it simplifies the config (no comma-separated list of values). And it removes the exceptions from the integration, and moves that to automations, supported by blueprints.

So to allow this simplification and not lose any functionality, 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). Yes, this is a bit more complicated than before, but we are talking about very specific and complicated scenarions, in which you can use the blueprints if you want to. But it will keep it easy for everyone else. Before, it was complicated for everyone. And if you feel this is too complicated, then just do not use the blueprints, right?

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. We have finally cracked scenarios such as skipping holidays or overflow to the next week if there is more than one.

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.
• #342 bug when configuring frequency for every-n-days.
• #344 translation did not translate (so theat the state displayed in all lowercase)
• #351 unable to configure blank frequency
• #354 better handling import fo legacy config - converting list of weekdays to a list

4.4: Simplification, beautification, great flexibility through Blueprints

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

(and this is why this text is longer, sorry - worth reading though)

• 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)
  • 4.4.3 #351 unable to configure blank frequency

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. In another world - TO MAKE IT REALLY EASY... BUT ALLOW YOU TO MAKE IT COMPLICATED IF YOU REALLY WANT TO.

And the way this works is, it simplifies the config (no comma-separated list of values). And it removes the exceptions from the integration, and moves that to automations, supported by blueprints.

So to allow this simplification and not lose any functionality, 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). Yes, this is a bit more complicated than before, but we are talking about very specific and complicated scenarions, in which you can use the blueprints if you want to. But it will keep it easy for everyone else. Before, it was complicated for everyone. And if you feel this is too complicated, then just do not use the blueprints, right?

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. We have finally cracked scenarios such as skipping holidays or overflow to the next week if there is more than one.

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.
• #342 bug when configuring frequency for every-n-days.
• #344 translation did not translate (so theat the state displayed in all lowercase)
• #351 unable to configure blank frequency