Moving Home Assistant From a Raspberry Pi 4 to an Intel NUC

I have been slowly building a problem into my house.

Every time I bought a new smart device, I added another Wi-Fi client, another vendor account, another app, and another cloud dependency. It worked, but the more devices I added, the more complicated the system became.

My Raspberry Pi 4 had been running Home Assistant, and it did a good job for a long time. Eventually, though, I started asking it to do more than I thought it could comfortably handle. I wanted more add-ons, more dashboards, Music Assistant, and more devices without constantly wondering if the Pi was going to keep up.

That was the reason for the move to an Intel NUC. It was not just a hardware upgrade. It gave me a better foundation for moving away from Wi-Fi IoT devices and the collection of vendor bridges that had slowly taken over my house.

The hardware

#

The host is an Intel NUC with a 10th-generation Core i5 processor and 16 GB of RAM. It is still small and fairly low-power, but it gives Home Assistant considerably more room to grow than the Raspberry Pi 4 did.

The radio hardware consists of two USB coordinators:

I wanted Zigbee and Z-Wave to have their own coordinators and their own networks, with Home Assistant handling the dashboards and automation logic. That keeps the radios separate and gives me one place to manage the house instead of relying on several different bridges.

Why I moved from ZHA to Zigbee2MQTT

#

When I first started using Zigbee with Home Assistant, I went with ZHA. It was already integrated into Home Assistant, and I wanted to keep things as simple as possible.

That did not work out as well as I expected.

One of the devices I was trying to add was the SONOFF ZBMINIL2, a no-neutral relay. After hours of trying to pair it, ZHA simply would not see it. I also had some devices that would randomly drop off the network.

In fairness, the drop-offs were not entirely ZHA’s fault. At that point, I had not migrated my Zigbee smart switches yet. Those switches could have acted as routers and helped build out the mesh, but the devices I had migrated were battery-powered. Without enough powered Zigbee devices in place, the mesh was not very strong, so the battery devices had a hard time staying connected.

Still, the experience made me look more seriously at Zigbee2MQTT. I migrated from ZHA to Zigbee2MQTT, and the difference was noticeable. Device support and pairing made more sense to me, and I had better visibility into what was happening on the Zigbee network.

I started with the SONOFF ZBDongle-P. It worked, but when I decided to make the setup more uniform—and because I wanted a newer device—I upgraded to the SONOFF Zigbee Dongle with the EFR32MG24 chip. It also looks better alongside the SONOFF Z-Wave dongle in the custom mount, which is a small thing, but I like the setup to be organized and aesthetically pleasing too.

Installing Home Assistant on the NUC

#

For the installation, I used balenaEtcher to write the Home Assistant image to the NUC’s SSD. Once the image was written, I installed the SSD in the NUC, booted it, and went through the initial Home Assistant setup.

The most important part of the installation was not starting from scratch. I created a backup of Home Assistant on the Raspberry Pi 4 and restored that backup on the NUC. This brought over my existing configuration, integrations, automations, and other settings, which made the migration much easier.

There was still some cleanup afterward. The hardware was different, the Zigbee coordinator had changed, and I had to check that the integrations and devices were behaving as expected. I also took the opportunity to rebuild parts of my dashboards instead of copying everything exactly as it was on the Pi.

The NUC gave me enough headroom to run the add-ons and services I had been holding back on. Music Assistant in particular did not work very well for me on the Raspberry Pi. On the NUC, it has been much more usable, along with the other add-ons that were putting more pressure on the Pi.

Building the dashboards

#

Once the migration was stable, I started spending more time on the dashboards. Home Assistant is much more useful to me when I can see what is happening in the house without opening several different apps.

I built dashboards for the main areas of the house, devices, sensors, climate, and automations. They give me a quick view of doors and windows, lights, temperature, plant sensors, and the devices that need attention.

I also wrote a script for mapping my Apple TV remote. That lets me control the Apple TV from Home Assistant and tie it into some of the other automations in the house.

I have also converted a Microsoft Surface Go and a Google Nexus 7 into portable control dashboards. I am still working on that project and will write it up separately soon.

I am also sending my activities and logs to ClickHouse and Loki. This gives me a better audit trail of what is happening throughout the house, and it will also give me data to use while training my own “MikeOsude AI.” I want it to understand the patterns in my home instead of only reacting to isolated events.

I am also looking for ways to integrate MikeOsude AI directly into Home Assistant. I am still trying to figure out where it fits agentically instead of just making it another chatbot that I can ask to turn things on and off. The interesting part, for me, is seeing whether it can understand context, make useful decisions, and help coordinate automations on its own while still keeping me in control.

The automations I am using

#

The system is not just a collection of dashboards. The automations are where it starts to feel like the house is actually responding to what is happening.

I have Third Reality soil sensors watching my plants, along with a smart watering kit that helps keep them alive. That has been especially useful because I am much better at building an automation than I am at remembering to check every plant.

Door and window sensors turn off the air conditioning when a door or window is open. Motion sensors handle lights, and I use lux sensors to make sure the lights do not turn on when there is already enough light in the room.

I also have an Emporia home energy monitor watching the grid and tracking the energy consumption in my home. I have more automations planned around that data, so I will be writing about those as they come together.

The motion timeout also changes depending on the time of day. At night, the lights stay on for about ten minutes after the last motion. During the day, they turn off after about a minute and a half. It is a simple change, but it makes the lighting feel much less annoying than using one timeout all day.

There are plenty of other automations throughout the house, and I am still adding more as I find ways to remove small repetitive tasks.

I also added HACS for my car, which gives me full visibility into my plug-in hybrid. I can track servicing, the high- and low-voltage batteries, remote start, lock and arm status, logs, and much more. It has turned the car into another useful source of information and automation data inside Home Assistant.

I added my Bambu printer, home vacuum cleaner, TVs, and plenty of other devices too. The printer and vacuum are still Wi-Fi devices, and I cannot replace them with Zigbee or Z-Wave versions anytime soon, so those will remain part of the Wi-Fi side of the network for now.

The smart toothbrush rabbit hole

#

Here is a funny story. Home Assistant somehow connected to my neighbor’s Oral-B toothbrush. I disconnected it, but not before copying down the model number and spending more than an hour going down the rabbit hole of figuring out how I could automate my own toothbrush.

Eventually, I stopped and decided to put a pin in it for now.

You thought I was going to say I would not get a smart toothbrush?

Decommissioning the bridges

#

One of the main reasons for building this system was to get rid of the separate vendor bridges.

So far, I have decommissioned my Hue bridge and SONOFF bridge. I am also working through the IKEA and Leviton Decora equipment. I originally thought the Leviton devices used Z-Wave, but I am still having trouble adopting them and figuring out the best way forward.

Those have been the least reliable automation devices in my home. I may eventually retire them and replace them with Zigbee or Z-Wave devices that work more cleanly with the rest of the system.

I also moved my August lock from Wi-Fi to Bluetooth. I am probably going to replace it eventually with a Zigbee or Z-Wave lock, but moving it off Wi-Fi was a useful step in the meantime.

The goal is not to replace every device immediately. I am moving things over as it makes sense, testing each change, and keeping the old bridges around only until I know I no longer need them.

The custom 3D-printed assembly

#

The two USB dongles are small, but leaving them hanging from the side of the NUC did not feel like a good final installation. I designed a custom 3D-printed assembly to hold the Zigbee and Z-Wave modules together.

It keeps the hardware organized, makes the two radios easier to identify, and gives the whole setup a much cleaner look. It also makes it easier to move or replace one of the dongles later.

That is one of the parts I enjoy about homelab projects. I could have used a generic bracket, but designing and printing something that fits this exact setup was more satisfying.

It is funny to mention the final design without mentioning how many times I got it wrong first. I have scrap 3D-printed models all over my house from trying to get the fit and shape right. Before I even started making proper CAD designs, I had some pretty bad drawings in Apple Freeform trying to work out how the pieces should fit together.

There were several versions that were almost right, but not quite. Some were too tight, some did not hold the dongles the way I wanted, and others looked fine on the screen but did not work once they were printed. The final assembly came from all of those failed attempts.

The build media is available here: Home Assistant NUC build media.

The printable design

#

I am also publishing the custom files so that other people can inspect, modify, or print the assembly for their own NUC and radio setup:

• Download cap_top.stl
• Download tray_bottom.stl

The design is split into a top cap and a bottom tray. The exact fit will depend on the NUC model, USB hardware, printer tolerances, and print orientation, so treat these files as a starting point and check the dimensions before printing.

How it has been going

#

The NUC has been very stable so far. Home Assistant feels more responsive, Music Assistant is much more usable, and I have more room for the add-ons and services I wanted to run.

The Zigbee network has also improved as I have migrated more powered devices and built out the mesh. Moving from ZHA to Zigbee2MQTT and upgrading to the MG24 coordinator helped, but the powered Zigbee devices acting as routers have been just as important.

Home Assistant is now becoming the central place for the house. The Hue and SONOFF bridges are gone, more devices are moving to Zigbee and Z-Wave, and the dashboards give me a much better view of what is happening.

There is still plenty left to do. I am working through the remaining unreliable devices, deciding what to do with the IKEA and Leviton equipment, and continuing the portable dashboard project. But the system is heading in the direction I wanted: fewer vendor islands, less Wi-Fi IoT, and more control over the devices in my own home.

The best part is that I did not have to rebuild everything in one weekend. I restored the backup, fixed what needed fixing, moved devices over gradually, and kept improving the dashboards and automations as I went. That is usually how my homelab projects evolve—one small improvement at a time until the whole system is different.