Up until a couple of weeks ago, we used a Philips Hue bridge and had it connected to Home Assistant. Things worked well. Then, of course, I decided I could improve it. Here’s how I moved all of my lights to be locally-controlled and moved away from the Hue bridge altogether.

Why mess with something that works?

This started a few weeks ago, when I read an article about how Philips Hue released an update that bricked their Hue Bridge Pro for some users. There were a few details that made this especially concerning for me:

  • The Hue Bridge Pro costs more than the standard Hue Bridge and supports 3x the number of devices
  • So, it’s reasonable to assume this affected users with large installations
  • The bridge doesn’t have a backup function
  • The bridge also doesn’t expose serial numbers of the lights, which would make them easy to pair
  • Most importantly: we have a lot of devices, and we used a Hue Bridge Pro!

In the event something like this happened for us, I probably would have needed to remove every recessed light from the ceiling to read its serial number to add it back to the bridge. It’d be a grueling amount of work, and it’d likely happen at a very inconvenient time. I don’t even have a ladder tall enough for some of our ceilings.

In addition, every time we turned on a light, the command went out, over the internet to Philips Hue’s servers, and came back to switch on the light. There wasn’t a noticeable delay at all, but it seemed like a lot of unnecessary overhead.

Consolidating everything into Home Assistant meant we’d have backups of everything. If we needed to, we could restore from a backup and all of our lights would continue working. This was probably the biggest reason I wanted to do this.

Preparing Home Assistant for the migration

Since we’re already using Home Assistant, which has native support for Zigbee, moving these devices to connect locally took very little planning. I bought a Home Assistant Connect ZBT-2 antenna.

Purchasing this is also a great way to support the Home Assistant project!

When it arrived, I plugged it into a USB port on my Home Assistant server, and it was instantly recognized. After a quick firmware update, it asked me if I wanted to set it up for Zigbee or Matter over Thread (you can only choose one, but you can add multiple antennas for both). I picked Zigbee. An additional section appeared in Settings to control my new Zigbee network.

In preparation, I also exported a list of all of our entities in Home Assistant. Specifically, I used the method described in this comment: in Developer Tools > Template Editor, enter:

{{ states|map(attribute='entity_id')|list }}

I saved that to a text file for safekeeping. That way, when I moved devices over into HA, I could override their names and keep our existing automations working. Since everything in Home Assistant is based around the entity ID, it’d never know the difference.

Performing the migration

After that, I migrated all of our devices. The bulbs were surprisingly easy. I started with a regular light bulb that I could easily reset if necessary. I made sure it was as close as possible to the Hue Bridge Pro. I deleted it from the Hue app, which reset the bulb (this contradicts the official documentation, but it worked for me). The light turned a bright white. With the Home Assistant app open on my iPad, I went to Settings > Zigbee > Add Device. Home Assistant noticed the bulb was in pairing mode and immediately added it – the bulb flashed green, and it was ready to be controlled via Home Assistant.

To keep things organized, I made sure to note the bulb’s name before deleting it from the Hue app. I copied and pasted it from the Hue app into Home Assistant, then when I had migrated enough bulbs, hopped on the computer to rename their entities and match the export I had done earlier.

As I got towards the end, I found the Hue bridge no longer had enough connectivity to some of the lights at the far edges of our house. That made sense – all of the wired Zigbee devices create a mesh network, so removing the lights closest to the bridge made it tough to control the remaining ones. Since we added ethernet ports to nearly every room in the house, I picked up the Hue bridge and plugged it in near the last few lights just to finish those up.

With the lights finished, I moved on to the battery-powered accessories. We use a motion sensor inside of the house for some lights, and that was similarly easy to reset. For the dimmer switch remotes, I used a spudger to pop off the battery cover and press the tiny reset button for 10 seconds. After that, I was able to add those into Home Assistant, too. When the Hue Bridge Pro was finally empty, I performed a factory reset and deleted the Hue app from my devices. I also deleted the Philips Hue integration in Home Assistant. Success!

Well..not quite. Although all of our existing automations worked, they took a very long time, then they’d fail. It was frustrating to see only half the lights in a room change to the correct color.

I also found that the dimmer switch remotes don’t expose any entities to Home Assistant for controlling the buttons. That was annoying. All of my existing automations for controlling the four buttons were all useless. Home Assistant was showing nearly 70 errors for these automations, and my server was crashing every few minutes. I started to regret the switch.

I had trouble deleting the automations via the GUI, and I think it’s because the server was repeatedly crashing. As a workaround, I used the File Editor add-on to export a copy of my automations.yaml file, then I manually deleted all automations for the “old” dimmer switch remotes. After reloading Home Assistant, the errors were gone, and things seemed a bit more stable again.

To get the dimmer switch remotes working again, I found a blueprint that almost worked – I’m glad it’s published as a GitHub Gist, as I found one of the forks worked with the models we purchased. Referencing the automations.yaml file I exported, I was able to rebuild my automations for each remote.

The author of this blueprint did a great job – this was very easy to set up

However, my scenes still did not work properly. It seemed like the lights responded very slowly – for a scene that changed a bunch of lights, you could look at the ceiling and see each…one…change…individually. I think I’ve mostly fixed that, and it took three major changes:

Optimizing my new Zigbee network

First, I realized that the Zigbee channel (how all of the lights communicate with each other) was chosen before any of the devices were added. It probably wasn’t optimal for our house’s topology. I went to Settings > Zigbee > Network Information > Channel and clicked the pencil icon. From the pop-up menu, Smart was already chosen, so I clicked Change Channel. This performed a one-time change across our whole Zigbee network. Some lights took several hours to function again. I don’t recommend doing this at night.

Second, I combined a lot of the lights into groups, as I had done when we had the Hue bridge. For example, my home office has four recessed lights. It would be very unusual to want to control them individually, so I combined them into a group named Mike’s Office Recessed Lights and changed the visibility for the individual bulbs to be hidden. If nothing else, this simplified both the dashboard and automations.

Finally, I realized we were sending a lot of commands at once. For every scene, we were telling the bulb to turn on, set a specific color and brightness, then we followed up with a “reset manual control” command so adaptive lighting would take over the color and brightness. While this somehow worked well with the Hue bridge, it failed horribly when run locally.

I had remembered from my last post about adaptive lighting that for the plugin to work, you had to turn on a light without specifying color or brightness. Since that’s not possible to do via a scene, I rebuilt every scene as a Home Assistant script instead. It took some time and experimentation, but I’m much happier with the result. Each “scene” (rebuilt as a script) sends a “turn on” command to the light without specifying anything, and adaptive light kicks in immediately. In hindsight, I probably should have done it this way in the first place. Each automation works pretty consistently, and it’s very easy to debug if things don’t work properly after all.

The script for Good Morning

Here’s what the YAML looks like for that second step:

action: light.turn_on
metadata: {}
target:
  entity_id:
    - light.dining_room_recessed_lights
    - light.kitchen_recessed_lights
    - light.living_room_recessed_lights
    - light.mike_s_office_recessed_lights
    - light.mikes_office_floor_lamp
    - light.mikes_office_speaker_lamp
    - light.mudroom_recessed_lights
data: {}
continue_on_error: true

Notice what’s missing? Pretty much everything except for the command to turn on the light, and the list of lights. Compare that with the third step – we don’t use adaptive lighting with the cabinet lights in the kitchen:

action: light.turn_on
metadata: {}
target:
  entity_id: light.kitchen_cabinet_lights
data:
  brightness_pct: 80
  rgb_color:
    - 255
    - 193
    - 118
continue_on_error: true

I then swapped those scripts into the appropriate automations (so lights that turn on at sunset actually do). To keep things clean, I deleted my original scenes. I also refreshed my HomeKit Bridge plugin so all of the identically-named scripts appeared in the Home app for Siri.

The automation for Good Morning

Conclusion

Overall, I’m still glad I made the switch. Things mostly work as expected now, but occasionally, we notice a light that isn’t the right color and have to fix it. Everything is local now, and is properly backed up, so I have a bit more time before I need to purchase a very tall ladder.

After some thought, I’m going to sell our Hue Bridge Pro, but keep a standard Hue bridge around. Why? Although Home Assistant can update the firmware for Hue bulbs, Philips Hue chooses not to make them available unless the bulb is connected to their bridge. In the future, when we buy more lights, I’ll add those to the Hue bridge, update them, then move them into Home Assistant. It’s annoying, but probably worth the trouble for the stability fixes.

In the process of writing this blog post, I discovered the concept of Zigbee Groups, so I’ll probably migrate my lights to that (from Home Assistant’s Groups, which is a separate thing). It sounds like that might further increase stability.

If you have any questions, please leave a comment below!