O que você vai precisar
Passo a passo
1. Escreva a automação em uma frase
Dica: Use o formato: quando X acontecer, se Y for verdadeiro, faça Z.2. Escolha um gatilho específico
Dica: Quando possível, use duração: porta aberta por 3 minutos, potência baixa por 5 minutos.3. Adicione uma condição principal
Dica: Teste antes de empilhar várias condições.4. Configure ações curtas
Dica: Ações repetidas em várias automações quase sempre merecem script.5. Use o trace para depurar
Dica: Trace economiza tentativa e erro.6. Teste exceções
Dica: Automação não testada é palpite com botão bonito.
alias: "Luz inteligente sem neutro"
description: "Automação para acender a luz ao detectar movimento"
trigger:
- platform: state
entity_id: binary_sensor.presenca_corredor
to: "on"
condition:
- condition: state
entity_id: sun.sun
state: below_horizon
action:
- service: light.turn_on
target:
entity_id: light.luz_corredorAutomação ruim parece assombração. A luz acende quando ninguém pediu, o ar-condicionado desliga com gente no quarto, a notificação chega três vezes e ninguém sabe qual regra fez aquilo. O Home Assistant não é culpado sozinho. A maioria desses fantasmas nasce de automação escrita sem pensar em gatilho, condição, ação e exceção. O editor visual ajuda muito, mas ele não impede raciocínio torto. Ele só deixa o erro mais bonito.
A automação boa tem uma frase simples por trás. Quando a porta da lavanderia ficar aberta por mais de 3 minutos, se for depois das 22h e houver alguém em casa, envie aviso no celular. Repare que a frase já carrega quase tudo: gatilho, tempo, condição e ação. Se você não consegue explicar a automação em voz alta, ela provavelmente está confusa. Antes de clicar no editor, escreva a frase. Papel aceita rascunho melhor que painel de produção.
Gatilho é o acontecimento, não a intenção#
Gatilho é o que inicia a automação. Movimento detectado, porta aberta, horário chegou, potência passou de 1.500 W, celular entrou na zona casa, botão foi pressionado. Ele não diz se a ação deve acontecer; só chama a regra para avaliação. Esse ponto evita muita confusão. “Quando anoitecer” é gatilho. “Se a sala estiver escura” pode ser condição. “Acender a luz” é ação. Misturar esses papéis cria automação que funciona por sorte.
Use gatilhos específicos. Em vez de “qualquer mudança no sensor de presença”, prefira “sensor mudou para detected”. Em vez de “estado da porta mudou”, prefira “porta ficou aberta por 2 minutos”. O Home Assistant permite colocar duração em muitos gatilhos, e isso reduz falso positivo. Porta aberta por 1 segundo não merece notificação. Porta aberta por 5 minutos às 23h talvez mereça. A casa precisa reagir a eventos relevantes, não a espirros de estado.
Condição é o freio que salva a automação#
Condição responde: agora faz sentido executar? Uma automação de luz por presença pode ter condição de sol abaixo do horizonte, iluminância menor que 80 lux ou horário entre 18h e 6h. Uma automação de ar-condicionado pode exigir janela fechada, presença no quarto e temperatura acima de 25 °C. Condição é onde a casa deixa de ser controle remoto automático e começa a parecer esperta. Sem condição, qualquer sensor vira criança apertando botão.
O erro clássico é criar condição demais sem testar uma por vez. Você adiciona horário, presença, modo casa, luminosidade, janela, feriado e bateria, e depois reclama que nada dispara. Comece com uma condição central, teste, olhe o trace da automação e só então refine. O trace é seu amigo: ele mostra por onde a regra passou, qual condição falhou e qual ação executou. Iniciante que aprende trace cedo economiza noites inteiras.
Ação precisa ser curta ou virar script#
Ação é o que acontece. Ligar luz, ajustar brilho, enviar notificação, esperar, chamar cena, executar script, desligar tomada. Se a ação tem cinco linhas, tudo bem. Se tem 25, com esperas, escolhas e notificações, talvez ela devesse virar script. Script organiza procedimentos reutilizáveis. Por exemplo, Boa noite pode desligar luzes, ativar alarme, reduzir ar-condicionado e avisar portas abertas. Várias automações podem chamar esse script, em vez de repetir a mesma sequência em lugares diferentes.
Também evite automação que briga com automação. Uma regra acende a luz do corredor por movimento; outra apaga quando a TV liga; outra acende ao abrir a porta; outra muda brilho ao anoitecer. Sem um modo ou helper coordenando isso, uma desfaz a outra. O usuário sente como instabilidade, mas é só conflito lógico. Home Assistant executa o que você mandou. Se você mandou ordens contraditórias, ele obedece todas.
Blueprints ajudam, mas não terceirizam entendimento#
Blueprint é uma automação pronta da comunidade que você configura com seus dispositivos. Para iniciante, é uma ótima entrada. Você escolhe o sensor, a luz, o tempo e alguns parâmetros, e o Home Assistant monta a lógica. Use blueprints para aprender padrões: botão de quatro cliques, sensor de movimento com temporizador, aviso de bateria baixa. Só não trate blueprint como caixa preta eterna. Se algo falhar, você ainda precisa entender gatilho, condição e ação.
Minha recomendação: use blueprint para casos repetitivos e bem conhecidos. Para automações que expressam rotina da sua casa, escreva no editor visual. A rotina tem detalhe pessoal: bebê dormindo, cachorro no corredor, sol batendo na janela da cozinha, gente que trabalha de madrugada. Blueprint genérico não conhece essas manias. Ele dá base. A casa de verdade pede ajuste fino.
A primeira automação que vale fazer#
Escolha uma automação pequena e útil: luz de corredor por presença à noite. Gatilho: sensor de presença detectou movimento. Condição: sol abaixo do horizonte ou iluminância baixa. Ação: acender luz em 40%. Depois, espere 2 minutos sem movimento e apague. Parece simples, mas ensina quase tudo. Você aprende entidade, área, estado, tempo, condição e ação reversa. Também aprende a lidar com o incômodo real: a luz apagou cedo demais? Aumente o tempo. Acendeu durante o dia? Ajuste luminosidade.
Não comece com “modo cinema que controla TV, receiver, cortina, luz, ar, notificação e portão”. Comece com corredor. Casa inteligente madura nasce de automações pequenas que sobrevivem ao cotidiano. O corredor vai denunciar sensor lento, posicionamento ruim, entidade errada e lógica mal pensada. Melhor descobrir isso no corredor do que na automação da fechadura.
Use helpers para dar contexto#
Helpers entram quando a casa precisa entender modos. Modo visita, modo sono, modo limpeza, modo férias. Sem eles, você tenta inferir contexto por sinais tortos: se TV ligada, se horário tal, se luz tal. Às vezes funciona, às vezes cria comportamento bizarro. Um input_boolean chamado Modo visita pode impedir automações agressivas enquanto há gente em casa. Um input_select chamado Estado da casa pode alternar Casa, Ausente, Sono e Viagem. Simples. Poderoso.
O segredo é não exagerar. Dois ou três modos bem usados valem mais que 12 estados que ninguém lembra. Helper deve aparecer no dashboard ou ser controlado por regra clara. Se ele fica escondido, vira variável fantasma. A pessoa da casa precisa saber por que uma automação mudou comportamento. Se só você entende, ainda não está bom.
Notificação boa incomoda pouco#
Notificação é onde muita automação vira spam. Porta abriu, porta fechou, porta abriu, porta fechou. Em dois dias, todo mundo ignora. Notificação boa tem atraso, prioridade e texto útil. “Porta da lavanderia aberta há 5 minutos” é melhor que “porta aberta”. “Máquina de lavar terminou: consumo caiu para menos de 5 W por 3 minutos” é melhor que “tomada mudou”. Coloque informação acionável. Se a pessoa não sabe o que fazer depois de ler, a notificação está mal escrita.
Use cooldown quando necessário. Se a automação já avisou uma vez, espere 15 ou 30 minutos antes de avisar de novo. Para alertas críticos, use canal diferente, som diferente ou notificação persistente. Não misture aviso de bateria baixa com vazamento de água no mesmo peso. A casa deve falar pouco. Quando falar, precisa valer a interrupção.
Teste como se você quisesse quebrar#
Depois de criar automação, teste os caminhos. Gatilho verdadeiro com condição verdadeira. Gatilho verdadeiro com condição falsa. Dispositivo indisponível. Internet fora, se a regra depende de serviço externo. Reinício do Home Assistant. Parece excesso até a primeira regra falhar no fim de semana. O editor visual deixa criar automação rápido; o teste é o que torna a automação confiável.
E mantenha automações curtas. Se o nome não explica, renomeie. Se a ação ficou longa, vire script. Se há exceção demais, crie helper. Se duas regras brigam, junte ou defina prioridade por modo. Automação boa não precisa ser esperta o tempo todo. Ela precisa ser previsível. Casa que surpreende demais parece mágica no primeiro dia e defeito no segundo.
Separe também automação de rotina e automação de segurança. Rotina pode falhar sem estrago: uma luz acende atrasada, uma notificação chega depois, uma cena não muda brilho. Segurança pede redundância, teste e lógica simples. Vazamento, fumaça, porta externa e carga elétrica alta não devem depender de uma corrente longa de condições frágeis. Quanto mais séria a consequência, menos malabarismo a regra deve ter.
Depois de uma semana, revise o histórico. Veja quantas vezes a automação disparou, em que horários e se alguém da casa reclamou. Automação boa some no cotidiano; ninguém comenta porque ela fez o que deveria. Automação ruim vira assunto de jantar. Se a família cria apelido irritado para uma regra, conserte. O melhor sensor do mundo perde para uma regra mal educada.
No sétimo dia, a automação já existe. Falta a parte que todo mundo quer mexer cedo demais: dashboards. A tela boa não mostra tudo; mostra o que a casa precisa para ser usada sem manual.