Thanks mate.
I bought another 9 lights yesterday. I’ll set them up on my Z2M network and test your blueprint out.
Really appreciate you getting back to me.
hi
would love to see if there was a way to use it to change the color of the light by turning the wheel, because it has rgbw led strips
Sadly, currently both HA and ZHA do not support this.
Z2M does with the color_temp_step commands, but this can only be done with RAW MQTT commands, which my Blueprint is not based on as it would only work with Zigbee lights.
My blueprint relies on the fields supported in light.turn_on, light.turn_off and light.toggle actions.
For dimming it uses the brightness_step commands which is supported in HA, ZHA and Z2M.
I'm not super familiar with the code behind your blueprint but it is possible to control the color with the dial. I have it set up in an automation using the light.turn_on action.
action: light.turn_on
metadata: {}
data:
transition: 1
hs_color:
- >-
{{ (state_attr('light.kitchen_undercabinet_lights', 'hs_color')[0] - 10)
% 360 }}
- 100
target:
entity_id: light.kitchen_undercabinet_lights
You can do the same thing with temperature
action: light.turn_on
metadata: {}
data:
transition: 1
kelvin: >
{% set current_kelvin = state_attr('light.kitchen_undercabinet_lights',
'color_temp_kelvin') %}
{% set new_kelvin = (current_kelvin + 200) if current_kelvin is not none else 2000 %}
{{ [new_kelvin, 7042] | min | round(0) }}
target:
entity_id: light.kitchen_undercabinet_lights
As mentioned several times in this topic, there is no native way to do this directly in Home Assistant, but it can be achieved using Jinja2 templating. You can even use the raw dial data as input, multiplied by a factor, to control how fast the color temperature increases or decreases.
Your example also uses the deprecated kelvin: parameter -- this should be color_temp_kelvin: instead. I've updated the command to use the correct parameter and made it more flexible by reading the light's maximum color temperature directly from its attributes, rather than hardcoding a value:
action: light.turn_on
data:
color_temp_kelvin: >
{% set current_kelvin = state_attr('light.kitchen_undercabinet_lights',
'color_temp_kelvin') %} {% set max_kelvin =
state_attr('light.kitchen_undercabinet_lights', 'max_color_temp_kelvin') %}
{% set new_kelvin = (current_kelvin + 200) if current_kelvin is not none
else 2000 %} {{ [new_kelvin, max_kelvin] | min | round(0) }}
transition: 1
metadata: {}
target:
entity_id: light.kitchen_undercabinet_lights
As for implementing this in the blueprint, I'm still working out the best approach. The simplest option would be to add a select input to enable adjusting brightness and/or color temperature independently. However, most people have asked for the ability to toggle between brightness and color temperature control using the buttons itself, which is more complex to implement.
New Update Available (2026.06.1)
Dial color temperature control and double press light mode
What's New:
- Dial now adjusts color temperature — select "Color Temperature" in Rotate Mode per button
- Color Temp Speed slider (1–10) controls how fast color temperature changes
- Rotate Mode Helper — configure an input_text helper to toggle the dial between brightness and color temperature from any button action
- "Toggle Rotate Mode" action option in short release, long release, and double press selectors
- Double Press Mode light selector per button — turn_on/turn_off/toggle/toggle_rotate_mode
- Separate "Auto-Adjust Brightness" and "Auto-Adjust Color Temperature" toggles — disable color temp auto-adjust when using dial color temperature control alongside adaptive or schedule mode
Upgrade Instructions:
- Re-save any automations using dial rotation (renames "Dim" to "Brightness" internally)
- Re-enable "Auto-Adjust Brightness" or "Auto-Adjust Color Temperature" if you had "Auto-Adjust on Value Change" enabled
New Update Available (2026.06.2)
Fix adaptive auto-adjust race condition — all buttons now update correctly
What's Fixed:
- Auto-Adjust now works for all buttons, not just Button 1. When the lights_bright and lights_dimmed schedulers fire simultaneously, mode:single was silently dropping all but the first trigger — meaning Button 3 (dimmed profile) never auto-adjusted.
- All buttons in adaptive or schedule mode are now processed in a single automation run, so no adaptive update is ever dropped regardless of how many schedulers fire at once.
Upgrade Instructions:
- Reload the automation after updating the blueprint (no config changes needed)
Hi, I'm new to Home Assistant and I'm currently trying to migrate all my lights and switches from my Hue Bridge to Home Assistant. I'm using zigbee2mqtt. I found this blueprint, which is really great! I especially like the ability to control the volume of my media players.
What isn't working for me is adjusting the brightness or color temperature by rotating the knob. Sometimes nothing happens, sometimes it takes forever, or the brightness changes randomly. Could this be because I'm using grouped bulbs in my Hue Bridge? Do I need to integrate the bulbs into Home Assistant beforehand (via zigbee2mqtt)?
The API used to connect to the Hue Bridge will probably not be fast enough to do this no. I moved my Lights and Buttons at the same time so have never tested in a mixed setup.
If you have the Buttons paired to the original Hub, the Hub handles the traffic between the Buttons and Lights directly.
New Update Available (2026.07.1)
Fix auto-adjust "expected float for brightness_pct" error
What's Fixed:
- "Expected float for brightness_pct" error flooding the system log (500+ entries per session) when Auto-Adjust Brightness is off but Auto-Adjust Color Temperature is on, or vice versa
Upgrade Instructions:
- Reload the automation after updating the blueprint
Hi Daniel! Thanks for implementing my suggested changes a few months back.
I have some more suggestions I’d like to make.
Apologies in advance for the VERY long comment.
I’ve been playing around and feel like I’ve finally gotten the dimming to work very smoothly and without unintentionally going the wrong way (eg, dimming down when you rotate it right).
Not sure if I was the only one experiencing this issue though?
Problem:
Although you are using “brightness_step” for dimming, which should be relative, I think Home Assistant translates it into an absolute brightness value before sending the command to the bulb.
Let’s say your bulb is on 50 brightness. Even though your code might submit brightness +20, what actually gets sent to the bulb is brightness 70.
Now lets say based on how you’ve spun the dial, you’re wanting to send brightness +20 and then +10.
If your bulb doesn’t report the status changes to HA quick enough, what might end up happening is the following:
- Brightness goes from 50 to 70
- Home Assistant hasn’t yet received the report that the bulb is at 70 now, so it still assumes it’s at 50
- The second command for +10 changes the brightness from 50 to 60
- So what you see in the end: 50 → 70 → 60
- So you see it going up in brightness and then down, even though you only spun the dial right
I am not 100% sure about the above, it’s honestly just an educated guess based on what I can see happening. But the fix I’m suggesting below seems to have fixed the issue for me.
Solution:
Changing the automation mode to queued, and adding a 750ms delay after each dimming command seems to solve the issue.
This will give enough time for the bulb to report its updated brightness, so subsequent commands won’t go backwards.
In addition, queued will make the automation more responsive in general (eg quick button presses won’t be missed now).
The delay has also solved another issue I was having where Z2M would show a “Group Busy” error if too many commands were sent too quickly, which would just freeze up the dimming altogether for a small amount of time.
This should probably be applied to media mode too, but I don’t use that so haven’t tested it.
750ms is just a number I picked which seemed to work well during testing. Maybe a field to let users adjust it could be good?
- action: light.turn_on
target: '{{ button_1_light }}'
data:
brightness_step: -{{ (step_size | int(0) * button_1_step_size / 10) | int
}}
transition: '{{ button_1_transition }}'
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 750
There’s also one other change I made. The above change should technically be enough, but this additional change will provide some extra redundancy in one particular situation.
The Tap Dial seems to send a minimum of 2 events, even if you just rotate it one click to the right.
The final event sometimes results in a brightness_step of 0.
Which can cause the issue of brightness going from 50 → 70 → 50.
Therefore, I’ve added an IF statement above the dimming code, to prevent anything from happening if the brightness_step is 0.
- if:
- condition: template
value_template: "{{ ((step_size | int(0) * button_1_step_size / 10) | int) != 0 }}"
then:
- action: light.turn_on
target: '{{ button_1_light }}'
data:
brightness_step: -{{ (step_size | int(0) * button_1_step_size / 10) | int
}}
transition: '{{ button_1_transition }}'
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 750
I haven’t had a tonne of time to test, but from what I’ve seen, the tap dial seems to be working much smoother for me now!
Sidenote:
I know I previously suggested setting the automation to single mode.
It did seem to reduce the issue (though not solve it fully). It probably just helped as it caused some of the subsequent commands to be ignored.
Thanks again for the blueprint!
Actually upon further testing, this now causes an issue with the double press custom action (Z2M).
Both the light mode short release action and custom mode double press action execute, rather than just the double press executing.
I’ve changed to single mode and the solution still seems to be working, but I’ll do more testing and let you know.
Would be nice to be able to use queued or parallel mode for the improved responsiveness, but not sure how.
Single mode does still work with the fix (750ms delay fixing lights going in the wrong direction), and also retains double presses working properly.
So its what I’m using for now. But if there’s some way to make queued or parallel mode work, that would be great. It would make both dimming and button presses feel more responsive.
Queued:
Works with dimming (750ms delay applied properly) but not sure how you would go about making double presses work.
Parallel:
750ms delay and double presses don’t work as expected. It might be fixable with a helper to maintain a list of dimming events / double presses waiting to run, with an increasing delay added to each event in the list (eg 750ms and then 1500ms and so on).
Single Mode is the only mode usable for several things, for one, double press isn’t doable in any other mode.
I will need to check on the delays for the dial actions. 750ms is way too long for my taste.
The step commands don’t actually check the state of the light at all, that’s the whole point of the step commands. It would take way too much time to check the light state for every action and would make it not fluent at all.
Don’t know when I have time for this though, maybe next week.
Is there a way to adjust the speed of button presses when tied to the left and right turn of the dial in a custom action?
I have two buttons in HA tied to volume down and volume up key presses on a PC. I have these button presses tied to left and right turns of the dial respectively. Slow turns of the dial work great, increasing or decreasing the volume by the minimal steps with each notch of the dial. Large turns of the dial though do not register every click of the Hue dial, making large increases or decreases in volume occur very slowly.
New Update Available (2026.08.1)
Fix dial brightness jumping and add community discussion badge
What’s Fixed:
- Dial brightness jumping up and down while turning, caused by spurious zero-step rotation messages consuming the single-mode slot. Added step_size > 0 guard alongside the existing step_size != 255 guard.
- Fast custom-action turns dropping clicks for the same reason.
What’s New:
- Community Discussion badge at the top of the blueprint linking to this post.
Upgrade Instructions:
- Reload the automation after updating the blueprint.
1 Like
Having just purchased a selection of Smart Buttons to try with various results and some with poor design, I decided on the Philips Hue Tap Dial Button (RDM002) and I have to say the design and quality of this was absolutely perfect, so easy to mount with either screws or double sided tape (included) and with the strong magnetic button to the faceplate, these are ideal, quiet satisfying clicks, with control for up to 4 devices and with the dial too, these are perfect.
Anyway on to my actual reply to this topic, I came across this Blueprint from ‘danieldeni’ and this blueprint is absolutely fantastic, so easy to use and setup, you can just go basic or even advanced with it and more to the point it just works! Some other blueprints I tried, didn’t do what I wanted or just didn’t work at all.
So a big shout out and sincere thanks to you ‘danieldeni’ for all your hard work, time and effort you’ve put in to creating this Blueprint for us novice Home Assistant users and also with it being compatible with both Zigbee2MQTT (Z2MQTT) and Zigbee Home Automation (ZHA), it should work with any Home Assistant setup!
Thanks again Daniel - you’re a star!
1 Like