Home Assistant: Três anos depois

Artigo original ↗ Discussão no Hacker News ↗

O Home Assistant é elogiado como uma forma poderosa de unificar dispositivos de casa inteligente e manter o controle local, mas muitos usuários descrevem uma troca entre flexibilidade e sobrecarga contínua de manutenção. Os comentaristas destacam pontos recorrentes de dor como armazenamento frágil em Raspberry Pis, mudanças que quebram coisas com atualizações frequentes, hardware Zigbee/Z-Wave instável e os riscos de dispositivos dependentes da nuvem. Há amplo apoio a padrões como Matter e a configurações local-first, mas permanece o ceticismo sobre confiabilidade de longo prazo, implantação profissional e quanto de complexidade vale a pena introduzir em funções centrais da casa como aquecimento, iluminação e segurança.

Controle remoto e troca de energia do watchdog

  • Para reiniciar dispositivos remotamente em outro local, muitos consideram aceitáveis as tomadas inteligentes baseadas na nuvem, já que uma queda de internet bloqueia qualquer solução.
  • Alternativas sugeridas: TP-Link Kasa (protocolo TCP local simples), tomadas Sonoff/Shelly com ESPHome/Tasmota, tomadas controladas por SMS/GSM e cabos de alimentação dedicados de “watchdog” que ciclam após falha de ping (embora alguns os achem caros demais).

Padrões de adoção e escolhas de implantação

  • Vários migraram de outras plataformas (OpenHAB, Homebridge, X10, apps de fornecedores) e acharam o HA consideravelmente mais capaz, especialmente para configurações complexas/off-grid.
  • Implantações comuns: contêineres Docker, VMs e caixas dedicadas com HAOS; alguns preferem ZFS, Proxmox ou armazenamento apoiado por NFS para resiliência.
  • Add-ons como o HACS dão extensibilidade estilo HAOS no Docker, embora a configuração possa ser trabalhosa.

Automações vs dashboards e filosofia de UX

  • Há um forte sentimento de que, se você usa regularmente um dashboard para controlar dispositivos, o design das automações está falhando; switches, sensores e presença deveriam lidar com a maior parte do comportamento.
  • Outros valorizam dashboards para monitoramento (por exemplo, energia, status da casa toda) e controles em massa (por exemplo, “desligar todas as luzes”).
  • Alguns executam automações muito “leves”; outros automatizam agressivamente iluminação, HVAC e “modos” (casa/ausente/convidado).

Interruptores, cenas e estado mecânico vs digital

  • O desejo por interruptores físicos que sempre reflitam o estado real das luzes leva à discussão sobre interruptores sem estado/momentâneos, dimmers capacitivos/à base de LED e configurações com botões e relés.
  • Muitos argumentam que a luz do cômodo é o indicador relevante; a simetria da posição mecânica é, em grande parte, uma preocupação estética.

Protocolos: Zigbee, Z-Wave, Matter, outros

  • Zigbee e Z-Wave são amplamente usados; Z-Wave é visto como mais caro e mais exigente em energia, mas confiável, com menos tipos de dispositivos.
  • Alguns preferem Zigbee2MQTT ao ZHA do HA por suporte mais amplo a dispositivos e maior flexibilidade, ao custo de complexidade extra.
  • As opiniões sobre Matter são mistas: otimismo com o controle local e o suporte multi-ecossistema vs frustração de que os dispositivos Matter atuais muitas vezes expõem menos recursos (por exemplo, faltam métricas de energia) e parecem imaturos.

Confiabilidade, atualizações e armazenamento

  • As experiências variam de “à prova de falhas por anos” a “cada atualização corre o risco de quebrar algo”, especialmente em setups pesados em YAML ou mais antigos.
  • Cartões SD em Raspberry Pis são amplamente considerados pouco confiáveis para armazenamento de HA a longo prazo; as recomendações incluem SSDs, boot por USB, NAS ou hipervisores com snapshots e backups.
  • Alguns usuários atualizam mensalmente e acompanham as notas de lançamento; outros atrasam as atualizações e aceitam catch-ups dolorosos em várias versões.

Instaladores profissionais e viabilidade de longo prazo

  • Vários participantes veem uma lacuna: pessoas com sistemas legados ou complexos querem integração profissional com HA, mas o ecossistema de serviços é escasso.
  • As razões citadas incluem mudanças rápidas, atualizações que quebram coisas, integrações de terceiros fora do controle do instalador, forte acoplamento entre backend e frontend e grande carga de suporte.
  • As sugestões incluem uma trilha de release LTS/estável e uma separação mais clara entre “plataforma” e UI personalizada, mas isso exigiria esforço substancial.

Nuvem vs local-first

  • Há uma forte preferência no tópico por controle local para evitar lock-in de fornecedor, indisponibilidades, banimentos nos termos de serviço e descontinuação de produtos.
  • Alguns ainda pagam pelo cloud do HA para acesso remoto fácil, ou dependem de serviços de voz na nuvem, citando restrições de tempo e melhor precisão do que opções no dispositivo.
  • Experiências passadas com fornecedores que inutilizaram ou degradaram produtos levam muitos a hardware aberto e controlável localmente (muitas vezes via Zigbee + HA).

Segurança, watchdogs e modos de falha

  • Há preocupação com automações controlando estados “absolutos” como setpoints de aquecimento ou carga de bateria sem salvaguardas independentes.
  • Padrão recomendado: deixar o HA escolher modos ou cronogramas, mas manter termostatos/ lógicas de segurança independentes no dispositivo.
  • Notificações de perda de contato, baixa temperatura ou falha do dispositivo são vistas como essenciais para sistemas críticos.

UI, dashboards e curva de aprendizado

  • O dashboard de Energia do HA é elogiado por ser polido; a criação de dashboards em geral é vista como poderosa, mas intimidadora e demorada.
  • Pedidos por melhores padrões, assistentes de configuração, UIs baseadas em planta baixa e até mapeamento de “gêmeo digital” baseado em LiDAR refletem o desejo por menos configuração “tijolo por tijolo”.