Disclosure: Some links in this article are affiliate links. We may earn a commission on qualifying purchases at no extra cost to you.
If you are trying to decide which Home Assistant add-ons and integrations are genuinely worth installing, the first step is understanding the current ecosystem—and the Home Assistant beginner's guide is the best place to start before you change a production setup.
The problem with most add-on lists is that they treat Home Assistant as a software store where more installed components equals a better system. That was never true, and the 2026 stack makes it more false than ever. Home Assistant renamed Add-ons to Apps in release 2026.2, and Home Assistant OS plus Home Assistant Container are now the only supported production installation methods—Core and Supervised lost support after 2025.12. If you are still following a guide that says an App runs on Supervised, you are working from outdated material.
That matters because Apps are a Home Assistant OS feature. A Container user often does not install "Apps" at all; they run the equivalent service as a separate Docker container and connect it through a Home Assistant integration. The distinction between an App, an integration, and a community custom integration is no longer pedantry—it determines what you can install, where it runs, and what happens when you upgrade.
This guide is organized by problem solved, not popularity. Each section answers four questions: what the component does, whether you actually need it, whether it stays local, and what you can automate after installing it.
Before You Install Anything: Apps, Integrations, and What Actually Changed
Home Assistant now has three layers that get conflated in old tutorials:
- Apps are standalone services running alongside Home Assistant. On Home Assistant OS they install through Settings → Apps. They are not integrations.
- Integrations connect Home Assistant to a device or service. The native MQTT integration, native Z-Wave integration, ESPHome integration and Matter integration are examples.
- Custom integrations live in
custom_components/and are installed through HACS, the Home Assistant Community Store. HACS itself is a custom integration, not an App, and it does not contain Apps.
The practical impact is simple. If you run Home Assistant OS, you can install an official Mosquitto broker App and pair it with the native MQTT integration. If you run Home Assistant Container, you deploy Mosquitto as a separate container and point the same native MQTT integration at it. Same function, different installation path.
This is also why install methods now matter more than brand names. Home Assistant OS and Container are the only supported production paths. Home Assistant Green and Yellow run Home Assistant OS out of the box, while a mini PC or Raspberry Pi install gives you the same App experience without proprietary hardware.
Quick Reference: Pick Components by the Problem You're Solving
| Component | What it solves | Install when | HA OS path | Container equivalent | Local/cloud |
|---|---|---|---|---|---|
| Mosquitto broker + MQTT integration | Local message bus for Zigbee2MQTT, Frigate, Tasmota | A specific service needs MQTT | Official Mosquitto App + native MQTT integration | Separate Mosquitto container + native integration | Fully local |
| Zigbee2MQTT | Zigbee network service with broad device support | ZHA cannot expose a device or setting you need | Third-party Zigbee2MQTT App + MQTT | Separate Zigbee2MQTT container + MQTT | Fully local |
| Z-Wave JS App + Z-Wave integration | Z-Wave locks, sensors, thermostats | You use Z-Wave devices | Official Z-Wave JS App + native integration | Z-Wave JS UI Docker + native integration | Fully local |
| ESPHome Device Builder + integration | DIY local sensors and controllers | You build or flash ESP32/ESP8266 devices | Official App + native ESPHome integration | Separate ESPHome container + native integration | Local native API |
| HACS | Community integration/frontend manager | A specific gap remains after Core integrations | HACS download App + HACS integration | HACS download script + HACS integration | Mixed |
| Node-RED | Visual automation runtime | You think in diagrams or need complex state machines | Community App | Separate Node-RED container | Local, unless a flow calls cloud APIs |
| Matter Server + Matter integration | Matter controller for local IP control | You add Matter/Wi-Fi or Matter/Thread devices | Official Matter Server App via integration setup | External server only; standalone Docker unsupported | Local IP |
| Wyoming + Speech-to-Phrase/Whisper/Piper | Local voice control | You want private voice without a cloud assistant | Voice Apps + Wyoming integration | Separate Wyoming service containers | Fully local if configured as local |
| Native Backup + SFTP/NFS/CIFS | Scheduled full backups off-device | Always | UI configuration + storage targets | Backup integration + network storage | Local or cloud depending destination |
| AdGuard Home | Network-wide DNS ad/tracker filtering | You want DNS-level blocking | Community App | Separate AdGuard Home container | Local DNS with chosen upstream |
| NGINX SSL proxy | TLS reverse proxy for remote access | You need public HTTPS by your own domain | Official NGINX App | Normal NGINX container | Local service, public exposure |
| Frigate + Frigate integration | Local NVR and object detection | You run cameras and want local AI alerts | Frigate App + HACS integration + MQTT | Separate Frigate container + HACS integration | Fully local |
Every component in that table can stay local for routine control. Local control, however, is a stack rather than a checkbox: an AdGuard Home instance forwards DNS to an upstream resolver you choose, NGINX exposes a service to the internet, and HACS needs internet for downloads even though an installed custom integration may later operate locally.
MQTT Infrastructure: Mosquitto and the Native MQTT Integration
Mosquitto is the MQTT broker—the service that receives and routes MQTT messages. Home Assistant's native MQTT integration is the client that turns MQTT discovery payloads and topics into devices, entities, triggers and commands. They are different layers, and Home Assistant's easiest supported path is the official Mosquitto broker App paired with the native MQTT integration.
The strongest reason to install Mosquitto is that a specific service or device requires MQTT. Zigbee2MQTT needs it for Home Assistant discovery. Frigate's Home Assistant integration requires the native MQTT integration for many entities. Tasmota, OpenMQTTGateway and DIY MQTT sensors all speak MQTT directly. If none of those apply, you do not need a broker.
On Home Assistant OS, install the official Mosquitto App and then add the native MQTT integration. Home Assistant can create and manage the broker credentials automatically. On Container, run Mosquitto as a separate service and point the same integration at its address. The current official App supports aarch64 and amd64, and the hardware cost is negligible on modern 64-bit hardware.
A local MQTT bus has a privacy advantage that cloud integrations cannot match: a MQTT-connected relay keeps working against the local broker even when internet access is down. Keep authentication enabled, use a dedicated account for external applications, and do not expose port 1883 to the public internet. Open issue reports—such as an amd64 startup segfault in Mosquitto App 7.1.0 on at least one HAOS system and an MQTT v5 migration report—are release-specific items to monitor, not reasons to avoid MQTT.
When this becomes useful in practice, a Zigbee door sensor can travel from Zigbee2MQTT to Mosquitto to Home Assistant and turn on a hallway light, while a DIY microcontroller publishes a water tank level and Home Assistant alerts below a threshold.
Zigbee: ZHA vs Zigbee2MQTT and the Coordinator You'll Need
Home Assistant has two local Zigbee paths: ZHA is built directly into Home Assistant and requires no external MQTT broker, while Zigbee2MQTT runs the Zigbee network as a separate service and translates devices into MQTT messages. The full Zigbee2MQTT path is coordinator → Zigbee2MQTT → Mosquitto → MQTT integration → Home Assistant.
Zigbee2MQTT generally exposes more device-specific settings, adds new devices faster, has stronger debugging tools, and can decouple the Zigbee service from Home Assistant Core. Its HA App currently supports 64-bit aarch64/amd64 and recommends at least a Raspberry Pi 4-class device. If you have a small network whose devices already work correctly in ZHA, there is no reason to migrate just because a listicle calls Zigbee2MQTT "better." A healthy ZHA network should not be rebuilt for fashion—migration involves re-pairing risk and rebuilding entity references.
The Zigbee2MQTT setup guide covers the full architecture, but the hardware rule is the same for both stacks: one compatible coordinator, and never the same coordinator for ZHA and Zigbee2MQTT simultaneously. A second radio is required to run two independent Zigbee stacks.
For coordinators, the SONOFF Zigbee 3.0 USB Dongle Plus-E is a budget Zigbee 3.0 adapter with an EFR32MG21 radio, +20 dBm transmit power and pre-flashed coordinator firmware. It is explicitly supported with Zigbee2MQTT and Home Assistant.
The official Home Assistant Connect ZBT-2 is a mid-range MG24 adapter that works with Zigbee2MQTT, but it must be dedicated to either Zigbee or Thread—one radio cannot run both protocols simultaneously.
Most Zigbee network failures are not protocol failures. Coordinator placement, USB interference, weak router density, Wi-Fi overlap and insufficient power can damage either stack. If ZHA already works with the devices you own, keep it. Use Zigbee2MQTT when you need obscure device settings, faster support for a niche device, or a Zigbee service that runs independently from Home Assistant. For protocol selection beyond Zigbee, see the Zigbee vs Z-Wave vs Matter comparison.
Z-Wave: The Z-Wave JS App and Native Integration
Z-Wave remains the strongest option for many locks, deadbolts, leak sensors, thermostats and detached-building sensors because the 800-series radios and Z-Wave Long Range extend reach in difficult locations. Home Assistant's current architecture is Z-Wave adapter → official Z-Wave JS App → native Z-Wave integration.
The official Z-Wave JS App is the HA OS successor to the older Z-Wave JS UI App, and Home Assistant provides an in-place migration procedure that does not require re-pairing devices. If you are running Home Assistant Container, the recommended server is the Z-Wave JS UI Docker container, after which Home Assistant connects through the same native Z-Wave integration. Old guides that say "install Z-Wave JS UI on HAOS for a new setup" are outdated.
The native Z-Wave integration is Local Push, so devices report state directly to Home Assistant without cloud polling. For new setups, Home Assistant recommends an 800-series adapter and currently lists the Connect ZWA-2 as its preferred choice. That adapter uses a Silicon Labs ZG23 800-series SoC and supports conventional Z-Wave plus Z-Wave Long Range simultaneously.
Direct USB connection is recommended because communication between the Z-Wave server and the adapter is latency-sensitive. Firmware also matters: Home Assistant currently recommends SDK 7.23.x or newer and warns against several older SDK branches on third-party adapters.
A Z-Wave network opens local deadbolt user-code management, leak-sensor shutoff automations, garage contact monitoring, thermostat scheduling, and multi-tap wall-switch scenes without a vendor account. There is no reason to expose any of that to a cloud.
ESPHome: Building Local Sensors Without MQTT
ESPHome generates device firmware from YAML and supports ESP32, ESP8266, BK72xx, RP2040, RTL87xx and other microcontrollers. Home Assistant's ESPHome integration talks directly to devices over ESPHome's native API, so MQTT is optional rather than a prerequisite.
The most important correction to old tutorials is that ESPHome does not require a broker. Its recommended Home Assistant integration uses the native API over a persistent connection, and devices push state changes to Home Assistant instead of being polled. The default native API port is 6053, and current configurations favor Noise pre-shared-key encryption because older password-based API authentication is deprecated.
On Home Assistant OS, install the ESPHome Device Builder App and the automatically discovered native ESPHome integration. On Container, run the Device Builder separately and use the same integration. Device-to-Home Assistant operation is fully local; internet access can help the first time you compile or download packages, but normal control does not require a vendor cloud.
ESPHome is especially useful when no commercial sensor exists for a niche: a DIY mmWave bed-occupancy sensor, a BLE proxy forwarding nearby Bluetooth sensor data, a garage-door position sensor plus relay, a water or electricity meter pulse counter, HVAC temperature probes, or soil-moisture irrigation control. The tradeoff is ownership—you become the hardware and firmware maintainer. For a standard commodity door sensor, a Zigbee device is often less work.
HACS: Install It Only for a Specific Custom Integration
HACS is the Home Assistant Community Store, but it is not an App and contains no Apps. It is a custom integration and repository manager that installs community integrations, dashboard components, themes, templates, AppDaemon apps and Python scripts into custom_components/.
The correct decision tree is Core integration first, HACS only if a gap remains. Install HACS because you need Frigate's Home Assistant integration, Auto Backup, Battery Notes, LocalTuya, or a specific dashboard card—not because every tutorial says to install it. The full HACS installation guide covers the download App, restart, and integration setup.
HACS requires Home Assistant 2024.4.1 or newer, file-system and log access, stable internet, and outbound access to GitHub and Cloudflare. It is therefore mixed from a privacy perspective: discovery, download and update depend on a third-party service, while the behavior of each installed integration depends on that integration's own architecture.
Every custom integration increases the trust surface. Community code can contain credentials and run inside Home Assistant without the same review or support path as Core. Before installing an unfamiliar repository, check age, maintainers, issue activity, release history, requested permissions, and whether it asks for sensitive API tokens. Integration sprawl is a genuine failure mode in 2026, not a sign of expertise.
Node-RED: The Optional Visual Automation Runtime
Node-RED is a flow-based programming environment that can wire Home Assistant state nodes, service calls, JavaScript functions, timers and external APIs visually. It is a Community App, not an official Core App, and it adds a second automation runtime with its own backup and debugging surface.
The current Home Assistant native automation editor has closed much of the old gap. Trigger, condition and action automations now cover many complex branching and state-machine use cases, which means Node-RED is no longer a mandatory next step for advanced users. It remains the right choice if you think naturally in diagrams, already maintain flows, or need reusable flow-based logic independent of the Home Assistant UI.
Practical examples include an occupancy flow combining motion, mmWave, doors, illuminance, time and presence; dynamic electricity-price charging; a state machine for alarm or HVAC modes; or transforming JSON from a local API before updating Home Assistant. For normal trigger/condition/action automations, the Home Assistant automations guide is the better first stop.
Node-RED runs locally, so routine processing is local by default. Inspect any third-party nodes and external APIs as carefully as you would a HACS integration.
Matter Server: Running Matter Without Vendor Clouds
Matter is an application protocol that runs over Wi-Fi, Ethernet or Thread. It is not the same thing as Thread, and a Matter-over-Wi-Fi plug does not require a Thread Border Router. The Matter explained guide covers that distinction in depth.
Home Assistant's Matter integration connects over WebSocket to a separate Matter Server process that acts as the Matter controller and fabric manager. In 2026, Matter Server 9.0 replaced the older Python/C++ SDK with a matter.js-based implementation. On Home Assistant OS, adding the Matter integration through the recommended flow automatically installs the official Matter Server App.
For Matter-over-Wi-Fi or Ethernet, no Thread radio is required. For Matter-over-Thread, you need a Thread network and at least one Thread Border Router. The Home Assistant Connect ZBT-2 can operate as a Thread radio, but it must be dedicated to Thread rather than simultaneously serving Zigbee. The full Home Assistant Matter integration setup guide walks through onboarding.
Standalone Matter Server Docker use is documented but currently unsupported by Home Assistant. Do not present a Container Matter deployment as equivalent to the HA OS supported experience, especially for Matter-over-Thread. During the 9.0 migration, unusually long first startups were normal as data migrated to the new server format; allow the migration to finish rather than assuming a long "Starting" state is failure.
The payoff is local IP control. A Matter lock can trigger a presence or alarm routine, a local Matter plug can drive an energy-aware shutdown, and multi-admin sharing lets supported devices operate in both Home Assistant and an Apple or Google ecosystem without a vendor cloud dependency.
Local Voice with Wyoming: Speech-to-Phrase, Whisper and Piper
Wyoming is the protocol that connects local speech-to-text, text-to-speech and wake-word services to Home Assistant. The main supported components are Speech-to-Phrase, Whisper, Piper and openWakeWord, and the Home Assistant Voice setup guide covers the hardware and pipeline.
A fully local voice stack works like this: Speech-to-Phrase or Whisper converts speech to text, Home Assistant Assist interprets the command, and Piper converts the spoken response back to audio. openWakeWord adds optional local wake-word detection. When the entire pipeline is configured locally, spoken commands remain inside the home.
The choice between Speech-to-Phrase and Whisper is about compute, not correctness. Speech-to-Phrase is optimized for home-control phrases and processes commands quickly on modest HA hardware, but its closed vocabulary excludes some open-ended tasks. Whisper handles unrestricted speech better and requires materially more compute for fast transcription—stronger x86, Apple-silicon or Nvidia-class hardware becomes more relevant.
For deterministic home control, Speech-to-Phrase connected to Assist is often faster, cheaper and more deterministic than throwing a large Whisper model or local LLM at every command. You do not need a conversational AI model to say "turn off downstairs" or "what doors are open." A local voice satellite or microphone-compatible HA hardware supplies the room input; no Amazon voice-hardware SKU is needed here because the value sits in the software stack, not a single proprietary speaker.
Backups: Native Automation and Off-Device Storage
The native Backup integration is the 2026 baseline. It creates and restores Home Assistant backups and now works across installation types, with automatic scheduled backups configurable directly through the UI. Custom automations are no longer required for ordinary backup scheduling.
The one non-negotiable rule: a backup stored on the same physical boot disk is not disaster recovery. The privay-first destinations are a local second storage target, a NAS over NFS, a NAS over CIFS/SMB 2.1, or a remote self-hosted server through the native SFTP Storage integration. Home Assistant OS can mount NFS or CIFS through Settings → System → Storage; a target assigned Backup usage becomes selectable for manual and automatic backups, and the first such target becomes the default destination.
Native cloud options now include Google Drive, OneDrive, OneDrive for Business and Home Assistant Cloud. Google Drive stores backups in a dedicated Home Assistant folder; OneDrive has access to an application-specific folder; OneDrive for Business arrived in 2026.3 and requests broader Microsoft permissions. Those are cloud-dependent by definition. Old tutorials that push the community Google Drive Backup add-on for every user are outdated—native Google Drive backup already exists.
Auto Backup via HACS remains useful only when your retention logic or automations exceed native backup capability: generational retention, per-backup expiration, exclusions, USB-directory download, status sensors and lifecycle events are its real remaining value. For mainstream users, native automatic backup plus one off-device destination is the correct starting point.
AdGuard Home: Network-Wide DNS Filtering
AdGuard Home is a Community App that provides DNS-level ad and tracker filtering, configurable rules and parental controls without client software on each device. It is local in the sense that the service runs on your hardware, but DNS queries ultimately depend on whatever upstream resolver you configure. AdGuard Home alone does not magically make all DNS private.
This is a privacy layer for the entire LAN, not a magic shield. It can reduce some telemetry and ad domains used by IoT devices, expose AdGuard status and statistics to Home Assistant, disable blocking temporarily from a dashboard, and notify on DNS service outage. It cannot block ads embedded in the same domains or content streams, and it is not a substitute for network segmentation.
Because AdGuard Home becomes DNS infrastructure, reliability of the Home Assistant host matters more than raw compute. A misconfigured router or DHCP DNS setup can create loops or take down the entire home network. The 2024 high-CPU/reboot incident that circulated in older community reports is historical, but it illustrates the blast radius of placing DNS on the same machine as Home Assistant. A dedicated host or container running AdGuard Home—or Pi-hole—is arguably more resilient because a Home Assistant restart no longer takes DNS down with it.
NGINX: TLS Reverse Proxy When You Really Need Public Exposure
NGINX Home Assistant SSL proxy is an official Home Assistant App that runs NGINX as an SSL/TLS reverse proxy, accepting HTTPS externally and proxying to Home Assistant locally. The current official App supports aarch64 and amd64, with HTTP/1.1, HTTP/2 and optional HTTP/3/QUIC in the 4.5.1 configuration.
The key facts are that NGINX itself is local, but public HTTPS normally requires DNS, a domain, a TLS certificate and internet exposure. Home Assistant must be configured with the correct use_x_forwarded_for and trusted_proxies settings. This is a high-complexity path compared with Home Assistant Cloud or a simple VPN.
Self-hosted does not automatically mean safer. A misconfigured public reverse proxy increases attack surface, and casually forwarding the Home Assistant port to the internet is a bad idea. The privacy-first ranking is: local-only first, VPN when remote access is needed, then carefully configured reverse proxy only if a public domain and certificate management are justified. The Home Assistant remote access guide compares Nabu Casa Cloud, Tailscale, VPN and related options.
Advanced users sometimes pair NGINX with client certificates and firewall restrictions. Everyone else is better served by WireGuard or another private VPN before exposing the Home Assistant web UI.
Frigate: Local NVR and Camera Automations
Frigate is a self-hosted NVR built around local real-time object detection. The separate Frigate Home Assistant integration brings cameras, object sensors, snapshots, recording and detection switches, PTZ actions, events and media browsing into Home Assistant. It is one of the clearest ways to keep camera analysis and recordings local instead of sending video to Ring, Nest or other cloud AI services.
The architecture has two mandatory pieces: Frigate itself can run through its HA App repository or as a standalone Docker service, and the Home Assistant integration installs through HACS. Frigate's documentation also requires the native MQTT integration, because Frigate and Home Assistant should share the same MQTT broker for many entities to work.
The most important 2026 correction is accelerator advice. Frigate now explicitly states that Google Coral is no longer recommended for most new installs, except for particularly low-power systems or hardware unable to use newer accelerators. Supported alternatives include Hailo, OpenVINO, Nvidia and ROCm. If you already have Intel hardware, OpenVINO on an iGPU is often the first thing to test before buying an accelerator. The detailed Frigate + Home Assistant guide covers real-world deployment.
Cameras with H.264 plus AAC and usable substreams offer the strongest compatibility, because multiple substreams can separate low-resolution detection from high-resolution recording. Once configured, Frigate turns semantic detections into automation triggers: person detected on the driveway turns on exterior lights and sends a mobile snapshot, car entry prepares a garage routine, and package or animal detection replaces generic motion alerts.
Which Add-ons Should You Actually Install?
The answer depends on the devices you own and the problems you are solving, not on a count.
Minimal local Zigbee home: Start with ZHA or Zigbee2MQTT, a coordinator, and the best Zigbee coordinators and dongles for your layout. Add Mosquitto only if you choose Zigbee2MQTT or another MQTT-dependent service. Skip Node-RED, AdGuard, NGINX and Frigate until there is a concrete reason.
Z-Wave-first home: Run the official Z-Wave JS App and native Z-Wave integration with an 800-series adapter. Use a local backup target from day one. Skip Zigbee2MQTT unless you also use Zigbee devices.
Camera and presence home: Deploy Frigate with MQTT, test an existing Intel iGPU or OpenVINO path before buying an accelerator, and avoid Google Coral for new builds. The automation payoff is person alerts rather than generic motion.
Voice-first home: Use Wyoming with Speech-to-Phrase first, Piper for responses, and add Whisper or a local LLM only if you need unrestricted speech. A Home Assistant Voice setup guide will keep the pipeline local.
Privacy-remote user: Configure native automatic backups to a NAS or SFTP target before enabling any remote access. Prefer WireGuard or Tailscale over NGINX unless you have a domain and certificate workflow already running.
The anti-pattern to avoid is the "25 must-have Apps" install session. Every additional App, custom integration or MQTT broker adds updates, logs, dependencies and another failure surface. The strongest local-control stack is the smallest stack that solves your actual device and automation needs.
Frequently Asked Questions
Q: What is the difference between a Home Assistant App and an integration?
An App is a standalone service running alongside Home Assistant, installed through Settings → Apps on Home Assistant OS. An integration connects Home Assistant to a device or service, such as the native MQTT, Z-Wave, ESPHome or Matter integrations.
Q: Is Zigbee2MQTT better than ZHA?
Not inherently. Zigbee2MQTT generally exposes more device-specific settings and gains support for new devices faster, while ZHA has fewer moving parts because it is built into Home Assistant and needs no MQTT broker. If your devices already work correctly in ZHA, there is no reason to migrate.
Q: Do I need MQTT for ESPHome?
No. ESPHome's recommended Home Assistant integration uses its own native API over a persistent connection, not MQTT. MQTT is an optional alternative, not a prerequisite.
Q: What replaced the old "Z-Wave JS UI" App on Home Assistant OS?
The official Z-Wave JS App is the HA OS successor to Z-Wave JS UI, and Home Assistant provides an in-place migration path that does not require re-pairing devices. Container users should use the Z-Wave JS UI Docker container.
Q: Does a Matter device always need Thread?
No. Matter can run over Wi-Fi, Ethernet or Thread. Only Matter-over-Thread devices require a Thread Border Router; Matter-over-Wi-Fi devices do not.
Q: Should I still buy a Google Coral for Frigate?
No longer as a default. Frigate now recommends testing existing Intel iGPU or OpenVINO hardware first, and lists Hailo, OpenVINO, Nvidia and ROCm as supported alternatives. Coral remains a niche low-power option, not the universal Frigate accelerator.
Q: Is local voice fully private?
If you configure Speech-to-Phrase or Whisper, Assist, Piper and optionally openWakeWord all locally, spoken commands can stay inside your home. If you use Home Assistant Cloud speech services, you introduce a cloud dependency and subscription.
Conclusion
The strongest Home Assistant installation in 2026 is not the one with the most Apps. It is the one whose components map cleanly to the devices you own and the automations you actually run. Native integrations should come first, community custom integrations only when a specific gap remains, and every additional service should either solve a local-control problem or not be installed at all.
Start with the Home Assistant beginner's guide for installation basics, then move through Zigbee vs Z-Wave vs Matter for protocol decisions. If you run cameras, the Frigate + Home Assistant guide will save more time than any generic add-on list.
For most users, the optimal path is a short local stack: one radio protocol, one coordinator, native backups off-device, and optional local voice. Build from need, not from a list.
