Les réponses aux questions les plus fréquentes.

Trois. Confirmer comme Réel escalade l’alarme et déclenche le flux de travail configuré, qui peut appeler un technicien, envoyer un SMS ou un courriel, ou contacter le client. Marquer comme Fausse alarme la clôture comme un faux positif et renvoie cette décision aux analyses NOVA99x. Escalader la transmet à un superviseur ou à un opérateur de niveau supérieur. Quelle que soit votre sélection, clôturer l’alarme avec une note de résolution — elle est enregistrée dans le Journal d’audit avec l’opérateur qui l’a traitée, l’heure, les étapes effectuées et le résultat.

• Utiliser Masque pour les zones qui génèrent continuellement des fausses alarmes plutôt que de les rejeter une à une
• Une note de résolution sur chaque alarme est ce qui maintient le Journal d’audit et les rapports propres

L’assigner. La file d’attente Talos est En direct et chaque Alarme peut être assignée à un opérateur spécifique, la file indique qui travaille actuellement sur chaque Alarme, de sorte que la coordination d’équipe est visible d’un seul coup d’œil. Laisser une Alarme non assignée permet à deux personnes de la prendre simultanément, il faut donc l’assigner immédiatement à son arrivée. Ce qu’une Alarme déclenche ensuite dépend de son type et de la configuration de la LOCATION — les flux de travail Talos peuvent notifier le Client, dépêcher un technicien, envoyer un SMS ou un courriel, escalader vers un superviseur, ou enregistrer la réponse pour le reporting.

La cause première la plus fréquente est la Détection de Mouvement de base, qui se déclenche sur tout changement de pixel, y compris le vent, la pluie, les réflexions et les insectes. Passer aux événements du Système Vidéo Intelligent (IVS) cible uniquement l’activité réelle : la Détection de franchissement de ligne se déclenche lorsqu’un objet traverse une ligne définie, la Détection d'intrusion lorsqu’un objet entre dans une zone définie, et les filtres Humain/Véhicule utilisent une IA en périphérie pour ignorer les autres mouvements avant qu’un signal ne soit envoyé. Vous pouvez également diminuer la sensibilité du mouvement, augmenter la taille minimale de l’objet, ou exiger une durée de détection soutenue avant qu’une alarme ne soit envoyée. Exécuter d’abord le client de test du fabricant confirme si l’appareil lui‑même inonde.

• La Détection de franchissement de ligne et la Détection d'intrusion remplacent la Détection de Mouvement de base
• Les filtres Humain/Véhicule éliminent les autres mouvements en périphérie
• Diminuer la sensibilité ou augmenter la taille minimale de l’objet
• Exiger un mouvement soutenu (par exemple 2 secondes) avant d’alerter

Oui. Pour les locataires ayant des exigences légitimes d’Alarme à haut volume, la limite par défaut de 25 alarmes peut être augmentée, par exemple à 50 ou 100, en utilisant la Propriété personnalisée style.overflow.threshold définie au niveau du locataire ou du Fournisseur de services. Le defaultIsolationDuration, défini en minutes au niveau du Fournisseur de services, peut également être configuré lorsqu’un Client a besoin d’un comportement de suppression de notification différent. Les modifications de seuil doivent être coordonnées avec l’équipe R&D et appliquées uniquement après confirmation que le volume est légitime, comme pour une LOCATION industrielle avec une forte activité de capteurs, plutôt qu’un appareil mal configuré.

Une alarme est toujours traitée pour un site spécifique, et Talos recherche un workflow correspondant par ordre de priorité : un workflow configuré directement sur ce site l’emporte, puis celui appliqué à son groupe de sites, puis le fallback global ou au niveau de l’entreprise. Ainsi, pour garantir qu’un site critique obtienne une réponse particulière, il faut attacher le workflow au niveau du site. Chaque workflow doit se terminer par un Closing Status tel que False Alarm ou Police Dispatched, ce qui maintient le reporting et la traçabilité complets. Utilisez l’icône en forme de cloche sur la page Alarms pour déclencher une alarme de test manuelle et vérifier votre logique avant de la déployer sur des sites réels.

• Les conditions entrantes combinent le code d’alarme, un planning et la logique Tous (AND) ou Un (OR).
• Les flux de travail automatisés conviennent aux signaux techniques de routine et peuvent être escaladés vers un manuel si non résolus.
• La page Alarms affiche les alarmes non assignées à gauche et la charge de travail de chaque opérateur en ligne à droite.

Les récepteurs CMS sont configurés depuis le Marketplace, aucune configuration manuelle de protocole n’est requise. Ouvrir le Marketplace, sélectionner l’onglet Système de gestion d’alarmes, cliquer sur Explorer sur le CMS souhaité puis sur Configurer, et saisir l’adresse IP du récepteur DC09 et le port TCP ; les systèmes non répertoriés utilisent « Other CMS System », qui accepte les mêmes champs. Un nouvel onglet Système de gestion d’alarmes apparaît alors sous Configuration pour chaque Fournisseur de services, où chaque Location est répertoriée avec son ID de compte DC09 et son statut de connexion. Modifier la ligne d’une Location pour saisir l’ID de compte DC09, qui doit correspondre à l’identifiant côté CMS, ainsi qu’une clé de chiffrement facultative, et les alarmes de cette Location sont transmises automatiquement lorsqu’elles sont déclenchées.

• Les récepteurs basés sur DC09 incluent Amwin, Lisa, Immix et tout système SIA DC-09.
• Vert indique que la Location est configurée, rouge indique qu’elle n’est pas mappée.
• Chaque ID de compte DC09 doit être unique ; les doublons sont bloqués.
• GCXONE ajoute un lien d’événement sécurisé avec des preuves pré-événement, événement et post-événement.

Evalink Talos est une plateforme de gestion d’alarmes cloud sélectionnée dans le Marketplace comme tout autre récepteur. Cliquez sur Configurer et saisissez le Company ID et l’API Key de votre compte Talos. L’API Key doit disposer d’autorisations d’accès complet, et les deux valeurs se trouvent dans les paramètres de votre compte Evalink Talos sous API Access. Une fois configuré, les alarmes déclenchées dans GCXONE apparaissent automatiquement dans Talos en tant qu’événements actifs prêts à être traités par l’opérateur. Une erreur d’identification indique que le Company ID ou l’API Key est incorrect, ou que la clé ne possède pas l’accès complet.

Chaque point de terminaison de l’API Genesis attend un jeton dans l’en‑tête de requête auth-token, et une Demande sans celui‑ci renvoie 401. Vous obtenez ce jeton en échangeant un identifiant d’API avec POST /proxy/apiToken. L’identifiant est délivré par Fournisseur de services, ainsi la Demande indique le fournisseur pour lequel le jeton doit être utilisé.

• L’en‑tête est auth-token, envoyé à chaque Demande
• Un jeton manquant ou rejeté renvoie 401
• GET /user/me renvoie le compte auquel appartient le jeton

La plateforme Genesis expose une API REST via HTTPS, et chaque Demande est effectuée contre une URL de base unique, https://api.nxgen.cloud/api/v1. Chaque chemin de la référence est relatif à celle‑ci, ainsi GET /user/me signifie GET https://api.nxgen.cloud/api/v1/user/me. Les Demandes transportent un jeton dans l’en‑tête auth-token et l’API renvoie du JSON. La version de la spécification publiée est 1.0.0.

Les accessId et clientSecret des informations d’identification sont délivrés dans la plateforme Genesis sous les paramètres du Fournisseur de services. Vous échangez ces informations d’identification contre un jeton avec POST /proxy/apiToken, qui renvoie les codes 200, 204, 400, 401 et 403. Conservez le secret sur votre serveur : un jeton peut être envoyé à un navigateur, mais l’information d’identification qui le crée ne doit pas l’être.

Oui. GET /user/me renvoie le compte auquel le jeton appartient, ce qui constitue la vérification la plus rapide du bon fonctionnement d’un jeton. Un jeton manquant ou rejeté renvoie 401.

La référence interactive à /api‑reference est la même spécification dans Swagger UI, et l’Aperçu répertorie chaque ressource. Appuyer sur Autoriser, coller un token, et chaque panneau Essayer cette fonction envoie le token comme auth‑token. Le token reste dans votre navigateur ; les demandes sont envoyées directement depuis celui‑ci vers https://api.nxgen.cloud/api/v1.

401 signifie que le jeton était absent ou rejeté, et 403 signifie qu’il était valide mais que l’accès à la ressource n’est pas autorisé. Le tableau de réponses de chaque opération répertorie tous les statuts déclarés par la spécification, il faut donc considérer ce tableau comme la liste des valeurs que l’appel peut renvoyer.

Les paramètres de chemin sont écrits entre accolades, comme dans /site/{id}, et vous remplacez l’ensemble du paramètre, accolades incluses. Les corps de demande sont au format JSON sauf indication contraire d’une opération. Sur ces pages, un corps est présenté sous forme de squelette : les noms de champ suivis du type attendu à la place de chaque valeur, et (required) sur les champs qui doivent être présents.

L'aperçu répertorie 26 ressources avec le nombre d'opérations : User, Account, Site, Device, Sensor, Camera Controls, Event, Event Search, IO, Trigger, Proxy, Storage Service, Analytics, Status View, Blog, Contact, Dashboard, Folder, Integration, Audit, Report Template, Report, Schedule, Service Requests, Service Request Tab et Developer Tools. Site est la plus étendue et Event Search, Proxy, Dashboard et Developer Tools ne comportent qu'une seule opération chacun.

• Site 19 opérations, Account 11, Sensor 9, Device 8
• Report 8, IO 7, Camera Controls 6, User 6, Blog 6
• Audit 5, Analytics 4, Contact 4, Storage Service 4

POST /device/filter récupère la liste des appareils avec filtrage, tri et pagination. Il permet la recherche par niveau hiérarchique, il peut donc être filtré en utilisant une hiérarchie spécifiée ou il utilise la hiérarchie de l'utilisateur connecté, et il offre la possibilité d'obtenir des champs d'entité supplémentaires dans la réponse ainsi que les métadonnées de configuration de l'entité. Il déclare 200 Success avec un objet, ainsi que 204, 400, 401 et 403.

• POST /device/filter pour la liste ; GET /device/{id} pour un appareil
• site/filter, sensor/filter et user/filter suivent la même forme

POST /device/ crée un nouvel appareil, PUT /device/{id} met à jour un appareil existant et DELETE /device/{id} le supprime par identifiant. Les trois déclarent 200 Success et 204 No Content ainsi que 400 Invalid input, 401 Unauthorized et 403 Forbidden. GET /device/{id} lit un seul appareil et ajoute 404 Not Found.

GET /site/{id} renvoie un site par son ID et GET /site/ renvoie un site par son nom (siteName), tandis que POST /site/filter répertorie les sites avec filtrage, tri et pagination. GET /site/{id}/devices répertorie les appareils d’un site et GET /site/{id}/users les utilisateurs associés. POST /site/ crée un site, PUT /site/{id} le met à jour et DELETE /site/{id} le supprime par son ID.

• POST /site/listByCustomerIds récupère les sites à partir d’une liste d’ID client.
• POST /site/search recherche les sites pour l’application.
• GET /site/id/{id}/app renvoie les informations du site par son ID pour l’application.

Oui. PUT /site/arming?siteId={siteId}&action={action} met à jour l'armement et le désarmement par siteID, et PUT /site/arming?siteName={siteName}&action={action} effectue la même opération par siteName, l'action étant un booléen. GET /site/arming/info/{id} renvoie le détail de l'armement pour un id de site et GET /site/arming/infoByName renvoie les détails de l'armement par nom de site. L'Isolation propose la même paire, PUT /site/isolate?siteId={siteId}&enable={enable} et PUT /site/isolate?siteName={siteName}&enable={enable}.

• isolateStartTime et duration sont optionnels sur les appels isolate.
• GET /site/isolation/infoByName lit l'état par nom de site

GET /cameraControls/getStream renvoie les détails du flux d’un capteur : sensorId est obligatoire, et channelId, startTime et endTime sont optionnels. GET /cameraControls/getSnapshot renvoie les détails de la capture d’un capteur et nécessite sensorUniqueId et deviceUniqueId, avec un paramètre optionnel dateTime. GET /cameraControls/clipInfo récupère les informations de clip pour la chronologie à partir de id, startDate et endDate, les dates étant fournies en temps epoch.