Finalize compatibility with ESPHome 1.19.0.

CHANGELOG.md

@@ -6,6 +6,14 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Not yet released]
 
+### Added
+- Implemented support for visual feedback during the OTA flashing process in the
+  `example.yaml` file: the light becomes blue during the process, the brightness bar
+  represents the update progress, when updating fails the light flashes red and when it
+  completes successfuly, the light flashes green.
+
+## [1.1.0]
+
 ### Changed
 - Made it possible to use lambdas with the `preset.activate` automation. This makes it
   possible to link the action to an api service, which exposes the preset functionality
@@ -13,15 +21,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Fixed a rounding error in the slider sensor component. When using custom "range from" / "range to"
   settings, the maximum value could exceed the "range to" value due to rounding errors.
   Thanks to Jos for the heads up!
-- Made the codebase compatible with ESPHome v1.x.0
+- Made the codebase compatible with ESPHome v1.19.0
   ([PR #1657: Introduce new async-def coroutine syntax](https://github.com/esphome/esphome/pull/1657))
 
-### Added
-- Implemented support for visual feedback during the OTA flashing process in the
-  `example.yaml` file: the light becomes blue during the process, the brightness bar
-  represents the update progress, when updating fails the light flashes red and when it
-  completes successfuly, the light flashes green.
-
 ## [1.0.0]
 
 **Note**: This release requires ESPHome v1.18.0 or newer.

example.yaml

@@ -58,47 +58,6 @@ api:
 ota:
   password: "Password-For-Flashing-This-Device-Over-The-Air"
 
-  # These OTA triggers are used to provide some visual feedback during the OTA
-  # flashing process. The light is turned blue when the upgrade starts, the
-  # brightness indicator will represent the update progress (fills up from 0%
-  # to 100%), the light will flash red when the upgrade fails or green when the
-  # upgrade succeeds.
-  # You can safely remove these if you don't want the visual feedback.
-  on_begin:
-    then:
-      - light.disco_on:
-          id: ${id_light}
-          red: 0%
-          green: 0%
-          blue: 100%
-          brightness: 2%
-          transition_length: 0s
-  on_progress:
-    then:
-      - output.set_level:
-          id: ${id_front_panel_illumination}
-          level: !lambda return (x / 100.0f);
-  on_end:
-    then:
-      - light.disco_on:
-          id: ${id_light}
-          red: 0%
-          green: 100%
-          blue: 0%
-          brightness: 2%
-          transition_length: 0s
-  on_error:
-    then:
-      - light.disco_on:
-          id: ${id_light}
-          red: 100%
-          green: 0%
-          blue: 0%
-          brightness: 2%
-      - delay: 1s
-      - light.disco_off:
-          id: ${id_light}
-
 # The log level can be raised when needed for debugging the firmware. For
 # production, a low log level is recommended. Mainly because high volume log
 # output might interfere with the API/WiFi connection stability. So when