TotalConnect/ultimos_cambios.txt

No te preocupes por el formato del bloque de código. Aquí tienes el reporte detallado escrito directamente en texto plano estructurado, fácil de leer y sin riesgo de que se desborde o se corte:

REPORTE TÉCNICO: ARQUITECTURA E IMPLEMENTACIÓN DEL MOTOR HÍBRIDO DE MONITOREO (TOTALCONNECT 2.0)

Este documento detalla las optimizaciones, razones de diseño y componentes implementados en el núcleo del sistema de monitoreo (index.py) para garantizar estabilidad, prevención de bloqueos (rate-limits) y eficiencia en el uso de la API de Honeywell.

1. Resumen Ejecutivo de Cambios
Se rediseñó el ciclo de consulta en segundo plano para transicionar de un modelo lineal pesado a un motor híbrido dinámico (Poll Lite SOAP + Poll Full REST con control de rotación y contadores 2:1). Además, se dotó al panel web de un visor de bitácoras interactivo en vivo y de un mecanismo de recuperación de fallos (Hard Reset).

2. Detalle de Cambios Implementados y Razones Técnicas

A. Motor Híbrido Dinámico (Lotes Optimizados y Grupos de Prioridad)

Implementación: Se dividió el procesamiento de las sucursales en cuatro grupos lógicos dentro de cada ciclo de 30 segundos: Grupo 0 (Alarma Activa con prioridad absoluta y forzada al 100%), Grupo A (Turno Secuencial Ordinario), Grupo B (Alta Frecuencia para desarmadas/fallos) y Grupo C (Triggers SOAP).

Razón: Las llamadas REST (fullStatus) consultan el panel físico y tardan ~1.1 segundos. Consultar las 285 sucursales de golpe en cada ciclo saturaría la red y provocaría un bloqueo por rate-limiting en Honeywell. Este sistema por grupos prioriza las emergencias y distribuye la carga inteligentemente.

B. Ciclo 2:1 (Poll LITE por SOAP y Poll FULL Preventivo)

Implementación: Se introdujo un contador interno (lite_count) por sucursal persistido en la base de datos de estado (last_state.json). Cuando una sucursal es revisada mediante un Poll LITE (SOAP) rápido (~200ms), el contador se incrementa (+1). Si alcanza 3 Lites consecutivos, el sistema fuerza un Poll FULL (REST) preventivo de mantenimiento y reinicia el contador a 0. Si SOAP detecta un cambio de estado en vivo, se fuerza un Full inmediato en la siguiente vuelta.

Razón: El uso exclusivo de Poll Full estancaba la rotación o saturaba las peticiones. Combinar 2 revisiones ligeras por SOAP y 1 profunda por REST reduce en más de un 60% las consultas pesadas a Honeywell manteniendo la precisión intacta.

C. Sincronización y Unificación de Timestamps de Rotación (last_download_epoch)

Implementación: Tanto en los bloques de Poll FULL como de Poll LITE (SOAP), se actualiza el registro de tiempo de verificación a la hora actual (time.time() y now_str).

Razón: En la arquitectura preliminar, los Polls Lite no actualizaban el reloj de antigüedad, lo que provocaba que las mismas sucursales se quedaran atoradas al frente de la cola del Round-Robin de forma infinita. Al actualizar el timestamp en ambas modalidades, la sucursal avanza de manera fluida al final de la fila tras cada chequeo, permitiendo una rotación limpia del catálogo completo.

D. Resilencia ante Caducidad de Sesiones SOAP (ConnectionResetError / OSError)

Implementación: Se añadió un manejador de excepciones específico en las peticiones SOAP para capturar la expiración del token de sesión (GUID) de AlarmNet. Al detectarlo, se ejecuta un .pop() para purgar el token obsoleto de la memoria en caliente, forzando a que el siguiente ciclo solicite uno totalmente fresco.

Razón: Los identificadores de sesión SOAP caducan de forma impredecible en los servidores de Honeywell. Sin esta limpieza automática, el script se quedaba intentando reutilizar el mismo token muerto indefinidamente.

E. Visor de Logs Interactivo en el Dashboard (/activity-log)

Implementación: Se añadió un botón en la cabecera del panel web ("Ver Log") que despliega una ventana modal con terminal oscura, conectada al endpoint backend /activity-log, el cual devuelve de forma limpia las últimas 150 líneas del archivo de actividad (activity.log).

Razón: Facilita la auditoría en tiempo real del comportamiento del servidor, el estado de los polls y la detección de eventos sin necesidad de conectarse por SSH al servidor o revisar archivos de texto manualmente.

F. Autogestión y Límite de Tamaño de Logs (activity.log)

Implementación: Se programó una función de rotación automática en caliente dentro del método de escritura log_msg().

Razón: Cada vez que el log de actividad de la aplicación supera los 5 MB, el sistema lo renombra automáticamente a activity.log.1 (preservando un respaldo único) y abre un archivo limpio, previniendo que el almacenamiento de la VM o del servidor colapse por acumulación desatendida.

G. Mecanismo de Hard Reset (Reinicio de Fábrica por Clic Largo)

Implementación: Se programó una interacción táctil y de ratón en el botón "Actualizar" de la interfaz con un retardo visual de 1 segundo (el indicador rojo de advertencia aparece únicamente tras cruzar los primeros 1000 ms de presión continua). Si se mantiene presionado por 3.0 segundos o más, borra físicamente del disco los archivos temporales (last_state.json, locations_cache.json, last_event_ids.json), vacía el caché de clientes en memoria y reinicia el escaneo de cero tras una confirmación de seguridad.

Razón: Permite resolver de forma limpia y directa cualquier inconsistencia severa de datos o corrupción temporal de caché sin requerir intervención técnica avanzada por comandos.

H. Protección de Espacio en server.log (Opción 1 Implementada)

Implementación: Se modificó la redirección del comando de arranque en segundo plano en Linux (nohup ... > /dev/null 2> server.log &) y se sobreescribió el método interno log_message del servidor HTTP para silenciar las peticiones secundarias de red repetitivas.

Razón: Evita que el archivo server.log crezca gigabytes con peticiones HTTP ordinarias o duplicados de consola, manteniéndolo en 0 bytes y reservado exclusivamente para atrapar trazas de error (tracebacks de excepciones críticas) si el sistema llegara a fallar.