Uma OTA não termina quando o dispositivo baixa os bytes. Ela termina quando uma imagem compatível é verificada, o novo app inicializa, as funções essenciais passam nos testes e a frota consegue parar ou recuperar uma versão ruim. Trate a atualização como uma transação distribuída entre dispositivos que podem ficar offline, com bateria baixa ou inalcançáveis por dias.
Mantenha um manifesto vinculando família, revisão de hardware, versão, digest da imagem, identidade de assinatura, canal, bootloader mínimo e política de rollout. Autentique o serviço e verifique a assinatura no dispositivo; HTTPS protege o transporte, mas não substitui firmware assinado. Mantenha chaves de assinatura fora do servidor de atualização e separe permissões de build, aprovação e assinatura.
O OTA do ESP-IDF costuma usar dois slots de aplicação e uma partição de dados OTA para escolher qual imagem inicializa. Reserve flash para app atual e candidato, além dos dados que precisam sobreviver. Baixe no slot inativo, valide antes de alterar o boot e projete mudanças em NVS/esquema para continuar compatíveis se houver rollback.
Teste falta de energia durante apagamento, download, verificação, seleção do boot e primeira inicialização. A metadata OTA tolera interrupções específicas, mas o sistema completo precisa de testes. Rollback não ajuda se a versão nova fez uma migração irreversível antes de confirmar saúde.
Não marque a imagem como válida apenas porque a task principal iniciou. Defina um teste limitado: periféricos essenciais inicializados, configuração legível, função local disponível e comunicação, quando esperada. Dê prazo. Se falhar ou reiniciar antes da confirmação, permita rollback. Não exija nuvem para validar um aparelho que deve funcionar offline.
Depois, envie resultado compacto com coorte, versão, motivo de boot e códigos diagnósticos. O serviço deve distinguir não oferecida, adiada, baixando, verificada, aguardando confirmação, concluída, revertida e inacessível. Assim, pausar o rollout se baseia em evidência, não em contagem de downloads.
| Etapa | Objetivo | Avance somente quando |
|---|---|---|
| Bancada | Variantes de hardware e interrupções controladas. | Boot, periféricos, rollback e dados passam. |
| Piloto interno | Observar redes, uso e energia reais. | Métricas ficam dentro dos limites definidos. |
| Fatia pequena da frota | Validar escala operacional e suporte. | Sem regressão por coorte nem aumento de rollback. |
| Frota ampla | Entregar na velocidade controlada. | Monitorar e manter pausa e recuperação disponíveis. |
Distribua verificações por janelas ou coortes para não sobrecarregar a rede quando toda a frota consultar ao mesmo tempo. Respeite bateria, banda e horário de uso. Defina antes os limites de parada: falha de boot, watchdog, perda de conectividade, função essencial, taxa de rollback e relatos de suporte. Pausar ofertas novas não deve interromper um dispositivo no meio da gravação flash.
Rollback volta para versão funcional após uma atualização experimental que falha. Anti-rollback rejeita firmware abaixo da versão de segurança gravada em eFuse, evitando reinstalar uma versão vulnerável mas assinada. Não são equivalentes. Planeje o avanço da versão de segurança: depois disso, uma imagem antiga de recuperação pode deixar de inicializar. Preserve recuperação compatível e documente rotação de chaves e serviço de fábrica antes de habilitar controles irreversíveis.
Acompanhe oferta para sucesso, tempo de atualização, dispositivos adiados/offline, falhas de assinatura, motivos de rollback, distribuição de versões e idade do firmware mais antigo suportado. Proteja identificadores e não coloque segredos em URL ou logs. Preserve manifests auditáveis e tenha processo testado para revogar chave comprometida. O suporte precisa diagnosticar um aparelho travado sem contornar verificação de assinatura.
OTA segura no ESP32 combina imagens assinadas, partições compatíveis, validação no primeiro boot, rollback, coortes e limites de parada. Teste interrupções e compatibilidade de dados, não apenas downloads bem-sucedidos. Trate anti-rollback como política com consequências para recuperação e amplie um release só após o produto demonstrar saúde.