Antworten auf die Fragen, die am häufigsten kommen.

Melden Sie sich bei GCXONE an, öffnen Sie die Konfiguration App und wählen Sie die Hierarchieebene, in der Sie aktivieren möchten – Dienstleister, Kunde, Standort oder Gerät. Wechseln Sie zur Analytik‑Registerkarte, finden Sie Alarm Clip Download in der Analytik‑Liste, klicken Sie auf das Settings‑Symbol, wählen Sie Abonnieren und klicken Sie auf Bestätigen. Neue Alarm‑Ereignisse zeigen dann einen Videoclip‑Button in der Quad-Ansicht für sowohl VAS als auch Salvo. Der Play‑Clip‑Button erscheint nur, wenn das Feature für das Gerät abonniert ist und das Gerät selbst Alarm Clip Download unterstützt, prüfen Sie also die Geräteunterstützung, bevor Sie sich darauf für die Vorfallsdokumentation verlassen.

• In der Konfiguration App die Hierarchieebene auswählen, zur Analytik‑Registerkarte gehen, Alarm Clip Download finden
• Settings‑Symbol, dann Abonnieren und Bestätigen
• Auf Kunden‑ oder Standort‑Ebene aktivieren, um jedes darunterliegende Gerät abzudecken
• Zuerst prüfen, ob das Gerät Alarm Clip Download unterstützt

Die häufigste Ursache ist die Basis‑Bewegungserkennung, die bei jeder Pixeländerung auslöst, einschließlich Wind, Regen, Reflektionen und Insekten. Der Wechsel zu Intelligentes Video‑System (IVS)‑Ereignissen zielt nur auf reale Aktivitäten: Line‑Crossing‑Detection feuert, wenn ein Objekt eine definierte Linie überschreitet, Intrusionserkennung, wenn ein Objekt in eine definierte Zone eintritt, und Human/Fahrzeug‑Filter nutzen Edge‑AI, um andere Bewegungen zu ignorieren, bevor ein Signal gesendet wird. Sie können außerdem die Bewegungsempfindlichkeit senken, die minimale Objektgröße erhöhen oder eine anhaltende Erkennungsdauer verlangen, bevor ein Alarm gesendet wird. Der Testclient des Herstellers bestätigt zunächst, ob das Gerät selbst überflutet.

• Line‑Crossing‑Detection und Intrusionserkennung ersetzen die Basis‑Bewegungserkennung
• Human/Fahrzeug‑Filter entfernen andere Bewegungen am Rand
• Empfindlichkeit senken oder minimale Objektgröße erhöhen
• Anhaltende Bewegung verlangen (z. B. 2 Sekunden), bevor alarmiert wird

Zuweisen. Die Talos‑Queue ist aktiv und jeder Alarm kann einem bestimmten Bediener zugewiesen werden; die Queue zeigt an, wer gerade an welchem Alarm arbeitet, sodass die Teamkoordination auf einen Blick sichtbar ist. Ein nicht zugewiesener Alarm ermöglicht es zwei Personen, ihn gleichzeitig zu übernehmen, daher sollten Sie ihn sofort bei Ankunft zuweisen. Was ein Alarm als Nächstes auslöst, hängt von seinem Typ und der Site‑Konfiguration ab – Talos‑Workflows können den Kunden benachrichtigen, einen Techniker entsenden, eine SMS oder E‑Mail senden, an einen Vorgesetzten eskalieren oder die Reaktion für das Reporting protokollieren.

Ja. Für Mandanten mit legitimen, hochvolumigen Alarmanforderungen kann das Standard‑Limit von 25 Alarmen erhöht werden, zum Beispiel auf 50 oder 100, indem die benutzerdefinierte Eigenschaft style.overflow.threshold auf Mandanten‑ oder Dienstleister‑Ebene gesetzt wird. Die defaultIsolationDuration, in Minuten auf Dienstleister‑Ebene festgelegt, kann ebenfalls konfiguriert werden, wenn ein Kunde ein anderes Verhalten bei der Benachrichtigungsunterdrückung benötigt. Schwellenwertänderungen müssen mit dem R&D‑Team abgestimmt und erst nach Bestätigung der Legitimität des Volumens angewendet werden, etwa bei einem Industrie‑Standort mit hoher Sensoraktivität, nicht bei einem fehlerhaft konfigurierten Gerät.

Ein Alarm wird immer für einen bestimmten Standort verarbeitet, und Talos sucht in Prioritätsreihenfolge nach einem passenden Workflow: Ein direkt auf diesem Standort konfigurierter Workflow gewinnt, dann einer, der auf die Standortgruppe angewendet wird, danach das globale oder unternehmensweite Fallback. So stellen Sie sicher, dass ein kritischer Standort eine bestimmte Reaktion erhält, indem Sie den Workflow auf Standort‑Ebene anhängen. Jeder Workflow muss mit einem Closing Status wie Falscher Alarm oder Polizei entsandt enden, wodurch Reporting und Journal vollständig bleiben. Verwenden Sie das Glockensymbol auf der Alarms‑Seite, um einen manuellen Testalarm auszulösen und Ihre Logik zu prüfen, bevor er bei Live‑Standorten eingesetzt wird.

• Eingehende Bedingungen kombinieren den Alarmcode, einen Zeitplan und All of (UND)‑ oder One of (ODER)‑Logik
• Automatisierte Workflows eignen sich für routinemäßige technische Signale und können zu einem manuellen Workflow eskalieren, wenn sie nicht gelöst werden
• Die Alarms‑Seite zeigt nicht zugewiesene Alarme links und die Arbeitslast jedes online‑verbundenen Operators rechts

CMS‑Empfänger werden im Marketplace konfiguriert, sodass keine manuelle Protokolleinrichtung erforderlich ist. Öffnen Sie den Marketplace, wählen Sie den Tab Alarm Management System, klicken Sie auf Explore beim gewünschten CMS und dann auf Configure, und geben Sie die DC09‑Empfänger‑IP‑Adresse und den TCP‑Port ein; nicht gelistete Systeme verwenden „Other CMS System“, das dieselben Felder nutzt. Ein neuer Alarm Management System‑Tab erscheint dann unter Konfiguration für jeden Dienstleister, wobei jeder Standort mit seiner DC09‑Account‑ID und dem Verbindungsstatus aufgelistet ist. Bearbeiten Sie die Zeile des Standorts, um die DC09‑Account‑ID einzugeben, die mit dem Identifier auf der CMS‑Seite übereinstimmen muss, sowie optional einen Verschlüsselungsschlüssel, und Alarme dieses Standorts werden automatisch weitergeleitet, sobald sie ausgelöst werden.

• DC09‑basierte Empfänger umfassen Amwin, Lisa, Immix und jedes SIA DC‑09‑System
• Grün bedeutet, dass der Standort konfiguriert ist, rot bedeutet, dass er nicht zugeordnet ist
• Jede DC09‑Account‑ID muss eindeutig sein; Duplikate werden blockiert
• GCXONE fügt einen sicheren Ereignislink mit Vor‑Ereignis‑, Ereignis‑ und Nach‑Ereignis‑Beweisen hinzu

Evalink Talos ist eine cloudbasierte Alarm‑Management‑Plattform, die im Marketplace wie jeder andere Empfänger ausgewählt wird. Klicken Sie auf Konfigurieren und geben Sie die Company ID und den API Key aus Ihrem Talos‑Konto ein. Der API Key muss volle Zugriffsberechtigungen besitzen, und beide Werte finden Sie in den Evalink Talos‑Kontoeinstellungen unter API Access. Nach der Konfiguration erscheinen Alarme, die in GCXONE ausgelöst werden, automatisch in Talos als aktive Ereignisse, die zur Bediener‑Verarbeitung bereitstehen. Ein Anmeldefehler bedeutet, dass die Company ID oder der API Key falsch ist oder der Schlüssel nicht über vollen Zugriff verfügt.

Jeder Endpunkt der Genesis API erwartet ein Token im Request‑Header auth-token, und ein Request ohne dieses liefert den Statuscode 401. Das Token erhalten Sie, indem Sie ein API‑Credential mit POST /proxy/apiToken austauschen. Das Credential wird pro Dienstleister ausgestellt, daher muss der Request den Dienstleister benennen, für den das Token gelten soll.

• Der Header ist auth-token und wird bei jedem Request gesendet
• Ein fehlendes oder abgelehntes Token liefert 401
• GET /user/me gibt das Konto zurück, zu dem das Token gehört

Die Genesis‑Plattform stellt eine REST‑API über HTTPS bereit, und jede Anfrage wird gegen eine Basis‑URL, https://api.nxgen.cloud/api/v1, gestellt. Jeder Pfad in der Referenz ist relativ dazu, sodass GET /user/me bedeutet GET https://api.nxgen.cloud/api/v1/user/me. Anfragen enthalten ein Token im auth-token‑Header und die API liefert JSON. Die veröffentlichte Spezifikationsversion ist 1.0.0.

Die Zugangsdaten accessId und clientSecret werden in der Genesis-Plattform unter den Einstellungen des Dienstleisters bereitgestellt. Sie tauschen diese Zugangsdaten gegen ein Token mit POST /proxy/apiToken aus, das die Statuscodes 200, 204, 400, 401 und 403 zurückgibt. Bewahren Sie das clientSecret auf Ihrem Server auf: Ein Token kann an einen Browser gesendet werden, aber die Zugangsdaten, die es erzeugen, dürfen nicht weitergegeben werden.

Ja. GET /user/me gibt das Konto zurück, dem das Token zugeordnet ist, was die schnellste Prüfung ist, ob ein Token funktioniert. Ein fehlendes oder abgelehntes Token liefert stattdessen 401.

Die interaktive Referenz unter /api-reference ist dieselbe Spezifikation in Swagger UI, und der Überblick listet jede Ressource auf. Klicken Sie auf Authorize, fügen Sie ein Token ein, und jedes Try it out‑Panel sendet es als auth-token. Das Token bleibt in Ihrem Browser; die Anfragen werden direkt von dort an https://api.nxgen.cloud/api/v1 gesendet.

401 bedeutet, dass das Token fehlte oder abgelehnt wurde, und 403 bedeutet, dass es gültig war, aber keine Berechtigung für die Ressource hat. Die Antworttabelle zu jeder Operation listet alle Status auf, die die Spezifikation dafür deklariert, behandeln Sie diese Tabelle also als die Liste der möglichen Rückgabewerte.

Pfadparameter werden in geschweiften Klammern geschrieben, z. B. /site/{id}, und Sie ersetzen den gesamten Platzhalter inklusive der Klammern. Anfragetexte sind JSON, sofern nicht ausdrücklich etwas anderes angegeben ist. Auf diesen Seiten wird ein Anfragetext als Skelett dargestellt: die Feldnamen mit dem erwarteten Typ anstelle jedes Wertes und (required) bei den Feldern, die vorhanden sein müssen.

Der Überblick listet 26 Ressourcen mit ihren Vorgangszahlen auf: 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 und Developer Tools. Site ist die größte Oberfläche und Event Search, Proxy, Dashboard und Developer Tools haben jeweils einen Vorgang.

• Site 19 Vorgänge, 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 ruft die Geräteliste mit Filterung, Sortierung und Pagination ab. Es ermöglicht die Suche auf hierarchischer Ebene, sodass nach einer angegebenen Hierarchie gefiltert werden kann oder die Hierarchie des angemeldeten Benutzers verwendet wird, und es bietet die Möglichkeit, zusätzliche Entitätsfelder sowie Konfigurations‑Metadaten zur Entität in der Antwort zu erhalten. Es deklariert 200 Success mit einem Objekt, plus 204, 400, 401 und 403.

• POST /device/filter für die Liste; GET /device/{id} für ein Gerät
• site/filter, sensor/filter und user/filter folgen derselben Struktur

POST /device/ erstellt ein neues Gerät, PUT /device/{id} aktualisiert ein bestehendes und DELETE /device/{id} löscht es anhand der ID. Alle drei geben 200 Success und 204 No Content zusammen mit 400 Invalid input, 401 Unauthorized und 403 Forbidden zurück. GET /device/{id} liest ein einzelnes Gerät aus und fügt 404 Not Found hinzu.

GET /site/{id} liefert eine site anhand der ID und GET /site/ liefert eine site anhand des siteName, während POST /site/filter sites mit Filterung, Sortierung und Pagination auflistet. GET /site/{id}/devices listet die Geräte einer site auf und GET /site/{id}/users die Benutzer dieser site. POST /site/ erstellt eine site, PUT /site/{id} aktualisiert sie und DELETE /site/{id} löscht sie anhand der ID.

• POST /site/listByCustomerIds ruft sites anhand einer Kunden-ID-Liste ab.
• POST /site/search durchsucht sites für die App.
• GET /site/id/{id}/app liefert site-Informationen anhand der site-ID für die App.

Ja. PUT /site/arming?siteId={siteId}&action={action} aktualisiert das Scharf‑ und Entschärfen per Site ID, und PUT /site/arming?siteName={siteName}&action={action} erledigt das gleiche per Site‑Name, wobei action als boolescher Wert interpretiert wird. GET /site/arming/info/{id} liefert die Scharf‑Schalt‑Details für eine Site ID und GET /site/arming/infoByName liefert die Scharf‑Schalt‑Details per Site‑Name. Isolation bietet das gleiche Paar: PUT /site/isolate?siteId={siteId}&enable={enable} und PUT /site/isolate?siteName={siteName}&enable={enable}.

• isolateStartTime und duration sind bei den Isolationsaufrufen optional.
• GET /site/isolation/infoByName liest den Zustand nach Site-Name.

GET /cameraControls/getStream liefert die Streaming‑Details eines Sensors: sensorId ist erforderlich, channelId, startTime und endTime sind optional. GET /cameraControls/getSnapshot liefert Snapshot‑Details für einen Sensor und erfordert sensorUniqueId und deviceUniqueId, mit einem optionalen dateTime. GET /cameraControls/clipInfo holt Clip‑Info für die Zeitleiste von id, startDate und endDate, die Daten werden als Epoch‑Zeit angegeben.