It will be proportional to how much it’s turned if you automate it the way I described.
A small turn of the dial will change the light a little bit. A medium turn of the dial will change it more. A large turn will change it even more.
It will be proportional to how much it’s turned if you automate it the way I described.
A small turn of the dial will change the light a little bit. A medium turn of the dial will change it more. A large turn will change it even more.
First up, big thanks to @gTunes !
I liked the original, but because I use mine for lights, I though it’s more appropriate to just have two actions for rotation: Clockwise and Counter-Clockwise.
To still have proportional dimming, I just pass the step_size
to the script I use for controlling the lights, this in turn calculates the brightness_step to adjust the lights by, assuming the dial’s step size is proportional to degrees turned, which seems to be the case (more or less).
This way you have more granular control. This is probably as close as you can get to having realtime control of lights using the Philips dial in Home Assistant using ZHA. Using this setup, I have a minimum brightness_step of about 5, which is perfect for my purposes.
Bugs fixed:
step_with_on_off
zha event with a transition_time
of 8step_size
and step_mode
are only accessed/rendered if the dial is turnedThis is what an action with the step_size
looks like:
action: script.dial_dimmer
metadata: {}
data:
dial_helper: input_text.dial_1_helper
step_size: "{{ step_size }}"
enabled: true
I use it together with this script I made:
alias: Dial Dimmer
mode: restart
sequence:
- if:
- condition: template
value_template: "{{ is_negative }}"
then:
- action: light.turn_on
metadata: {}
data_template:
entity_id: "{{ states(dial_helper) }}"
brightness_step: "{{ -1 * (255 * (step_size) | int / 360) | int }}"
else:
- action: light.turn_on
metadata: {}
data_template:
entity_id: "{{ states(dial_helper) }}"
brightness_step: "{{ (255 * (step_size) | int / 360) | int }}"
fields:
step_size:
selector:
number:
min: 1
max: 360
step: 1
name: Step Size
required: true
dial_helper:
selector:
entity: {}
required: true
name: Dial Helper
description: The Input Text to get the lights entity id from
is_negative:
selector:
boolean: {}
name: is_negative
default: false
required: true
(the dial_helper is something I came up with, to be able to dim different zones with one dial. It saves the last selected light’s entity id. So this way I can have the dial controll different lamps with the rotary encoder)
alias: Dial Zone Updater
sequence:
- action: input_text.set_value
metadata: {}
data:
entity_id: "{{ dial_helper }}"
value: "{{ lights }}"
- condition: template
value_template: "{{ feedback }}"
- action: light.toggle
metadata: {}
data_template:
entity_id: "{{ lights }}"
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 250
- action: light.toggle
metadata: {}
data_template:
entity_id: "{{ lights }}"
fields:
dial_helper:
selector:
entity: {}
required: true
name: Dial Helper
description: The Input Text to update with the entity Id of the lights
lights:
selector:
entity: {}
name: Lights
description: The entity Id of the lights to be controlled
required: true
feedback:
selector:
boolean: {}
name: Feedback
description: Enable to pulse the lights (toggle twice with short delay)
default: true
required: true
Hi, @david_kalbermatten.
Thanks for sharing your blueprint and for crediting mine as inspiration
You might be better off with a new thread for you blueprint rather than posting it here, in mine. A new thread will make it discoverable and will also allow you to have conversations with your users without those being intermixed with discussions of this blueprint.
The issue you identified with long presses generating step events was, coincidentally, very recently discovered by another user and was being discussed on the PR thread for the RDM002 changes. A new issue was created today to track it: [BUG] Philips RDM002 long press indistinguishable from dial left rotation · Issue #3696 · zigpy/zha-device-handlers · GitHub
Your observation that we may be able to use transition_time to discriminate the events is very helpful. I’m investigating using that workaround in my blueprints until (or unless) the underlying issue gets fixed.
I’m working on another Blueprint which is based on yours as a start but with more functions added, like dimming/volume per button so it gets more multi functional.
I managed to filter out the wrong long press commands with:
conditions: "{{ command == 'step_with_on_off' and step_mode == 'StepMode.Down' and step_size != 255 }}"
I uploaded my own Blueprint as well.
I didn’t see @david_kalbermatten already made the fixes, but the same are fixed in my Blueprint as well.
A small update today. Existing users can re-import by clicking the “Import” button in the first post. Today’s update fixes the issues identified by @david_kalbermatten and @danieldeni. Thank you both!
Can someone give feedback if the switches configured with this BP now update the GUI as well or is it still bugged out?
I’m not sure what this is in reference to.
This blueprint, like other blueprints, just allows you to specify automations for various events. It runs the scripts when the appropriate events occur.
Typically a script will do something to change the state of an entity and display elements respond to that state change. Maybe you’re using a custom card or something else that isn’t reflecting state changes. That’s just a guess.
If you think there is a bug here, or even the possibility of a bug, can you help figure out what that might be? Otherwise, I just don’t think there’s something to be fixed.
Hi,
Thank you for your blueprint !
I have a request for this, would it be possible to increase/decrease the volume only if the media player is playing, this in order to avoid that if someone “plays” with the Philips Hue Tap Switch, it increases the volume very loudly.
Sorry for my English, I am from France !!!
Hi, @stephane1.
Thank you for the suggestion!
This particular blueprint doesn’t have the concept of a player or volume controls - everything the user does is fully custom. So there’s no way for me to check the state of a player but if you use this template, you can certainly do it yourself in the automations you provide for the rotation events.
I wonder if you might be thinking about my similar blueprint that is meant for media controls. That one is here:
I liked your suggestion so much that I went ahead and implemented it in that blueprint!
If you use that blueprint, you can now find a new toggle switch under “Volume Controls” that will allow you to do exactly what you’re asking. It defaults to “off” so it won’t change the behavior for existing users. You just need to turn it on to get the behavior you want. If you have comments about that feature, please leave them on that post rather than this one.
Thanks again for the suggestion! You’re credited in the release notes
Thank you for your reply and for the modification you have done in the other blueprint, I am going to use it !
Hi,
I am trying to use the custom controls blueprint, however no philips devices are found.
An idea ?
Thanks
Sorry I did a mistake, my problem is with the custom controls blueprint !
Got it.
I’m surprised to hear this. You definitely have a Philips RDM002 as pictured in the first post and its connected via Zigbee Home Automation (and not Zigbee 2 MQTT or something else)?
Can you share a picture of what you see when you look at the device? I see this for mine.
My devices are connected via Zigbee 2 MQTT !
This blueprint, and the other one I referenced, is specific to Zigbee Home Automation (ZHA) and doesn’t support Zigbee 2 MQTT.
Unless you decide to switch to ZHA, I’m afraid you won’t be able to use it. I’m glad we at least figured out what the issue was!
I did make a blueprint for controlling this dial using Z2M back in 2023, but I’m not sure if that blueprint still works and I’m not currently supporting it because I’ve moved to ZHA. If you’re interested in looking at it, it’s here, but if you find issues I don’t think I’ll be able to help.
Ok, thanks you for all your explanations.
Thank your for your blueprint, it helps a lot.
But unfortunate it does not work when activating scenes.
I noticed the blueprint is called three times when I press a button.
The the third one is my problem. Because this one cancels my action which is configured for button 1 short presses.
Any idea what is going on here?
Hi. Thanks for posting this.
I have a theory but before I explain that - based on your explanation, it seems that moving your automation to the button_1_short_release event would fix the problem. If it does, that’s probably the simplest thing to do.
I suspect that the issue you’re encountering is caused by the “automation mode” specified within the blueprint. The automation mode is currently set to “restart” which means that if an event is being processed and another event arrives, the in-progress event is stopped.
You can read about automation modes here: Automation modes - Home Assistant
I’m guessing that whatever your automation is doing is in progress at the time of the button release. So the in-progress “press” event is pre-empted so the release event can be handled.
I’m not sure the other modes are better for this automation. If you want to experiment with a different mode, you can edit your local blueprint and change the line that is currently
mode: restart
to use single, queued, or parallel. Honestly, though, I think the most straightforward approach is to just move to using release events.
Please let me know what you try and how it goes! Thanks!