Which Home Assistant Hardware Is Worth Buying Again?

What I would buy again, and why

This is not a ranking of everything that works with Home Assistant. It is the purchase filter I can defend from the equipment in my own house.

The easiest yes: Caséta for the walls

The strongest purchase decision in this house is also the least futuristic. I want a visitor to press the wall control and get light. I want that to remain true while Home Assistant is restarting, the network is down, or an automation is wrong.

That is why permanent lighting here uses Lutron Caséta. The September 12 inventory recorded nine PD-6WCL dimmers, eleven PD-8ANS switches, three PD-FSQN fan controls, three Pico remotes, and one L-BDG2 hub. The older controls still work, so I would not replace them for cosmetic reasons.

For a new room, I would start with the current paddle-style DVRF-6L Diva smart dimmer for a compatible dimmable lighting load, the DVRF-5NS Claro smart switch when I need a neutral-wire on/off switch, and the PD-FSQN only for a compatible pull-chain fan that needs four-speed control. The L-BDG2 hub is the bridge into Home Assistant.

The model numbers are not interchangeable. Load type, neutral availability, lamp compatibility, and whether the circuit controls a fan all come before automation. I keep the exact ratings and the current-versus-installed distinction in my Caséta and Matter buying guide.

A Matter bulb is an exception, not a lighting plan

A small lamp in a kid’s room is where a Matter bulb makes sense to me. There is no useful in-wall dimmer to install, the lamp can remain powered, and color or tunable white can add something that a normal bulb cannot.

I would not scatter smart bulbs behind ordinary wall switches. Somebody will switch off the power, the bulb will disappear, and the house will need an instruction manual for turning on a light.

I am deliberately not naming a bulb to buy yet. I know the role, but I have not rechecked the exact model in this house. “Matter bulb” is not specific enough for a product recommendation: the transport can be Wi-Fi or Thread, exposed features vary, and a Thread logo is not proof of Matter support.

I would build the WLED lighting again—with a parts list next time

The kitchen has six separate LED runs because that made the wiring and service boundaries sane. Home Assistant groups them for normal on/off and brightness. For the named white and color modes, one helper sends the same WLED JSON state directly to all six controllers.

I would keep that architecture. One unreachable controller does not stop the other five, and a newer scene request can replace the one already running. It solved a real problem that the common light abstraction did not: the strips do not all expose white in the same way.

I would not publish a cart full of generic ESP32 boards and power supplies from memory. The useful buying guide has to include the exact controller, strip voltage, power-supply capacity, injection points, wire, fusing, and enclosure. Until I recover those part numbers, the six-controller article is a control design, not a complete shopping list.

Bond makes sense as a retrofit, not as permission to ignore power

My Bond Bridge exists because the ceiling fan already used an RF remote. It let Home Assistant send the same light and fan commands without replacing the receiver. The September inventory identified my bridge as Olibra zermatt on firmware 3.17.4; Home Assistant documents zermatt as Bond Bridge v2.

I would use Bond again for that job: making a compatible fan I already own available to Home Assistant. I would not buy it to make a new fan “smart” if accurate state were a requirement. The receiver sends no state back, so the dashboard can track commands and still be wrong after a missed RF packet or a handheld-remote press.

I also would not put the receiver behind a daily smart switch. My PD-8ANS once cut power out from under Bond, creating a four-to-five-second boot race. For normal use, I expose the Bond light and fan rather than the upstream switch. The guard automation requests power restoration after an off event; it cannot prevent the initial interruption, and it cannot act while Home Assistant is offline. It can also override a paddle press. That switch must not be treated as a dependable way to keep the fan de-energized for maintenance.

The full failure and fix are in my Bond and Caséta case study.

I like the S2 integration. I would not buy the vacuum for it.

My current Eufy Omni S2 appears in Home Assistant as a local Matter vacuum. I can start a room, several mapped areas, or the normal downstairs route. I use error and prolonged dock-seeking states for alerts. The linked setup article includes an adapted notification example tested offline, not proof that every failure will produce an alert.

That is useful. It is not enough to justify flagship-vacuum money. Home Assistant does not replace the Eufy app for maps, station settings, obstacle details, or model-specific cleaning choices. The live battery percentage has also contradicted the full-charge state, so I leave it out of automations.

I would choose the vacuum on cleaning, obstacle handling, dock maintenance, consumable cost, and repair support first. Matter is the bonus that lets the chosen vacuum participate in the house. The exact controls and rough edges are in my S2 setup.

Lightning changed how I treat the Eufy label

The old Eufy S1 Pro vacuum and video doorbell were both taken out by lightning. The current security base is HomeBase 3, model T8030, but a shared logo does not turn the base, vacuum, doorbell, and outdoor lights into one product family with one consistent Home Assistant integration.

I am not recommending a replacement doorbell until I have the exact replacement model and can verify what it does with HomeBase 3. I am applying the same rule to the permanent outdoor lights: I know what is installed and how I want exterior lighting to behave, but I need the model from the device or app before linking a product.

The RTX 5070 Ti is useful because it was already here

My local Qwen3 model is fast enough to feel natural on an RTX 5070 Ti: about two seconds for a warm response in the September observations. That was a setup-specific result, not a controlled hardware comparison or a latency guarantee. It can control exposed Home Assistant devices and use a bounded local memory list. It can also claim that it changed the lights when it did nothing.

I would not buy this GPU solely to run a home assistant. The sensible path is to try the hardware already available, watch actual GPU placement and response time, and keep the model behind tested scripts and scenes. The recorded timings, their limitations, and the false-success failure are in the local Ollama article.

The purchase test I use now

1. What still works when Home Assistant is unavailable? Essential controls should have a simple answer.
2. Am I buying the core job or the integration? A vacuum has to clean; a dimmer has to control its load; a light has to make sense at the wall.
3. Do I know the exact model? A product-family name is not enough for compatibility or a responsible link.
4. Can I explain the failure mode? Power loss, boot time, one-way radio, cloud dependence, and bad telemetry each need different handling.
5. Would one purchase remove complexity? If the new device adds another app, radio, bridge, and recovery path without making the room better, I skip it.

I would keep the working Caséta controls and buy the next device only after identifying the problem it solves. A better dashboard is not enough if the room becomes harder to use.

Disclosure: This guide draws on equipment I own and use. The Diva and Claro models are alternatives for a new installation, not claims that I installed or tested them here.