Hue bridge - 14 bulbs - frequent loss of connectivity to bulbs {"reachable":"false"}

After so many wasted hours with the Wink Hub, I really thought the Hue bridge would be create a more reliable, stable environment.  Now that I have been using the Hue bridge for months, I've come to learn my initial hopes were not met.

My primary issue consisted of unpredictable loss of 'reachability' to different bulbs.  This can be seen the Philips Hue app as lights with a (!) symbol next to them.

After much googling I found some things to try to resolve this issue.

Easy - Turn light off and back on

1) Turn the light off and back on.  Wait a minute.  Sometimes the light would rejoin communications.
2) Repeat the above until it worked... when step (1) didn't.

*Save this one if nothing else works - Bulb Reset - Discovery
Time consuming...potential headache... may not even work...
1) Try a different Zigbee channel.  Turn all lights on (make sure the power is on).  Use the Hue app to change the Zigbee channel.  Go around and test the lights.  Under Settings>Lights>tap each one with a (!) make next to it and see if the light flashes on and off.  If so, click ok, and it should be back in contact.  If not, then having to trigger a reset on the bulb (differs by bulb but usually something like turn on, wait a few seconds, turn off, wait at least 3 seconds, repeat 5 times).  The light will give a sign that it reset (GE Link bulbs fade and then go bright, Hue flash (if I remember)).  Then running the auto detection routine in the app (light will flash when detected), name, and should be back on.

Alternate version - perform a reset on the Hue bridge (reset button is on bottom)

Next reset the bulbs using whatever method is used for your type of buld
Use the app to discover the bulb.
Re-add it.

I don't recommend either of the above two approaches unless as a last resort.  Especially if you have a large number of bulbs.  This will take a long time to get fully back up and running, if it succeeds.

When the problem manifests somewhat randomly, and at times works, or at least only affects a small number of bulbs, troubleshooting is a great first step.

• Did the problem start after a software/firmware update to the Hue bridge?
• Did the problem begin after some kind of change?
• Have diagnostics been run on the home network to ensure it is working problem?
• Anything documented online that matches your situation and has a good solution?
• If using a mix of brands of bulbs, are the problems limited to a certain brand?

To make this short... I did all of the above, I spent much time trying to find a pattern, a change to my environment, or anything potentially defective.

Essentially, I believe I may have found the problem.  Although the Hue bridge is using Zigbee to communicate with the lamps, it also shares a frequency spectrum near enough to WiFi signals that interference is a potential issue. Well, if you really want to boost the RF interference, put the WiFi network device, and the Hue bridge near each other.  Proximity increase the potential, or real, RF interference.  By creating interference, the Zigbee network suffers significantly.  So after thorough troubleshooting, my issue was having a WiFi AP too close to the Hue bridge.

Oddly, this was not something I really came across while researching the problem I was experiencing.  It was not until I read a research paper on the potential interference be 2.4Ghz Wifi and Zigbee that I realized my AP and bridge may be too close (approximately 3 feet).  

But, I should point out this was a recent change to my environment, yet I have had these issues on and off for a good while.  Further, the AP was still somewhat close, at about 6 feet.  So I would say most of the time the AP has been fairly close.  Today I moved the WiFi AP to another room, about 24 feet way from the Hue bridge.  I then when to each like that had a (!) next to it in Hue app>Settings>Lights and turned the light off and back on.  After about a minute the (!) went away and I regained control of the device.  This went relatively smooth and quick.  I would say this was the most positive sign I have had regarding stability and easy of communication among the devices connected to the Hue bridge.

Although I made this change just a few hours ago, the way things went so easily and quickly, it makes me think this may have been the predominant issue.  

I should add that a while back I did add more bulbs to my environment to ensure that the mesh network should have adequate proximity between bulbs and a reasonable changes to form good signal strength.

To sum, I wanted to get something posted right away in case it might help others.  I am very tired and realize this may be poorly written and a bit confusing.

I'll come back and review when I am rested.  So, when troubleshooting an unreliable Zigbee mesh network, include RF interference as a culprit between WiFi and the Hue bridge.

Analyzing and troubleshooting network and bandwidth issues

Full diagnostics

http://n1.netalyzr.icsi.berkeley.edu/analysis/

This site reports back a great deal of helpful information.  I recently installed Tomato USB firmware (Shibby) on a Netgear R7000 and as part of the setup process, used this site to help with QOS setup and inspecting for any other issues.

Windows Update - accidentally applied update during production hours and now have restart countdown timer - how to stop it

I was troubleshooting a problem on a Windows 2008 R2 server that would not install an update properly.  After much Googling, I resorted to this:

1. Computer>Manage>Configuration>Services
1. Right click Windows Update service and choose Stop.  Set Startup Type to disabled.
2. That stopped the restart countdown timer (where you can choose to postpone 10 minutes to 4 hours).  I need this server up all day and I could not sit and keep clicking postpone.
3. Just stopping the service is not enough.  It will automatically restart itself (it use delay startup).  So you need to set the Startup Type to disabled.
4. This should get us through the working day without an extremely important server rebooting.

Some notes about the problem.

Microsoft had released an out of band update and the server kept erroring over night trying to install it.  I stopped Windows Update Service, deleted the C:\Windows\SoftwareDistribution folder's contents, and then restarted Windows Update Service.

Apparently that took care of it because after a bit I received notification that the update was applied and the computer needed to restart.

This was not supposed to happen based on GPO settings but after review I saw that the time for installing the update was wrong (11AM instead of 11PM).

Finally,
To finish this I need to get back on the server this evening after work hours, and set the Windows Update service back to Automatic-Delayed and then Start the service.  That should restore the status of Update services and I can then safely reboot the server.

Another tip: I have read only another solution to this was to run the command 'shutdown /a'.  This was supposed to clear the pending reboot.  It did not.  The command returned the message that no reboots were pending.

If you run into this situation you may want to try what I posted above, just remember to re-enable the Windows Update service and remove the Disabled startup type.  This will allow your system to resume normal updating.