Dr. Hue is in and the Bulbs are back (Reset Hue bulbs to factory)


(John Rucker) #1

I’m so happy I get to post something positive about my direct connected Hue Bulbs I’m about to bust. I just got my RaspBee Gateway from Germany http://www.dresden-elektronik.de and I was able to reset my bulbs back to factory and rejoin them to SmartThings direct (no Hue Hub).

If anyone needs help resetting their direct connected Hue bulbs to factory new let me know I will be happy to help. I have been through the ringer on this one. I have over 10 Hue Bulbs that SmartThings lost communications with over Christmas and no matter what I did I couldn’t get them back. Tech support had my try everything including standing on my head with a bulb in my mouth (well maybe not that) and they couldn’t get them back. Thanks to @manu and his team in Germany I was able to reset them.

Hue Reset to factory << key words to help people find this


Hue Bulb Factory Reset: SOLVED if your Hue Bulb is on a ZLL Channel
Reset hue bulb to factory once it has joined the SmartThings hub
Zigbee HA vs. Zigbee LL
FAQ: Exact remote needed to reset Hue bulbs? (UK)
Reset hue bulb to factory once it has joined the SmartThings hub
Please Offer Help and Guidance - Newbie (UK)
#2

Got a guide anywhere? I’d be interested in duplicating that setup over here.


(John Rucker) #3

Okay here is a little background on what happened and how I fixed it.

The Philips Hue bulb can join to two types of ZigBee networks; a Light Link network, or a Home Automation network. When a bulb joins to the a Philips Hue hub it is joining a ZigBee Light Link network. When it joins directly to your SmartThings hub it is joining a ZigBee Home Automation network. Once a bulb has joined a network it has to be told to leave the network to be moved to another hub. So as long as you can communicate with the bulb it is possible to reset it or move it from one network to another. There are several ways to do this one is to use a program called lamp stealer and the other is to use a Light Link Remote.

However, if your bulb has been orphaned and it is not communicating with anything your only option is to use the Light Link Remote to reset it. Philips makes such a remote and to reset the bulb you have to physically touch it to the bulb and hold a couple of buttons down to start the reset process. Well this is what happened to me and I have one of these remotes and it still didn’t work. It turns out that the Philips Light Link remote only operates on the ZigBee Light Link channels 11, 15, 20, and 25. Well my SmartThings hub is operating on channel 14 (a non light link channel) so I was stuck.

Now we come to dresden-elektronik they make several Light Link devices and one of them is the RaspBee Gateway that happens to reset Light Link devices on all the ZigBee channels. That is what I used to reset my bulbs so they can talk to the SmartThings hub again!

I do appreciate the assistance you guys have give me and If I can help anyone else I would even be willing to let them ship me an orphaned bulb so I can reset it for them.


(Dekker) #4

Hello john
Good for you, i was already aware tht it should be possible to reset an orphan hue bulb via. The raspbee, can you share how? That would help me lot i am in same situation as you… Bulbs having a non light link channel…pieter thnks!!


(Mike Gershowitz) #5

Hello John,

I am having the same problem trying to reset the Philips Hue lamps so they can be moved from the Philips gateway to the deCONZ on the Raspberry-pi. Can you please provide the specific details on what you did to use deCONZ to reset the Philips lamps? Everything that I try cannot discover these lamps so that they may be reset.

Thanks!

Mike


(John Rucker) #6

I used the software already on this gateway from Dresden in Germany https://www.dresden-elektronik.de/funktechnik/solutions/wireless-light-control/raspbee-gateway/?L=1. I bought their whole solution RaspBee and their SDHC card together. When it arrived I plugged it into my network booted it up and then went to its IP address with my browser. Once logged in they have menu options that allow me to reset Light Link devices. Worked like a charm. Has worked every time I have tried it.

I’m not sure if you can do it with their deCONZ software. You may want to send them an eMail or ping @manu he checks this forum from time to time he may be able to help.

Let me know what you get working.


#7

Hello,

@MikeGersh if you already have a Raspberry Pi and a RaspBee shield you need to install the deCONZ package as described in chapter 5. in the user manual (the documents box on the right side).

Afterwards please start the deCONZ application on commandline (in a GUI session terminal):

$ deCONZ-autostart.sh

Now you can open the WebApp in your Browser with default login/password = delight/delight

    http://

The WebApp will likely ask you to update the RaspBee shield. This is needed in order to use the reset bulb feature called Touchlink. After the update the reset feature is available under WebApp > Settings > Touchlink .


(Mike Gershowitz) #8

Hello,
@manu, thank you for your prompt reply. After following your instructions I was able to see and run the Touchlink option in the WebApp, but it is never finding any device (even new lamps never assigned to any network, or lamps assigned to deCONZ formed networks). The lamps were held right next to the RaspBEE board. I believe that the problem is that I cannot re-flash the RaspBEE shield.

To explain what I have and what I’ve done: I do have a Raspberry Pi and RaspBee shield (two of each actually), and I had deCONZ version 1.14.03 already installed. In the past when I ran the web app, I saw the update message, but was never able to get it to update properly (just kept giving …), Your instruction to do $deCONZ-autostart.sh worked correctly to get a number of file updates, but it appears to have failed when trying to re-flash the raspBEE shield. The message that came up was
"2015-06-18 12:12:09 (268 KB/s) - `/home/pi/otau/14010400_0x0005.zigbee’ saved [157271/157271]

14010400_0x0005.zigbee: OK
deCONZ - exit code 46
GCFFlasher V1.02 © dresden elektronik ingenieurtechnik gmbh 2013/07/11
using firmware file: /home/pi/raspbee_firmware/deCONZ_Rpi_0x1a0a0500.bin.GCF
reset target

error: RaspBee shield not responding
/dev/ttyAMA0 used by other application?
delete /var/tmp/deCONZ-update-firmware.sh"

I tried to perform the flash “manually” by exiting deCONZ and entering the command line to GCFFlasher. I did this both without restarting the pi, and with restarting the pi (power cycle) - in all cases always the same message about ttyAMA0 used by other application. I am able to run deCONZ without problem or conflict, and I can run the “GCFFlasher -r” and get “SUCCESS” for a reset. I had already edited the /boot/cmdline.txt and /etc/inittab files as instructed for the deCONZ install.

The results when I tried to manually flash the RaspBEE were (note that I first did a reset to confirm that the GCFFlasher was communicating with the RaspBEE properly:
"pi@raspberrypi ~ $ sudo GCFFlasher -r
GCFFlasher V1.02 © dresden elektronik ingenieurtechnik gmbh 2013/07/11
reset target SUCCESS
pi@raspberrypi ~ $ sudo GCFFlasher -f /home/pi/raspbee_firmware/deCONZ_Rpi_0x1a0a0500.bin.GCF
GCFFlasher V1.02 © dresden elektronik ingenieurtechnik gmbh 2013/07/11
using firmware file: /home/pi/raspbee_firmware/deCONZ_Rpi_0x1a0a0500.bin.GCF
reset target

error: RaspBee shield not responding
/dev/ttyAMA0 used by other application?
pi@raspberrypi ~ $"

Is there any way to determine what binary image is flashed on the RaspBEE shield? There doesn’t seem to be a command on GCFFlasher to read the flash image or any info about it. Is there some way to determine the version from one of the apps? Is there something else I need to do to be able to flash the RaspBEE shield?

What next step would you suggest?

Thank you in advance for your help. Mike


#9

From the error message I would guess that the serial UART is not reachable by the RaspBee shield maybe a configuration issue. Note that it is very important to complete the whole configuration from the user guide to setup the /dev/ttyAMA0 interface since the default settings of Raspbian distribution won’t let the deCONZ application communicate with the shield.


(Mike Gershowitz) #10

I agree about your assessment of the error message. However, I have been very careful to follow the setup instructions precisely (both the cmdline.txt and inittab files have had references to ttyAMA0 removed). I also confirmed that ttyAMA0 is not being used by any other process (by using the ps aux|grep tty command). I can see tty1~7 being used by root, but nothing running with ttyAMA0.

The odd thing is that deCONZ runs perfectly. If there was a problem reaching the serial port, or if the serial port was actually being used by another process, I would expect deCONZ to fail to launch.

Also, keep in mind that I have two different systems, and both of them behave exactly the same on this point (although I could just be repeating the same operator error on both systems :smile:

Is there someone at Dresden-Elektronik that you can suggest I contact for further guidance?

Thanks again for your assistance.


#11

Phew, took a while to figure it out. I’ve tested a clean install on a Raspberry Pi 2 with NOOBS/Raspbian. Albeit deCONZ could connect to the shield, GCFFlasher couldn’t update the RaspBee firmware with the very same error message as above. I’m not quite sure if the problem is Raspberry Pi model 2 or changes in the Raspbian distribution.

Anyway a recompilation of GCFFlasher with updated libraries fixed the problem. I’ve uploaded the new version you can update GCFFlasher with following commands (will be in the next offical update).

$ wget http://www.dresden-elektronik.de/rpi/gcfflasher/gcfflasher-1.03.deb
$ sudo dpkg -i gcfflasher-1.03.deb

Afterwards the update from the WebApp should run without errors and RaspBee shield should be updated.
Always feel free to ask me here, also the normal dresden elektronik support via email is keen to help :slight_smile:


#12

You should be able to unpair/reset bulbs by following their method of powering on and off repeatedly, I have successfully done it a few times. Power on for 5 seconds, then power off for 5 seconds, repeat and after around the 5th time it turns on, it will blink, indicating it has reset. You will likely have to re-pair the bulb (although i think I didn’t need to on one occasion) to the hub, and reassigning any SmartApps.

correction: this was for the GE link bulbs


Hue bulb without Hue Bridge?
(John Rucker) #14

@dEEE can you please past a link on this on/off procedure you refer too. I have not heard of this process for Hue bulbs and would like read up on it. Thanks.


#15

Good catch!

According to this March 2015 article, while Cree, Osram, GE, and WeMo bulbs can be reset by blinking, Hues cannot.


#16

total derp, i forgot i got rid of my hue bulbs and went to GE, i corrected above


(Mike Gershowitz) #17

@Manu - Thanks for looking into this and correcting the gcfflasher. Version 1.03 works fine on my system - the connection error is gone, and I can now flash the RaspBEE modules.

However, even after re-flashing the RaspBEE with the 0x1a0a0500.bin file it appears that the 'Touchlink" via the GUI interface (WebApp>Settings>Touchlink) is still unable to find any lamps. I have tried this with three Philips lamps (already joined to Philips Hub, already joined to deCONZ hub and brand new) as well as two OSRAM lamps (ZHA) one that was already joined to deCONZ and another that was reset. In all reports that “No Lights were found…” The lamps were almost touching the RaspBEE (much less than 50cm), so something is still not working.

I used my protocol sniffer (TI Smart RF Packet sniffer), and I can see that the RaspBEE is transmitting three packets in response to the Touchlink Scan command (if no lamp is present) and many more packets if a lamp is present. From the packet addressing, I can see that the RaspBEE is communicating with the lamp (both IEEE and NWK addresses match correctly) - but despite the fact that they are “in range” the scan still shows “No Lights were found…” message.

Do you have any other suggestions why the TouchLink is not working? Would you like me to email you the sniffer log files?

Thank you for all of your assistance!
Mike


(John Rucker) #18

Mike, just to make sure you do have the Hue bulb physically close to the RaspBEE touching or just an inch or so away? The touch-link reset is based on signal strength the bulbs have to touch the remote. In my case i have them just a few inches away and they work.


#19

That’s really strange! Yes if the sniffer logs would be very helpful (I’ve send you my email address via PM). Could you also please provide a sniffer log for the channel where the Philips hue bridge is located? You can see the actual channel in the app.

Philips hue app > Settings > My Bridge > ZigBee Channel

Can you further please verify the firmware version of Raspbee shield in deCONZ (should be 0x1A0A0500).

Help > About deCONZ

Here is a screenshot after Touchlink scanning in my setup (Philips hue bridge paired with one FLS-PP lp and one Living Colors Bloom) the lights distance to the RaspBee is ~ 15cm .


(Mike Gershowitz) #20

@JohnR: Yes, I place the lamps right up against the RaspBEE chip antenna. No Joy. Thanks for the suggestion

@manu: I’ve sent you the sniffer logs via PM. The Hue hub is on channel 11 (which I didn’t sniff). The deCONZ system is on channel 15.

The RaspBEE firmware version is confirmed as 0x1A0A0500 as reported by "about deCONZ"
I was running deCONZ version 1.14.03 when I did the sniffing, but reverted back to 1.14.00 (to match your setup) and still have the same problem/behavior.

I have been working with 4 versions of Philips Hue lamps (FW version also indicated):
A19 Hue Model: LCT001 FW:5.23.1.13187 (reported via deCONZ)
A19 Lux Model: LWB004 FW:66012040 (reported via Hue API)
PAR16 Hue Model: LCT003 FW:5.23.1.13105 (reported via deCONZ)
BR30 Hue Model: LCT002 FW:66010673 (reported via Hue API)
I’ve also been working with OSRAM TW60 lamps (A19, Tunable white, ZHA) and GE-Link Lamps (A19, Dimmable, ZHA). All lamps give the same result with deCONZ:

  1. Not found by touchlink
  2. Able to join deCONZ network if in the “reset” condition
  3. Not able to join deCONZ network if already joined to another network.

For the Philips lamps I’ve been trying to ensure that they are all of the latest firmware version, but that is hard to be certain of because Philips keeps updating. For the Philips lamps above I have indicated the firmware version.

Let me know if you have any ideas.

Thanks!

Mike


#21

@JohnR The Touchlink feature is really a little beast :slight_smile: The ZigBee Light Link specification says devices should only respond within 2m, big unknown is the different radios and power amplifiers which are used in different products. But normally the Hues should respond if they are within 50cm range of the RaspBee.

@MikeGersh Thank you very much for the sniffer logs! I’ve checked them in the TI sniffer and so far the shield does the right thing and sends out the Touchlink commands (the ones with destination PANID 0xffff).

Here is a little bit more detail on what is going on: the RaspBee tunes in on every channel 11 - 26 and sends multiple so called Touchlink Scan Request commands and waits a while for responses from ZLL lights (I don’t think the ZHA lights have this feature). Normally nearby ZLL devices will respond with a Touchlink Scan Response command the deCONZ collects all devices with information on which channel they are.

Since your Philips hue bridge is on channel 11 these responses, if there are any, are not visible in the sniffer log of channel 15. (except with some quite expensive multi-channels sniffers it’s only possible to sniff on one channel).

Therefore it would be helpful if you could provide a sniffer log from channel 11 while Touchlink scanning. So we can see if the ZLL bulbs do respond correctly.

I only have the A19 Hue LCT001 and A19 Lux for testing (Europe, 240V, still on shipping firmware). Tomorrow I will check if these respond correctly.

Thanks for all the input!

Manu