[FEATURE REQUEST] Cycle action (click alternative to hold_*_toggle)

[denilsonsa]

Feature Request

Is your feature request related to a problem?

I have a 2-button IKEA remote control, and I'd like to be able to both change the brightness and the color temperature from it. This can get tricky, as this controller doesn't have enough buttons. If I would also want to change the color as well, it becomes impossible.

The hold_*_toggle actions are the only ones that can set a value both up and down. However, they can only be set to button-hold events. (Well, you can set them to clicks as well, but then you have to manually set another click to release, which is both counter-intuitive and also requires an additional dedicated button.) We are missing similar up/down actions for clicks.

Describe the solution / feature you'd like

I'd like a click_*_toggle action, or maybe click_*_cycle action. The idea is that repeatedly clicking would change a value up (or down), and then either wrap around or switch direction. Look a these examples (wrapping around):

• warm white → click → medium white → click → cold white → click → warm white → …
• 10% → click → 50% → click → 100% → click → 10% → …
• 1% → click → 33% → click → 67% → click → 100% → click → 1% → …

This would behave like those non-smart LED lamps that are dimmable with a standard wall switch.

This kind of cycling could be used for any of the already existing light attributes (brightness, color, colortemp, …), and also…

• Volume levels (not sure if this is useful).
• Light presets (combination of multiple attributes, e.g. "dim warm light" → "bright warm light" → "bright cold light" → "medium purple light" → "dim red light" → …)
• Scenes (cycles between a list of HA scenes)
• Service calls (so the user could configure multiple service calls to be called in sequence, after each button press)
  • Configuration-wise, this is the most verbose. But this also allows implementing anything, including the other suggestions in this list.

Describe alternatives you've considered

Currently, I can use hold_brightness_toggle and hold_colortemp_toggle.

| event |           1            |           0           |
|-------|------------------------|-----------------------|
| click | on                     | off                   |
| hold  | hold_brightness_toggle | hold_colortemp_toggle |

However, that's a bit counter-intuitive, I'd prefer to keep holding up/down to increase/decrease brightness, and then assign double-clicks to changing the color temperature.

| event |           1            |           0           |
|-------|------------------------|-----------------------|
| click | toggle                 | cycle colortemp       |
| hold  | hold_brightness_up     | hold_colortemp_down   |

I know I can implement this behavior by using one or more scripts coupled with one or more inputs, and call them from controllerx. However, having it built-in would be much simpler to configure.

Additional context

Observe the available combinations of click, hold and up, down, toggle in the following table:

|         |  click  |  hold  |
| _up     |    ✓    |    ✓   |
| _down   |    ✓    |    ✓   |
| _toggle | missing |    ✓   |

This feature request aims to complete the "missing" combination, by suggesting a click-friendly up/down/cycle action.

[xaviml]

Hi @denilsonsa,

Thank you for the very detailed explanation of this proposal. This is, indeed, a very goo didea, but I have some questions to clarify some things. You said:

I'd like a click_toggle action, or maybe click_cycle action. The idea is that repeatedly clicking would change a value up (or down), and then either wrap around or switch direction. Look a these examples (wrapping around):

And then in the example you showed below, you only show how it goes up, but not down. So if the click_colortemp_toggle would do this, what would be the action to go down?

Also, correct me if I am wrong, the goal for this proposal is to have an action to step up or down through brightness or color in a cycle mode, right? Well, for this we already have the click_*_up/down, however, they do not work in cycle mode, just from min to max. Someone mentioned a similar (if not the same) feature in the community forum, and this was my reply. Is this behaviour what you are loking for? If so, my proposal was to add an option to change the way that the brightness and color stepper behave (MinMax or Circular).

Let me know what you think :)

Regards,
Xavi M,

[denilsonsa]

Those are fair questions, as my suggestion was more in the brainstorming phase than in actual implementation details.

And then in the example you showed below, you only show how it goes up, but not down.

Yeah, for conciseness I only showed the wrap-around/cycling behavior.

Also, correct me if I am wrong, the goal for this proposal is to have an action to step up or down through brightness or color in a cycle mode, right?

My initial idea (when I started writing) was to imitate the hold_*_toggle behavior ("bounces", reversing direction when hitting the extremes). Then I remembered about those non-smart bulbs that usually have 3 presets (depending on the bulb, either 3 brightness, or 3 color temperatures; but not both), and those behave as cycling (or wrapping around). Then I thought about expanding this idea in a more generic way, and I thought about having a list of presets (any combination of light parameters) and having a way to cycle between them. So, yeah, feature-creep started creeping up in the brainstorm. :)

Anyway… Both bouncing and cycling have same end result of allowing to go either up or down (given enough calls), the only difference is the path. Then, cycling from a preset list is a superset of both, because this list can be populated in any arbitrary way.

---

As a quick-to-implement solution, allowing the bouncing (MinMax?) and/or circular (wrapping around) and/or capping (stop at extremes, which is the current behavior) seems like a sufficiently simple solution. But I worry about how this option will interact with the existing actions. (Should it affect both click and hold? Or only one of them? Only for certain attributes? What if a user would like one button to behave a certain way, and another button in a different way?)

Side note: Custom light controllers already have too many actions ({click,hold}{brightness,white_value,color,colortemp,xycolor}{up,down,toggle} = 2×5×3 = 30). Maybe this feature here should wait until #78 gets solved.

[xaviml]

Hey @denilsonsa,

Thank you for expanding your idea. I see two requests from here then:

• bouncing: This is to have the same behaviour as the hold_*_toggle, but with clicks. So every time we click it goes to one direction and when reaching the extremes, it bounces and goes to another direction.
• cycling: This feature is to have a way of cycling through with brightness and color_temp the same way we can do it with xy_color. As of now this cycling feature is done through Steppers which is used internally, but it is a good idea to give the user the option of changing this. So this would add a cycling and minmax option. The cycling will not make sense to work together with the bouncing one, however, minmax yes.

Both features can then leverage the {manual, automatic}_steps (probably, they should be renamed to {click, hold}_steps) attributes, so user can specify the steps.

The total actions would be then:

{click,hold}_{brightness,white_value,color,colortemp,xycolor}_{up,down,toggle,cycle_up,cycle_down}

This is a total of 2×5×5=50 options. Although #78 aims to add parameters to the predefined actions, I think it is nice to have a set of predefined actions like this ready to be used.

Does this make sense to you as well?

Regards,
Xavi M.

[xaviml]

Hi there,

This feature is now part of the ControllerX beta v4.16.0b1. Unfortunately, the docs are not yet ready to be seen, but this is the markdown documentation about this feature that will be added to the documentation:

This page assumes you already know how the mapping attribute and predefined actions work.

A new feature that came with ControllerX v4.16.0 is the ability to configure the hold and click actions. Up until now, we had the {hold,click}_{brightness,color_temp,white_color,...}_{up,down,toggle} predefined actions like:

• hold_brightness_toggle
• hold_color_up
• click_colortemp_up
• click_brightness_down
• ...

They allow to use click (1 step) or hold (smooth dim) with different attributes and directions. However, it became difficult to expand and add more functionality, so now the click and hold actions can be configured as follows:

example_app:
  module: controllerx
  class: E1810Controller
  integration: deconz
  controller: my_controller
  light: light.my_light
  merge_mapping:
    2001:
      action: click # [click, hold] This is the predefined action.
      attribute: brightness # [brightness, color_temp, white_value, color, xy_color]
      direction: up # [up, down, toggle (only for hold)]
      mode: stop # [stop, loop, bounce (only for hold)] Stepper mode
      steps: 10 # It overrides the `manual_steps` and `automatic_steps` global attributes

The fields are the following:

• action: This is the predefined action, which in this case is click or hold.
• attribute: Attribute we want to act on. The available values are: brightness, color_temp, white_value, color, and xy_color. However, xy_color will ignore the mode and steps attribute since it already loops through the color wheel.
• direction: Direction to start. Options are up, down, and toggle. In case of click action, it will not accept toggle.
  • up: It goes up.
  • down: It goes down.
  • toggle: It changes direction everytime the action is performed.
• mode: This is the stepper mode. Options are stop, loop, and bounce. In case of click action, it will not accept bounce.
  • stop: This is the default behaviour. It stops when it reaches the ends (min or max).
  • loop: It loops through all the values under the same direction, so when reaching the end, it will start over. For example, if you configure the brightness with direction up, it will go from the value is currently in until 255 (default max), and then it will start over (1 default min) without releasing the button. This mode will not unless there is a release action or it reaches the max_loops attribute (default is 50 steps).
  • bounce: It bounces the ends, so when reaching the end it will switch directions. For example, if you configure the brightness with direction down, it will go from the value is currently in until 1 (default min), then it will start going up until reaching 255 and bouncing back again. This mode will not unless there is a release action or it reaches the max_loops attribute (default is 50 steps).

As you can see, the configuration is much flexible, however, it adds more lines than using the direct predefined actions. For this reason, the predefined actions like {hold,click}_{brightness,color_temp,white_color,...}_{up,down,toggle} will not be removed, but ControllerX will not have more of these since now it can be configured differently. This means for example that this configuration:

example_app:
  module: controllerx
  class: E1810Controller
  integration: deconz
  controller: my_controller
  light: light.my_light
  merge_mapping:
    2001:
      action: hold
      attribute: brightness
      direction: up

It is the same as:

example_app:
  module: controllerx
  class: E1810Controller
  integration: deconz
  controller: my_controller
  light: light.my_light
  merge_mapping:
    2001:
      action: hold_brightness_up

The old predefined actions have stop as a default mode.

[xaviml]

Once enough people download the beta, and not issues are reported, I will ship this with ControllerX 4.16.0.

[xaviml]

This feature has been added to ControllerX v4.16.0.