FAQ: Exact remote needed to reset Hue bulbs? (UK)

Hi all,

I’ve decided to get rid of the Hue bridge and pair my Hue lights directly with the SmartThings Hub. Some of the lights I bought after that choice and I’ve been able to pair them with very little effort.

The bulbs that I paired with the Hue Hub, on the otherhand, have become expensive dust collectors. I’d really like to be able to factory reset them and pair them with ST. Especially because a couple of them are the really expensive multi-colour bulbs.

I’m in UK and both the ST hub and Hue hub were on Zigbee Channel 11, so there should be not channel problem that other people in the forums are mentioning.

I tried factory reseting the bulbs using TouchLink, but that doesn’t work. It only seems to transfer Hue bulbs from one ZLL network to another, NOT to factory reset it completely.

Other posts mention a Philips remote that can do this. I’ve Googled around and I’m confused about the exact model of the remote that could do this. The last thing I want to do is spend some money to recover the bulbs and buy the wrong thing.

So… could anyone please point me towards the exact model(s) of remotes that I would be able to use to factory reset the bulbs, so as to transfer them from a ZLL network to a ZHA network please?

Thanks for you help,
Peter

No Philips remote that I know of. However the new Lutron “connected bulb remote” can.

I don’t know if it’s being sold in the UK yet.

Before the Lutron device came out, people were using a German device with a raspberry pi. See the following.

See the following:

You can use the Lutron Connected Bulb Remote. It is $35. I use it to control and also reset my hue bulbs.
http://www.lutron.com/en-US/Products/Pages/Components/ConnectedBulbRemoteControl/Overview.aspx

lutron connected remote is 29 bucks at home depot… search for lutron remote

That Lutron Connected Remote looks great.

But I couldn’t find it anywhere in the UK :frowning:

Good news, I bought this on eBay:

If I hold down the “on” (1) and “scene 1” (one dot), it successfully reset my Hue Bulb. I was then able to pair it with my ST hub. Yeh these remotes are dirt cheap in the UK!

3 Likes

Hi @peter.major!

I have received one such remote and succesfully managed to reset two hue bulbs (old color model) and add them to ST hub.

However it does not seem to work for newer hue lux bulbs. Although the remote seems to be working fine and the reset procedure is same as before, ST hub cannot find these bulbs.

I am now stuck with two bulbs that are not visible either from hue or ST hub.

What type of bulbs have you successfully reset and added to ST? Do you remember?

All help is appreciated (wife is gonna ask for a divorce soon if i cannot fix the lights…)!

Hi @ktsi Is this one of the new Philips Hue White bulbs, and if so, does it appear in Smartthings as a ‘Thing’? I have one of these bulbs and it will not connect properly. It just displays as a ‘Thing’ and when I change the device type to any of the Zigbee bulb profiles, it lists all the attributes but it is not possible to control the bulb.

I wonder if something has changed with these new bulbs and a new device handler might be required.

Hey Kevin,

These two bulbs are Hue lux. Yes they do appear as things and act the way you described.

I also have a Hue white still connected to Hue hub.

My conclusion is:

The old hue bulbs are okay with ST. Hue lux and White are not
Can someone help? Would logs help?

Thanks

Can you go to the Device screen for one of the bulbs in the IDE and paste here what is in the line Raw Description?

There was a similar issue with Osram simple white bulbs where the stock zigbee bulb devicetypes wouldn’t work. We might be able to hard code the endpoint number to get it working like we did for the Osram.

Hi @Sticks18, not sure if that request was directed at me or @ktsi, but unfortunately the Raw Description field is not present in the IDE for the bulb, I guess this is due to the fact It never finishes the identification process in the app.

Is there any other way to acquire it?

It’s also sometimes in the join event, so if you could reset and re-pair the bulb while running live logging, you might see it there.

In general if you set the bulb to the zigbee dimmer device type, start live logging and try to dim/turn on/off; do you get an error in the logs?

Nothing shows up in the logs when I set the device type to Zigbee dimmer, and I don’t have a remote handy to reset the bulb so I cant properly reset it. I’ve tried removing the bulb and then repairing, but again nothing written to the logs.

Possibly @ktsi may have more luck as he has a remote to reset the bulbs, but after reading his earlier post I’m not 100% convinced it will work. I was contemplating buying a remote for myself but it wasn’t much more expensive to buy another Osram Lightify bulb which do work so chose that option instead.

Hopefully we’ll be able to get the bulbs working as I think the New Hue bulbs are brighter and have a better colour temperature range.

The Hue White bulbs can’t vary their color temperature that I’m aware of. Only the Hue color can do both RBG and White color temp. Maybe something is out in the UK though…

If Hue always uses the same endpoint, then this might work:

/**
 *  Copyright 2015 SmartThings
 *
 *  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:
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 *  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.
 *
 */
metadata {
	definition (name: "Zigbee Hue White - HC", namespace: "smartthings", author: "SmartThings") {
		capability "Switch Level"
		capability "Actuator"
		capability "Switch"
		capability "Configuration"
		capability "Sensor"
		capability "Refresh"

		fingerprint profileId: "C05E", inClusters: "0000,0003,0004,0005,0006,0008", outClusters: "0019"
	}

	// simulator metadata
	simulator {
		// status messages
		status "on": "on/off: 1"
		status "off": "on/off: 0"

		// reply messages
		reply "zcl on-off on": "on/off: 1"
		reply "zcl on-off off": "on/off: 0"
	}

	// UI tile definitions
	tiles {
		standardTile("switch", "device.switch", width: 2, height: 2, canChangeIcon: true) {
			state "on", label:'${name}', action:"switch.off", icon:"st.switches.switch.on", backgroundColor:"#79b821", nextState:"turningOff"
			state "off", label:'${name}', action:"switch.on", icon:"st.switches.switch.off", backgroundColor:"#ffffff", nextState:"turningOn"
			state "turningOn", label:'${name}', action:"switch.off", icon:"st.switches.switch.on", backgroundColor:"#79b821", nextState:"turningOff"
			state "turningOff", label:'${name}', action:"switch.on", icon:"st.switches.switch.off", backgroundColor:"#ffffff", nextState:"turningOn"
		}
		standardTile("refresh", "device.switch", inactiveLabel: false, decoration: "flat") {
			state "default", label:"", action:"refresh.refresh", icon:"st.secondary.refresh"
		}
		controlTile("levelSliderControl", "device.level", "slider", height: 1, width: 3, inactiveLabel: false) {
			state "level", action:"switch level.setLevel"
		}
valueTile("level", "device.level", inactiveLabel: false, decoration: "flat") {
			state "level", label:'${currentValue} %', unit:"%", backgroundColor:"#ffffff"
		}
		main "switch"
		details(["switch", "refresh", "level", "levelSliderControl"])
	}
}

// Parse incoming device messages to generate events
def parse(String description) {
	log.info description
	def msg = zigbee.parse(description)
	if (description?.startsWith("catchall:")) {
		log.trace msg
		if(description?.endsWith("0100") ||description?.endsWith("1001")) {
			def result = createEvent(name: "switch", value: "on")
			log.debug "Parse returned ${result?.descriptionText}"
			return result
		}
		if(description?.endsWith("0000") || description?.endsWith("1000")) {
			def result = createEvent(name: "switch", value: "off")
	log.debug "Parse returned ${result?.descriptionText}"
	return result
		}
	}
	else {
		def name = description?.startsWith("on/off: ") ? "switch" : null
		def value = name == "switch" ? (description?.endsWith(" 1") ? "on" : "off") : null
		def result = createEvent(name: name, value: value)
		log.debug "Parse returned ${result?.descriptionText}"
		return result
	}

   if (description?.startsWith("read attr")) {
		Map descMap = (description - "read attr - ").split(",").inject([:]) { map, param ->
			def nameAndValue = param.split(":")
			map += [(nameAndValue[0].trim()):nameAndValue[1].trim()]
			}
		
		log.debug "Desc Map: $descMap"
 
		switch (descMap.cluster) {

			case "0008":

				log.debug description[-2..-1]
				def i = Math.round(convertHexToInt(descMap.value) / 256 * 100 )
				sendEvent( name: "level", value: i )
		sendEvent( name: "switch.setLevel", value: i) //added to help subscribers
		break
		}
  	}
}


// Commands to device
def on() {
	log.debug "on()"
	sendEvent(name: "switch", value: "on")
	"st cmd 0x${device.deviceNetworkId} 0x0B 6 1 {}"
}

def off() {
	log.debug "off()"
	sendEvent(name: "switch", value: "off")
	"st cmd 0x${device.deviceNetworkId} 0x0B 6 0 {}"
}

def setLevel(value) {
	log.trace "setLevel($value)"
	def cmds = []

	if (value == 0) {
		sendEvent(name: "switch", value: "off")
		cmds << "st cmd 0x${device.deviceNetworkId} 0x0B 6 0 {}"
	}
	else if (device.latestValue("switch") == "off") {
		sendEvent(name: "switch", value: "on")
		cmds << "st cmd 0x${device.deviceNetworkId} 0x0B 6 1 {}"
	}

	sendEvent(name: "level", value: value)
	def level = hexString(Math.round(value * 255/100))
	cmds << "st cmd 0x${device.deviceNetworkId} 0x0B 8 4 {${level} 1500}"

	//log.debug cmds
	cmds
}

def refresh() {
	[
		"st wattr 0x${device.deviceNetworkId} 0x0B 6 0", "delay 200",
		"st wattr 0x${device.deviceNetworkId} 0x0B 8 0"
	]
}

def configure() {

	log.debug "binding to switch and level control cluster"
	[
		"zdo bind 0x${device.deviceNetworkId} 0x0B 1 6 {${device.zigbeeId}} {}", "delay 1000",
		"zdo bind 0x${device.deviceNetworkId} 0x0B 1 8 {${device.zigbeeId}} {}", "delay 500",

		//Switch Reporting
		"zcl global send-me-a-report 6 0 0x10 0 3600 {01}", "delay 500",
		"send 0x${device.deviceNetworkId} 0x0B 1", "delay 500",

		//Level Control Reporting
		"zcl global send-me-a-report 8 0 0x20 5 3600 {0010}", "delay 200",
		"send 0x${device.deviceNetworkId} 0x0B 1"
	]

}



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

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

Thanks for this, I’ll give it a try when I get home. Regarding the Hue colour temp, not entirely sure if they do have it, just noticed it when trying one of the Hue Zigbee white device types and assumed they would have it. Either way though, the out of the box colour temp is better than anything I can get from my Osram bulbs.

Just tried the new device handler and it works!!!
I cannot thank you enough my friend!

BTW, i have gathered logs from the time i tried connecting the bulb to the hub. This was before i saw your latest post. If you think you need them, please let me know.

Again THANK YOU so much!

2 Likes

You’ve only gone and done it… Working perfectly, thanks so much.:grinning:

2 Likes

Hey guys,

Sorry I’m not using any of the new Hue White bulbs so I can’t try reseting them with the remote. I bought a couple only to realize that they were screw when I need bayonet…

I’d be very surprised if the generic ZigBee Dimmer device handler does not work for the new Hue Whites though.

I’ve noticed that ST have deprecated device handlers for various ZigBee HA bulbs (like the WeMo bulbs) and moved the footprints for those handlers into the ZigBee Dimmer type. I’ve converted all my Hue Lux and WeMo bulbs to this type and they work fine.

Glad to hear its working though…

1 Like

I agree that they should work with the generic Zigbee dimmer. Based on the raw description being missing, I suspect the initial join didn’t complete fully causing the devicetype code that pulls the endpointId dynamically to fail. It simply can’t find the endpointId properly, which is why the hardcoded endpoint works.

I’ve seen it happen in several threads with unsupported Osram lights and a report of the Kudle hue clone. Unfortunately, ST support understandably won’t be much help because the devices are not officially supported. Usually the users have reported trying to reset and pair again with no success, so I’m happy to try and get someone that works even if it’s not ideal.

@ktsi and @kjj1978, if you’re able and inclined to try, I would suggest you reset your bulbs and pair them again very close to your hub to see if you get a better join. Then see if the Raw Description gets populated and the generic device handler works. You can always fall back to this code again,

Hi there!

I have one Hue white bulb that is currently connected to Hue hub.
I will attempt later on today to reset it as well and connect it to ST hub.

Note however that when I was trying to connect (already have logs - need to get back home first) the two Hue bulbs I was doing that with the hub almost touching the bulb, so distance was no issue.

Do you want these logs?

BTW, i have this screenshot of the “thing” device handler.

I have ordered some more bulbs which should arrive reset so will try your suggestion, either way I’m happy now I can connect them and they seem to function ok.

I’m interested to hear if @ktsi has any success resetting his bulbs, if he does I will purchase the remote. I have no intention of getting the hue bridge, but at some point I can guarantee I will need to replace / upgrade my hub and will need some way of migrating the bulbs over to the new one.