Hue Dimmer Switch Connected to ST

Continuing the discussion from New Philips HUE devices:

Creating a new topic to see if the community can help draw up ideas to configure this remote directly connected to ST. It’s similar to the Lutron Connected Bulb Remote, but doesn’t have the ZLL commissioning built in and I can’t get it to pair with any bulbs.

Unreliable integration: I have been able to get it to send responses back to the hub, so it can emulate a button controller; but it frequently loses its connection to ST and requires re-pairing. Below is a link to the custom device type and info on connecting to ST, but please manage expectations until I can report that the connection is more solid.

If this is your first time using custom code with ST, please see the following thread on how to get started in the IDE. This code will be for a device handler. It is best to create the device handler in the IDE before pairing the remote to ST, otherwise you may need to reset and re-pair to make sure the configuration commands are sent.

Link to code:

Once this device handler is created and published in your IDE, you can pair the remote to ST. To pair:

  1. If this remote was a standalone dimmer switch package. With the remote very close to the ST Hub, go to the Marketplace in the ST App (rightmost icon along bottom) and press Connect New Device. Once ST starts searching press and hold the ‘On’ button on the remote until the light flashes green. The remote has paired.

  2. If the remote came paired to Hue White bulbs or step 1 doesn’t work correctly. Use a paperclip/staple to press and hold the pinhole setup button on the back for approximately 10 seconds. The light should blink green/red/green then slowly blink red/orange noting that it is ready to pair. Press Connect New Device in the Marketplace to start ST searching for a new device. The remote will blink green when it joins the network.

**ST may not recognize the new device in the usual way, but if you back out you should find a new Hue Dimmer Remote under your list of things. If the new device is listed as Unknown, then you must go into the IDE and assign it the Hue Dimmer Remote device type by selecting it under the My Devices section and clicking Edit at the bottom, then using the Device Type dropdown. If you have to assign the custom device type manually, you will need to reset and re-pair the remote by following step 2 above. Do not delete the device in ST! Just reset and re-pair.

The device handler configures the remote as a 4 button controller with On = Button 1, Pushed; Dim up (big sun) = Button 2, Pushed; Dim down (little sun) = Button 3, Pushed; Off = Button 4, Pushed. It can be used with Smart Lighting SmartApp, Button Controller SmartApp under More in Marketplace or using any custom Button Controller SmartApp that recognizes buttons 1-4 as pressed.


You mean you can’t get it to pair with any bulbs after it’s paired to smart things?

Or you can’t get it to pair with any bulbs at all?

I have one running through the Hue bridge, and it works fine that way, I just associated it with 2 bulbs using the bridge.

BTW, i’ve been assuming that the Phillips dimmer switch wouldn’t reset a bulb on a ZHA Channel like 14 that is not a ZLL channel, same as a regular touchlink device, but I honestly don’t remember why I thought that. The LUTRON remote will reset on any ZHA channel. What’s the reset behavior for the Phillips?

I have not gotten it to pair with any bulbs, but I’ve only had it paired to ST, as I don’t own a Hue Hub, which is why I I’m trying to directly connect it. As far as I can tell it doesn’t initiate the association itself, so we need to tell it what bulbs to associate with, which is what the Hue app allows you to do.

I don’t think the Phillips dimmer switch can reset bulbs at all. I’m pretty sure that the Lutron uses its ZLL commissioning cluster to initiate the “stealing” of bulbs, which essentially resets them. The Hue dimmer switch does not support ZLL commissioning cluster per the raw description info.

Note: I have no instructions of any kind as to what button(s) initiate pairing or really do anything in the setup process. There is no product manual or instructions on the Hue website. It seems like the setup guide only exists in the Hue app.

What I’ve tried: I was able to pair it with ST initially by holding the ‘On’ button and having ST search for a new device. I’ve tried holding each button near the bulb I want to pair with no luck, although holding the ‘On’ button will cause it to flash RED at me. I’ve also tried pressing the Setup button on back to cause it to blink ORANGE, which basically wakes it up, then sending binding commands and read attribute to the Basic cluster. No responses of any kind.

Without a bridge…

To connect other Hue bulbs, you hold the dimmer switch close to the light bulb, press and hold the On button for 10 seconds, then wait for the light to flash and, finally, release the button.

I’d recommend tapping a couple of buttons on the remote before you try adding the bulb, just to make sure the remote is awake.

You shouldn’t need the set up button to add more bulbs to the remote.


Thanks for the info JD! I tried this, but the remote flashed RED at me after 5-10 seconds. The bulb(s) never flashed. I wonder if this only works before the remote and/or bulb is connected to a Zigbee network.

i think what Sticks want its to control a bulb or switch directly connected to smartthings with the hue dimmer, correct me if I am wrong but if I Connect the bulb to the switch directly smartthings will not know when i turn the bulb or on off using the switch.


My understanding from conversations else where is that once you join the remote to the Hue bridge, it can no longer add bulbs to itself. They have to then be added through the bridge.

So, yes, if you already joined it to smartthings, it’s probably flipped to secondary mode.

You know how wink and Lutron are getting around this right? Instead of making the Lutron remote a secondary to wink, they’re having wink spoof itself as a dimmer switch. So wink is getting commands from the remote, instead of the other way around. Basically like the zwave association With a hub is used to get around the hail restriction for status updates.

1 Like

Yes, I think it’s really smart how they’ve programmed the work around to make these 4 button remotes. The Hue bridge/software must be doing something similar because you can assign the Hue remote to a scene instead of directly controlling bulbs. Hopefully ST can do something similar for us eventually.

The Lutron also can still pair itself to bulbs after joining a Zigbee network (per users getting it to work on the ST network) and acting as a secondary controller. Normally it will “steal” the bulb and join it to its own network, but if it’s been joined to another Zigbee network, then it will pair to the bulbs on the same network.

1 Like

BTW, The set up button on the Philips remote is only used, as far as I know, when you are changing its coordinator status. So you need that either to connect to a hue bridge, or disconnect it again. But it’s not part of the bulb join process.

Finally got this to send messages to ST. I still can’t figure out how to pair it directly to a bulb after its joined my ST network. For that I would most likely want/need the unique GroupId that it comes pre-configured with; and I keep hitting dead ends there.

I can see 1 message for each on and off. I can also see 3 messages for each of the dim buttons: one after pressing, another as you hold and a 3rd when you release a hold. So we can easily make this a 4 button remote or we can try some debounce logic and get 6 total buttons by having a press and hold for the dim keys.

Here’s my first pass of it as a 4 button remote:


So this is definitely working as a 4 button remote with the Button Controller SmartApp, but I don’t really like the granularity of control or the processing overhead of device, smartapp, device. I started working on an alternative control method that would allow you to get the full functionality of the remote and possibly faster performance by converting the parse messages directly into commands out to a selected bulb (in time, maybe multiple bulbs).

Here’s the current code. The problem seems to be that the parse() doesn’t expect the result to be a command, so it isn’t firing the zigbee commands at all. I’ve run through a ton of logging and the results are valid zigbee commands, and it does work to send zigbee commands to a different device. If I could get this code to work, it would mean that a long press on the dim up/down keys would continuously work and throw a stop command when it’s released. Any ideas?

 *  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
/* Philips Hue Wireless Dimmer

  Switch Level

metadata {
	definition (name: "Hue Dimmer Remote", namespace: "Sticks18", author: "Scott G") {
		capability "Actuator"
		capability "Button"
		capability "Configuration"
		capability "Sensor"
        capability "Switch"
		capability "Refresh"
		command "zigbeeCommand"
		fingerprint profileId: "C05E", deviceId: "0820", inClusters: "0000", outClusters: "0000,0003,0004,0006,0008", manufacturer: "Philips", model: "RWL020"

	// simulator metadata
	simulator {
		// status messages


	// UI tile definitions
	tiles {
		standardTile("button", "device.button", width: 2, height: 2) {
			state "default", label: "", icon: "st.unknown.zwave.remote-controller", backgroundColor: "#ffffff"
		main "button"
    preferences {
        	input("zigId", "string", title: "4 Character Zigbee ID of Target Bulb", defaultValue: "FEFE", required: true, displayDuringSetup: true)
            input("endP", "string", title: "Endpoint of Target Bulb", defaultValue: "01", required: true, displayDuringSetup: true)

// Parse incoming device messages to generate events
def parse(String description) {
    //	log.trace description

def zigbeeCommand(description) {
    def msg = zigbee.parse(description)
    log.debug msg
	if (msg.clusterId == 6) {
    	def c = (msg.command == 1 ? 1 : 0)
        "st cmd 0x${zigId} 0x${endP} 8 ${c} {}"
    else if (msg.clusterId == 8) {
        def c = msg.command
        def p = (c==2 ? description[-8..-1] : "")      	
           // def m = description[-8..-7]
           // def s = description[-6..-5]
           // def t = description[-4..-1]
        "st cmd 0x${zigId} 0x${endP} 8 ${c} {${p}}" 

def configure() {

	log.debug "configure"
	String zigbeeId = swapEndianHex(device.hub.zigbeeId)
	log.debug "Confuguring Reporting and Bindings."
	def configCmds = [	
        "zdo bind 0x${device.deviceNetworkId} 1 1 6 {${device.zigbeeId}} {}", "delay 1000",
		"zdo bind 0x${device.deviceNetworkId} 1 1 8 {${device.zigbeeId}} {}", "delay 500",
    return configCmds  

private getEndpointId() {
	new BigInteger(device.endpointId, 16).toString()

private hex(value, width=2) {
	def s = new BigInteger(Math.round(value).toString()).toString(16)
	while (s.size() < width) {
		s = "0" + s

private Integer convertHexToInt(hex) {

private String swapEndianHex(String hex) {

private byte[] reverseArray(byte[] array) {
    int i = 0;
    int j = array.length - 1;
    byte tmp;
    while (j > i) {
        tmp = array[j];
        array[j] = array[i];
        array[i] = tmp;
    return array

I really wanted to avoid the latency of a SmartApp, but I’m thinking maybe a Service Manager style SmartApp-Child Device system would work. Can a child device be assigned to a physical device? Also would a Service Manager type setup have better performance than a simple subscribing SmartApp?

This would allow me to send the parse messages to the SmartApp for processing, and have the SmartApp send commands back to the child. That way they would actually fire.

i am sorry if i don’t understand this, but if you can already get the switch to be recognised by smarthings as a 4 button remote can’t you link a bulb to the remote witch the current smart lighting smart app? as in: turn x bulb on when x button is press?

I can turn a bulb on or off with the current setup. Not sure about dimming, but I could add that. It’s a bit slow to respond, so I was hoping to get better performance. It’s also not as natural as using the remote’s Zigbee commands. It was designed to control these bulbs, so I’m just trying to get as close to the stock experience as possible; but through ST.

I understand you can have the remote connected to SmartThings zigbee controller, and you can toggle a zigbee bulb which is also connected to the smarthings zigbee controller on or off using your version of the button controller smart app.

Could you also toggle a zwave switch on and off with it? Or not yet?

(Sorry, I can’t read the code.)

That’s the thing with this remote. Unlike the Lutron Connected Bulb Remote that seems to be able to pair itself directly to bulbs after joining ST for dual control, this remote doesn’t have the ZLL commissioning functions to make that work. Once it’s connected to ST, you have to use ST to configure it and since I don’t know the Group ID I can’t have it control bulbs directly.

Instead with the first version of code posted above (via GitHub link) it’s connected simply as a 4 button remote. It reports to ST button 1-4 pushed. There is no “held” option (the dim buttons do report when they’re held/released, but it also sends the same message as “pushed” first, so it’d be messy).

Yes. Using the stock Button Controller SmartApp it can turn any light on/off, change modes, HH, etc… just like an Aeon Minimote, except without the extra 4 actions for “held”.

1 Like

Brilliant. Seriously, just amazingly brilliant. I am in awe.

So the main issue you’re seeing is some lag?

Because this could solve a lot of use cases. Including for all the new UK members. :sunglasses:

( BTW, for my own personal use cases, I actually prefer that it not process long holds. That’s because it’s the dog who usually works the switch and he just doesn’t understand those distinctions. And that and when I usually work it it’s the same thing, I can’t really get enough find control to differentiate consistently. Ihave my button remotes all programmed so that short press andlong press do the same thing anyway. So just any press at all having the same meaning is what works best for us. :sunglasses::dog:)

this is awesome news, my only worry about the new switch was that if I connected it directly to the hue system, smarrthings will never know when the bulbs were being turned on or off, this way the whole system keeps up to date smartthings and hue.

great work, is the delay so large that it represents a problem? if not I don’t see the need for directly controlling the bulbs.

Part of it is the lag. I was really hoping not to depend on the hub plus cloud roundtrip.

Part of it is the lost granularity in the dim function. The remote sends different level change commands as its dim buttons are held and then released; but the button controller will just be Button 2 pushed either once or over and over again.

Part of it might be that I can’t get it to do what I originally intended it to do, or to function as well as it does with the Hue Hub.

The other difference is that if the switch is connected to a Hue bridge, you can set it to control one hue scene. This way all your controls have to be within SmartThings. But I agree, that would be a small price to pay for a multiprotocol switch. :sunglasses:

1 Like