Automações
Condição por Pessoa
Elemento de lógica contextual, a condição por pessoa consulta o estado atribuído a um usuário, como home, not_home ou uma zona, antes de autorizar uma sequência. Por exemplo, uma rotina pode enviar aviso apenas se o responsável estiver fora e outra pessoa permanecer em casa. Integra dados de GPS, Wi‑Fi, BLE, aplicativo e zonas, mas a ressalva é que localização pode atrasar, ficar indisponível ou ser compartilhada. Para segurança, presença estimada não substitui autenticação nem confirmação.
⚙ Definição Técnica
Condição por pessoa é um filtro lógico que avalia o estado de presença ou localização associado a uma identidade antes de permitir que a automação prossiga. A entidade de pessoa normalmente agrega um ou mais rastreadores, como aplicativo móvel, GPS, Wi‑Fi, Bluetooth, roteador ou beacon, e produz estados como home, not_home ou nome de zona. A condição deve considerar atraso, prioridade entre fontes, compartilhamento de dispositivos, privacidade e indisponibilidade, e não deve ser usada como prova única de identidade em ações de segurança.
Tipos comuns de gatilhos
Pessoa está em casa
A condição retorna verdadeiro quando a entidade indica home. É usada para personalizar iluminação, climatização, áudio e notificações. A presença pode vir do telefone conectado ao Wi‑Fi, GPS dentro da zona, BLE ou combinação. Cada fonte tem latência. Wi‑Fi pode manter associação depois que a pessoa saiu ou desconectar durante economia de energia. GPS pode demorar em ambientes internos. A agregação precisa ter regra de prioridade. Em plataformas como Home Assistant, a entidade person pode usar vários device_trackers. Se um rastreador está home e outro not_home, o algoritmo escolhe conforme fonte e recência. O projeto deve testar o comportamento. Para desligar cargas, condição de presença pode ser adequada; para trancar porta, convém confirmação adicional.
Pessoa está ausente
A condição verifica not_home ou ausência de todas as zonas. Ela pode permitir modo econômico, simulação de presença ou alertas. Ausência é mais difícil de provar que presença. Um telefone sem bateria ou aplicativo sem permissão pode parecer fora. O sistema deve usar atraso, múltiplas fontes ou confirmação. Não desligue equipamento médico, bloqueie acesso ou arme alarme imediatamente com base em um único rastreador. Uma janela de 5–15 min pode reduzir falsos eventos, mas depende da função. O morador precisa ter caminho para corrigir estado. O histórico deve mostrar qual fonte determinou. Se a entidade está unavailable, não presuma ausência automaticamente.
Pessoa está em uma zona específica
A condição verifica estados como trabalho, escola, academia ou condomínio. Zonas são áreas geográficas ou lógicas. A automação pode preparar climatização quando a pessoa deixa o trabalho, mas isso é gatilho; como condição, pode permitir notificação apenas durante permanência. O raio da zona, precisão GPS e sobreposição importam. Em prédios altos, coordenada pode cair fora. Geofencing do sistema operacional usa economia de energia e não garante atualização imediata. Zonas sensíveis revelam rotina e precisam de privacidade. O nome pode mudar. Para regras críticas, use identificador estável ou entidade auxiliar. A condição deve tratar transição e estado desconhecido.
Uma entre várias pessoas atende ao critério
A lógica pode usar ANY: pelo menos um morador em casa; ALL: todos fora; ou contagem: duas ou mais pessoas presentes. Isso permite climatização por ocupação e segurança. A representação deve excluir visitantes sem rastreamento, crianças sem telefone e funcionários temporários conforme política. “Todos fora” baseado apenas em perfis cadastrados pode ser falso. Sensores de presença física podem complementar. Use grupo de pessoas ou sensor derivado para centralizar. A condição precisa definir membros e atualização. Quando um perfil é removido, o grupo muda. O trace deve registrar quais pessoas satisfizeram. Privacidade limita exposição desnecessária de localização individual.
Pessoa identificada como responsável
A condição verifica se o usuário associado ao evento tem papel específico, como administrador, adulto ou cuidador. Isso vai além de localização e se aproxima de autorização. A identidade deve vir de sessão autenticada, não apenas do nome da entidade person. Um comando por aplicativo pode carregar user_id confiável. Uma presença física não prova quem acionou. Para permitir alterar alarme, use permissões da plataforma, MFA ou PIN. A condição por pessoa pode personalizar notificações e escolhas, mas não deve substituir RBAC. O modelo precisa separar “onde a pessoa está” de “quem está autorizado a executar”.
Considerações de Implementação
Presença estimada não é autenticação
GPS, Wi‑Fi e BLE indicam provável localização de um dispositivo. O telefone pode ser emprestado, deixado em casa, roubado ou sem bateria. A conta pode estar compartilhada. Não use presença como único fator para destravar portas, desarmar alarme ou revelar dados sensíveis. Para conveniência, ela pode preparar contexto. A ação crítica deve exigir credencial, dispositivo confiável, PIN, biometría ou confirmação. O princípio é separar inferência de localização de prova de identidade. Logs precisam registrar a fonte e o usuário que efetivamente autorizou.
Estado indisponível não deve virar ausência por padrão
Quando o aplicativo perde permissão, o telefone fica offline ou o servidor reinicia, a entidade pode ficar unknown ou unavailable. Converter isso para not_home gera falsos “todos saíram”. A regra deve manter último estado por período, marcar incerteza ou bloquear ações. O tempo de validade depende da função. Para climatização, 30 min pode ser aceitável. Para segurança, a incerteza deve exigir confirmação. Uma automação de diagnóstico pode alertar rastreador sem atualização. O dashboard deve diferenciar ausente de desconhecido.
Fusão de fontes melhora cobertura e aumenta complexidade
GPS funciona fora; Wi‑Fi, dentro; BLE, em cômodos; sensores físicos detectam ocupação sem identidade. Combinar reduz falhas, mas exige prioridade e tempo. Uma entidade pessoa pode usar tracker principal e secundário. Sensores de presença podem evitar desligar luz quando telefone está fora. A lógica deve ser centralizada para não criar regras divergentes. Um sensor derivado de “casa ocupada” pode usar pessoas e presença física. O histórico precisa explicar. Quanto mais fontes, maior manutenção e coleta de dados.
Privacidade e retenção precisam ser proporcionais
Histórico de localização revela rotina, trabalho e ausência. Colete apenas o necessário. Processamento local reduz exposição. Limite acesso por usuário. Retenha eventos por período definido e evite enviar coordenadas a serviços não necessários. Para muitas automações, basta estado home/not_home, não rota detalhada. Pessoas devem saber quais fontes são usadas e como desativar. Mudanças de consentimento precisam refletir na automação. Segurança do banco e backups é parte do sistema.