v1.8.1 — Abril 2026

Esta versión introduce nuevas funcionalidades en el motor de alertas, notificaciones y administración de facilities, junto con mejoras significativas de performance para entornos con miles de alertas activas.

Nuevas funcionalidades

Alertas compuestas (AND / OR)

Ahora es posible combinar hasta 5 condiciones dentro de una misma alerta usando operadores lógicos AND u OR.

• Caso de uso: disparar una alarma solo cuando se cumplen simultáneamente varias condiciones (ejemplo: temperatura alta AND humedad baja).
• Configuración: en el editor de alerta, seleccione el operador desde el dropdown Logic (Single / AND / OR) y agregue condiciones adicionales con + Add condition.
• Restricción: todas las condiciones de una alerta compuesta deben pertenecer a endpoints de la misma facility.

Notificaciones push en navegador (Monitor)

El módulo Monitor ahora soporta notificaciones push directas al navegador vía Firebase Cloud Messaging, incluso con la pestaña en segundo plano.

• Activación: ícono de campana en la barra superior → Activate notifications → permitir en el navegador.
• Sonido custom y etiqueta (OPEN) para alarmas abiertas.
• Soporte multi-tenant: cada cliente puede registrar su propio proyecto Firebase.
• Disponibilidad: módulo Monitor (en Manager el ícono está oculto intencionalmente).

Modo Mantenimiento por facility

Permite suspender temporalmente la creación de nuevas alarmas y la ejecución de acciones automáticas en una facility, sin afectar las alarmas activas existentes.

• Acceso: Manager → Facilities → editar facility → tab Operational Status.
• Toggle Put in maintenance abre un diálogo donde se puede:
  • Especificar una razón (opcional) — queda registrada en el historial.
  • Configurar un timeout de auto-reversión en horas (0 = sin timeout).
• Historial de cambios: la sección History muestra los toggles previos con fecha, autor y razón.
• Cuando una facility está en Mantenimiento:
  • No se crean alarmas nuevas.
  • No se disparan acciones automatizadas.
  • Las alarmas activas previas permanecen abiertas.
• Auto-revert: un job programado verifica los timeouts y devuelve la facility a Active automáticamente cuando expira.

Variable {SECTOR_NAME} en notificaciones

La descripción del sector al que pertenece el endpoint ahora puede usarse como placeholder en cualquier template de notificación de alarma.

• Disponible en: Email, SMS, Voice y WhatsApp, tanto para apertura como cierre de alarma.
• Resolución: si el endpoint está asociado a un sector, se inserta la descripción del sector. Si no, se inserta cadena vacía (sin afectar el resto del template).

Vista agrupada de alertas por dispositivo

La pantalla Manager → Alarms → Alerts ahora agrupa las alertas por dispositivo, con resumen visual de severidades.

• Por device: total + badges de color por severidad (High rojo, Medium naranja, Low amarillo, Information azul).
• Expandible: click en el device muestra la lista de alertas con columnas Endpoint / Alert / Severity / Status.
• Performance: la lista soporta paginación de servidor — facilities con miles de alertas cargan sin demora.

Permisos por defecto del grupo "Everyone"

Al crear un cliente nuevo, el grupo Everyone recibe automáticamente:

• Client.Read (acceso al módulo Monitor)
• Client.ReadAllFacilities (acceso a todas las facilities del cliente)

Nota para clientes existentes: el permiso se backfilea automáticamente en el próximo reinicio del app pool. Si necesita compartimentalización estricta entre facilities (un usuario sólo debe ver una facility puntual), no asigne el grupo Everyone a ese usuario; cree grupos custom con permisos por facility.

Mejoras de performance

Listado de alertas paginado en base de datos

La vista de alertas en Manager ahora usa un stored procedure paginado que filtra y ordena en SQL. Antes esto se hacía en memoria, lo que generaba TTFB de >10 segundos en facilities grandes.

• Resultado: carga sub-segundo en facilities con miles de alertas.
• Búsqueda en línea: filtro por descripción, address o DeviceID se ejecuta en DB.

Reducción de queries para alertas compuestas

Las condiciones de alertas compuestas (AND/OR) ahora se cargan en una sola consulta batched, en vez de una consulta por alerta. Antes: N+1 query pattern.

• Resultado: páginas con muchas alertas compuestas cargan ~40% más rápido.

Estabilidad y hardening

• Null safety en operaciones críticas del motor de alertas y dashboards (defensive guards en mapeos de datos legacy).
• Coordinación cross-server para invalidación de cache de Maintenance: se publica un mensaje vía Redis al cambiar el estado, asegurando que servidores en topología load-balanced refresquen su cache local de inmediato.
• Limpieza automática de archivos token del cache de Camera widget — un job nuevo elimina archivos .token con más de 7 días de antigüedad.
• Manejo defensivo de devices ausentes cuando un widget de dashboard solicita un device borrado: el frontend recibe un error estructurado en vez de un fallo genérico.

Actualizaciones técnicas

Cambios transparentes para el usuario:

• Microsoft IdentityModel actualizado a 8.12.0 (manejo de tokens JWT/Auth0).
• Newtonsoft.Json a 13.0.3.
• MQTTnet a 3.1.2 (bus interno de eventos IoT).
• Jint y Esprima a versiones estables (motor de scripting JavaScript).
• System.Runtime.CompilerServices.Unsafe consolidado a 6.0.0.

Acciones recomendadas

1. Reinicio del app pool (lo realiza el equipo de Cloud Studio en el deploy) — backfilea automáticamente el permiso Client.ReadAllFacilities para todos los clientes existentes.
2. Habilitar campana de notificaciones desde el Monitor — cada usuario debe activar el permiso una vez por dispositivo.
3. Revisar templates de notificación custom si quieren incluir el sector en el mensaje — agregar el placeholder {SECTOR_NAME} donde corresponda.

Soporte

Para consultas, contactar al equipo Cloud Studio: contacto@cloud.studio.