Home Assistant: Three years later

Original Article ↗ Hacker News Discussion ↗

Home Assistant is praised as a powerful way to unify smart home devices and keep control local, but many users describe a trade-off between flexibility and ongoing maintenance overhead. Commenters highlight recurring pain points such as fragile storage on Raspberry Pis, breaking changes with frequent updates, flaky Zigbee/Z-Wave hardware, and the risks of cloud-dependent devices. There’s broad support for standards like Matter and local-first setups, yet skepticism remains about long-term reliability, professional deployment, and how much complexity is worth introducing into core home functions like heating, lighting, and security.

Remote control and watchdog power switching

  • For remotely rebooting devices at another location, many see cloud-based smart plugs as acceptable since an internet outage blocks any solution.
  • Alternatives suggested: TP-Link Kasa (simple local TCP protocol), Sonoff/Shelly plugs flashed with ESPHome/Tasmota, SMS/GSM-controlled plugs, and dedicated “watchdog” power cables that cycle on ping failure (though some find them too expensive).

Adoption patterns and deployment choices

  • Several migrated from other platforms (OpenHAB, Homebridge, X10, vendor apps) and found HA markedly more capable, especially for complex/off-grid setups.
  • Common deployments: Docker containers, VMs, and dedicated HAOS boxes; some favor ZFS, Proxmox, or NFS-backed storage for resilience.
  • Add-ons like HACS give HAOS-like extensibility in Docker, though setup can be fiddly.

Automations vs dashboards and UX philosophy

  • Strong sentiment that if you regularly use a dashboard to control devices, the automation design is lacking; switches, sensors, and presence should handle most behavior.
  • Others value dashboards for monitoring (e.g., energy, whole-house status) and bulk controls (e.g., “turn off all lights”).
  • Some run very “light-touch” automations; others aggressively automate lighting, HVAC, and “modes” (home/away/guest).

Switches, scenes, and mechanical vs digital state

  • Desire for physical switches that always reflect the true state of lights leads to discussion of stateless/momentary switches, capacitive/LED-based dimmers, and button-based setups with relays.
  • Many argue the room’s light is the relevant indicator; mechanical position symmetry is mostly an aesthetic concern.

Protocols: Zigbee, Z-Wave, Matter, others

  • Zigbee and Z-Wave are widely used; Z-Wave is seen as pricier and more power-hungry but reliable, with fewer device types.
  • Some prefer Zigbee2MQTT over HA’s ZHA for broader device support and flexibility, at the cost of extra complexity.
  • Matter opinions are mixed: optimism about local control and multi-ecosystem support vs frustration that current Matter devices often expose fewer features (e.g., energy metrics missing) and feel immature.

Reliability, updates, and storage

  • Experiences range from “rock solid for years” to “every update risks breaking something,” especially for YAML-heavy or older setups.
  • SD cards on Raspberry Pis are widely regarded as unreliable for long-term HA storage; recommendations include SSDs, USB boot, NAS, or hypervisors with snapshots and backups.
  • Some users update monthly and follow release notes; others delay updates and accept painful multi-version catch-ups.

Professional installers and long-term viability

  • Multiple posters see a gap: people with legacy or complex systems want professional HA integration, but a service ecosystem is scarce.
  • Reasons cited: rapid change, breaking updates, third-party integrations outside installer control, tight coupling between backend and frontend, and high support burden.
  • Suggestions include an LTS/stable release track and clearer separation of “platform” vs custom UI, but this would require substantial effort.

Cloud vs local-first

  • Strong preference in the thread for local control to avoid vendor lock-in, outages, ToS bans, and product shutdowns.
  • Some still pay for HA’s cloud for easy remote access, or rely on cloud voice services, citing time constraints and better accuracy than on-device options.
  • Past experiences with vendors bricking or degrading products drive many toward open, locally controllable hardware (often via Zigbee + HA).

Safety, watchdogs, and failure modes

  • Concern about automations controlling “absolute” states like heating setpoints or battery charge without independent safeguards.
  • Recommended pattern: let HA choose modes or schedules, but keep independent thermostats/safety logic on the device.
  • Notifications for lost contact, low temperature, or device failure are seen as essential for critical systems.

UI, dashboards, and learning curve

  • HA’s Energy dashboard is praised as polished; general dashboard creation is viewed as powerful but daunting and time-consuming.
  • Requests for better defaults, setup wizards, floorplan-based UIs, and even LiDAR-based “digital twin” mapping reflect a desire for less “brick-by-brick” configuration.