Automações
Condição por Dispositivo
Evoluída a partir de comparações manuais de estados, a condição por dispositivo usa uma abstração oferecida pela integração para verificar situações como fechadura trancada, sensor aberto ou botão em modo específico. A configuração costuma ser amigável e vinculada ao registro do equipamento. A limitação é o acoplamento ao fabricante ou à integração: mudanças de firmware, substituição ou migração podem invalidá-la. Para o morador, simplifica a criação, mas condições por entidade tendem a ser mais portáveis e transparentes.
⚙ Definição Técnica
Condição por dispositivo é um filtro de automação definido por uma integração que apresenta estados ou capacidades de um equipamento em termos orientados ao usuário, como “está trancado”, “está detectando movimento” ou “nível de bateria abaixo de determinado valor”. Em vez de o autor escolher manualmente entidade, atributo e valor, a plataforma armazena identificador do dispositivo, domínio, tipo de condição e parâmetros. A abstração reduz a complexidade inicial, mas depende do contrato da integração e pode ser menos portável, menos expressiva e mais difícil de depurar que uma condição explícita por entidade.
Tipos comuns de gatilhos
Condição binária oferecida pela integração
A interface apresenta opções como porta aberta/fechada, movimento detectado/limpo, fechadura trancada/destrancada ou tomada ligada/desligada. O motor traduz a escolha para entidades e estados internos. Isso facilita a configuração sem conhecer nomes como binary_sensor ou lock. O risco é a semântica variar. “Aberto” pode vir de contato, tamper ou estado agregado. A integração deve documentar. Ao substituir o equipamento, o device_id muda e a condição pode quebrar mesmo que a nova entidade tenha o mesmo nome amigável. Antes de excluir dispositivo, revise automações. Ferramentas de referência ajudam. Para regras críticas, entidade explícita e testes podem ser mais transparentes.
Condição numérica encapsulada pelo dispositivo
Algumas integrações expõem bateria, temperatura, potência ou posição como condição configurável. O editor solicita limite sem mostrar o atributo subjacente. A conveniência é alta, mas unidade, disponibilidade e precisão podem ficar ocultas. Um dispositivo pode mudar de °C para °F conforme configuração. A condição precisa armazenar unidade de forma estável. Se o recurso não permite histerese, frescor ou cálculo, uma condição numérica por entidade é preferível. O uso é adequado para regras simples e locais, como notificar bateria baixa. Para controle de processo, a abstração pode ser insuficiente. O trace deve mostrar valor real que foi avaliado.
Condição de capacidade específica do fabricante
Um robô pode estar docked, uma câmera em privacy mode, um purificador com filtro válido ou um inversor em island mode. A integração conhece estados proprietários e oferece condição pronta. Isso evita decodificar atributos. A desvantagem é dependência. Migração para outra marca exige reescrever. Firmware pode mudar enumerações. O produto pode ficar indisponível na nuvem. A automação deve tratar. Quando a capacidade é essencial, crie sensor binário derivado com semântica própria da casa. Assim, integrações diferentes alimentam o mesmo conceito, como “sistema de limpeza pronto”. A condição usa essa abstração local.
Condição vinculada a múltiplas entidades do mesmo dispositivo
Um único equipamento pode ter várias entidades: estado, bateria, conectividade, alarme e modo. A condição por dispositivo pode combinar internamente ou selecionar uma. O usuário precisa saber qual. Uma fechadura “trancada” pode ignorar porta entreaberta se o contato é entidade separada. Para segurança, combine estado do trinco, sensor de porta e disponibilidade. Uma câmera “online” não garante stream. Uma bomba “ligada” não garante fluxo. A abstração de dispositivo é conveniente, mas o serviço real pode exigir múltiplos sinais. Use condições AND e health checks. Documente.
Condição de dispositivo com duração
Algumas plataformas permitem “está aberto há 5 min” ou “está ligado por 30 min”. A integração ou motor mantém duração. Reinício pode resetar. A condição é avaliada no instante do fluxo; ela verifica quanto tempo o estado atual persiste. Se a entidade foi restaurada sem timestamp real, a duração pode ser incorreta. Para alertas de porta, use gatilho com for ou timestamp de abertura. Para filtro, a duração é útil. A documentação deve esclarecer persistência. Teste após restart. Não confunda com tempo desde último evento quando o estado mudou e voltou.
Considerações de Implementação
Substituição e exclusão de dispositivo podem invalidar a condição
Device_id é associado ao registro criado pela integração. Reset de fábrica, migração de hub, nova conta ou reemparelhamento pode gerar novo ID. A automação pode aparecer quebrada ou simplesmente não atender. Antes da manutenção, exporte referências. Depois, use ferramenta de reparo e teste. Nomes amigáveis iguais não garantem identidade. Em instalações grandes, abstrações por área, grupo ou helper reduzem acoplamento. Para função crítica, um sensor derivado mantém interface estável enquanto o dispositivo de origem muda.
A condição pode ocultar estados unavailable e qualidade
O editor simplifica, mas pode não mostrar como trata indisponibilidade. “Não está aberto” pode retornar true quando o dispositivo está unknown, dependendo da implementação. Isso é perigoso. Teste desligando o equipamento e observando. Para segurança, disponibilidade deve ser condição separada. O trace precisa mostrar resultado. Se a integração não oferece semântica segura, use condição por entidade ou template com tratamento explícito. A interface amigável não elimina necessidade de conhecer o comportamento de falha.
Condições por entidade são mais portáveis e auditáveis
Referenciar entity_id e estado torna a lógica visível e facilita migração quando a entidade pode ser remapeada. Condições por dispositivo são mais fáceis no editor e podem expor recursos especiais. A escolha depende de complexidade e público. Em automações simples criadas por morador, dispositivo é adequado. Em configuração versionada, templates e entidades oferecem revisão. Uma política pode preferir dispositivo para capacidades proprietárias e entidade para estados comuns. Documente a decisão.
A função real pode exigir mais de uma condição
Estado do dispositivo não equivale ao resultado físico. Relé on não prova luz acesa. Fechadura locked não prova porta fechada. Bomba on não prova fluxo. Para ações críticas, combine sensores independentes. A condição por dispositivo pode ser uma camada. Feedback físico confirma. O custo aumenta, mas reduz falsa confiança. Quando feedback não existe, registre como “comando aceito”, não “ação concluída”. A terminologia da automação deve refletir.