it loses its connection after a few weeks, then i have to go into find new device in smartthings and press the button on the back of the remote and it starts working again after fiddling around a bit.
Thanks, looks like I’d best just add them to the hue bridge then.
Even without connecting the remote to ST – I can’t seem to get the hue bulb (no bridge) to connect to both smartthings and the dimmer switch. Every time I connect one, the bulb disconnects from the other. Is this normal? I was hoping to be able to control the bulb both ways – via ST (or echo) or the dimmer switch.
That won’t be possible.
A zigbee device can only connect to one coordinator. If you connect the bulb to the dimmer switch, it will not be able to connect directly to the SmartThings hub, and vice versa.
The Hue bridge works differently, which is why it is a “bridge.” In that case, the bridge is the zigbee coordinator for the devices connected to it, The bridge talks to SmartThings over the local area network (not zigbee), and when SmartThings wants a bulb to do something, it tells the bridge and the bridge tells the bulb.
There’s no similar arrangement between SmartThings and just a Hue dimmer switch.
So once you connect a Hub bulb directly to SmartThings, it is no longer available to talk to the hue dimmer switch, and vice versa.
2 Likes
In testing, I have found the Hue Dimmer Switch to reliable as a Button Controller with the above code and when you turn on “Allow Unsecure Rejoin (Most Compatible)” on the hub. Please know and understand your security risks before doing so.
Has anyone else had success with this?
Andie - is it still working reliably?
I am curious about this myself. Is it still working? It’s also my understanding that the security risks are very, very low. Anyone care to chime in on this, please?
1 Like
I have about 8 of these and they are still spotty, Even with insecure rejoin enabled (i understand the risks)
I have recently discovered though that they have a second Zigbee Endpoint and it is ZHA as opposed to the ZLL one that this device handler uses. I had previously used these on the HUE bridge with very customized befores for all of the buttons. It has always struck me as odd that none of this seemed possible with the clusters advertised.
The biggest one being battery, HUE can get the battery status but there is no cluster 0x0001 for that… But there is in endpoint 2. I think that Endpoint 1 is intended for connecting directly to bulbs and 2 might be what HUE uses when you connect it the the bridge.
So far I am having a hell of a time getting ST to talk to the second endpoints reliably and the dimmer loves to go to sleep and not wake up, but I have gotten battery information out of the second endpoint so there may be hope after all.
Here is the RawDescription if anyone is interested in the second endpoint
zbjoin: {
"dni":"DAD6",
"d":"00178801103317AA",
"capabilities":"80",
"endpoints":[
{
"simple":"01 C05E 0820 02 01 0000 05 0000 0003 0004 0006 0008",
"application":"02",
"manufacturer":"Philips",
"model":"RWL020"
},
{
"simple":"02 0104 000C 00 05 0000 0001 0003 000F FC00 01 0019",
"application":"02",
"manufacturer":"Philips",
"model":"RWL020"
}
]
}
1 Like
Not sure if this has any relevance at all, but you can completely reprogram the hue dimmer switch and expose some features which are not evident in the regular bridge integration. I wonder if that has anything to do with the second endpoint.
http://www.gottabemobile.com/2016/02/15/how-to-turn-a-philips-hue-dimmer-switch-into-a-tap-switch/
This is what I was referring too when I mentioned missing functionality. To do this doesn’t really even take much ‘hacking’ in the HUE world I had it setup to handle long presses and things like that in the past. If i recall correctly the buttons have 4 states - press,being held,release and held.
So far the 0x000F cluster looks promising but there is also the 0x00FC cluster which is manufacturer specific so no docs 
I am leaning towards 0x000F though cause I think I read somewhere that it works on the Osram Gateway and on wink - I doubt they would have cracked some secret Philips implementation to make it work
These are the button states from the HUE docs
BUTTON STATE CODE
Button 1 (ON)
INITIAL_PRESSED 1000
HOLD 1001
SHORT RELEASED 1002
LONG RELEASED 1003
Button 2 (DIM UP)
INITIAL_PRESSED 2000
HOLD 2001
SHORT RELEASED 2002
LONG RELEASED 2003
Button 3 (DIM DOWN)
INITIAL_PRESSED 3000
HOLD 3001
SHORT RELEASED 3002
LONG RELEASED 3003
Button 4 (OFF)
INITIAL_PRESSED 4000
HOLD 4001
SHORT RELEASED 4002
LONG RELEASED 4003
1 Like
I found dem button presses, Still need to work out the data format but they come from monitor the manufacturer specific cluster.
Button Down
’catchall: 0104 FC00 02 02 0100 00 18E7 01 04 100B 00 01 0300003002210100’
Button Up
catchall: 0104 FC00 02 02 0100 00 18E7 01 04 100B 00 01 0200003000210000’
Edit: I got too excited that this was working and now my wife thinks I am strange 
For those of you who have these working whats other devices do you have, Mainly wondering if you have any CREE Connected or Osram bulbs. Same question for those you are having problems.
Currently I am testing with my CREE bulbs removed from smartthings, Actually they are being proxied through the HUE hub so they are not part of the same mesh. I dont have any bulbs to replace them with so they need to stay online.
Some people might say I have a vested interest in getting these things working properly, my wife says I spend to much money of gadgets. (i have 2 more that are awol at the moment)
1 Like
I really love this hue switch. thanks to provide the connection to ST
I put sticker on it and use it with lightify plug!
So is this working reliably for you? or also seeing the disconnects?
No unfortunately I still see disconnects. I have moved all of my CREE bulbs off of the SmartThings hub and onto the hue hub, Leaving the dimmers on the SmartThings hub and it has improved significantly but still not perfect. I am tinkering in my ZHA device handler tonight but apart from cleaning it up I haven’t made much headway.
The dimmer is whats called an ‘end device’ because it sleeps to conserve battery, Generally these devices latch onto a parent device and have it relay all of there messages and buffer inbound messages - At least this is what I understand from reading the documentation. The end device is supposed to negotiate how often it wakes up with the coordinator (SmartThings Hub) upon joining the network, I think this negotiation might not be happening correctly or one of the devices is ignoring the result causing the network to too far out of sync for the end device to catch up.
I really wish I had the tools to sniff zigbee traffic and see what was going on but I do not… Yet maybe 
Because my Sunday night was clearly not exciting enough, I decided to crack open a dimmer only to find… Test points! including a serial port. Much rummaging and some jiggery pokery later said serial port outputs logs from the dimmer.
Originally I was hoping to snoop on the traffic between the cpu and zigbee chip, but they are the same chip.
Output of it booting while paired to ST
[Log,Info,Switch,MCUCR=0x00,LockBits=0xFC,LowFuse=0xF6,HighFuse=0x9A,ExtFuse=0xFE]
[Log,Info,Switch,devsig=0x1EA803]
[Log,Info,S_DeviceInfo,Booting into normal mode...]
[Log,Info,S_DeviceInfo,DeviceId: HueDimmerSwitch-US]
[Log,Info,N_Security,LIB4.5.101]
[Log,Info,N_Security,KeyBitMask,0x0012]
[Log,Info,SC_BatteryMeter,Vbat=2563, adcValue=549, calMask=3]
[Log,Info,AC_OTAUpgrade,signature=FFFFFFFF, status=FF]
[Log,Info,Switch,errs=0,lastErr=NULL@0]
[Log,Info,Switch,Platform 0.65.1: r15377, BC_V3.2.0_0.5_M: r15377]
[Log,Info,Switch,Product version Switch 5.45.1.15767,built by LouvreZLL]
[Log,Info,Switch,N_Watchdog_GetResetReason 3]
[Log,Info,AC_Commissioning,NwkAddr: 0x2145, Ch: 19, Pan: 0x2A33, NwkUpdId: 2, ExtPanID: E8C3F529C7899A14]
[TH,Ready,0]
Hue Connected boot
ÿÿÿÿÿÿÿ
[Log,Info,Switch,MCUCR=0x00,LockBits=0xFC,LowFuse=0xF6,HighFuse=0x9A,ExtFuse=0xFE]
[Log,Info,Switch,devsig=0x1EA803]
[Log,Info,S_DeviceInfo,Booting into normal mode...]
[Log,Info,S_DeviceInfo,DeviceId: HueDimmerSwitch-US]
[Log,Info,N_Security,LIB4.5.101]
[Log,Info,N_Security,KeyBitMask,0x0012]
[Log,Info,SC_BatteryMeter,Vbat=2777, adcValue=594, calMask=3]
[Log,Info,AC_OTAUpgrade,signature=FFFFFFFF, status=FF]
[Log,Info,Switch,errs=0,lastErr=NULL@0]
[Log,Info,Switch,Platform 0.65.1: r15377, BC_V3.2.0_0.5_M: r15377]
[Log,Info,Switch,Product version Switch 5.45.1.15767,built by LouvreZLL]
[Log,Info,Switch,N_Watchdog_GetResetReason 3]
[Log,Info,AC_Commissioning,NwkAddr: 0x2B4B, Ch: 20, Pan: 0xA40D, NwkUpdId: 3, ExtPanID: 89D9B1AA5E2B1A73]
[TH,Ready,0]
Those are almost identical, But here is an odd log. This is connected to ST you can see that it drops some messages from the hub that are too old when it wakes up but after mashing buttons I finally got it to redlight and drop off the network. Note the line marked with *** it thinks it received a commisioning request to connect to a network with an ID of
0000000000000000. I suspect it did exactly that and now its off in la la land.
[Log,Info,Switch,MCUCR=0x00,LockBits=0xFC,LowFuse=0xF6,HighFuse=0x9A,ExtFuse=0xFE]
[Log,Info,Switch,devsig=0x1EA803]
[Log,Info,S_DeviceInfo,Booting into normal mode...]
[Log,Info,S_DeviceInfo,DeviceId: HueDimmerSwitch-US]
[Log,Info,N_Security,LIB4.5.101]
[Log,Info,N_Security,KeyBitMask,0x0012]
[Log,Info,SC_BatteryMeter,Vbat=3284, adcValue=701, calMask=3]
[Log,Info,AC_OTAUpgrade,signature=FFFFFFFF, status=FF]
[Log,Info,Switch,errs=0,lastErr=PWRON@0]
[Log,Info,Switch,Platform 0.65.1: r15377, BC_V3.2.0_0.5_M: r15377]
[Log,Info,Switch,Product version Switch 5.45.1.15767,built by LouvreZLL]
[Log,Info,Switch,N_Watchdog_GetResetReason 0]
[Log,Info,AC_Commissioning,NwkAddr: 0xE81F, Ch: 19, Pan: 0x0F41, NwkUpdId: 3, ExtPanID: E8C3F529C7899A14]
[TH,Ready,0]
[Log,Info,Switch,Dropping stale message from 0x0000]
[Log,Info,Switch,Dropping stale message from 0x0000]
[Log,Info,S_Nv,CompactSector(s=0)]
[Log,Info,S_Nv,CompactSector(s=1)]
[Log,Info,S_Nv,CompactSector(s=0)]
*** [Log,Info,AC_Commissioning,NwkAddr: 0xE81F, Ch: 19, Pan: 0x0F41, NwkUpdId: 3, ExtPanID: 0000000000000000]Hi Stephen, I’ve managed to keep a dimmer connected for a couple of days now using your DTH so thank you very much for the work on this.
I was wondering if you have used the DTH with @ady624’s CoRE - I can see the button in CoRE but only as a single press or hold button not as 4 buttons, I use CoRE for pretty much all my automatons and would be nice to use it if possible.
It works under smart lighting fine.
Cheers
Matt
Hi Stephen - Just saw
// TODO: handle ‘numberOfButtons’ attribute in the code so will await an updated version at some point.
Thanks
Matt
1 Like
After the latest hub update my dimmer is now stable for three days. before it only worked for an hour. So i guess the changed something. Also does anyone know it ST supports held and doubblepressed for this Dimmer?
Did I miss something? I can only get the switch to show up as a single button when adding it to Smart Lighting (when it is paired with the ST hub). How do I specify buttons 1-4?
Thanks to @Sticks18 for the device handler.