Automações
Bloco If-Then
Estrutura de controle condicional, o bloco If-Then avalia uma condição e executa a sequência Then quando o resultado é verdadeiro; implementações modernas também oferecem Else. Presente desde linguagens estruturadas consolidadas nos anos 1960, aparece em Home Assistant, Node-RED e controladores lógicos. Comparado ao Choose, é mais direto para uma decisão binária. A limitação surge quando muitos níveis são aninhados: legibilidade, trace e manutenção degradam, favorecendo choose, scripts ou máquinas de estado.
⚙ Definição Técnica
Bloco If-Then é uma estrutura de controle que avalia uma condição booleana no ponto em que a execução a alcança e, conforme o resultado, executa uma sequência principal ou segue por caminho alternativo. Pertence à família das estruturas condicionais das linguagens de programação e foi incorporado aos motores de automação para representar decisões binárias de forma explícita. Em Home Assistant, ações do tipo if podem conter conditions, then e else; no Node-RED, a mesma lógica pode ser montada com nós Switch e Change; em controladores IEC 61131-3, IF…THEN…ELSE aparece em Structured Text. A forma é simples, mas precisa de tratamento para dados indisponíveis, efeitos colaterais, concorrência e aninhamento.
Tipos comuns de gatilhos
If-Then simples sem Else
A condição é avaliada. Se verdadeira, a sequência executa. Se falsa, o fluxo continua depois do bloco sem ação alternativa. É adequado para passos opcionais, como enviar notificação apenas quando ninguém está em casa. A condição deve ser clara e barata. Se a sequência altera o estado usado na condição, isso não muda o resultado já calculado, salvo se o motor reavaliar explicitamente. Um erro comum é esperar que o bloco aguarde a condição ficar verdadeira; ele não aguarda. Para isso, use wait template, wait for trigger ou loop. O bloco decide no instante. O trace deve mostrar false e o salto. Ausência de Else não é falha.
If-Then-Else binário
Uma de duas sequências é escolhida. Exemplo: se iluminância < 50 lux, ligar a luz; caso contrário, abrir a cortina. A lógica é fácil de ler quando os caminhos são realmente mutuamente exclusivos. Ações precisam ser idempotentes. Se duas execuções paralelas avaliam estados diferentes, podem competir. O modo da automação e bloqueios importam. O Else cobre todo resultado não verdadeiro, incluindo eventualmente unknown ou erro convertido, o que pode ser perigoso. É melhor separar indisponibilidade em condição anterior ou usar expressão ternária com estado explícito. O caminho alternativo não deve ser tratado automaticamente como “seguro” sem analisar dados ausentes.
If-Then com múltiplas condições AND
Várias condições precisam ser verdadeiras: presença, horário e janela fechada. Motores geralmente interpretam lista como AND. O bloco é adequado quando todas fazem parte de uma única decisão. A ordem pode influenciar desempenho e diagnóstico. Coloque verificações de disponibilidade antes de cálculos. Alguns motores curto-circuitam no primeiro false; outros avaliam tudo. Se uma condição tem efeito colateral, o desenho está errado: condições devem ser puras. O trace deve mostrar qual falhou. Para lógica extensa, agrupe e nomeie. Repetir a mesma lista em vários blocos cria divergência futura; centralize em sensor derivado ou script.
If-Then com grupo OR e negação
A condição pode ser composta: se fumaça OU calor alto, então alertar; se NÃO houver manutenção ativa, executar. Parênteses e grupos precisam tornar a precedência explícita. Linguagens visuais ajudam, mas aninhamento excessivo confunde. Uma regra de segurança deve preferir expressões positivas, como sistema_operacional, a múltiplas negações. Teste todas as combinações. Em OR, uma fonte falsa positiva pode acionar; em AND, uma fonte indisponível pode bloquear. O desenho depende da consequência. Sensores independentes e certificação são necessários para funções de segurança; um If-Then genérico não substitui central de alarme ou detector certificado.
If-Then aninhado
Um bloco dentro de Then ou Else cria árvore de decisão. Isso permite lógica rica, mas o custo cresce rapidamente. Três níveis geram vários caminhos e dificultam trace. Use quando cada nível representa refinamento natural e limitado. Para mais de três alternativas, Choose tende a ser mais claro. Para estados persistentes e transições, máquina de estados é melhor. Para sequências reutilizadas, scripts. Em YAML, indentação incorreta pode alterar estrutura. O editor visual reduz sintaxe, mas não resolve complexidade semântica. Documente cada ramo e adote nomes. Métricas por caminho ajudam a identificar ramos nunca usados.
Considerações de Implementação
Else pode absorver indisponibilidade como se fosse condição oposta
Se a condição verifica sensor == on e o sensor está unavailable, o resultado pode ser false e executar Else. Isso não significa off. A distinção é crítica. Use três estados: verdadeiro, falso e desconhecido. Antes do If, valide disponibilidade. Ou use Choose com ramos on, off e default. Em ações de segurança, o default deve falhar fechado ou alertar, conforme política. Nunca presuma que “não verdadeiro” equivale ao estado contrário. Teste reinício e perda de conexão, porque esses estados aparecem na prática.
Aninhamento profundo reduz auditabilidade e aumenta erros
Cada nível multiplica caminhos. Alterar uma condição pode afetar ramos distantes. O trace fica longo. Reuso diminui. Limite a profundidade. Extraia decisões para helpers, sensores binários, scripts ou choose. Uma regra com muitos estados talvez seja máquina de estados. Controle de versão e revisão são recomendáveis. O objetivo não é evitar If-Then, mas manter cada bloco responsável por uma decisão. Nomes descritivos e comentários ajudam. Se uma pessoa não consegue explicar os caminhos sem abrir o editor, a estrutura precisa ser simplificada.
A avaliação ocorre no momento da chegada ao bloco
Depois de delays, waits e chamadas externas, o estado pode ter mudado. Isso pode ser desejado. Se o fluxo precisa da decisão baseada no evento original, capture a variável antes. Se precisa da realidade atual, reavalie. Exemplo: movimento inicia, espera 5 min e If verifica presença antes de apagar luz. A reavaliação evita apagar com ocupação. Em outro caso, preço de energia no início deve permanecer constante para contabilização. A semântica temporal precisa ser documentada. Concorrência pode gerar avaliações simultâneas com resultados distintos.
Ações dos ramos devem convergir a estados conhecidos
Use turn_on, turn_off, set_temperature e select_option em vez de toggle quando possível. Isso torna repetição segura. Se Then e Else comandam o mesmo dispositivo, considere histerese para evitar alternância rápida. Registre o ramo escolhido e o resultado. Falha numa ação deve ter tratamento. O bloco não garante transação: algumas ações podem concluir e outras falhar. Para sequências críticas, use rollback ou reconciliação. If-Then decide o caminho; não oferece atomicidade.