Wymuszenie

Potwierdza otwarty incydent napadowy w imieniu użytkownika: rejestruje, że użytkownik reaguje, i może zatrzymać dalszą eskalację. Potwierdzać można tylko otwarte incydenty.

Zawsze najpierw uzyskaj potwierdzenie. Wywołaj bez confirm, aby pobrać incydent, poinformuj użytkownika, co potwierdza, i wywołaj ponownie z confirm: true dopiero po wyrażeniu przez niego zgody.

W przepływie pracy lub z poziomu agenta działa to tylko tam, gdzie plan reagowania obiektu pozwala przepływom pracy potwierdzać, zamykać i wywoływać alarmy. Aby zamknąć incydent, użyj duress_resolve_incident.

Odczytuje przyciski napadowe w obiekcie: ich stan (bateria, ostatni odebrany sygnał, ostatni test), pełne profile (etykieta, pomieszczenie, strefa, umiejscowienie, powiązane kamery, drzwi i ekrany, wyciszone alerty, stan nadzoru), elementy, z którymi można je powiązać, ekrany przekazujące ich naciśnięcia oraz test konfiguracyjny nowo dodanego przycisku.

Bateria: low oznacza 30% lub mniej (wkrótce wymień), critical 20% lub mniej (wymień teraz). Wartości null w polach battery i lastSeenAt oznaczają, że żaden ekran jeszcze nie odebrał sygnału przycisku. Czasy są w formacie ISO.

Akcje:

• status: Stan przycisków. Każdy przycisk ze strefą, pomieszczeniem, baterią, informacją, kiedy ekran ostatnio odebrał jego sygnał i kiedy był ostatnio testowany. „Czy przyciski napadowe działają?”, „Które wymagają nowych baterii?”
• list: Profile przycisków. Pełny profil każdego przycisku: to, co zmienia duress_buttons_write update, a także sygnał, ekrany, które odebrały jego sygnał w ostatniej dobie, stan nadzoru i oczekujący test konfiguracyjny.
• link_options: Opcje powiązań. Kamery, drzwi, ekrany i strefy dostępu obiektu, z którymi można powiązać przycisk (identyfikatory dla duress_buttons_write update).
• receivers: Odbiorniki przycisków. Ekrany w obiekcie, które odbierają sygnały przycisków i przekazują naciśnięcia, oraz informacja, czy każdy z nich jest online. ready ma wartość false, gdy nic nie mogłoby odebrać sygnału przycisku.
• setup_test: Test konfiguracyjny. Test konfiguracyjny nowo dodanego przycisku: waiting (jego pierwsze naciśnięcie jest tylko testem), received, expired, ended lub none, oraz informacja, czy od dodania przycisku jakiś ekran odebrał jego sygnał. Wymaga deviceSerialNumber.

Zmienia przyciski napadowe w obiekcie: dodawanie nowego przycisku, jego profil (etykieta, pomieszczenie, strefa, umiejscowienie, notatki, powiązane kamery, drzwi, ekrany i strefa dostępu, wyciszone alerty urządzenia), włączanie sygnału dźwiękowego, aby personel mógł go znaleźć, kończenie testu konfiguracyjnego nowego przycisku, aby zaczął działać, oraz usuwanie przycisku.

Pola pominięte w update zachowują swoje wartości; null je czyści. Bieżący profil odczytasz za pomocą duress_buttons_read list.

Akcje:

• update: Zaktualizuj przycisk. Zapisuje profil przycisku w obiekcie, w którym jest zarejestrowany (wymaga tam Duress Configuration). zone ma wartość od 001 do 999 i jest unikalna w obiekcie. alertsMutedUntil (ISO, maksymalnie 30 dni w przód) wycisza alerty dotyczące baterii i braku połączenia. Wymaga deviceSerialNumber.
• locate: Włącz sygnał dźwiękowy przycisku. Przycisk przez 30 sekund wydaje dźwięk i miga, aby personel mógł go znaleźć, np. taki, który ciągle zgłasza niski poziom baterii. Polecenie wysyła pobliski ekran, więc przycisk musi być w jego zasięgu. Niedostępne, gdy przycisk ma otwarty alarm. Wymaga deviceSerialNumber.
• go_live: Uruchom nowy przycisk. Natychmiast kończy test konfiguracyjny nowo dodanego przycisku, więc jego następne naciśnięcie wywoła prawdziwy alarm. Najpierw sprawdź duress_buttons_read setup_test. Wymaga Device Management lub Duress Configuration w obiekcie. Wymaga deviceSerialNumber. Prosi o potwierdzenie.
• remove: Usuń przycisk. Rozparowuje przycisk z obiektem i usuwa jego profil, co zwalnia jego strefę. Niedostępne, gdy przycisk ma otwarty alarm. Wymaga Device Management w obiekcie. Wymaga deviceSerialNumber. Prosi o potwierdzenie.
• add: Dodaj przycisk. Rejestruje nowy przycisk napadowy w obiekcie na podstawie nadrukowanego na nim numeru seryjnego. Domyślnie jego pierwsze naciśnięcie w ciągu następnych 30 minut jest tylko testem (setupTest). Obiekt musi mieć ekran z włączoną funkcją Duress alarm monitoring lub IoT Gateway. Wymaga Device Management w obiekcie. Wymaga deviceSerialNumber. Prosi o potwierdzenie.

Natychmiast kończy test napadowy trwający w obiekcie, więc następne naciśnięcie wywoła prawdziwy alarm. Wyniki są dostępne około 10 minut później, tak jak w przypadku każdego testu.

Odczytuje incydenty alarmów napadowych (personel nacisnął przycisk napadowy lub przepływ pracy wywołał alarm): listy, oś czasu i dostarczenia jednego incydentu, raport poincydentalny oraz nagrania CCTV z okresu alarmu.

Statusy: open (nikt go jeszcze nie potwierdził), acknowledged (ktoś reaguje), resolved (zamknięty, z klasyfikacją: genuine, false_alarm, test lub unknown). active oznacza open lub acknowledged. Incydenty testowe (isTest) pochodzą z testów przycisków; testType 'unplanned' to alarm wywołany jako prawdziwy, który osoba reagująca zamknęła jako test.

Status dostarczenia: sent, acknowledged (odbiorca potwierdził), failed (zobacz error), shadow (przebieg próbny, nic nie zostało wysłane). Dostarczenia do centrum monitorowania są też sumowane w monitoringCentre. Wyniki zawierają imiona i nazwiska osób, ale nigdy numery telefonów ani adresy e-mail. Czasy są w formacie ISO.

Akcje:

• list: Wyświetl incydenty. Od najnowszych. scope: facility (domyślnie; podany lub połączony obiekt) lub organisation (wszystkie widoczne dla Ciebie obiekty w organizacji; domyślnie organizacja obiektu).
• get: Pobierz incydent. Status, naciśnięte przyciski, oś czasu (naciśnięcia, eskalacje, potwierdzenia, notatki) i każda próba dostarczenia powiadomienia lub sygnału do centrum monitorowania wraz z wynikiem. Wymaga incidentId.
• report: Raport incydentu. Do analizy poincydentalnej: incydent, liczba sekund do potwierdzenia i zamknięcia, osiągnięte kroki, każdy wpis na osi czasu, co zostało wysłane każdym kanałem i co się nie powiodło oraz czy nagrania zostały zachowane. Połącz z duress_incidents_write add_note, aby dodać analizę do incydentu. Wymaga incidentId.
• footage_previews: Nagrania z alarmu. Każda kamera w nagraniach z alarmu: jej stan, liczba klatek i klipów, przesłane klipy oraz klatka najbliższa naciśnięciu (posterSeconds). Z cameraId tylko ta kamera wraz z czasem Unix w sekundach dla każdej klatki (frameSeconds). Wymaga CCTV w obiekcie. Wymaga incidentId.
• footage_frame: Klatka z nagrania alarmu. Jedna klatka poklatkowa z nagrania alarmu, zwracana jako obraz: zachowana kopia, jeśli nagranie zostało zachowane, w przeciwnym razie klatka na żywo z okresu alarmu. seconds to wartość posterSeconds lub frameSeconds z footage_previews. Wymaga incidentId, cameraId, seconds.

Zmienia incydent napadowy bez ingerowania w sam alarm: nadaje mu nazwę, dodaje notatki personelu oraz zachowuje lub zwalnia nagrania CCTV z jego okresu. Nikt nie jest powiadamiany. Aby potwierdzić lub zamknąć incydent albo przekazać informacje osobom reagującym, użyj duress_acknowledge_incident, duress_resolve_incident lub duress_post_update.

Akcje:

• rename: Nadaj nazwę incydentowi. Nadaje incydentowi nazwę, aby łatwo go było później znaleźć, np. "Agresywny gość przy ladzie recepcji". Pusta nazwa lub null usuwa nazwę. Nazwy są widoczne w konsoli Duress i w raportach. Wymaga incidentId.
• add_note: Dodaj notatkę. Dodaje notatkę do osi czasu incydentu, np. co zastał użytkownik lub kto był na miejscu. Dowolny status; notatki widzi tylko personel i nie zmieniają one incydentu. Zapisz ją słowami użytkownika i najpierw potwierdź z nim treść. Wymaga incidentId, note.
• keep_footage: Zachowaj nagrania z alarmu. Zachowuje nagrania CCTV z okresu zamkniętego prawdziwego alarmu, aby nie zostały usunięte razem ze zwykłymi nagraniami, z użyciem minut i kamer z planu reagowania. Następuje kilka minut później, po przesłaniu nagrań. Nie dotyczy testów, otwartych alarmów ani nagrań już zachowanych lub zwolnionych. Wymaga incidentId.
• release_footage: Zwolnij zachowane nagrania. Rezygnuje z nagrań zachowanych dla alarmu: klipy wracają do zwykłego okresu przechowywania, a zachowane klatki są usuwane, więc po wygaśnięciu zwykłych nagrań nie można ich już wyświetlić. Wymaga Duress Configuration w obiekcie. Wymaga incidentId. Prosi o potwierdzenie.

Znosi blokadę alarmu napadowego: zablokowane przez nią drzwi ponownie wpuszczają osoby. Działa niezależnie od statusu alarmu.

Najpierw uzyskaj potwierdzenie. Wywołaj bez confirm, aby zobaczyć blokadę, poinformuj użytkownika i wywołaj ponownie z confirm: true, gdy wyrazi zgodę.

Publikuje aktualizację dla osób reagujących na alarm napadowy, np. "Policja jest w drodze" lub "Wszystko w porządku, osoba opuściła obiekt". Aktualizacja pojawia się na ich stronie alarmu i w aplikacji Duress, a w przypadku prawdziwego alarmu plan reagowania może ją też wysłać SMS-em do wszystkich, którzy otrzymali już SMS o alarmie. Aktualizacje można publikować do 24 godzin po zamknięciu alarmu.

Najpierw uzyskaj potwierdzenie. Wywołaj bez confirm, aby sprawdzić incydent, pokaż użytkownikowi dokładną treść i wywołaj ponownie z confirm: true, gdy wyrazi zgodę. Jeśli informacja ma być widoczna tylko dla personelu, użyj zamiast tego duress_incidents_write add_note.

Wywołuje prawdziwy alarm napadowy w obiekcie, tak jakby naciśnięto przycisk: uruchamia się plan reagowania (osoby są powiadamiane, następuje eskalacja i przypomnienia, wykonywane są działania reagowania), a alarm informuje, że wywołał go ten przepływ pracy, i podaje powód.

• reason: co się stało, np. "Wyważone drzwi przy tylnym wyjściu" (do 200 znaków).
• deviceSerialNumber: opcjonalnie. Przycisk, którego lokalizacji należy użyć; tylko wtedy powiadamiane jest również centrum monitorowania, ze strefą tego przycisku.

Tylko jako krok przepływu pracy, w obiektach, których plan reagowania pozwala przepływom pracy potwierdzać, zamykać i wywoływać alarmy. Dopóki alarm tego przepływu pracy jest otwarty, nie wywoła on kolejnego; zamiast tego zwróci istniejący alarm.

Raportowanie zgodności Duress dla obiektu, marki lub organizacji: czasy reakcji (P50/P95), incydenty według klasyfikacji i odsetek fałszywych alarmów, pokrycie testami i obiekty z zaległymi testami, czas sprawności przycisków, skuteczność dostarczania do centrum monitorowania oraz eksport incydent po incydencie. Do tego niedostarczone alerty ostatniego alarmu w jednym obiekcie.

Dni są liczone według czasu lokalnego obiektu; okresy dłuższe niż 400 dni są skracane (range.capped). Incydenty prawdziwe i testowe są liczone osobno. Czasy trwania są podawane w ms (p50Ms, p95Ms). Raporty marki obejmują tylko obiekty, do których masz dostęp, chyba że masz dostęp w całej organizacji (scope.restrictedToAccessibleFacilities).

Akcje:

• overview: Przegląd raportu Duress. Sumy, trend miesięczny oraz wskaźniki dla organizacji, marek i obiektów (incidents, testCoverage, deviceUptime, deliveries). Obiekty są stronicowane.
• compliance_summary: Podsumowanie zgodności Duress. To, co pokazuje raport PDF zgodności: pokrycie testami z obiektami z zaległymi testami, czas sprawności przycisków, skuteczność dostarczania, ostatnie testy (testHistory), a dla każdego obiektu jego ostatni test, ćwiczenie i prawdziwy alarm wraz z czasem sprawności każdego przycisku. Obiekty są stronicowane.
• incident_export: Eksport incydentów Duress. Jeden wiersz na incydent, od najstarszych, z kolumnami eksportu CSV: obiekt, test lub prawdziwy, status, klasyfikacja, czasy lokalne, liczba sekund do potwierdzenia i zamknięcia, kto potwierdził i zamknął, przyciski i liczba dostarczeń.
• delivery_problems: Niedostarczone alerty alarmowe. Ostatni alarm lub test w obiekcie (z całym oknem testu) i alerty, które nigdy nie dotarły, według kanału. problems ma wartość null, gdy wszystko zostało dostarczone. Wymaga tam Duress lub Duress Configuration.

Zamyka incydent napadowy: kończy alarm, zatrzymuje eskalację i rejestruje wynik. Zamykać można incydenty otwarte i potwierdzone.

• disposition: genuine (prawdziwy nagły wypadek), false_alarm, test lub unknown.
• note: co się stało. Wymagane w przypadku prawdziwego alarmu.

Zawsze najpierw uzyskaj potwierdzenie. Wywołaj bez confirm, aby pobrać incydent, poinformuj użytkownika, który alarm zamyka i z jakim wynikiem, i wywołaj ponownie z confirm: true dopiero po wyrażeniu przez niego zgody.

W przepływie pracy lub z poziomu agenta działa to tylko tam, gdzie plan reagowania obiektu pozwala przepływom pracy potwierdzać, zamykać i wywoływać alarmy.

Odczytuje ustawienia Duress: plany reagowania (kto jest powiadamiany, w jakiej kolejności i w jaki sposób, w obiekcie lub jako szablon marki), ustalony plan, którego faktycznie używa mechanizm alarmowy, osoby i role, które można dodać, alerty urządzeń (bateria, brak połączenia, problemy z zasięgiem i dostarczaniem), reguły kontaktów marki i stan planów, przegląd przycisków marki lub organizacji oraz sposób przekazywania alarmów do centrum monitorowania.

Obiekt stosuje szablon swojej marki (lub, w jego braku, organizacji), rozszerza go o dodatkowe kontakty (mode extend) albo zastępuje go własnym planem (mode replace). Ustawienia zmienisz za pomocą duress_settings_write. Czasy są w formacie ISO.

Akcje:

• response_plan: Plan reagowania. Plan obowiązujący w obiekcie (effective) i zawartość każdego poziomu (sources: facility, brand, organisation) lub, tylko z brandId, szablon marki. Kontakty są w postaci zapisanej, gotowe do edycji i ponownego zapisania.
• resolved_plan: Ustalony plan. Z kim mechanizm alarmowy kontaktuje się w obiekcie, poziom po poziomie: role rozwinięte do osób, kanały, którymi można się z każdą z nich skontaktować, opóźnienia oraz ostrzeżenia do usunięcia przed alarmem. Tylko imiona i nazwiska, bez numerów telefonów i adresów e-mail.
• contact_options: Opcje kontaktów. Osoby i role, które można dodać do planu obiektu (wymaga tam Duress Configuration) lub, tylko z brandId, do szablonu marki, z uwzględnieniem reguł kontaktów marki.
• device_alerts: Alerty urządzeń. Kto jest informowany o niskim poziomie baterii, przyciskach offline, utracie zasięgu i nieudanych dostarczeniach: reguły na każdym poziomie i ustaleni odbiorcy w obiekcie lub, tylko z brandId, reguły marki.
• contact_rules: Reguły kontaktów marki. Które role obiekty marki mogą dodawać do planów: allowAllExcept ukrywa wymienione role, manual oferuje tylko je. Wymaga tych samych uprawnień co edycja planu marki. Wymaga brandId.
• plan_status: Stan planów marki. Każdy obiekt marki: czy stosuje szablon, rozszerza go, czy ma własny plan, ile kontaktów dodał i jakie ostrzeżenia ma jego plan. Wymaga brandId.
• buttons_summary: Przegląd przycisków. Każdy obiekt marki lub organizacji: liczba przycisków, przycisków z niskim poziomem baterii i offline, następny i ostatni test. Dane przeglądów Brands & Customisation i organizacji.
• monitoring: Kierowanie do centrum monitorowania. Jak alarmy są przekazywane z obiektu: eaAlarmType none, cid (połączenie z centrum monitorowania przez eaAlarmProvider) lub relay (przewodowy panel przez eaRelayModel), oraz dostawcy, z których obiekt może korzystać.

Zmienia ustawienia Duress: plany reagowania (w obiekcie albo szablon marki lub organizacji), alerty urządzeń, reguły kontaktów marki oraz sposób przekazywania alarmów do centrum monitorowania. Każda zmiana wymaga potwierdzenia, ponieważ zmienia to, kto jest powiadamiany.

Przekaż jedno z: facilityId (domyślnie: połączony obiekt), brandId lub organisationId. Plany obiektu wymagają w nim Duress Configuration; szablony wymagają administratora organizacji z Duress Configuration, a w przypadku marki Duress Configuration w każdym jej obiekcie. Najpierw odczytaj ustawienia za pomocą duress_settings_read.

Akcje:

• save_response_plan: Zapisz plan reagowania. Poziomy kontaktów powiadamianych po afterSeconds od naciśnięcia (rosnąco, pierwszy zwykle 0), ackRequired, reminders i responseActions. Obiekt może zamiast tego rozszerzyć swój szablon (mode extend) o dodatkowe kontakty. Pominięte pola zachowują zapisane wartości; responseActions są scalane według akcji. Prosi o potwierdzenie.
• remove_response_plan: Usuń plan reagowania. Usuwa plan zapisany na tym poziomie, więc obiekt ponownie stosuje swój szablon, a marka wraca do szablonu organizacji. Prosi o potwierdzenie.
• save_device_alerts: Zapisz alerty urządzeń. Zastępuje reguły alertów urządzeń na tym poziomie: do 10 reguł, każda to zestaw zdarzeń i kontaktów (push, sms lub email). Zachowaj identyfikatory reguł odczytane z duress_settings_read device_alerts. Wymaga rules. Prosi o potwierdzenie.
• remove_device_alerts: Usuń alerty urządzeń. Usuwa reguły alertów urządzeń na tym poziomie, więc ponownie obowiązuje następny wyższy poziom. Prosi o potwierdzenie.
• save_contact_rules: Zapisz reguły kontaktów marki. Które role obiekty marki mogą dodawać do planów: allowAllExcept ukrywa roleIds, manual oferuje tylko roleIds. Zapisane już kontakty pozostają; ustalone plany są odświeżane. Wymaga brandId, mode, roleIds. Prosi o potwierdzenie.
• save_monitoring: Zapisz kierowanie do centrum monitorowania. Dokąd trafiają alarmy: eaAlarmType none, cid (wymaga eaAlarmProvider, jednego z dostawców wymienionych przez duress_settings_read monitoring) lub relay (eaRelayModel). Wymaga Duress Configuration w obiekcie. Wymaga eaAlarmType. Prosi o potwierdzenie.

Blokuje obiekt w związku z alarmem napadowym: wszystkie drzwi przestają wpuszczać osoby do czasu zniesienia blokady (duress_lift_lockdown lub z konsoli). Alarm może mieć tylko jedną blokadę.

Nigdy dla alarmów testowych ani zamkniętych. Wymaga Door/Gate Access w obiekcie.

Najpierw uzyskaj potwierdzenie. Wywołaj bez confirm, aby sprawdzić incydent, poinformuj użytkownika, że wszystkie drzwi zostaną zablokowane, i wywołaj ponownie z confirm: true, gdy wyrazi zgodę.

Natychmiast rozpoczyna test napadowy w obiekcie. Do jego zakończenia każde naciśnięcie jest testem, a nie prawdziwym alarmem:

• walk: personel naciska każdy przycisk; powiadamiany jest tylko pierwszy krok planu reagowania, z oznaczeniem TEST.
• drill: uruchamia się cały plan reagowania, z oznaczeniem TEST.

Kontakty testowe obiektu są informowane o rozpoczęciu testu i otrzymują wyniki około 10 minut po jego zakończeniu. W obiekcie może trwać tylko jeden test naraz. Wcześniej zakończysz go za pomocą duress_end_test; testy z wyprzedzeniem zaplanujesz za pomocą duress_tests_write.

Najpierw uzyskaj potwierdzenie. Wywołaj bez confirm, poinformuj użytkownika, że przez durationMinutes naciśnięcia nie będą wywoływać prawdziwych alarmów, i wywołaj ponownie z confirm: true, gdy wyrazi zgodę. W przepływie pracy lub z poziomu agenta działa to tylko tam, gdzie plan reagowania obiektu pozwala przepływom pracy potwierdzać, zamykać i wywoływać alarmy.

Odczytuje testy przycisków napadowych: harmonogramy, które je planują (walk, comms lub drill, jednorazowe lub powtarzane, dla organizacji, marek lub obiektów), okna testowe tworzone przez nie w każdym obiekcie (scheduled, active, completed, cancelled oraz testy doraźne) i wyniki okna (które przyciski zostały naciśnięte lub pominięte, kto został poinformowany, sygnały do centrum monitorowania, czasy potwierdzenia).

Informacje o tym, kto zaplanował, zmienił lub anulował test, są pomijane; odbiorcy dostarczeń są ukryci. Czasy są w formacie ISO; localDate i localStartTime są w strefie czasowej obiektu. Testy zaplanujesz lub zmienisz za pomocą duress_tests_write; natychmiast rozpoczniesz test za pomocą duress_start_test.

Akcje:

• schedules: Harmonogramy testów. scope facility (domyślnie; każdy obejmujący go harmonogram, w tym wspólne, które obiekt pomija lub zastępuje), brand (brandId) lub organisation (domyślnie: organizacja obiektu). Od najnowszej zmiany.
• windows: Okna testowe. Okna testowe obiektu od from do to (domyślnie od około tygodnia wstecz do miesiąca w przód) lub, tylko z organisationId, nadchodzące okna organizacji we wszystkich jej obiektach.
• results: Wyniki testu. Okno i jego wyniki: zapisane po wysłaniu, obliczane na bieżąco podczas trwania testu (lista kontrolna testu obchodowego), null dla okien zaplanowanych lub anulowanych. Wymaga Duress w obiekcie. Wymaga startsAtKey.

Rezerwuje, zmienia i anuluje harmonogramy testów alarmów napadowych, ustawia, jak jeden obiekt stosuje wspólny harmonogram, oraz anuluje pojedyncze nadchodzące okno testowe. Każda zmiana rezerwuje lub przepisuje przyszłe okna i wysyła e-maile do interesariuszy, dlatego każda akcja prosi o potwierdzenie.

Harmonogramy wymagają uprawnienia Duress Configuration dla całego celu (w przypadku harmonogramów dla całej organizacji — administratora organizacji). Godziny są podawane w strefie czasowej każdego obiektu. Najpierw odczytaj harmonogramy i okna za pomocą duress_tests_read; test od razu uruchomisz za pomocą duress_start_test.

Akcje:

• create_schedule: Rezerwacja harmonogramu testów. Rezerwuje okna z wyprzedzeniem do około roku w każdym obiekcie objętym celem i wysyła e-mail z potwierdzeniem rezerwacji. Wymaga: name, type, target, startDate, localStartTime i recurrence. Wymaga: name, type, target, startDate, localStartTime, recurrence. Prosi o potwierdzenie.
• update_schedule: Zmiana harmonogramu testów. Pominięte pola zachowują swoje wartości. Przyszłe okna są przepisywane (rozpoczęte pozostają bez zmian), a interesariusze otrzymują powiadomienie o zmianie. Następnie używaj ownerScope z wyniku. Wymaga: ownerScope, scheduleId. Prosi o potwierdzenie.
• cancel_schedule: Anulowanie harmonogramu testów. Anuluje harmonogram i jego przyszłe okna oraz wysyła e-mail o anulowaniu. Obiekty z własną kopią ją zachowują. Wymaga: ownerScope, scheduleId. Prosi o potwierdzenie.
• set_facility_override: Zmiana wspólnego harmonogramu dla jednego obiektu. mode follow (ponownie stosuj tu wspólny harmonogram), skip (zatrzymaj go tutaj) lub own (zastąp go tutaj kopią utworzoną z schedule). Wymaga uprawnienia Duress Configuration tylko w tym obiekcie. Wymaga: ownerScope, scheduleId, mode. Prosi o potwierdzenie.
• cancel_window: Anulowanie jednego okna testowego. Anuluje jeden zaplanowany test w obiekcie (harmonogram trwa dalej) i wysyła e-mail do jego interesariuszy. Wymaga uprawnienia Duress w obiekcie; aktywny test kończy się zamiast tego za pomocą duress_end_test. Wymaga: startsAtKey. Prosi o potwierdzenie.

Odblokowuje drzwi na potrzeby alarmu napadowego, np. aby wpuścić policję lub pierwszą pomoc: drzwi powiązane z naciśniętym przyciskiem, a w przeciwnym razie drzwi z planu reagowania. Pomiń doorIds, aby odblokować wszystkie, lub wskaż niektóre z nich. Każde odblokowanie trafia na oś czasu incydentu i do rejestrów dostępu.

Nigdy dla alarmów testowych ani rozwiązanych. Wymaga uprawnienia Door/Gate Access w obiekcie.

Najpierw potwierdź. Wywołaj bez confirm, aby zobaczyć, które drzwi zostałyby odblokowane, poinformuj o tym użytkownika i wywołaj ponownie z confirm: true, gdy się zgodzi.