Antes de tudo, confira
- Verifique se o dispositivo tem energia ou bateria suficiente.
- Veja se a entidade volta sozinha após reinício ou queda de rede.
- Cheque logs do Home Assistant e da integração usada.
- Confirme sinal Wi‑Fi, Zigbee ou Matter/Thread no ponto real.
- Revise templates para não calcular com valor unavailable ou unknown.
- Use histórico para descobrir se é falha pontual ou recorrente.
Soluções, da mais provável à menos
Filtrar estados inválidos
Por que acontece: Automação trata unavailable como mudança real.
- Adicione condição para ignorar from/to unavailable e unknown.
- Use for: em gatilhos de estado para evitar disparo por oscilação curta.
- Em templates, defina availability antes de calcular.
- Teste reiniciando o Home Assistant.
Corrigir rede e alimentação
Por que acontece: Dispositivo some por sinal fraco, bateria baixa ou fonte instável.
- Troque bateria se houver quedas frequentes.
- Aproxime roteador Zigbee ou adicione repetidor alimentado.
- Afaste dongle Zigbee de porta USB 3.0 e fontes ruidosas.
- Meça fonte de dispositivos Wi‑Fi e hubs.
Criar alerta de indisponibilidade persistente
Por que acontece: Falha recorrente fica mascarada no painel.
- Crie automação que avise se entidade crítica ficar unavailable por 5 a 15 minutos.
- Separe alerta crítico de ruído momentâneo.
- Inclua nome da entidade, cômodo e duração no aviso.
- Revise semanalmente entidades com maior indisponibilidade.
Adicionar redundância em funções críticas
Por que acontece: Um único sensor define ação importante.
- Combine dois sensores ou sensor mais estado do ambiente.
- Evite comando perigoso baseado em uma entidade instável.
- Use fallback manual para luz, fechadura, portão e alarme.
- Documente o comportamento de falha.
Unavailable não é erro cosmético. É o sistema dizendo: “eu conheço essa entidade, mas não consigo confiar no valor dela agora”.
O primeiro marco é a inicialização. Depois de reiniciar o Home Assistant, algumas entidades voltam antes de outras. Sensores Zigbee acordam no tempo deles. Integrações em nuvem demoram. Templates calculam em cima de dados que ainda não chegaram. O segundo marco é a falha curta: Wi‑Fi pisca, coordenador Zigbee reinicia, API responde lento. O terceiro é o defeito persistente: bateria acabou, dispositivo morreu ou integração quebrou.
A dor real aparece quando uma automação trata unavailable como se fosse evento legítimo. Sensor de temperatura vira unavailable e o aquecedor desliga. Fechadura deixa de reportar estado e o painel fica vermelho. Medidor de energia some por 2 segundos e cria gráfico absurdo.
Não confunda silêncio com dado.
Por que aparece unavailable?#
Aparece quando o Home Assistant não consegue obter ou atualizar o estado de uma entidade existente. Em Zigbee, pode ser roteador de malha ruim, bateria fraca ou interferência em 2,4 GHz. Em Wi‑Fi, roteador saturado ou RSSI fraco. Em nuvem, API fora do ar. Em template, cálculo com fonte indisponível.
Qual a diferença entre unknown e unavailable?#
Unknown costuma aparecer quando o estado ainda não foi determinado. Unavailable aparece quando o sistema sabe da entidade, mas ela não está disponível. Na prática, ambos pedem automação defensiva: antes de calcular, mandar comando ou disparar alerta, verifique se o valor é válido.
Como mitigar no dia a dia?#
Comece pelo físico: energia, bateria, sinal, roteadores Zigbee e distância do hub. Depois corrija templates com disponibilidade explícita. Em automações, ignore transições vindas de unavailable quando elas não representam evento real. Para sensores críticos, use redundância ou lógica de confirmação.
Quando escalar?#
Se a mesma entidade some várias vezes ao dia, não é “normal do sistema”. É problema de rede, alimentação, firmware, integração ou arquitetura. O Home Assistant consegue conviver com falha curta; casa inteligente séria não deveria depender de entidade que vive desaparecendo.
O objetivo não é zerar todo unavailable. É impedir que uma falha transitória vire automação errada, e que uma falha recorrente fique invisível.