O cenário e a regra do alarme
Os robôs (ESP32) operam em uma área operacional de uma indústria e são monitorados pelo Zabbix, com painéis no Grafana. O Zabbix testa a porta de aplicação de cada um a cada 30 segundos. Dois testes consecutivos sem resposta, ou seja, um minuto, abrem um card de “fora da rede”. O card só fecha após quatro respostas positivas com menos de quatro mudanças em 30 minutos. A regra foi pensada para evitar oscilação, mas tinha um efeito colateral: esticava o alarme muito além da falha real.
O que foi descartado (e por que isso importa)
Antes de investigar a causa, o método foi descartar hipóteses com evidência:
- Queda de Wi-Fi: descartada. A controladora registrava todos os robôs conectados sem interrupção, com sinal estável entre −53 e −58 dBm.
- Falha de antena: descartada. Não havia reinicializações no período, e 100 % dos pings do monitor foram respondidos.
- Mudança de configuração: descartada. Os logs de administração mostravam apenas acessos somente-leitura nos dias anteriores.
- Defeito em um robô: descartada. Todos ficaram lentos ao mesmo tempo, o que elimina problema isolado de hardware.
Cada hipótese descartada reduzia o espaço de busca. O que sobrou foi o que ninguém tinha olhado: o canal de rádio.
A causa raiz: canal 2,4 GHz congestionado
O canal da antena da área operacional operava normalmente a 42 % de ocupação. Em uma janela de cerca de 6 minutos, celulares corporativos com sinal fraco (−80 a −107 dBm) conectados à mesma antena elevaram o uso do canal para 61–75 %.
Aparelhos distantes transmitem mais devagar e ocupam o canal por mais tempo por pacote. Com o canal saturado, os robôs, mesmo com sinal ótimo, precisavam aguardar para transmitir. O tempo de resposta ao teste de porta saltou de ~3 ms para 70–150 ms, exatamente no intervalo das falhas consecutivas que abriram o alarme.
Como foi apurado
Toda a análise foi passiva: leitura da controladora Wi-Fi (somente leitura) para o estado dos robôs, log de conexões da antena e log de administração; monitoramento com dados de ping (a cada 3 min), teste TCP de porta (a cada 30 s) e ocupação do canal 2,4 GHz (a cada 1 min). Nenhuma configuração foi alterada durante a investigação, o que é importante tanto para a segurança do ambiente quanto para a validade da evidência.
A solução e a validação
Foi ativado o RSSI mínimo (≈ −80 dBm) no rádio 2,4 GHz da antena da área operacional. Aparelhos com sinal abaixo desse limiar são desassociados; a reconexão a um AP mais próximo depende do cliente e da cobertura disponível e não é garantida. Os robôs industriais, com sinal entre −53 e −58 dBm, não foram afetados.
Após a configuração, o canal voltou à faixa normal de ocupação e os alarmes desse tipo não se repetiram.
Caso completo no portfólio: Alarme falso de robô industrial: congestionamento de canal Wi-Fi 2,4 GHz
Caso irmão: monitor de quedas Wi-Fi em Python ↗ (abre em nova aba)
Para profissionais de infraestrutura
O que esse caso ensina
- “Sinal bom” não significa “conexão boa”. Em 2,4 GHz, ocupação de canal e tempo de ar importam mais que RSSI.
- Diagnóstico passivo é subestimado. Dá para provar causa raiz sem alterar uma configuração.
- Métrica sem linha de base é chute. O monitor de quedas Wi-Fi foi o que permitiu medir o “antes e depois” com dados, em vez de percepção.
Para professores de Computação e Redes
O que esse caso ensina
Este é o ponto que me interessa particularmente como licenciando em Computação: o mesmo caso que resolve um problema de produção é um excelente problema de sala de aula.
O paradoxo central, “sinal ótimo, conexão ruim”, é contraintuitivo o suficiente para provocar investigação. Ele se conecta diretamente a dois eixos da BNCC Computação:
- Mundo Digital: redes, protocolos, transmissão de dados, compartilhamento de meio físico.
- Pensamento Computacional: formular hipóteses, testar, descartar com evidência, concluir.
Uma transposição possível para o 9º ano ou Ensino Médio técnico
- Apresente o paradoxo sem a solução. “O sinal está ótimo, mas o robô não responde. O que pode ser?”
- Peça hipóteses e conduza o descarte. Use evidências fictícias: logs, prints de controladora, medições.
- Introduza fila e tempo de ar com uma atividade desplugada. Cartões representando pacotes disputam um único “canal” na lousa.
- Feche com a linha do tempo. Ocupação do canal × latência × abertura do alarme.
Esse desenho dialoga com dois materiais que já publiquei:
- A Rede Parou: laboratório de investigação de incidente com logs fictícios, em que os estudantes testam hipóteses com evidências.
- Laboratório: senha, usuário ou máquina?: versão didática do caso de autenticação 802.1X, no mesmo espírito de transpor um caso técnico real para a sala.
A ideia não é ensinar ESP32 ou controladora UniFi, mas ensinar o método: observar, formular hipótese, buscar evidência, descartar, concluir. É o mesmo raciocínio que uso em produção, só que com dados sanitizados e no ritmo da turma.
Fechamento
O sinal estava ótimo. O problema nunca foi o sinal. Foi o canal, e a falta de dados para enxergá-lo.
Se você é professor e quer transformar casos reais como este em aula, os materiais e a oficina de BNCC Computação estão no portfólio: Computação e Educação. Se você atua em infraestrutura e convive com alarmes recorrentes de “fora da rede” ou quedas de Wi-Fi sem causa aparente, o método está descrito no caso completo: alarme falso de robô industrial.