Hue lights borderline unusable with SkyConnect vs Hue Bridge...did I make a mistake?

Configuration
1

I feel like I’ve made a mistake switching from a Hue Bridge to SkyConnect for my Hue bulbs. With the Bridge, lights always worked every time when integrated via HomeAssistant. But, with the upcoming changes in Phillip’s ToS requiring an account, I wanted to finally take the plunge into buying a SkyConnect and start setting things up fully locally with Zigbee. It’s horrible.

When turning on/off lights in a room, quite often one just won’t turn on or off. Sometimes, when trying to turn on/off a light in HomeAssistant, it just won’t do anything. If the Hue Bridge used Zigbee, then there shouldn’t be anything different, right?

Does having a lot of devices cause a potential problem? I’ve got 66 devices on my SkyConnect. From what I’ve read, Zigbee is a mesh, right?

I’ve read about making sure that there’s no interference with Wifi and Zigbee. My 2.4 Wifi networks are on channel 1 and my SkyConnect is on channel 24. If I’m correct, there should be no interference, right?

Any tips would be appreciated. Will provide and logs/etc. that are needed, I just honestly have no clue where to start.

Edit: As we speak, devices are just now “Unavailable”. Attempting to Reconfigure them results in failure every time. For things like Plugs, this is easy to remedy by putting back into pairing mode and repairing. For bulbs in the ceiling, this just simply isn’t feasible.

2

In theory. However, there may have been weaknesses in your original network that were being masked by the Hue bridge. For example, it would have had a bigger antenna than the SkyConnect dongle, so it may have been connecting directly with more devices.

They are certainly at opposite ends of the spectrum, but channel 24 is not recommended, according to the docs.

Channel 20 would be well clear of your wi-fi.

image
image890×443 68.8 KB

…but don’t forget your neighbours. If you go to the ZHA integration card and click on Download diagnostics they include a summary of current channel usage (right at the bottom) which should look something like this:

"energy_scan": 
      "11": 55.9836862725909,
      "12": 89.93931580241996,
      "13": 87.33047519856483,
      "14": 49.512515447068886,
      "15": 89.93931580241996,
      "16": 88.70042934643088,
      "17": 13.711043742539033,
      "18": 8.631361812931262,
      "19": 4.15070068297423,
      "20": 70.89933442360993,
      "21": 1.9464625152460222,
      "22": 36.830390267097734,
      "23": 4.15070068297423,
      "24": 3.2311094587038967,
      "25": 2.2107128772756957,
      "26": 70.89933442360993

Unlike wi-fi scans, this includes Zigbee usage - channels 11 (Z2M) and 20 (ZHA) in this example. If you do decide to change channels, the ZHA integration will do it from the GUI. Go to the device card for your coordinator, click add devices via this device and then the network tab at the top. I did this recently and all my Hue devices switched automatically without needing re-pairing.

Sixty-six devices is quite normal, but it depends on what kind of devices they are. Only routers (mains-powered devices) contribute to the mesh, so you need to look at how many of them there are and how they are distributed.

If you have Hue motion sensors there is a known problem with them in that they sometimes disconnect from the network then try to re-connect as a new device, which the network will not allow. There is a simple fix for this here.

It may also help to update the firmware on the SkyConnect. The simplest way to do this is with the Silicon Labs Flasher add-on, which defaults to the latest version.

If you have a Hue dimmer switch you can use it to put bulbs into pairing mode. Hold it as close as you can to the bulb, then press and hold down top and bottom buttons together for 5-10 seconds. The bulb will flash when it’s in pairing mode.

There’s a community guide on migrating from the Hue bridge here.

1 Like
3

Ouch, painful.

A couple things, “rip and replace” is often a recipe for disaster in home automation (and most other places). Guessing that Signify ToS is not looking as bad the ToS from your ‘Significant Other’ right now :wink:.

IMHO, unfortunately, you picked two of the worst choices you could have made for moving from Hue up to an open source solution:

  1. Choosing the SkyConnect Zigbee Coordinator device. I highly recommend you toss this in your tech junk drawer and purchase a coordinator device based on the TI 2652P chip set. There are a number of good vendors of this device, search this forum.

  2. Choosing ZHA as your Zigbee platform. Unfortunately, it is less developed of the two prime choices for use with Home Assistant. I highly recommend you setup a Zigbee2MQTT based solution. The level of quality, support and function with Zigbee2MQTT is night and day vs. ZHA. It is a sad truth, I would like ZHA to be successful, however just not the time, place and people for it to thrive.

I would start by moving your key, if not all of your Zigbee devices back to Hue hub and either stay there (it was a ‘happy place’ aka it worked, correct?). If you are still inclined to move forward with an open Zigbee solution, then do a paced move to the Zigbee2MQTT system.

Another recommendation, while a bit more complicated, I would install your Zigbee2MQTT server and the required MQTT broker separate and NOT within your Home Assistant OS setup. Putting these three all together and under Home Assistant makes your solution less stable. Docker is a very good technology to have in your quiver. Your Hue hub is 100% independent of your Home Assistant system, any amount of futzing with your Home Assistant server did not effect the basic operation of your Zigbee devices on the Hue hub, many reasons to keep that model.

Another recommendation, a simple way to test for ‘network’ problems/interference (which is, based on my experience is way way down the list of things that will probably be root cause of problems you are having, the two items I cite above are 1 and 2):

On your original Hue hub setup, bind a Zigbee switch directly to a Zigbee light bulb. Do the same on your new open Zigbee network with another pair of Zigbee devices. Press the button and watch the light. I call this the ‘Significant Other’ network latency test, if she presses the button multiple times and is happy with the performance then so are you…:wink:

Good hunting and much success with your home automation adventures in 2024!

4

I checked my energy_scan, and here’s the results. Is higher better, or does higher mean more use?

  "11": 97.97769123383605,
  "12": 99.44062726818147,
  "13": 99.44062726818147,
  "14": 97.39286236923465,
  "15": 99.9089403802638,
  "16": 94.48255331375627,
  "17": 92.95959997754716,
  "18": 55.9836862725909,
  "19": 25.74050169409602,
  "20": 88.70042934643088,
  "21": 49.512515447068886,
  "22": 80.38447947821754,
  "23": 80.38447947821754,
  "24": 78.25348754651363,
  "25": 52.75969252664325,
  "26": 99.89631182837557

Didn’t even think about the neighbors. We aren’t too terribly close in proximity, but it may be enough to cause issues.

Most devices are routers, only 10 devices aren’t (Hue dimmer switches)

Thanks for the tip for repairing bulbs, btw!

5

I’ll throw in my two cents…
I migrated about one week ago from Philips Hue Bridge to Zigbee2MQTT. I went with a Sonoff Coordinator using 2652P on my production HA system.

Although I have a SkyConnect, I use it on a “sandbox” HA system for experimenting with on a SiLabs Multiprotocol (Thread+Zigbee) and it works with a nearby Hue bulb just fine.

With the Hue Bridge, everything worked fine. Most of my Hue devices are 1st or 2nd generation lights (bulbs, strips) and a few old CREE Zigbee bulbs, along with EnOcean switch and Aurora Dimmer. After migrating (btw I use the same channel 25 before/after migration), everything works fine and seems pretty solid except for one particular Hue bulb which is the furthest away from the coordinator but it is in a room with 3 other bulbs/strips that themselves work just fine. This one exceptional bulb many times has a long delay (13-15 seconds) before it reacts…I’m still playing around and seeing improvements.

For now, no regrets :slight_smile:

6

What is the age and firmware of the flakey bulb. Over many years of use, I have had one Hue bulb flake on me, a number of others from other manufactures however.

You might run and monitor a script similar to one listed below. The idea is that the device should be ‘checking’ in on a regular basis, if you can identify any ‘gaps’ that look odd, it might point to a signal issue at the bulb. This is not a really quality test of the device, however might give you some ideas. It is an unfortunate fact of Zigbee that the universe of accessible network and device monitoring tools is pretty slim.

Another thought, you might try adding the flakey bulb to your test coordinator, try and do a ‘proper’ remove from that network. Then maybe do a couple of extra factory resets on the bulb and they try and add it back to your production coordinator.

Also, try my ‘significant other’ network latency test, bind one of your switches directly to the bulb and then with both in close proximity see what on/off performance you get.

What does the zigbee2mqtt map look like for connections to this device? And what are it’s LQI numbers?

Set your Zigbee2MQTT log to debug as well and give it a review after a good collection period to see if the coordinator sees any issues with the device.

Good hunting!

#!/bin/bash
echo "Bash version ${BASH_VERSION}..."

while :
do

    PRI=$(mosquitto_sub -C 1 -h 192.168.2.242 -t zigbee2mqtt/0x00158d0009ee3f7a)
    printf "%s\n" "$PRI"
#    echo $PRI


done

user@ud-22-04-01:~/zigbee-test$ ./hue-bulb.sh
Bash version 5.1.16(1)-release...
{"brightness":254,"color":{"hue":25,"saturation":95,"x":0.5267,"y":0.4133},"color_mode":"color_temp","color_temp":500,"color_temp_startup":500,"last_seen":"2023-12-22T13:43:28-08:00","linkquality":102,"power_on_behavior":"previous","state":"OFF","update":{"installed_version":16785162,"latest_version":16785162,"state":"idle"}}
{"brightness":254,"color":{"hue":25,"saturation":95,"x":0.5267,"y":0.4133},"color_mode":"color_temp","color_temp":500,"color_temp_startup":500,"last_seen":"2023-12-22T13:43:32-08:00","linkquality":98,"power_on_behavior":"previous","state":"ON","update":{"installed_version":16785162,"latest_version":16785162,"state":"idle"}}


{"brightness":254,"color":{"hue":25,"saturation":95,"x":0.5267,"y":0.4133},"color_mode":"color_temp","color_temp":500,"color_temp_startup":500,"last_seen":"2023-12-22T13:53:33-08:00","linkquality":94,"power_on_behavior":"previous","state":"OFF","update":{"installed_version":16785162,"latest_version":16785162,"state":"idle"}}
7

Thanks,
Here are some observations/experiments I’ve been doing
BTW its a 1st gen BR30 and according to z2m its: Firmware build date -20221006, Firmware version -67.101.2

  • In the situation where it takes 13-15sec delay to turn the bulb on, afterwards it always instantly responds to on/off for the next little while. But after some number of minutes of not doing anything, it again may take 13-15 secs to turn on/off.
  • The LQI in general is reporting in the 30s, but once it is turned on and instantly responds for the next little while, the LQI is in the 80s.
  • Increase power of Coordinator from default (+5dBm) to +10dBm, and the problem gets worse.
  • Decrease power of Coordinator to +2dBm, things get much better.
  • Add an automation that uses mqtt/z2m to get the state of the bulb every 4minutes. This improves things as well.

To me, this is symptomatic of a routing issue, seemingly the route picks the direct connect with the Coordinator rather than route hoping via another Hue device. The map shows a direct link with the coordinator with near zero LQI, and it shows a couple of 1-hop routes with much better LQI.

I’m also ordering a new bulb anyway to replace this old one, and we’ll see if that makes a difference.

8

They’re percentages and higher means more use.

The fact that they’re all quite high suggests interference from somewhere - normally there are distinct highs and lows. This will affect ZHA and Z2M.

Have you got your SkyConnect on an extension lead? The one in the box isn’t really long enough - I have mine on a 2m lead. Also, make sure it’s plugged into a USB 2.0 port - USB 3.0 ports (the blue ones) cause a lot of trouble. A USB 3.0 lead is OK - they have better shielding.

Lots of good advice here:

Edit: 56 router devices is very good!

9

Interesting. I’ve always shied away from mucking with raising the transmit power of the coordinator (how can it help if only one side of a conversation be heard?), however it never occured to me to lower the coordinators power :face_with_monocle: .

Back to all the kerfuffle about Signify’s ToS and ‘looking into your home’, I am very skeptical. However, are there some ‘tricks’ that Signify engineers have done to ‘fix’ problems with some of their devices … and of course (not) they have shared this with open source community. Yes, I can believe that might be a true occurrence. Back to why something worked fine on the Hue hub, however 'less ‘fine’ on Zigbee2MQTT…

LQI, routes and changes. Back to rant on better tools, a real weak spot for Zigbee IMHO.

Good hunting!

10

I’ve got it plugged in via USB 2.0 using the supplied extension. I’ve got a long extension cable somewhere in my bin-o-cables that my wife tells me isn’t useful… Looks like it will be today! I’ll try that and report back.

11

Okay, found a longer cable. Here’s the new energy-scan. Not much better :frowning:

  "11": 97.39286236923465,
  "12": 99.27573563839312,
  "13": 97.7033852118351,
  "14": 95.12234809209261,
  "15": 93.76433891498253,
  "16": 97.04162534718327,
  "17": 96.19660508390695,
  "18": 39.90320178295578,
  "19": 31.01324838787301,
  "20": 94.48255331375627,
  "21": 94.48255331375627,
  "22": 93.76433891498253,
  "23": 59.15797905332195,
  "24": 43.057636198227904,
  "25": 55.9836862725909,
  "26": 92.0598007161209

What sort of other things could be causing interference?

12

Do you know what channel your Philips Hue Bridge was on? If so, I would stick with that one simply because you know it works(ed).