APP-18 — Parametrização e Firmware

Falha controlada

Percentual de medidores que respondem erro na primeira tentativa. Quem falha é escolhido por hash do número de série — determinístico, para o ensaio e a apresentação falharem nos mesmos equipamentos —, e quem falhou não falha de novo: o reenvio normaliza, que é a cena de gestão de exceção.

Reflexo em cadastro

Grava o efeito da parametrização nos campos complementares do medidor (TB_MEDIDOR_COMPL) pela API de provisionamento — destino nativo, auditado, sem escrita direta. Nenhum dos 6 códigos tem coluna própria no cadastro, por isso é aqui que o efeito aparece. Cada reflexo custa um round-trip do documento do ponto, então o interruptor nasce desligado: ligue para a cena do reflexo, desligue para medir vazão. Com ele ligado, um reflexo que não acontece leva o comando a Parcial com o motivo — não a erro, porque o equipamento aceitou a parametrização.

Tentativas inclui a primeira: 1 desliga o reenvio e é o controle negativo do ensaio. O reenvio só acontece em recusa transitória (5xx, 408, 429, rede, tempo esgotado) — nunca em 4xx de pedido, porque reenviar um 400 transformaria um defeito de payload em latência que ninguém consegue explicar. ⚠️ O valor fica gravado. Quem conduz ensaio escreve, relê e confere antes de medir: valor persistido é valor herdado.

Versão de firmware no cadastro

Interruptor separado do de cima, e não por capricho: aquele escreve pela API de provisionamento, que é auditada; este escreve direto em TB_MEDIDOR.STR_VERSAO_FIRMWARE, porque versão de firmware não existe em nenhum contrato publicado do PIM. Ligado, ele também habilita o roster do gateway — a lista de medidores que o gateway atende, sem a qual a campanha não tem "dispositivo" para reportar. Duas limitações declaradas: a escrita não deixa trilha na auditoria da aplicação, e o medidor tem cache de segundo nível, então a tela pode exibir a versão antiga até a entrada expirar (a coluna no banco já mostra a nova).