Função De Vigia E Porteiro

Entendendo função de vigia e porteiro em automação residencial

Acho que muita gente confunde esses dois conceitos ou acha que são a mesma coisa. Não são. O vigia e o porteiro resolvem problemas diferentes, embora muitas vezes rodem no mesmo hardware. O vigia é um watcher, algo que monitora o estado do sistema e reage quando uma condição muda. O porteiro é um gatekeeper, decide se algo entra ou sai com base em regras de acesso. Já tive problema em um projeto onde as pessoas configuravam tudo como porteiro e ainda se perguntavam por que o alarme não disparava quando a carga do motor do portão oscilava. O porteiro não monitora estado contínuo. Ele filtra eventos discretos. Vou falar de exemplo prático porque a teoria sozinha não vai te salvar quando o sistema entrar em loop. Primeiro, defina claramente o que é vigia e o que é porteiro no seu cenário. Vigia é para coisas que precisam de observação constante. Temperatura que sobe, corrente que excede um limiar, latência que aumenta. Porteiro é para controle de acesso e permissões. Quem pode comandar qual dispositivo, quando, e sob quais condições. No meu caso, trabalhei num sistema de automação predial onde o porteiro precisava validar entradas por RF e o vigia monitorava o tempo de ciclo de cada atuador. A confusão começou quando o mesmo script tentava fazer as duas coisas. O porteiro processava o cartão RFID e depois chamava uma função de vigia que deveria apenas registrar, mas estava também decidindo se abria ou não. Resultado: o vigia entrava em conflito de decisão com o porteiro e o portão ficava preso no meio do ciclo, sem abrir nem fechar. A solução foi separar completamente. Criei um fluxo assíncrono onde o porteiro only valida e emite um evento de autorização, e o vigia only monitora e dispara alertas. O comando de actuacao passa por uma terceira camada independente que só executa se o porteiro autorizou E o vigia não detectou anomalia naquele momento.

Isso reduziu o tempo de resposta de 2,3 segundos para cerca de 180 milissegundos no processamento de entrada. A separação de responsabilidades não é só boa prática, é necessidade operacional quando você tem múltiplos dispositivos em tempo real.

Pegadinhas que ninguém conta

O problema mais comum é assumir que vigilância contínua funciona bem com polling. Em sistemas com mais de cinco sensores, polling a cada segundo já come CPU e introduz delays acumulados. Eu migrei um projeto inteiro de polling para eventos orientados a mudanças. Em vez de verificar periodicamente se a temperatura mudou, o sensor notifica quando muda. Isso eliminou 70% do overhead de CPU e reduziu falsos positivos em alertas de vigia que eram gerados pela oscilação natural dos dados entre duas leituras. Outro detalhe é o tratamento de falhas. Porteiros que bloqueiam tudo na menor anomalia viram gargalo. No meu sistema, o porteiro tinha um modo degradado configurado: quando o backend de validação Caía, ele passava a aceitar requisições com timeout de 300ms e logava tudo para revisão posterior. Funcionou por dois anos até a equipe conseguir resolver a instabilidade no serviço de autenticação. Um porteiro que não tem fallback adequado é apenas um ponto único de falha com nome bonito. Vigias também precisam de deadband. Se você colocar um sensor de corrente disparando alerta toda vez que a leitura varia mais de 0,1A, você vai receber cento e cinquenta alertas por hora sem motivo. Configurei deadband de 5% do valor de referência e o volume de notificações caiu para algo tratável. Sem deadband, o vigia vira ruído.

Quando não usar

Existem cenários onde função de vigia e porteiro simplesmente não fazem sentido. Se o sistema é pequeno, com menos de três dispositivos e operação manual predominante, adicionar essa camada só introduz complexidade desnecessária. Um relé controlado por interruptor direto é mais confiável que um porteiro software mal configurado. Também não recomendo para aplicações de segurança crítica sem redundância. Um porteiro single-node que decide quem entra num sistema de segurança patrimonial é um risco. Se ele cair, o sistema todo fica cego ou, pior, aberto. Para instalações que precisam de Alta disponibilidade, considere usar um sistema dedicado de controle de acesso com replicação ativa-ativa, em vez de improvisar com funções genéricas de vigia e porteiro em uma plataforma de automação genérica. Custa mais, mas na hora que o servidor principal cair, o secundário mantém o fluxo sem gap perceptível.