This is a blueprint for the Philips Hue Dimmer Switch specifically for use with ZHA.
Control lights with a Philips Hue Dimmer Switch.
The top "on" button will turn the lights on to the last set brightness
(unless the force brightness is toggled on in the blueprint).
Dim up/down buttons will change the brightness smoothly and can be pressed
and hold until the brightness is satisfactory.
The bottom "off" button will turn the lights off.
I’ve updated the root blueprint to make it slightly more generic. There’s a small chance for some confusion. But the criteria should be tight enough to generally only surface supported philips remotes. Once I figure out how to allow for a defined enum of model numbers I’ll provide another update.
I think this is wonderful, thanks!
I hope version could be released some time that mimicks the advanced scene toggle function (choosing scenes based on amount of clicks on the on-button)
Hi, thanks for sharing this. Big help for a newb like me.
The original scene select function is great, but I think it would be even better to have the “on” button step cycle through color_temp values (when light is on). Maybe with a selector for number of steps.
I have a very primitive automation doing this, but my lack of yaml skills prevent me from incorporating it with your blueprint and if your (very cool) brightness feature is on it’ll kick in whenever I press the “on” button. An additional feature could be a smooth transition through color_temp when “on” is held.
I’m looking at your code for minutes now, it’s awesome how easy blueprints would make automations for newcomers!
We’re using this dimmer switches in horizontal in the following way:
using the “I” button for light 1 & the “O” button for light 2
For both: on (short press) and off (long press)
I could thing of a way to use your blueprint to archive this.
But currently i’m using a variable to store the last changed light of this two and using the dim up/ down button to change the brightness of the last changed light. But I’ve got no idea how I could solve that using only one automation (currently having one for turning light 1 on/off, one for light 2 on/off, and one for each light to change the brightness) or make that available for others as a blueprint.
Maybe you find that helpful, too and are able to edit your blueprint and post that separately
Greets
I think its best to make one general template for each speciality. One base that do the dame as philips default and one that can switch between lights. I do the deconz version and have the color temp mode fixed tomorrow (code can be exchanged) but its also possible to use same principle (long press) to change bulb or so.
But not one size fits all, that i do not suggest. Keep this one simple
With the greatest respect to yours and others work, check out the ControllerX add on as mentioned above, it will make your life so much simpler, out of the box it makes the Hue Dimmer work as nature intended and that’s literally just the most basic function…
I have a wish to keep my setup as simple as possible, for instance:
Using ZHA instead of Deconz.
Using HA Automations instead of Node-Red.
Of course, it has to be without considerable loss of functionality (which is why I am using ControllerX now). But it is my experience, that a simpler setup brings less headaches down the road, and I am definitely going to test if this can replace ControllerX.
Thanks, man after my own heart, both examples are the same for me, other than came to ZHA from zigbee2mqtt, although I’ve also found they work better but must admit I just don’t get on with Node-Red, actually seems far more complicated than good old yaml for everything I want to do
Also admit I avoided AppDaemon like the plague for ages and only installed it for ControllerX but hadn’t realised the add-on now makes it so simple and it’s like it’s not even there.
@Bobby_Nobble Thanks for the suggestion, but I think the new blueprint is the way to go. No additional software needed, fully integrated into the web interface, no editor needed, growing community.
It’s good to hear that ControllerX can do much more than this blueprint right now, however I’m sure this will evolve very quickly.
I am the creator of ControllerX, and I agree on the fact that the setup process for ControllerX is tedious and relies on AppDaemon, which is not an official tool. I see that Blueprints are the official way towards something that ControllerX already does, but Blueprints are no more than parematrized automations that can be shared thrhough the community. They can be used for other use cases since they have a generic purpose, which is great.
ControllerX on the other hand, it is an specific tool that allows you to create controller-based automations. It can not be used for anything not related to controllers, this means that they don’t have a generic purpose, but focus well in the simple task of integrating controllers with your HA entities and services. ControllerX has the following functionality over Blueprints amongst others:
Integration with Z2M (state and mqtt), deCONZ and ZHA.
Easy to define a custom mappings through YAML code with predefined actions.
Smooth transition for brightness, color temp, volume.
Color loop for lights that support color.
Multiple click functionality for controllers with no hardware support for it.
Be able to define a very specific use case. For Blueprints if you want something specific, you need to change the blueprint yaml, which loses the purpose of using a Blueprint in my opinion.
Blueprints seem to be a beginning towards an easy way to create controller-based automations, but far to be fairly compared with ControllerX when it comes to functionality.