From 0f888188cf1b354a3152c89a0952661389d6f769 Mon Sep 17 00:00:00 2001 From: Xavier Moreno Date: Fri, 3 Jun 2022 22:28:35 +0200 Subject: [PATCH] feat: change release_delay type from bool to float related to #497 --- apps/controllerx/cx_core/release_hold_controller.py | 12 ++++++------ docs/docs/faq.md | 2 +- docs/docs/start/type-configuration.md | 4 ++-- tests/integ_tests/release_delay/config.yaml | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/apps/controllerx/cx_core/release_hold_controller.py b/apps/controllerx/cx_core/release_hold_controller.py index e0dacd11..7d451e3e 100644 --- a/apps/controllerx/cx_core/release_hold_controller.py +++ b/apps/controllerx/cx_core/release_hold_controller.py @@ -4,7 +4,7 @@ from cx_core import Controller, action DEFAULT_DELAY = 350 # In milliseconds -RELEASE_DELAY = 0.1 # In seconds +DEFAULT_RELEASE_DELAY = 0 # In seconds class ReleaseHoldController(Controller, abc.ABC): @@ -14,7 +14,7 @@ class ReleaseHoldController(Controller, abc.ABC): delay: float max_loops: int hold_release_toggle: bool - release_delay: bool + release_delay: int async def init(self) -> None: self.on_hold = False @@ -22,14 +22,14 @@ async def init(self) -> None: self.max_loops = self.args.get( "max_loops", ReleaseHoldController.DEFAULT_MAX_LOOPS ) - self.hold_release_toggle: bool = self.args.get("hold_release_toggle", False) - self.release_delay: bool = self.args.get("release_delay", False) + self.hold_release_toggle = self.args.get("hold_release_toggle", False) + self.release_delay = self.args.get("release_delay", DEFAULT_RELEASE_DELAY) await super().init() @action async def release(self) -> None: - if self.release_delay: - await self.sleep(RELEASE_DELAY) + if self.release_delay > 0: + await self.sleep(self.release_delay) self.on_hold = False async def hold(self, *args: Any) -> None: diff --git a/docs/docs/faq.md b/docs/docs/faq.md index 422ac606..c7ebd305 100644 --- a/docs/docs/faq.md +++ b/docs/docs/faq.md @@ -45,7 +45,7 @@ This is probably happenning to you sometimes and is because the stop/release act However, these are some actions you can take to overcome this problem and reduce the number of times that this happens: -- If `release` action is sent at a similar time than a `hold` one, you could use [`release_delay: true` attribute](/controllerx/start/type-configuration/?h=release_delay#light-controller) to execute `release` actions 100ms after they have been fired. +- If `release` action is sent at a similar time than a `hold` one, you could use [`release_delay` attribute](/controllerx/start/type-configuration/?h=release_delay#light-controller) to execute `release` actions some amount of time defined after they have been fired. For example: `release_delay: 0.01` (time in seconds). - If using z2m, change the integration to listen MQTT directly, this way it will avoid the HA state machine layer. Read more about in [here](/controllerx/start/integrations#zigbee2mqtt). - If using deCONZ and you just want to dim your lights smoothly, then you can consider using [this AppDaemon app](https://github.com/Burningstone91/Hue_Dimmer_Deconz) from [_@Burningstone91_](https://github.com/Burningstone91). It brightens/dims your lights with a deCONZ calls instead of calling HA periodically, this means that deCONZ would handle the dimming for you. - Play around with delay (default is 350ms) and automatic_steps (default is 10) attributes. You can read more about them in [here](/controllerx/start/type-configuration#light-controller). The lower the delay is, the more requests will go to HA. The more automatic_steps, the more steps it will take to get from min to max, and vice versa. diff --git a/docs/docs/start/type-configuration.md b/docs/docs/start/type-configuration.md index 1b8e9fdb..5556fb92 100644 --- a/docs/docs/start/type-configuration.md +++ b/docs/docs/start/type-configuration.md @@ -32,7 +32,7 @@ This controller allows the devices to control light or group of lights. This all | `delay` | int | [Controller specific](/controllerx/controllers) | Delay in milliseconds that takes between sending the instructions to the light (for the smooth functionality). Note that if leaving to 0, you might get uncommon behavior. | | `max_loops` | int | 50 | Maximum number of loops when holding. The loop will stop either with a release action or reaching the `max_loops` value. | | `hold_release_toggle` | boolean | False | If `true`, a `hold` action will work as a release when another `hold` is running. This is useful when you have a button with just one action event and you want to use the hold-release feature, then you just need to map that event to a `hold` action. | -| `release_delay` | boolean | False | If `true`, a `release` actions will be delayed 100 ms. This is to avoid cases where `release` is send almost at the same time as `hold` actions. | +| `release_delay` | float | 0 | `release` actions will be delayed this amount of time (in seconds). This is to avoid cases where `release` is send almost at the same time as `hold` actions. | | `transition` | int | 300 | Time in milliseconds that takes the light to transition from one state to another one. | | `add_transition` | boolean | True | If `true` adds transition if supported, otherwise it does not adds the `transition` attribute. | | `add_transition_turn_toggle` | boolean | True | If `false` does not add transition when turning on/off or toggling, otherwise it adds the `transition` attribute to the call. See [FAQ #6](/controllerx/faq#6-light-is-not-turning-on-to-the-previous-brightness) for a further explanation on the use of this parameter. | @@ -88,7 +88,7 @@ This allows you to control media players. It supports volume, play/pause and ski | `delay` | int | [Controller specific](/controllerx/controllers) | Delay in milliseconds that takes between sending the volume up/down instructions. Note that the maximum value is 1000 and if leaving to 0, you might get uncommon behavior. | | `max_loops` | int | 50 | Maximum number of loops when holding. The loop will stop either with a release action or reaching the `max_loops` value. | | `hold_release_toggle` | boolean | False | If `true`, a `hold` action will work as a release when another `hold` is running. This is useful when you have a button with just one action event and you want to use the hold-release feature, then you just need to map that event to a `hold` action. | -| `release_delay` | boolean | False | If `true`, a `release` actions will be delayed 100 ms. This is to avoid cases where `release` is send almost at the same time as `hold` actions. | +| `release_delay` | float | 0 | `release` actions will be delayed this amount of time. This is to avoid cases where `release` is send almost at the same time as `hold` actions. | | `supported_features` | int | `0b10111111` or `191` | See [below](#supported_features-field) for the explanation. | | `update_supported_features` | boolean | False | If `true`, it will check the supported features field everytime before calling any call service action. Useful in case the supported features of the device entity changes over the time. | diff --git a/tests/integ_tests/release_delay/config.yaml b/tests/integ_tests/release_delay/config.yaml index 20f925b7..29916b71 100644 --- a/tests/integ_tests/release_delay/config.yaml +++ b/tests/integ_tests/release_delay/config.yaml @@ -4,4 +4,4 @@ livingroom_controller: controller: sensor.livingroom_controller_action integration: z2m light: light.livingroom - release_delay: true + release_delay: 0.01