Respuestas a las preguntas más frecuentes.

Sí. Incluso cuando los recuentos individuales de dispositivos pasan por GCXONE, la capa CMS (Evalink Talos) aplica su propia lógica de desbordamiento a nivel de sitio, agregando alarmas de todos los sensores en ese sitio. Por ejemplo, dos dispositivos que envían 15 alarmas cada uno están por debajo del umbral de 25 por dispositivo, por lo que GCXONE los permite, pero Talos ve 30 alarmas para el sitio y las bloquea. En Talos esto aparece como el código de error Alarm Limit Exceeded.

Asignela. La cola de Talos está en vivo y cada alarma puede asignarse a un operador específico, y la cola muestra quién está trabajando actualmente en cada una, de modo que la coordinación del equipo es visible de un vistazo. Dejar una alarma sin asignar es lo que permite que dos personas la tomen simultáneamente, por lo que debe asignarse inmediatamente al llegar. Lo que una alarma desencadena a continuación depende de su tipo y de la configuración del sitio: los flujos de trabajo de Talos pueden notificar al Cliente, despachar a un técnico, enviar un SMS o Correo, escalar a un supervisor, o registrar la respuesta para el Informe.

La causa raíz más frecuente es la Detección de Movimiento Básica, que se activa con cualquier cambio de píxel, incluidos viento, lluvia, reflejos e insectos. Cambiar a eventos del Sistema de Video Inteligente (IVS) apunta solo a actividad real: la Detección de cruce de línea se dispara cuando un objeto cruza una línea definida, la Detección de intrusos cuando un objeto entra en una zona definida, y los filtros de Humano/Vehículo utilizan IA en el borde para ignorar otros movimientos antes de que se envíe cualquier señal. También puede reducir la sensibilidad al movimiento, aumentar el tamaño mínimo del objeto o requerir una duración sostenida de detección antes de que se envíe una alarma. Ejecutar primero el cliente de prueba del fabricante confirma si el propio dispositivo está generando inundación.

• La Detección de cruce de línea y la Detección de intrusos sustituyen la Detección de Movimiento Básica
• Los filtros de Humano/Vehículo descartan otros movimientos en el borde
• Reducir la sensibilidad o aumentar el tamaño mínimo del objeto
• Requerir movimiento sostenido (por ejemplo, 2 segundos) antes de generar la alarma

Sí. Para inquilinos con requisitos legítimos de alto volumen de Alarma, el límite predeterminado de 25 Alarmas puede incrementarse, por ejemplo a 50 o 100, mediante la Propiedad personalizada style.overflow.threshold configurada a nivel de Cliente o Proveedor de servicio. El defaultIsolationDuration, establecido en minutos a nivel de Proveedor de servicio, también puede configurarse cuando un Cliente necesita un comportamiento diferente de supresión de notificaciones. Los cambios de umbral deben coordinarse con el equipo de I+D y aplicarse solo después de confirmar que el volumen es legítimo, como en un sitio industrial con alta actividad de sensores, y no por un Dispositivo mal configurado.

Una alarma siempre se procesa para un sitio específico, y Talos busca un flujo de trabajo coincidente en orden de prioridad: gana un flujo de trabajo configurado directamente en ese sitio, luego uno aplicado a su grupo de sitios, y finalmente el de respaldo global o a nivel de empresa. Por lo tanto, la forma de garantizar que un sitio crítico reciba una respuesta determinada es Adjuntar el flujo de trabajo a nivel de sitio. Cada flujo de trabajo debe terminar con un Estado de cierre como Falsa alarma o Policía despachada, que es lo que mantiene completo el informe y la Auditoría. Use el ícono de campana en la página de Alarmas para generar una alarma de prueba manual y comprobar su lógica antes de que se acerque a sitios En Vivo.

• Las condiciones entrantes combinan el código de alarma, un horario y lógica de Todos (AND) o Uno (OR)
• Los flujos de trabajo automatizados se adaptan a señales técnicas rutinarias y pueden escalar a uno manual si no se resuelven
• La página de Alarmas muestra las alarmas no asignadas a la izquierda y la carga de trabajo de cada operador en línea a la derecha

Los receptores CMS se configuran desde el Marketplace, por lo que no es necesario configurar manualmente el protocolo. Abra el Marketplace, seleccione la pestaña Sistema de gestión de alarmas, haga clic en Explorar en el CMS que desee y luego en Configurar, e introduzca la Dirección IP del receptor DC09 y el Port TCP; los sistemas no listados utilizan "Other CMS System", que emplea los mismos campos. Entonces aparece una nueva pestaña Sistema de gestión de alarmas bajo Configuración para cada Proveedor de servicio, donde cada Lugar se muestra con su ID de cuenta DC09 y el estado de la Conexión. Edite la fila del Lugar para introducir el ID de cuenta DC09, que debe coincidir con el identificador en el lado del CMS, más una clave de cifrado opcional, y las Alarmas de ese Lugar se reenviarán automáticamente cuando se activen.

• Los receptores basados en DC09 incluyen Amwin, Lisa, Immix y cualquier sistema SIA DC-09
• Verde indica que el Lugar está configurado, rojo indica que no está asignado
• Cada ID de cuenta DC09 debe ser único; los duplicados se bloquean
• GCXONE añade un enlace de evento seguro con evidencia pre‑evento, evento y post‑evento

Evalink Talos es una plataforma de gestión de alarmas basada en la nube que se selecciona del Marketplace como cualquier otro receptor. Haga clic en Configurar e introduzca el Company ID y la API Key de su cuenta Talos. La API Key necesita permisos de acceso completo, y ambos valores se encuentran en la configuración de su cuenta Evalink Talos bajo API Access. Una vez configurado, las alarmas activadas en GCXONE aparecen en Talos automáticamente como eventos activos listos para el procesamiento del operador. Un error de credenciales indica que el Company ID o la API Key son incorrectos, o que la clave no tiene acceso completo.

Cada punto final en la Genesis API espera un token en el encabezado auth-token de la solicitud, y una solicitud sin él responde 401. Obtenga ese token intercambiando una credencial API con POST /proxy/apiToken. La credencial se emite por Proveedor de servicio, por lo que la solicitud indica el proveedor para el que debe actuar el token.

• El encabezado es auth-token, enviado en cada solicitud
• Un token ausente o rechazado responde 401
• GET /user/me devuelve la cuenta a la que pertenece el token

La plataforma Genesis expone una API REST sobre HTTPS, y cada solicitud se realiza contra una única URL base, https://api.nxgen.cloud/api/v1. Cada ruta en la referencia es relativa a ella, por lo que GET /user/me equivale a GET https://api.nxgen.cloud/api/v1/user/me. Las solicitudes llevan un token en el encabezado auth-token y la API responde con JSON. La Versión de la especificación publicada es 1.0.0.

El accessId y el clientSecret de la credencial se emiten en la plataforma Genesis bajo la configuración del proveedor de servicios. Intercambie esa credencial por un token mediante POST /proxy/apiToken, que devuelve 200, 204, 400, 401 y 403. Mantenga el secreto en su servidor: un token puede enviarse a un navegador, pero la credencial que lo genera no debe enviarse al navegador.

Sí. GET /user/me devuelve la cuenta a la que pertenece el token, lo que constituye la verificación más rápida de que un token funciona. Un token que falta o es rechazado responde con 401.

La referencia interactiva en /api-reference es la misma especificación en Swagger UI, y la visión general enumera cada recurso. Pulse Autorizar, pegue un token, y cada panel Probar envía el token como auth-token. El token permanece en su navegador; las solicitudes van directamente desde él a https://api.nxgen.cloud/api/v1.

401 indica que el token estaba ausente o fue rechazado, y 403 indica que era válido pero no tiene derecho al recurso. La tabla de respuestas en cada operación enumera todos los estados que la Especificación declara para ella, por lo que debe considerarse esa tabla como la lista de lo que la llamada puede devolver.

Los parámetros de ruta se escriben entre llaves, como en /site/{id}, y se reemplaza todo el marcador de posición, incluidas las llaves. Los cuerpos de solicitud son JSON a menos que una operación indique lo contrario. En estas páginas, un cuerpo se muestra como un esqueleto: los nombres de los campos con el tipo esperado en lugar de cada valor, y (required) en los campos que deben estar presentes.

El Resumen enumera 26 recursos con sus recuentos de operaciones: Usuario, Cuenta, Sitio, Dispositivo, Sensor, Controles de cámara, Evento, Búsqueda de eventos, IO, Disparador, Proxy, Servicio de almacenamiento, Analítica, Vista de estado, Blog, Contacto, Panel, Carpeta, Integración, Auditoría, Plantilla de informe, Informe, Programación, Solicitudes de servicio, Pestaña de solicitud de servicio y Herramientas de desarrollo. Sitio es la mayor superficie y Búsqueda de eventos, Proxy, Panel y Herramientas de desarrollo tienen una única operación cada una.

• Sitio 19 operaciones, Cuenta 11, Sensor 9, Dispositivo 8
• Informe 8, IO 7, Controles de cámara 6, Usuario 6, Blog 6
• Auditoría 5, Analítica 4, Contacto 4, Servicio de almacenamiento 4

POST /device/filter obtiene la lista de Dispositivos con filtrado, ordenación y paginación. Permite la búsqueda por nivel jerárquico, por lo que puede filtrarse usando una jerarquía especificada o la jerarquía del usuario autenticado, y ofrece la opción de obtener campos de entidad adicionales en la respuesta así como metadatos de Configuración sobre la entidad. Declara 200 Success con un objeto, además de 204, 400, 401 y 403.

• POST /device/filter para la lista; GET /device/{id} para un Dispositivo
• site/filter, sensor/filter y user/filter siguen la misma estructura

POST /device/ crea un nuevo dispositivo, PUT /device/{id} actualiza uno existente y DELETE /device/{id} lo elimina por id. Los tres devuelven 200 Success y 204 No Content, así como 400 Invalid input, 401 Unauthorized y 403 Forbidden. GET /device/{id} lee un único dispositivo y devuelve 404 Not Found.

GET /site/{id} devuelve un sitio por id y GET /site/ devuelve uno por siteName, mientras que POST /site/filter enumera los sitios con filtrado, ordenación y paginación. GET /site/{id}/devices enumera los Dispositivos bajo un sitio y GET /site/{id}/users los Usuarios bajo él. POST /site/ crea un sitio, PUT /site/{id} lo actualiza y DELETE /site/{id} lo elimina por id.

• POST /site/listByCustomerIds obtiene sitios a partir de una lista de IDs de cliente
• POST /site/search busca sitios para la app
• GET /site/id/{id}/app devuelve información del sitio por ID del sitio para la app

Sí. PUT /site/arming?siteId={siteId}&action={action} actualiza el armado y desarmado por Id. del sitio, y PUT /site/arming?siteName={siteName}&action={action} hace lo mismo por nombre del sitio, con action tomado como booleano. GET /site/arming/info/{id} devuelve el detalle del armado para un Id. del sitio y GET /site/arming/infoByName devuelve los detalles del armado por nombre del sitio. Aislamiento ofrece el mismo par, PUT /site/isolate?siteId={siteId}&enable={enable} y PUT /site/isolate?siteName={siteName}&enable={enable}.

• isolateStartTime y duration son opcionales en las llamadas de Aislar
• GET /site/isolation/infoByName lee el estado por nombre del sitio

GET /cameraControls/getStream devuelve el detalle de transmisión de un sensor: sensorId es obligatorio, y channelId, startTime y endTime son opcionales. GET /cameraControls/getSnapshot devuelve el detalle de la instantánea para un sensor y requiere sensorUniqueId y deviceUniqueId, con un dateTime opcional. GET /cameraControls/clipInfo obtiene la información del clip para la línea de tiempo a partir de id, startDate y endDate, las fechas se proporcionan como tiempo epoch.