Hi @k_manggaard,
Could you develop your idea? Do you mean infinitely cycling through the color temp? So from warm go to cold color directly and then cycle back again without releasing the button?
Regards,
Xavi M.
Thank you @Bobby_Nobble for the support. As I said, I understand the point of ControllerX not being part of Native HA. I did create ControllerX because HA was missing this functionality, and in my opinion it still does. Blueprints is a better way to solve that problem I had a year ago, but it does not solve the same problem as ControllerX does.
I guess if someone just needs an standard way of integrating a controller, Blueprints are okay, but if someone needs to go further with an specific use case, then I still recommend ControllerX for it since as you said, it is much flexible and solves all the problems that everyone is trying to solve in this thread.
2 Likes
Is it possible to add “multi functionality” to the on button, just like original work? First click on, second next collor/scene third next color/scene … and when you have cycled it goes back to the first color.
4 Likes
Hi,
I’ll try to explain:
Out of the box, when paired with a warm/cold bulb, the dimmer switch cycles through a number of predefined scenes when clicking the “on” button. What I would like is to cycle through predefined color_temp values instead. So if the bulb’s color_temp was at 50% when turned on, subsequent clicks would take it to 60%, 70%, 80% and so on, eventually going from 100% back to 0%. Preferably with the option to define the size and duration of “jumps”. This is actually the default behavior of the Trådfri remote, although that one only cycles through 3 values (I think).
Great work! And thanks for the interest.
Hi @k_manggaard,
Thank you for explaining this, I was not aware of the specific original behaviour. This is possible with ControllerX, including the adjustment of the steps you are mentioning. The only thing is not possible as of now is to go back from 100 to 0, unless you are working with a color light. But it could be easily added as a feature since there is the concept of a Stepper (MinMax Stepper: goes from min to max and stops; CircularSteper: cycles from from 100% to 0% and vice versa). However, the color temp and brightness are set to be MinMax Steppers.
Let me know if you are interested and I could help you out first with the configuration, and if needed I would need to create a feature ticket for the fact of going from 100% to 0%.
I have this controller paired with deCONZ, so I can show you this in a video when I can.
Regards,
Xavi M.
This is my solution for the cycling through scenes :
I have a script that takes a “scene” name (not a HA scene) and an light entity id and applies the scene to the light.
It goes like this :
alias: Set scene
sequence:
- choose:
- conditions:
- condition: template
value_template: '{{ scene == ''veilleuse'' }}'
sequence:
- data:
brightness: 25
color_temp: 369
effect: none
entity_id: '{{ light }}'
transition: 0.2
service: light.turn_on
- conditions:
- condition: template
value_template: '{{ scene == ''printemps_floral'' }}'
sequence:
- data:
brightness: 215
effect: none
entity_id: '{{ light }}'
hs_color:
- 338.447
- 40.392
service: light.turn_on
etc. for each scene.
Then, for each light, I have an input_select containing a list of scenes I want to cycle through for that particular light.
I then updated the blueprint as follow (extract of the changed part):
scenes:
name: List of scenes
description: List of light scenes
selector:
entity:
domain: input_select
mode: restart
max_exceeded: silent
variables:
scenes: !input 'scenes'
light: !input 'light'
trigger:
- platform: event
event_type: zha_event
event_data:
device_id: !input 'remote'
action:
- variables:
command: '{{ trigger.event.data.command }}'
cluster_id: '{{ trigger.event.data.cluster_id }}'
endpoint_id: '{{ trigger.event.data.endpoint_id }}'
args: '{{ trigger.event.data.args }}'
- choose:
- conditions:
- '{{ command == ''on'' }}'
- '{{ cluster_id == 6 }}'
- '{{ endpoint_id == 1 }}'
sequence:
- choose:
- conditions: '{{ is_state(light, ''on'') }}'
sequence:
- service: input_select.select_next
entity_id: !input 'scenes'
- service: script.set_scene
data:
light: !input 'light'
scene: '{{ states(scenes) }}'
default:
- service: light.turn_on
entity_id: !input 'light'
data:
transition: 1
It now works like with the Hue app.
Hey guys,
i have a Philips Hue Dimmer Switch but seemingly is this not the RWL020, RWL021 - BUT it looks so 
it haves the Model Number 324131137411!
Anyone knowes what kind of Hue Dimmer this is? Or is it possible to make this Blueprint ready for this one? =)
2 Likes
What had to be changed that this runs on Zigbee2Mqtt? =)
1 Like
I have added this blueprint + the automation but every time i press the Hue Dimmer switch i get a red light for all of the buttons except off. any idea why thats the only action that seems to work?
Can’t seem to get this to work. My RWL021 sends the event as follows, but nothing happens with the light. Anyone who can help be debug this?
{
"event_type": "zha_event",
"data": {
"device_ieee": "00:17:88:01:02:c1:50:19",
"unique_id": "00:17:88:01:02:c1:50:19:2:0xfc00",
"device_id": "7fda29db5cded63c24b37cc37391733b",
"endpoint_id": 2,
"cluster_id": 64512,
"command": "on_press",
"args": {
"button": "on",
"press_type": "press",
"command_id": 0,
"args": [
1,
3145728,
0,
33,
0,
0
]
}
},
"origin": "LOCAL",
"time_fired": "2020-12-22T12:44:51.760571+00:00",
"context": {
"id": "9d55de40164d587de24e3cab15347571",
"parent_id": null,
"user_id": null
}
}
The automation created looks like this, and it works like a charm to manually turn the light on.
alias: ZHA - Philips Hue Dimmer Switch
description: ''
use_blueprint:
path: vanstinator/zha-philips-hue-dimmer-switch-rwl020-rwl021.yaml
input:
brightness: '100'
remote: 7fda29db5cded63c24b37cc37391733b
light:
entity_id: light.sofflampan_level_on_off
I’ll reply to my own post. After updating the firmware for my Hue Dimmer Switches the blueprint works just fine!
Thanks @vanstinator this is great and eliminated many separate automations and scripts.
I added a Minimum Brightness option when dimming. Found this useful to set the brightness to the lowest setting that still produces a desirable amount of light.
Added Input
min_brightness:
name: Min Brightness
description: Minimum brightness of the light(s) when dimming
default: 0
selector:
number:
min: 0
max: 255
mode: slider
step: 1
Updated Variables
variables:
light: !input 'light'
force_brightness: !input 'force_brightness'
brightness: !input 'brightness'
min_brightness: !input 'min_brightness'
action:
- variables:
command: '{{ trigger.event.data.command }}'
cluster_id: '{{ trigger.event.data.cluster_id }}'
endpoint_id: '{{ trigger.event.data.endpoint_id }}'
args: '{{ trigger.event.data.args }}'
cur_brightness: '{{ state_attr(light.entity_id, ''brightness'') | int }}'
Updated Conditions
- conditions:
- '{{ command == ''step'' }}'
- '{{ cluster_id == 8 }}'
- '{{ endpoint_id == 1 }}'
- '{{ args == [1, 30, 9] }}'
sequence:
- choose:
- conditions: '{{ (cur_brightness - 25) >= min_brightness }}'
sequence:
- service: light.turn_on
target: !input 'light'
data:
transition: 1
brightness_step: -25
default:
- service: light.turn_on
target: !input 'light'
data:
transition: 1
brightness: !input 'min_brightness'
- conditions:
- '{{ command == ''step'' }}'
- '{{ cluster_id == 8 }}'
- '{{ endpoint_id == 1 }}'
- '{{ args == [1, 56, 9] }}'
sequence:
- choose:
- conditions: '{{ (cur_brightness - 50) >= min_brightness }}'
sequence:
- service: light.turn_on
target: !input 'light'
data:
transition: 1
brightness_step: -50
default:
- service: light.turn_on
target: !input 'light'
data:
transition: 1
brightness: !input 'min_brightness'
Still new to blueprints, any comments appreciated!
2 Likes
@term Interestingly enough in another Blueprint (ZHA - Philips Hue Dimmer Switch (individual buttons with long presses)) the author has a similar zha_event structure as you had prior to updating firmware and has long-press functionality that “we” don’t have here. It may be possible your old firmware actually supported more functionality, which I am unsure what to do with 
Anyone have a remote that may not “work” with this Blueprint, but has a more robust zha_event when you try e.g. a “press_type” for instance? Very curious as I’ve had remotes not upgraded for probably 2 years myself, so wondering what/when this all changed if I am observing the disparity correctly.
Self update from that other thread at ZHA - Philips Hue Dimmer Switch (individual buttons with long presses) – I just realized my weeks-old dimmer purchase has the more detailed zha_event like @term had prior. My other three remotes that are likely 3 years out-of-date on firmware updates have this Blueprint’s simpler zha_event structure.
Based on @term’s statement they upgraded firmware, I suspect my “new” remote has a very old firmware. The “firmware” value in Home Assistant’s Zigbee details show the same on both remotes, however, so I am unclear what value to trust to sort this out. I do not have a Hue hub to check further firmware information, unfortunately. Anyone have ideas/similar experiences?
OK, so based on some feedback about this event data being related to ZHA quirks functionality, I did a “Remove” in the Zigbee control panel on one of my “old” remotes and did the ‘Setup’ button on my remote. When the device was re-added, I am now seeing the extra button meta data! Will perform the same on my last two “old” remotes, but it seems like because they were added before some quirks functionality was updated, I never received that support in Home Assistant.
That said, I am now unclear this Blueprint structure is “the right one” long term. Love the design of it, but may be cool to merge functionality into the newer remote structure with the other Blueprint I linked so we can get more functionality out of the same remote long term.
same isue. hue app (and hub) can use the dimmer OK. “Standard” automations built manually can use the dimmer, but the 2 Hue DImmer automations dont see the device as being available for use. same model number on my device (bought from Amazon about 1 year ago)
I’m using this on 5 RWL021’s and it’s working great, thanks!
My only request, if possible, is to add the functionality of the on button cycling through the main 4? Color temperatures if you push the on button when the light is already on.
I saw a couple of posts mentioning scenes and scripts etc, but if it could be in a blueprint, that would be better.
1 Like
I’m having a weird issue with this blueprint where sometimes it sets the brightness to the minimum apparently just before turning a light off, I have the force brightness toggle off.
Tested with two different Hue bulbs, both of them always go back to their previous brightness level if toggled on/off via the HA interface or in the Hue app. If I just turn off the bulb with the switch using the blueprint though, when the bulb is turned back on through any method it’s set at minimum brightness.
It’s almost as if the “turn off” process which fades the brightness to off sets the actual brightness at the minimum in the last step.
Im not sure if its any changes, but I had to change all commands to named commands to make my EU-version work
1 Like
thank you for this, I had to use your version for my European dimmer, too.