Antwoorden op de vragen die we het vaakst krijgen.

Drie. Bevestig als Echt escaleert het alarm en activeert de geconfigureerde workflow, die een technicus kan oproepen, een SMS of Email kan verzenden, of de Klant kan contacteren. Mark as False sluit het als een vals alarm en voedt die beslissing terug in NOVA99x Analyse. Escalate geeft het aan een supervisor of een operator op hoger niveau. Welke optie u ook kiest, sluit het alarm af met een resolutienotitie – deze wordt opgeslagen in het Audit Log met de operator die het heeft afgehandeld, de tijd, de ondernomen stappen en het resultaat.

• Gebruik Masker voor zones die voortdurend vals alarm genereren in plaats van elk alarm af te wijzen
• Een resolutienotitie bij elk alarm houdt het Audit Log en de Rapportage schoon

De meest voorkomende oorzaak is Basic Motion Detection, die wordt geactiveerd bij elke pixelverandering, inclusief wind, regen, Reflectie en insecten. Overschakelen naar Intelligent Video System (IVS)‑gebeurtenissen richt zich alleen op echte activiteit: Line Crossing Detection wordt geactiveerd wanneer een object een gedefinieerde lijn kruist, Intrusion Detection wanneer een object een gedefinieerde zone betreedt, en Human/Vehicle‑filters gebruiken edge‑side AI om andere beweging te negeren voordat een signaal wordt verzonden. U kunt ook de gevoeligheid van Beweging verlagen, de minimale objectgrootte verhogen, of een voortgezette detectieduur eisen voordat een alarm wordt verzonden. Het eerst uitvoeren van de testclient van de fabrikant bevestigt of het apparaat zelf de flood veroorzaakt.

• Line Crossing en Intrusion Detection vervangen Basic Motion Detection
• Human/Vehicle-filters negeren andere beweging aan de rand
• Gevoeligheid verlagen of de minimale objectgrootte verhogen
• Vereis voortgezette beweging (bijvoorbeeld 2 seconden) vóór alarm

Wijs het toe. De Talos-wachtrij is live en elk alarm kan aan een specifieke operator worden toegewezen, en de wachtrij toont wie momenteel aan elk alarm werkt, zodat teamcoördinatie in één oogopslag zichtbaar is. Een alarm niet-toegewezen laten is wat twee personen in staat stelt het tegelijk op te pakken, dus wijs het onmiddellijk toe bij aankomst. Wat een alarm vervolgens activeert, hangt af van het type en de configuratie van de site – Talos-workflows kunnen de klant informeren, een technicus inschakelen, een SMS of e‑mail sturen, escaleren naar een supervisor, of de respons loggen voor rapportage.

Ja. Voor huurders met legitieme hoge‑volume alarmvereisten kan de standaardlimiet van 25 alarmen worden verhoogd, bijvoorbeeld naar 50 of 100, door de Custom Property style.overflow.threshold in te stellen op tenant‑ of serviceprovider‑niveau. De DefaultIsolationDuration, ingesteld in minuten op serviceprovider‑niveau, kan eveneens worden geconfigureerd wanneer een klant ander gedrag voor onderdrukking van meldingen nodig heeft. Drempelwijzigingen moeten worden afgestemd met het R&D‑team en alleen worden toegepast na bevestiging dat het volume legitiem is, zoals bij een industriële locatie met hoge sensoractiviteit, en niet bij een verkeerd geconfigureerd apparaat.

Een alarm wordt altijd verwerkt voor één specifieke locatie, en Talos zoekt een passende workflow in prioriteitsvolgorde: een workflow die direct op die locatie is geconfigureerd heeft voorrang, daarna een workflow die op de locatie‑groep is toegepast, vervolgens de globale of bedrijfs‑fallback. Om te garanderen dat een kritieke locatie een specifieke respons krijgt, moet u de workflow op locatieniveau Bijvoegen. Elke workflow moet eindigen met een Closing Status, zoals Vals alarm of Police Dispatched, wat de rapportage en het audit‑trail compleet houdt. Gebruik het bel‑icoon op de Alarmen‑pagina om een handmatig testalarm te activeren en uw logica te controleren voordat deze bij live locaties wordt ingezet.

• Inkomende voorwaarden combineren de alarmcode, een planning, en All of (AND) of One of (OR) logica
• Geautomatiseerde workflows zijn geschikt voor routinematige technische signalen en kunnen opschalen naar een handmatige workflow indien onopgelost.
• De Alarmen‑pagina toont ontoegewezen alarmen links en de werklast van elke online operator rechts

CMS-ontvangers worden geconfigureerd vanuit de Marketplace, dus handmatige protocolinstelling is niet nodig. Open de Marketplace, selecteer het tabblad Alarm Management System, klik op Verkennen op de gewenste CMS en vervolgens op Configureren, en voer het IP-adres van de DC09-ontvanger en de TCP poort in; niet‑geregistreerde systemen gebruiken "Other CMS System", die dezelfde velden gebruikt. Er verschijnt vervolgens een nieuw tabblad Alarm Management System onder Configuratie voor elke dienstverlener, waar elke Plaats wordt weergegeven met zijn DC09 Account ID en verbindingsstatus. Bewerk een Plaats‑rij om het DC09 Account ID in te voeren, dat moet overeenkomen met de identifier aan de CMS‑kant, plus een optionele coderingssleutel, en Alarmen van die Plaats worden automatisch doorgestuurd wanneer ze worden geactiveerd.

• DC09‑gebaseerde ontvangers omvatten Amwin, Lisa, Immix en elk SIA DC-09‑systeem
• Groen betekent dat de Plaats is geconfigureerd, rood betekent dat deze niet is gekoppeld
• Elk DC09 Account ID moet uniek zijn; duplicaten worden geblokkeerd
• GCXONE voegt een beveiligde gebeurteniskoppeling toe met pre‑event, event en post‑event bewijs

Evalink Talos is een cloudgebaseerd alarmbeheersplatform dat u vanuit de Marketplace selecteert zoals elke andere receiver. Klik op Configureren en voer de Bedrijfs-ID en API‑Key uit uw Talos‑account in. De API‑Key vereist volledige toegangspermissies, en beide waarden staan in uw Evalink Talos‑accountinstellingen onder API‑Access. Na configuratie verschijnen alarmen die in GCXONE worden geactiveerd automatisch in Talos als actieve gebeurtenissen die klaar zijn voor operatorverwerking. Een inlogfout betekent dat de Bedrijfs-ID of API‑Key onjuist is, of dat de sleutel niet over volledige toegang beschikt.

Elk eindpunt in de Genesis API verwacht een token in de auth-token request‑header, en een verzoek zonder token beantwoordt met 401. U verkrijgt dat token door een API‑credential uit te wisselen met POST /proxy/apiToken. De credential wordt per serviceprovider uitgegeven, zodat het verzoek de provider benoemt waarvoor het token moet gelden.

• De header is auth-token, verzonden bij elk verzoek
• Een ontbrekend of afgewezen token beantwoordt met 401
• GET /user/me retourneert het account waartoe het token behoort

Het Genesis‑platform biedt een REST API via HTTPS, en elk verzoek wordt gedaan tegen één basis-URL, https://api.nxgen.cloud/api/v1. Elk pad in de referentie is relatief ten opzichte daarvan, dus GET /user/me betekent GET https://api.nxgen.cloud/api/v1/user/me. Verzoeken dragen een token in de auth-token header en de API beantwoordt JSON. De gepubliceerde Specificatie‑versie is 1.0.0.

De accessId en clientSecret van de credential worden uitgegeven in het Genesis‑platform onder de instellingen van de serviceprovider. U wisselt die credential in voor een token met POST /proxy/apiToken, waarbij 200, 204, 400, 401 en 403 worden geretourneerd. Bewaar het geheim op uw server: een token kan naar een browser worden gestuurd, maar de credential die het genereert mag dat niet.

Ja. GET /user/me retourneert het account waartoe de token behoort, wat de snelste controle is dat een token werkt. Een token die ontbreekt of wordt afgewezen, geeft 401 terug.

De interactieve referentie op /api-reference is dezelfde specificatie in Swagger UI, en het overzicht somt elke resource op. Druk op Authorize, plak een token, en elk Try it out‑paneel verzendt het als auth-token. Het token blijft in uw browser; de verzoeken gaan rechtstreeks daarvan naar https://api.nxgen.cloud/api/v1.

401 betekent dat het token ontbrak of werd afgewezen, en 403 betekent dat het geldig was maar geen recht had op de bron. De responstabel bij elke operatie geeft alle statussen weer die de Specificatie ervoor opgeeft, dus beschouw die tabel als de lijst van wat de oproep kan retourneren.

Padparameters worden tussen accolades geschreven, bijvoorbeeld /site/{id}, en u vervangt de volledige placeholder, accolades inbegrepen. Verzoeklichamen zijn JSON, tenzij een bewerking anders aangeeft. Op deze pagina’s wordt een lichaam weergegeven als een skelet: de veldnamen met het verwachte type in plaats van elke waarde, en (required) bij de velden die aanwezig moeten zijn.

Het overzicht geeft 26 resources weer met hun aantal bewerkingen: User, Account, Site, Apparaat, Sensor, Camera Controls, Event, Event Search, IO, Trigger, Proxy, Storage Service, Analyse, Status View, Blog, Contact, Dashboard, Folder, Integratie, Audit, Rapport Template, Rapport, Schedule, Service Requests, Service Request Tab en Developer Tools. Site is het grootste oppervlak en Event Search, Proxy, Dashboard en Developer Tools hebben elk één bewerking.

• Site 19 bewerkingen, Account 11, Sensor 9, Apparaat 8
• Rapport 8, IO 7, Camera Controls 6, User 6, Blog 6
• Audit 5, Analyse 4, Contact 4, Storage Service 4

POST /device/filter haalt de apparaatlijst op met filteren, sorteren en paginering. Het ondersteunt zoeken op hiërarchisch niveau, zodat het kan worden gefilterd met een opgegeven hiërarchie of de hiërarchie van de aangemelde gebruiker gebruikt, en biedt de mogelijkheid om extra entiteitsvelden in de respons op te nemen evenals configuratiemetagegevens over de entiteit. Het geeft 200 Success met een object, plus 204, 400, 401 en 403.

• POST /device/filter voor de lijst; GET /device/{id} voor één apparaat
• site/filter, sensor/filter en user/filter volgen dezelfde structuur

POST /device/ maakt een nieuw Apparaat, PUT /device/{id} werkt een bestaand Apparaat bij en DELETE /device/{id} verwijdert het op id. Alle drie geven 200 Success en 204 Geen inhoud naast 400 Ongeldige invoer, 401 Niet geautoriseerd en 403 Forbidden. GET /device/{id} leest een enkel Apparaat terug en voegt 404 Not Found toe.

GET /site/{id} retourneert een site op basis van id en GET /site/ retourneert er één op basis van siteName, terwijl POST /site/filter sites lijst met filteren, sorteren en pagineren. GET /site/{id}/devices geeft de apparaten onder een site weer en GET /site/{id}/users de gebruikers ervan. POST /site/ maakt een site aan, PUT /site/{id} werkt deze bij en DELETE /site/{id} verwijdert deze op id.

• POST /site/listByCustomerIds haalt sites op op basis van een lijst met Klant ID's
• POST /site/search zoekt sites voor de app
• GET /site/id/{id}/app retourneert site‑informatie op site‑id voor de app

Ja. PUT /site/arming?siteId={siteId}&action={action} werkt activeren en deactiveren op siteID, en PUT /site/arming?siteName={siteName}&action={action} doet hetzelfde op siteName, waarbij action als een boolean wordt genomen. GET /site/arming/info/{id} geeft de arming‑details voor een site‑ID en GET /site/arming/infoByName geeft arming‑details op site‑naam. Isoleren biedt hetzelfde paar, PUT /site/isolate?siteId={siteId}&enable={enable} en PUT /site/isolate?siteName={siteName}&enable={enable}.

• isolateStartTime en duration zijn optioneel bij de Isoleren‑aanroepen
• GET /site/isolation/infoByName leest de status op site‑naam

GET /cameraControls/getStream retourneert de streaming‑details van een sensor: sensorId is verplicht, en channelId, startTime en endTime zijn optioneel. GET /cameraControls/getSnapshot retourneert snapshot‑details voor een sensor en vereist sensorUniqueId en deviceUniqueId, met een optionele dateTime. GET /cameraControls/clipInfo haalt clipinfo op voor de tijdlijn vanaf id, startDate en endDate, de data opgegeven als epoch‑tijd.