O navegador pode deixar a telemetria parecer imediata, mas um número mudando não é necessariamente uma medição atual e confiável. Um dashboard útil mostra conexão, idade da amostra, lacunas de sequência e identidade do dispositivo. Se também envia comandos, autorização e comportamento seguro do firmware importam mais que a animação do botão.
Para um protótipo local, o servidor HTTP do ESP-IDF pode hospedar WebSockets; o ESP32 também pode atuar como cliente usando o componente da Espressif. Escolha a topologia de propósito. Uma página HTTPS normalmente exige endpoint WSS seguro; não misture página segura com socket inseguro. Gateway ou backend costuma facilitar identidade, escala e atualização em comparação a expor o dispositivo diretamente à internet.
Envie tipos como telemetry, status, ack e error, com versão de esquema, ID, sequência e horário. Inclua unidades e flags de qualidade. Rejeite eventos malformados, grandes demais ou inesperados antes de renderizar. O navegador não deve confiar em HTML do dispositivo: exiba valores como texto e valide limites permitidos.
Limite frequência e tamanho. Um painel raramente precisa de toda amostra em alta taxa; agregue na borda/gateway e mantenha histórico durável separado. WebSocket é transporte ao vivo, não banco de dados.
Separe estado do socket e estado da medição. A conexão pode continuar aberta depois que o sensor parou. Mostre idade da última amostra, sequência, intervalos ausentes e saúde declarada. Gráficos devem mostrar lacunas em vez de ligar pontos ausentes. Ao ocultar ou reabrir a página, decida se mantém o socket ou busca um snapshot ao voltar.
Use backoff exponencial com jitter e limite máximo. Só zere o atraso após conexão estável, não imediatamente após handshake breve. Evite timers duplicados e remova listeners ao fechar. Na reconexão, solicite snapshot atual e cursor; não finja que quadros ao vivo perdidos foram reproduzidos se o servidor não os guardou. Limite clientes e filas do servidor para uma aba lenta não consumir memória sem controle.
| Estado | Evidência na tela | Comportamento |
|---|---|---|
| Conectado e recente | Socket aberto e amostra nova | Fluxo normal |
| Conectado, dado antigo | Socket aberto, idade excedida | Marcar telemetria como degradada |
| Desconectado | Reconexão explícita | Backoff e snapshot ao recuperar |
| Comando pendente | Pendente/aceito/rejeitado/expirado | Correlacionar ID e prazo |
URL do WebSocket ou cabeçalho Origin não são autenticação. Conferir Origin ajuda contra uso cross-site por navegadores, mas clientes não-browser podem falsificar o cabeçalho. Autentique usuário e sessão, autorize cada dispositivo e comando, valide payload no backend e no dispositivo e registre o responsável. Exija expiração e ID único para um comando atrasado ou repetido não parecer novo.
Para atuadores, mostre efeito previsto e estado atual, peça confirmação para ações relevantes e informe se o firmware aceitou e concluiu. Evento de envio no browser só diz que os bytes foram entregues à pilha do socket. Intertravamentos locais, estado seguro e parada manual continuam no dispositivo.
Meça sessões conectadas, taxa de mensagens, filas, falhas de parsing, dispositivos antigos, reconexões e latência de confirmação de comandos. Teste suspensão do navegador, troca de Wi-Fi, reinício do servidor, eventos duplicados, JSON inválido e dispositivo conectado com tarefa de sensor travada. Um painel liso no cenário ideal mas enganoso nesses casos não serve à operação.
WebSockets atendem painéis ESP32 responsivos quando há contratos de eventos, atualidade, reconexões limitadas e autorização de comandos. Use gateway quando isso melhorar identidade e gestão da frota, separe histórico durável e deixe dados antigos ou desconectados explícitos. “Ao vivo” é estado medido, não efeito de CSS.