Automações
Condição Numérica
Como uma porta lógica aplicada a uma grandeza, a condição numérica verifica um valor no instante da execução e retorna verdadeiro ou falso. Pode permitir irrigação apenas se a umidade estiver abaixo de 35%, ou carregamento se a potência solar exceder 1,5 kW. Diferentemente do gatilho numérico, não observa cruzamentos nem inicia a regra. Em comparação com templates livres, é mais simples e validável, mas ainda exige unidade correta, tratamento de unavailable e limites compatíveis com a precisão do sensor.
⚙ Definição Técnica
Condição numérica é um predicado avaliado durante a execução de uma automação que compara uma grandeza com limite inferior, superior ou faixa e permite a continuidade somente quando a relação é verdadeira. Ela não mantém observação contínua nem gera evento; apenas lê o valor disponível naquele momento, podendo usar estado principal ou atributo convertido para número. O desenho deve definir unidade, comportamento para dados ausentes, inclusividade dos limites e relação com a incerteza de medição.
Tipos comuns de gatilhos
Condição acima de um limite
Retorna verdadeiro quando o valor é maior que o limite configurado. Pode permitir ventilação somente se CO₂ estiver acima de 1000 ppm ou impedir aquecimento de água se excedente solar for inferior ao mínimo. A condição é avaliada quando outro gatilho inicia a automação. Se o valor já estava alto há horas, ela continua verdadeira. Isso é diferente do gatilho numérico, que depende de transição. O limite deve ser comparado na mesma unidade. Estados string precisam de conversão. Se o sensor está unavailable, o comportamento seguro normalmente é false para ações de conforto ou carga, e uma automação separada pode alertar a falha. Transformar indisponível em zero pode permitir ação incorreta.
Condição abaixo de um limite
Permite o fluxo quando a leitura é menor que o valor. Iluminação por movimento pode usar iluminância abaixo de 50 lux; irrigação, umidade do solo abaixo de 30%; aviso de bateria, carga abaixo de 20%. A escolha do limite precisa considerar precisão, posição do sensor e dinâmica. Um luxímetro junto à janela não representa o corredor. Umidade do solo varia por profundidade e salinidade. A condição não corrige dado ruim. Para evitar alternância entre automações opostas, combine com histerese. Se a ação muda a grandeza, reavaliar depois pode produzir outro caminho. Modos de execução precisam impedir concorrência.
Condição dentro de uma faixa
Usa simultaneamente limite inferior e superior. Pode permitir climatização entre 18 e 30 °C, carregamento quando SOC está entre 20% e 80% ou operação de bomba dentro de pressão segura. A plataforma deve documentar se limites são inclusivos. Para valores exatamente iguais, o resultado pode ser false se a comparação usa > e <. Sensores quantizados podem ficar no limite por longos períodos. A faixa também pode representar janela de segurança. Se o dado salta de abaixo para acima, a condição simplesmente será false no instante; não há evento de travessia. Para registrar violações, use gatilho ou sensor derivado.
Condição baseada em atributo
A grandeza está em atributo de entidade, como temperatura de dispositivo, potência instantânea, posição, nível de bateria ou contagem. O estado principal pode ser on, charging ou connected. A condição aponta ao atributo. Essa configuração é compacta, mas acoplada ao schema da integração. Atualizações podem renomear campo. A automação deve testar ausência e tipo. Se várias regras usam o atributo, criar sensor derivado com unidade e disponibilidade melhora. O atributo também pode atualizar sem evento de estado em algumas plataformas; para condição isso importa apenas no momento de avaliação, mas o valor precisa estar fresco.
Condição numérica com valor dinâmico
Alguns motores permitem que o limite venha de outra entidade, variável ou template. O limite de temperatura pode ser setpoint do termostato; o de carga, tarifa atual. O recurso transforma comparação fixa em política adaptativa. A unidade dos dois lados precisa ser compatível. Se o limite muda durante a execução, defina se deve ser capturado no início ou reavaliado. Valores dinâmicos aumentam flexibilidade e complexidade. Para segurança, aplique limites absolutos: um setpoint externo não deve permitir 80 °C se o equipamento suporta 60 °C. Validação e fallback são obrigatórios.
Considerações de Implementação
Condição não substitui gatilho e pode deixar estado sem correção
Se uma automação dispara apenas por horário e a condição numérica está false, nada acontece. Quando o valor muda depois, a regra não é iniciada. Isso é correto quando o horário é o evento. Se a intenção é reagir ao cruzamento, adicione gatilho numérico. Para garantir estado desejado, use múltiplos gatilhos e reconciliação idempotente. Exemplo: carga deve iniciar quando horário permitido e excedente são verdadeiros. Dispare tanto na abertura da janela quanto no cruzamento do excedente e avalie condições comuns. Assim, a ordem dos eventos não impede a ação.
Incerteza e resolução tornam limites exatos frágeis
Um sensor com precisão ±2% e resolução de 1 unidade não sustenta decisão fina de 0,1. Limiar muito próximo do ruído produz resultados inconsistentes. Use banda, histerese ou margem. Para segurança, adote limite conservador e dispositivo certificado quando aplicável. A condição avalia o número recebido, não a verdade física. Calibração, deriva e posição afetam. Documente a origem e a tolerância. Se o valor é derivado, inclua incerteza da conversão. Uma interface com muitas casas decimais não aumenta precisão.
O instante de avaliação precisa estar alinhado à atualização do dado
A condição lê o último estado conhecido. Se o sensor reporta a cada 15 min, a leitura pode estar antiga. Compare timestamp ou use gatilho na atualização. Em decisões rápidas, dados defasados são inadequados. A plataforma pode restaurar valores após reinício; eles parecem válidos, mas foram medidos antes da queda. Entidades devem expor disponibilidade e last_updated. Para uma bomba, confirme pressão recente. Para energia, use valores com poucos segundos. O requisito de frescor deve ser parte da condição, possivelmente por template.
Condições múltiplas exigem lógica AND/OR explícita
Várias condições em sequência normalmente formam AND. Um grupo OR permite alternativas. Negação muda. A estrutura deve ser legível. Misturar numéricas com presença, horário e estado pode criar caminhos difíceis. Nomeie grupos e use choose quando necessário. O trace deve mostrar qual condição falhou e valores. Evite duplicar limites em várias automações; centralize em helpers ou configuração. Alterações futuras permanecem consistentes. Teste combinações, inclusive limites, indisponibilidade e reinício.