Notruf

Bestätigt einen offenen Duress-Vorfall im Namen des Benutzers: Es wird festgehalten, dass er reagiert, und die weitere Eskalation kann gestoppt werden. Nur offene Vorfälle können bestätigt werden.

Immer zuerst bestätigen lassen. Rufen Sie ohne confirm auf, um den Vorfall abzurufen, teilen Sie dem Benutzer mit, was er bestätigt, und rufen Sie erst nach seiner Zustimmung erneut mit confirm: true auf.

In einem Workflow oder von einem Agent aus funktioniert dies nur, wenn der Reaktionsplan der Einrichtung Workflows erlaubt, Alarme zu bestätigen, aufzulösen und auszulösen. Um einen Vorfall abzuschließen, verwenden Sie duress_resolve_incident.

Liest die Notrufknöpfe einer Einrichtung: ihren Status (Akku, zuletzt empfangen, zuletzt getestet), vollständige Profile (Bezeichnung, Raum, Zone, Platzierung, verknüpfte Kameras, Türen und Bildschirme, stummgeschaltete Warnungen, Überwachungszustand), womit sie verknüpft werden können, die Bildschirme, die ihre Auslösungen weiterleiten, und den Einrichtungstest eines neu hinzugefügten Knopfes.

Akku: low bedeutet 30 % oder weniger (bald ersetzen), critical 20 % oder weniger (jetzt ersetzen). Null bei Akku und lastSeenAt bedeutet, dass noch kein Bildschirm den Knopf empfangen hat. Zeiten sind im ISO-Format.

Aktionen:

• status: Knopfstatus. Jeder Knopf mit Zone, Raum, Akku, wann ein Bildschirm ihn zuletzt empfangen hat und wann er zuletzt getestet wurde. "Funktionieren die Notrufknöpfe?", "Welche brauchen neue Batterien?"
• list: Knopfprofile. Das vollständige Profil jedes Knopfes: was duress_buttons_write update ändert, dazu Signal, die Bildschirme, die ihn am letzten Tag empfangen haben, Überwachungszustand und ein ausstehender Einrichtungstest.
• link_options: Verknüpfungsoptionen. Die Kameras, Türen, Bildschirme und Zugangszonen der Einrichtung, mit denen ein Knopf verknüpft werden kann (IDs für duress_buttons_write update).
• receivers: Knopfempfänger. Die Display Screens der Einrichtung, die Knöpfe empfangen und Auslösungen weiterleiten, und ob jeder online ist. ready ist false, wenn nichts einen Knopf empfangen könnte.
• setup_test: Einrichtungstest. Der Einrichtungstest eines neu hinzugefügten Knopfes: waiting (die erste Auslösung ist nur ein Test), received, expired, ended oder none, und ob ein Bildschirm ihn seit dem Hinzufügen empfangen hat. Erfordert deviceSerialNumber.

Ändert Notrufknöpfe einer Einrichtung: einen neuen Knopf hinzufügen, ihr Profil (Bezeichnung, Raum, Zone, Platzierung, Notizen, verknüpfte Kameras, Türen, Bildschirme und Zugangszone, stummgeschaltete Gerätewarnungen), einen Knopf piepen lassen, damit das Personal ihn findet, den Einrichtungstest eines neuen Knopfes beenden, damit er live geht, und einen Knopf entfernen.

Bei update weggelassene Felder behalten ihre Werte; null löscht sie. Lesen Sie das aktuelle Profil mit duress_buttons_read list.

Aktionen:

• update: Knopf aktualisieren. Speichert das Profil des Knopfes in der Einrichtung, in der er registriert ist (erfordert dort Duress Configuration). zone ist 001 bis 999 und in der Einrichtung eindeutig. alertsMutedUntil (ISO, höchstens 30 Tage im Voraus) schaltet seine Akku- und Offline-Warnungen stumm. Erfordert deviceSerialNumber.
• locate: Knopf piepen lassen. Lässt den Knopf 30 Sekunden lang piepen und blinken, damit das Personal ihn findet, z. B. einen, der ständig einen niedrigen Akkustand meldet. Ein Bildschirm in der Nähe sendet den Befehl, der Knopf muss also in Reichweite eines Bildschirms sein. Nicht, solange er einen offenen Alarm hat. Erfordert deviceSerialNumber.
• go_live: Neuen Knopf live schalten. Beendet den Einrichtungstest eines neu hinzugefügten Knopfes sofort, sodass seine nächste Auslösung ein echter Alarm ist. Prüfen Sie zuerst duress_buttons_read setup_test. Erfordert Geräteverwaltung oder Duress Configuration in der Einrichtung. Erfordert deviceSerialNumber. Fragt nach einer Bestätigung.
• remove: Knopf entfernen. Entkoppelt den Knopf von der Einrichtung und löscht sein Profil, wodurch seine Zone frei wird. Nicht, solange er einen offenen Alarm hat. Erfordert Geräteverwaltung in der Einrichtung. Erfordert deviceSerialNumber. Fragt nach einer Bestätigung.
• add: Knopf hinzufügen. Registriert einen neuen Notrufknopf in der Einrichtung anhand der aufgedruckten Seriennummer. Standardmäßig ist seine erste Auslösung in den nächsten 30 Minuten nur ein Test (setupTest). Die Einrichtung benötigt einen Bildschirm mit aktiviertem Duress alarm monitoring oder ein IoT Gateway. Erfordert Geräteverwaltung in der Einrichtung. Erfordert deviceSerialNumber. Fragt nach einer Bestätigung.

Beendet den laufenden Duress-Test in einer Einrichtung sofort, sodass die nächste Auslösung ein echter Alarm ist. Die Ergebnisse folgen etwa 10 Minuten später, wie bei jedem Test.

Liest Duress-Alarmvorfälle (das Personal hat einen Notrufknopf gedrückt oder ein Workflow hat einen Alarm ausgelöst): Listen, Zeitleiste und Zustellungen eines Vorfalls, einen Nachbetrachtungsbericht und die Videoaufnahmen rund um einen Alarm.

Status: open (noch von niemandem bestätigt), acknowledged (jemand reagiert), resolved (abgeschlossen, mit einer Einstufung: genuine, false_alarm, test oder unknown). active bedeutet open oder acknowledged. Testvorfälle (isTest) stammen aus Knopftests; testType 'unplanned' ist ein als echt ausgelöster Alarm, den eine Einsatzkraft als Test aufgelöst hat.

Zustellstatus: sent, acknowledged (der Empfänger hat bestätigt), failed (siehe error), shadow (Probelauf, nichts wurde gesendet). Zustellungen an die Notrufzentrale werden zusätzlich unter monitoringCentre summiert. Ergebnisse nennen Personen, enthalten aber nie Telefonnummern oder E-Mail-Adressen. Zeiten sind im ISO-Format.

Aktionen:

• list: Vorfälle auflisten. Neueste zuerst. scope: facility (Standard; die angegebene oder verbundene Einrichtung) oder organisation (jede für Sie sichtbare Einrichtung darin; standardmäßig die Organisation der Einrichtung).
• get: Vorfall abrufen. Status, die gedrückten Knöpfe, die Zeitleiste (Auslösungen, Eskalationen, Bestätigungen, Notizen) und jeder Zustellversuch einer Benachrichtigung oder an die Notrufzentrale mit seinem Ergebnis. Erfordert incidentId.
• report: Vorfallbericht. Für eine Nachbetrachtung: der Vorfall, Sekunden bis zur Bestätigung und Auflösung, erreichte Stufen, jeder Eintrag der Zeitleiste, was pro Kanal gesendet wurde und was fehlgeschlagen ist, und ob Aufnahmen aufbewahrt wurden. Kombinieren Sie dies mit duress_incidents_write add_note, um die Nachbetrachtung beim Vorfall zu hinterlegen. Erfordert incidentId.
• footage_previews: Alarmaufnahmen. Jede Kamera in den Aufnahmen des Alarms: ihr Status, Anzahl der Frames und Clips, hochgeladene Clips und der Frame, der der Auslösung am nächsten liegt (posterSeconds). Mit cameraId nur diese Kamera plus die Unix-Sekunden jedes Frames (frameSeconds). Erfordert Videoüberwachung in der Einrichtung. Erfordert incidentId.
• footage_frame: Frame der Alarmaufnahmen. Ein Zeitraffer-Frame aus den Alarmaufnahmen, als Bild zurückgegeben: eine aufbewahrte Kopie, sobald die Aufnahmen aufbewahrt sind, sonst der Live-Frame innerhalb des Alarmzeitfensters. seconds ist ein posterSeconds- oder frameSeconds-Wert aus footage_previews. Erfordert incidentId, cameraId, seconds.

Ändert einen Duress-Vorfall, ohne den Alarm selbst zu berühren: benennt ihn, fügt Notizen des Personals hinzu und bewahrt die Videoaufnahmen rund um den Vorfall auf oder gibt sie frei. Niemand wird alarmiert. Zum Bestätigen, Auflösen oder Informieren der Einsatzkräfte verwenden Sie duress_acknowledge_incident, duress_resolve_incident oder duress_post_update.

Aktionen:

• rename: Vorfall benennen. Benennt den Vorfall, damit er später leicht zu finden ist, z. B. "Aggressiver Besucher am Empfangstresen". Ein leerer oder null-Name entfernt ihn. Namen erscheinen in der Duress-Konsole und in Berichten. Erfordert incidentId.
• add_note: Notiz hinzufügen. Fügt der Zeitleiste des Vorfalls eine Notiz hinzu, z. B. was der Benutzer vorgefunden hat oder wer vor Ort war. Bei jedem Status; nur das Personal sieht Notizen, und sie ändern den Vorfall nicht. Verwenden Sie die Worte des Benutzers und stimmen Sie den Wortlaut zuerst mit ihm ab. Erfordert incidentId, note.
• keep_footage: Alarmaufnahmen aufbewahren. Bewahrt die Videoaufnahmen rund um einen aufgelösten echten Alarm auf, damit sie nicht mit den normalen Aufzeichnungen gelöscht werden, anhand der Minuten und Kameras des Reaktionsplans. Erfolgt einige Minuten später, sobald hochgeladen. Nicht für Tests, offene Alarme oder bereits aufbewahrte oder freigegebene Aufnahmen. Erfordert incidentId.
• release_footage: Aufbewahrte Aufnahmen freigeben. Gibt die für einen Alarm aufbewahrten Aufnahmen auf: Clips kehren zur normalen Aufbewahrung zurück und aufbewahrte Frames werden gelöscht, sodass sie nach Ablauf der normalen Aufzeichnungen nicht mehr angesehen werden können. Erfordert Duress Configuration in der Einrichtung. Erfordert incidentId. Fragt nach einer Bestätigung.

Hebt den Lockdown eines Duress-Alarms auf: Die gesperrten Türen lassen wieder Personen ein. Funktioniert unabhängig vom Status des Alarms.

Zuerst bestätigen lassen. Rufen Sie ohne confirm auf, um den Lockdown zu sehen, informieren Sie den Benutzer und rufen Sie nach seiner Zustimmung erneut mit confirm: true auf.

Sendet ein Update an die Personen, die auf einen Duress-Alarm reagieren, z. B. "Die Polizei ist unterwegs" oder "Entwarnung, die Person ist gegangen". Es erscheint auf ihrer Alarmseite und in der Duress-App, und bei einem echten Alarm kann der Reaktionsplan es zusätzlich per SMS an alle senden, die bereits per SMS über den Alarm informiert wurden. Updates können bis 24 Stunden nach der Auflösung des Alarms gesendet werden.

Zuerst bestätigen lassen. Rufen Sie ohne confirm auf, um den Vorfall zu prüfen, zeigen Sie dem Benutzer den genauen Wortlaut und rufen Sie nach seiner Zustimmung erneut mit confirm: true auf. Für etwas, das nur das Personal sehen soll, verwenden Sie stattdessen duress_incidents_write add_note.

Löst in der Einrichtung einen echten Duress-Alarm aus, als wäre ein Knopf gedrückt worden: Der Reaktionsplan läuft (Personen werden alarmiert, Eskalation und Erinnerungen folgen, Reaktionsaktionen werden ausgeführt), und der Alarm gibt an, dass er von diesem Workflow ausgelöst wurde, mit dem Grund.

• reason: was passiert ist, z. B. "Tür am Hinterausgang aufgebrochen" (bis zu 200 Zeichen).
• deviceSerialNumber: optional. Ein Knopf, dessen Standort verwendet werden soll; nur dann wird auch die Notrufzentrale informiert, mit der Zone dieses Knopfes.

Nur als Workflow-Schritt, in Einrichtungen, deren Reaktionsplan Workflows erlaubt, Alarme zu bestätigen, aufzulösen und auszulösen. Solange der Alarm dieses Workflows offen ist, wird kein weiterer ausgelöst; stattdessen wird dieser Alarm zurückgegeben.

Duress-Compliance-Berichte für eine Einrichtung, Marke oder Organisation: Reaktionszeiten (P50/P95), Vorfälle nach Einstufung und Fehlalarmquote, Testabdeckung und überfällige Einrichtungen, Verfügbarkeit der Knöpfe, Zustellerfolg an die Notrufzentrale und ein Export Vorfall für Vorfall. Dazu die nicht zugestellten Warnungen des letzten Alarms in einer Einrichtung.

Tage gelten in der Ortszeit der Einrichtung; Zeiträume über 400 Tage werden gekürzt (range.capped). Echte Vorfälle und Testvorfälle werden getrennt gezählt. Dauern sind in ms angegeben (p50Ms, p95Ms). Markenberichte umfassen nur die Einrichtungen, auf die Sie zugreifen können, sofern Sie keinen organisationsweiten Zugriff haben (scope.restrictedToAccessibleFacilities).

Aktionen:

• overview: Duress-Berichtsübersicht. Summen, monatlicher Trend und Kennzahlen pro Organisation, Marke und Einrichtung (incidents, testCoverage, deviceUptime, deliveries). Einrichtungen werden seitenweise ausgegeben.
• compliance_summary: Duress-Compliance-Zusammenfassung. Was das Compliance-PDF zeigt: Testabdeckung mit überfälligen Einrichtungen, Verfügbarkeit der Knöpfe, Zustellerfolg, letzte Tests (testHistory) und pro Einrichtung der letzte Test, die letzte Übung und der letzte echte Alarm mit der Verfügbarkeit jedes Knopfes. Einrichtungen werden seitenweise ausgegeben.
• incident_export: Duress-Vorfallexport. Eine Zeile pro Vorfall, älteste zuerst, mit den Spalten des CSV-Exports: Einrichtung, Test oder echt, Status, Einstufung, Ortszeiten, Sekunden bis zur Bestätigung und Auflösung, wer bestätigt und aufgelöst hat, Knöpfe und Anzahl der Zustellungen.
• delivery_problems: Nicht zugestellte Alarmwarnungen. Der letzte Alarm oder Test der Einrichtung (mit seinem gesamten Testzeitfenster) und die Warnungen, die nie angekommen sind, nach Kanal. problems ist null, wenn alles durchgekommen ist. Erfordert dort Duress oder Duress Configuration.

Löst einen Duress-Vorfall auf: Der Alarm wird geschlossen, die Eskalation gestoppt und das Ergebnis festgehalten. Offene und bestätigte Vorfälle können aufgelöst werden.

• disposition: genuine (ein echter Notfall), false_alarm, test oder unknown.
• note: was passiert ist. Bei einem echten Alarm erforderlich.

Immer zuerst bestätigen lassen. Rufen Sie ohne confirm auf, um den Vorfall abzurufen, teilen Sie dem Benutzer mit, welchen Alarm er schließt und mit welchem Ergebnis, und rufen Sie erst nach seiner Zustimmung erneut mit confirm: true auf.

In einem Workflow oder von einem Agent aus funktioniert dies nur, wenn der Reaktionsplan der Einrichtung Workflows erlaubt, Alarme zu bestätigen, aufzulösen und auszulösen.

Liest Duress-Einstellungen: Reaktionspläne (wer in welcher Reihenfolge und auf welche Weise alarmiert wird, in einer Einrichtung oder als Markenvorlage), den aufgelösten Plan, den die Alarm-Engine tatsächlich verwendet, die Personen und Rollen, die hinzugefügt werden können, Gerätewarnungen (Akku, offline, Abdeckungs- und Zustellprobleme), Kontaktregeln und Planstatus der Marke, die Knopfübersicht einer Marke oder Organisation und wohin Alarme an die Notrufzentrale gehen.

Eine Einrichtung folgt der Vorlage ihrer Marke (sonst ihrer Organisation), erweitert sie um zusätzliche Kontakte (mode extend) oder ersetzt sie durch einen eigenen Plan (mode replace). Ändern Sie Einstellungen mit duress_settings_write. Zeiten sind im ISO-Format.

Aktionen:

• response_plan: Reaktionsplan. Der in einer Einrichtung geltende Plan (effective) und was jede Ebene enthält (sources: facility, brand, organisation), oder mit nur brandId die Vorlage der Marke. Kontakte wie gespeichert, bereit zum Bearbeiten und Zurückspeichern.
• resolved_plan: Aufgelöster Plan. Wen die Alarm-Engine in der Einrichtung kontaktiert, Stufe für Stufe: Rollen in Personen aufgelöst, die Kanäle, über die jede Person erreichbar ist, Verzögerungen und Warnungen, die vor einem Alarm behoben werden sollten. Nur Namen, keine Telefonnummern oder E-Mail-Adressen.
• contact_options: Kontaktoptionen. Personen und Rollen, die dem Plan der Einrichtung (erfordert dort Duress Configuration) oder mit nur brandId der Vorlage der Marke hinzugefügt werden können, nach Anwendung der Kontaktregeln der Marke.
• device_alerts: Gerätewarnungen. Wer über niedrige Akkustände, Offline-Knöpfe, verlorene Abdeckung und fehlgeschlagene Zustellungen informiert wird: die Regeln auf jeder Ebene und die aufgelösten Empfänger der Einrichtung, oder mit nur brandId die Regeln der Marke.
• contact_rules: Kontaktregeln der Marke. Welche Rollen Einrichtungen der Marke zu Plänen hinzufügen dürfen: allowAllExcept blendet die aufgeführten Rollen aus, manual bietet nur diese an. Erfordert dieselben Rechte wie das Bearbeiten des Markenplans. Erfordert brandId.
• plan_status: Planstatus der Marke. Jede Einrichtung der Marke: ob sie der Vorlage folgt, sie erweitert oder einen eigenen Plan hat, wie viele Kontakte sie hinzugefügt hat und die Warnungen ihres Plans. Erfordert brandId.
• buttons_summary: Knopfübersicht. Jede Einrichtung einer Marke oder Organisation: Knöpfe, Anzahl mit Akkuproblemen und offline, der nächste und letzte Test. Die Daten der Übersichten in Brands & Customisation und der Organisation.
• monitoring: Weiterleitung an die Notrufzentrale. Wie Alarme die Einrichtung verlassen: eaAlarmType none, cid (ein Anruf bei der Notrufzentrale über eaAlarmProvider) oder relay (eine verkabelte Zentrale über eaRelayModel), und die Anbieter, die sie verwenden kann.

Ändert Duress-Einstellungen: Reaktionspläne (in einer Einrichtung oder als Vorlage einer Marke oder Organisation), Gerätewarnungen, Kontaktregeln der Marke und wohin Alarme an die Notrufzentrale gehen. Jede Änderung fragt nach einer Bestätigung, da sie ändert, wer alarmiert wird.

Übergeben Sie eines von facilityId (Standard: die verbundene Einrichtung), brandId oder organisationId. Pläne von Einrichtungen erfordern dort Duress Configuration; Vorlagen erfordern einen Organisationsadministrator mit Duress Configuration oder bei einer Marke Duress Configuration in jeder ihrer Einrichtungen. Lesen Sie zuerst mit duress_settings_read.

Aktionen:

• save_response_plan: Reaktionsplan speichern. Stufen von Kontakten, die afterSeconds nach der Auslösung alarmiert werden (aufsteigend, die erste meist 0), ackRequired, reminders und responseActions. Eine Einrichtung kann stattdessen ihre Vorlage um Ergänzungen erweitern (mode extend). Weggelassene Felder behalten ihre gespeicherten Werte; responseActions werden pro Aktion zusammengeführt. Fragt nach einer Bestätigung.
• remove_response_plan: Reaktionsplan entfernen. Löscht den auf dieser Ebene gespeicherten Plan, sodass eine Einrichtung wieder ihrer Vorlage folgt und eine Marke auf die der Organisation zurückfällt. Fragt nach einer Bestätigung.
• save_device_alerts: Gerätewarnungen speichern. Ersetzt die Regeln für Gerätewarnungen auf dieser Ebene: bis zu 10 Regeln, jeweils eine Menge von Ereignissen und Kontakten (push, sms oder email). Behalten Sie die aus duress_settings_read device_alerts gelesenen Regel-IDs bei. Erfordert rules. Fragt nach einer Bestätigung.
• remove_device_alerts: Gerätewarnungen entfernen. Löscht die Regeln für Gerätewarnungen auf dieser Ebene, sodass wieder die nächsthöhere Ebene gilt. Fragt nach einer Bestätigung.
• save_contact_rules: Kontaktregeln der Marke speichern. Welche Rollen die Einrichtungen der Marke zu Plänen hinzufügen können: allowAllExcept blendet roleIds aus, manual bietet nur roleIds an. Bereits gespeicherte Kontakte bleiben; aufgelöste Pläne werden aktualisiert. Erfordert brandId, mode, roleIds. Fragt nach einer Bestätigung.
• save_monitoring: Weiterleitung an die Notrufzentrale speichern. Wohin Alarme gehen: eaAlarmType none, cid (erfordert eaAlarmProvider, einen der von duress_settings_read monitoring aufgeführten Anbieter) oder relay (eaRelayModel). Erfordert Duress Configuration in der Einrichtung. Erfordert eaAlarmType. Fragt nach einer Bestätigung.

Versetzt die Einrichtung für einen Duress-Alarm in den Lockdown: Keine Tür lässt mehr Personen ein, bis der Lockdown aufgehoben wird (duress_lift_lockdown oder über die Konsole). Ein Alarm erhält immer nur einen Lockdown.

Nie für Test- oder aufgelöste Alarme. Erfordert Door/Gate Access in der Einrichtung.

Zuerst bestätigen lassen. Rufen Sie ohne confirm auf, um den Vorfall zu prüfen, teilen Sie dem Benutzer mit, dass jede Tür gesperrt wird, und rufen Sie nach seiner Zustimmung erneut mit confirm: true auf.

Startet sofort einen Duress-Test in einer Einrichtung. Bis zu seinem Ende ist jede Auslösung ein Test, kein echter Alarm:

• walk: Das Personal drückt jeden Knopf; nur die erste Stufe des Reaktionsplans wird alarmiert, mit der Kennzeichnung TEST.
• drill: Der gesamte Reaktionsplan läuft, mit der Kennzeichnung TEST.

Die Testkontakte der Einrichtung werden über den Start informiert und erhalten etwa 10 Minuten nach dem Ende die Ergebnisse. Ein Test gleichzeitig pro Einrichtung. Vorzeitig beenden mit duress_end_test; Tests im Voraus planen mit duress_tests_write.

Zuerst bestätigen lassen. Rufen Sie ohne confirm auf, teilen Sie dem Benutzer mit, dass Auslösungen für durationMinutes keine echten Alarme auslösen, und rufen Sie nach seiner Zustimmung erneut mit confirm: true auf. In einem Workflow oder von einem Agent aus funktioniert dies nur, wenn der Reaktionsplan der Einrichtung Workflows erlaubt, Alarme zu bestätigen, aufzulösen und auszulösen.

Liest Tests der Notrufknöpfe: die Zeitpläne, die sie planen (walk, comms oder drill, einmalig oder wiederkehrend, für eine Organisation, Marken oder Einrichtungen), die Testzeitfenster, die sie in jeder Einrichtung erzeugen (geplant, aktiv, abgeschlossen, abgesagt, dazu Ad-hoc-Tests), und die Ergebnisse eines Zeitfensters (welche Knöpfe gedrückt oder ausgelassen wurden, wer informiert wurde, Signale an die Notrufzentrale, Bestätigungszeiten).

Wer einen Test geplant, geändert oder abgesagt hat, wird weggelassen; Zustellempfänger werden unkenntlich gemacht. Zeiten sind im ISO-Format; localDate und localStartTime gelten in der Zeitzone der Einrichtung. Tests planen oder ändern mit duress_tests_write; einen Test sofort starten mit duress_start_test.

Aktionen:

• schedules: Testzeitpläne. scope facility (Standard; jeder Zeitplan, der sie abdeckt, einschließlich geteilter, die sie überspringt oder ersetzt), brand (brandId) oder organisation (Standard: die der Einrichtung). Neueste Änderung zuerst.
• windows: Testzeitfenster. Die Testzeitfenster einer Einrichtung von from bis to (Standard etwa eine Woche zurück bis einen Monat voraus) oder mit nur organisationId die anstehenden Zeitfenster der Organisation über ihre Einrichtungen hinweg.
• results: Testergebnisse. Ein Zeitfenster und seine Ergebnisse: nach dem Versand gespeichert, während eines laufenden Tests live berechnet (die Checkliste des Begehungstests), null für geplante oder abgesagte Zeitfenster. Erfordert Duress in der Einrichtung. Erfordert startsAtKey.

Bucht, ändert und storniert Duress-Testpläne, legt fest, wie eine Einrichtung einem gemeinsamen Plan folgt, und storniert ein einzelnes bevorstehendes Testfenster. Jede Änderung bucht künftige Fenster oder schreibt sie neu und benachrichtigt die Beteiligten per E-Mail, daher wird jeweils eine Bestätigung angefordert.

Pläne erfordern Duress Configuration für ihr gesamtes Ziel (für organisationsweite Pläne einen Organisationsadministrator). Zeiten gelten in der Zeitzone der jeweiligen Einrichtung. Lesen Sie Pläne und Fenster zuerst mit duress_tests_read; starten Sie einen Test sofort mit duress_start_test.

Aktionen:

• create_schedule: Testplan buchen. Bucht Fenster bis etwa ein Jahr im Voraus an jeder Einrichtung im Ziel und sendet eine Buchungsbestätigung per E-Mail. Erfordert name, type, target, startDate, localStartTime und recurrence. Erfordert name, type, target, startDate, localStartTime, recurrence. Fordert eine Bestätigung an.
• update_schedule: Testplan ändern. Weggelassene Felder behalten ihre Werte. Künftige Fenster werden neu geschrieben (bereits begonnene bleiben unverändert), und die Beteiligten erhalten eine Änderungsmitteilung. Verwenden Sie danach den ownerScope aus dem Ergebnis. Erfordert ownerScope, scheduleId. Fordert eine Bestätigung an.
• cancel_schedule: Testplan stornieren. Storniert den Plan und seine künftigen Fenster und versendet die Stornierung per E-Mail. Einrichtungen mit einer eigenen Kopie behalten diese. Erfordert ownerScope, scheduleId. Fordert eine Bestätigung an.
• set_facility_override: Gemeinsamen Plan für eine Einrichtung ändern. mode follow (den gemeinsamen Plan hier wieder ausführen), skip (ihn hier aussetzen) oder own (ihn hier durch eine aus schedule erstellte Kopie ersetzen). Erfordert Duress Configuration nur an dieser Einrichtung. Erfordert ownerScope, scheduleId, mode. Fordert eine Bestätigung an.
• cancel_window: Ein Testfenster stornieren. Storniert einen geplanten Test an einer Einrichtung (der Plan läuft weiter) und benachrichtigt dessen Beteiligte per E-Mail. Erfordert Duress an der Einrichtung; ein laufender Test wird stattdessen mit duress_end_test beendet. Erfordert startsAtKey. Fordert eine Bestätigung an.

Entriegelt die Türen für einen Duress-Alarm, z. B. um Polizei oder Ersthelfer einzulassen: die mit der gedrückten Taste verknüpften Türen, andernfalls die Türen des Reaktionsplans. Lassen Sie doorIds für alle Türen weg oder führen Sie einzelne davon auf. Jede Entriegelung erscheint in der Vorfall-Zeitachse und in den Zugriffsprotokollen.

Nie für Test- oder bereits gelöste Alarme. Erfordert Door/Gate Access an der Einrichtung.

Zuerst bestätigen. Rufen Sie das Tool ohne confirm auf, um zu sehen, welche Türen entriegelt würden, informieren Sie den Benutzer und rufen Sie es nach dessen Zustimmung erneut mit confirm: true auf.