Registry de dispositivos ESP32: identidade, saúde e atualizações da frota
Com poucos dispositivos, uma planilha parece suficiente. Com centenas, a operação precisa responder: qual unidade física é esta, quem é responsável, qual firmware deveria executar, o que reportou por último e ainda é confiável? Registry não é lista de MAC addresses; é o registro operacional que liga identidade, ciclo de vida, configuração desejada e saúde observada.
Publicado em 28 de setembro de 202614 min de leituraEngenharia do ciclo de vida da frota
Conecte cadastro à desativação
Identidade e estado acompanham transições controladas
1 / CadastrarAtribuir ID imutável e responsável.
2 / ProvisionarEmitir credencial única e perfil autorizado.
3 / ObservarReceber heartbeat, versão, saúde e local.
4 / OperarComparar estado desejado e reportado.
5 / EncerrarRevogar identidade, arquivar histórico e acesso.
Mantenha ID lógico estável, independente de endereço de rede. MAC, IP e nome exibido são atributos, não credenciais de autorização. O cadastro deve associar unidade física a responsável, local e revisão de hardware; emissão de credenciais ocorre em processo controlado. Nunca reutilize a identidade desativada em outra placa.
Separe inventário do estado atual
Um registry normalizado armazena identidade, modelo/revisão, local de instalação, responsável, referência de credencial, suporte e estado de ciclo de vida. Telemetria detalhada pertence a eventos ou série temporal; o registry guarda o resumo atual necessário para localizar e operar. Mantenha configuração desejada separada do estado reportado, com versões e horários próprios. Divergência é evidência útil, não dado para sobrescrever silenciosamente.
Campos úteis: primeiro cadastro, último contato autenticado, firmware e bootloader, revisão de configuração, saúde dos sensores, último erro, coorte de atualização e responsável de manutenção. Segredos ficam fora das linhas de inventário; armazene uma referência ao cofre de credenciais.
Trate heartbeat como evidência, não ponto verde
Heartbeat inclui ID, sequência monotônica, firmware, uptime ou causa do reset e flags compactas de saúde. O servidor adiciona horário próprio de recebimento. Defina intervalo esperado por classe e derive estados como saudável, atrasado, obsoleto, em quarentena ou encerrado. Estar “conectado” não prova que o sensor está amostrando ou a configuração atualizada.
Use chaves idempotentes e aceite eventos atrasados. Mantenha horário do evento e recebimento separados devido a deriva dos relógios. A visão da frota deve filtrar por local, revisão, coorte, atraso e incidentes, em vez de montar milhares de cartões.
Audite atualizações e configuração
Registre firmware e configuração desejados separadamente do que cada dispositivo confirmou. Um rollout deve indicar artefato, assinatura ou digest, coorte, autorização, início, resultado e rollback. Rollback OTA do ESP-IDF permite voltar a uma aplicação anterior funcional após nova imagem problemática; o registry deve distinguir “baixado”, “iniciado pendente de verificação” e “confirmado saudável”. Enviar comando de update não prova sucesso.
Campo/evento
Por que importa
Limite de acesso
ID lógico e revisão
Vínculos estáveis após troca de rede ou reparo
Cadastro e suporte
Referência/estado da credencial
Rotação, revogação e resposta a incidente
Nunca mostrar chave privada na UI
Estado desejado e reportado
Detecta divergência de configuração/firmware
Alterações exigem autorização
Último contato e saúde
Encontra segmentos atrasados ou falhos
Escopo por unidade e função
Estado de ciclo de vida
Controla ativação, quarentena e encerramento
Transições auditadas
Controle acesso por função da frota
Separe leitura, operação local, administração de credenciais e aprovação de firmware. Suporte pode inspecionar saúde sem ver segredos ou emitir comandos de atuação. Restrinja consultas e comandos às unidades autorizadas. Registre autor, motivo, request ID e estado anterior/novo nas transições sensíveis.
Trate troca de dono e fim de vida
Coloque em quarentena dispositivo perdido, comprometido ou devolvido antes de reassociá-lo. Revogue credenciais, interrompa comandos, preserve evidência necessária e registre destino físico. Substituta recebe nova identidade ligada ao chamado, sem copiar ID antigo. Equipamento fora de suporte precisa de política explícita de acesso, atualização e retenção de dados.
Em resumo
Um registry ESP32 útil liga identidade única a ciclo de vida, acesso, configuração pretendida e saúde observada. Mantenha segredos fora do inventário, separe estado desejado do reportado, explicite resultados de OTA e audite do cadastro ao encerramento. Assim, a frota vira algo que a operação consegue entender, não uma planilha que apenas conta dispositivos.