비상

사용자를 대신하여 열린 Duress 인시던트를 확인 처리합니다: 사용자가 대응 중임을 기록하며 추가 에스컬레이션을 중지할 수 있습니다. 열린 인시던트만 확인 처리할 수 있습니다.

항상 먼저 확인하십시오. confirm 없이 호출하여 인시던트를 가져오고, 사용자에게 무엇을 확인 처리하는지 알린 후, 동의한 경우에만 confirm: true로 다시 호출하십시오.

워크플로나 에이전트에서는 시설의 대응 계획이 워크플로의 알람 확인, 해결 및 발생을 허용하는 경우에만 작동합니다. 인시던트를 종료하려면 duress_resolve_incident를 사용하십시오.

시설의 Duress 버튼을 읽습니다: 상태(배터리, 마지막 수신, 마지막 테스트), 전체 프로필(레이블, 방, 구역, 설치 위치, 연결된 카메라, 문 및 화면, 음소거된 알림, 감시 상태), 연결할 수 있는 대상, 버튼 누름을 중계하는 화면, 새로 추가된 버튼의 설정 테스트입니다.

배터리: low는 30% 이하(곧 교체), critical은 20% 이하(즉시 교체)입니다. battery와 lastSeenAt이 null이면 아직 어떤 화면도 버튼 신호를 수신하지 않은 것입니다. 시간은 ISO 형식입니다.

작업:

• status: 버튼 상태입니다. 각 버튼의 구역, 방, 배터리, 화면이 마지막으로 신호를 수신한 시간, 마지막 테스트 시간입니다. "Duress 버튼이 작동합니까?", "배터리 교체가 필요한 버튼은 무엇입니까?"
• list: 버튼 프로필입니다. 각 버튼의 전체 프로필: duress_buttons_write update로 변경할 수 있는 항목과 신호, 지난 하루 동안 신호를 수신한 화면, 감시 상태, 대기 중인 설정 테스트입니다.
• link_options: 연결 옵션입니다. 버튼을 연결할 수 있는 시설의 카메라, 문, 화면 및 출입 구역입니다(duress_buttons_write update용 ID).
• receivers: 버튼 수신기입니다. 버튼 신호를 수신하여 누름을 중계하는 시설의 디스플레이 화면과 각 화면의 온라인 여부입니다. 버튼 신호를 수신할 수 있는 장치가 없으면 ready는 false입니다.
• setup_test: 설정 테스트입니다. 새로 추가된 버튼의 설정 테스트 상태: waiting(첫 번째 누름은 테스트로만 처리됨), received, expired, ended 또는 none, 그리고 추가된 이후 화면이 신호를 수신했는지 여부입니다. deviceSerialNumber가 필요합니다.

시설의 Duress 버튼을 변경합니다: 새 버튼 추가, 프로필(레이블, 방, 구역, 설치 위치, 메모, 연결된 카메라, 문, 화면 및 출입 구역, 음소거된 기기 알림) 변경, 직원이 찾을 수 있도록 버튼에서 신호음 울리기, 새 버튼의 설정 테스트를 종료하여 실제 운영 시작, 버튼 제거를 수행합니다.

update에서 지정하지 않은 필드는 값을 유지하며, null은 값을 지웁니다. 현재 프로필은 duress_buttons_read list로 확인하십시오.

작업:

• update: 버튼을 업데이트합니다. 버튼이 등록된 시설에 버튼의 프로필을 저장합니다(해당 시설에서 Duress Configuration 필요). zone은 001에서 999 사이이며 시설 내에서 고유해야 합니다. alertsMutedUntil(ISO, 최대 30일 후)은 배터리 및 오프라인 알림을 음소거합니다. deviceSerialNumber가 필요합니다.
• locate: 버튼에서 신호음을 울립니다. 직원이 찾을 수 있도록 버튼이 30초 동안 신호음을 내고 깜박이게 합니다(예: 배터리 부족을 계속 보고하는 버튼). 근처의 화면이 명령을 보내므로 버튼이 화면의 범위 안에 있어야 합니다. 열린 알람이 있는 동안에는 사용할 수 없습니다. deviceSerialNumber가 필요합니다.
• go_live: 새 버튼의 실제 운영을 시작합니다. 새로 추가된 버튼의 설정 테스트를 즉시 종료하여 다음 누름부터 실제 알람이 됩니다. 먼저 duress_buttons_read setup_test로 확인하십시오. 시설에서 Device Management 또는 Duress Configuration이 필요합니다. deviceSerialNumber가 필요합니다. 확인을 요청합니다.
• remove: 버튼을 제거합니다. 시설에서 버튼의 페어링을 해제하고 프로필을 삭제하여 구역을 해제합니다. 열린 알람이 있는 동안에는 사용할 수 없습니다. 시설에서 Device Management가 필요합니다. deviceSerialNumber가 필요합니다. 확인을 요청합니다.
• add: 버튼을 추가합니다. 버튼에 인쇄된 일련번호로 시설에 새 Duress 버튼을 등록합니다. 기본적으로 다음 30분 이내의 첫 번째 누름은 테스트로만 처리됩니다(setupTest). 시설에는 Duress alarm monitoring이 켜진 화면 또는 IoT Gateway가 있어야 합니다. 시설에서 Device Management가 필요합니다. deviceSerialNumber가 필요합니다. 확인을 요청합니다.

시설에서 실행 중인 Duress 테스트를 즉시 종료하여 다음 누름부터 실제 알람이 됩니다. 결과는 다른 테스트와 마찬가지로 약 10분 후에 제공됩니다.

Duress 알람 인시던트(직원이 Duress 버튼을 눌렀거나 워크플로가 알람을 발생시킨 경우)를 읽습니다: 목록, 인시던트 하나의 타임라인과 전송 내역, 사후 분석 보고서, 알람 전후의 CCTV 영상입니다.

상태: open(아직 아무도 확인하지 않음), acknowledged(누군가 대응 중), resolved(종료됨, 처리 결과: genuine, false_alarm, test 또는 unknown). active는 open 또는 acknowledged를 의미합니다. 테스트 인시던트(isTest)는 버튼 테스트에서 발생합니다. testType 'unplanned'는 실제 알람으로 발생했지만 대응자가 테스트로 해결한 알람입니다.

전송 상태: sent, acknowledged(수신자가 확인함), failed(error 참조), shadow(시험 실행, 아무것도 전송되지 않음). 모니터링 센터로의 전송은 monitoringCentre에도 합산됩니다. 결과에는 사람의 이름은 포함되지만 전화번호나 이메일 주소는 포함되지 않습니다. 시간은 ISO 형식입니다.

작업:

• list: 인시던트를 나열합니다. 최신순입니다. scope: facility(기본값, 지정되거나 연결된 시설) 또는 organisation(조직에서 볼 수 있는 모든 시설, 기본값은 시설의 조직).
• get: 인시던트를 가져옵니다. 상태, 눌린 버튼, 타임라인(누름, 에스컬레이션, 확인, 메모), 모든 알림 또는 모니터링 센터 전송 시도와 그 결과입니다. incidentId가 필요합니다.
• report: 인시던트 보고서입니다. 사후 분석용: 인시던트, 확인 및 해결까지 걸린 시간(초), 도달한 단계, 모든 타임라인 항목, 채널별 전송 내용과 실패 내역, 영상 보관 여부입니다. 사후 분석을 인시던트에 기록하려면 duress_incidents_write add_note와 함께 사용하십시오. incidentId가 필요합니다.
• footage_previews: 알람 영상입니다. 알람 영상에 포함된 각 카메라의 상태, 프레임 및 클립 수, 업로드된 클립, 누름 시점에 가장 가까운 프레임(posterSeconds)입니다. cameraId를 지정하면 해당 카메라만 반환하며 모든 프레임의 Unix 초(frameSeconds)도 포함합니다. 시설에서 CCTV가 필요합니다. incidentId가 필요합니다.
• footage_frame: 알람 영상 프레임입니다. 알람 영상의 타임랩스 프레임 하나를 이미지로 반환합니다: 영상이 보관된 경우 보관된 사본, 그렇지 않으면 알람 시간 범위 내의 실시간 프레임입니다. seconds는 footage_previews의 posterSeconds 또는 frameSeconds 값입니다. incidentId, cameraId, seconds가 필요합니다.

알람 자체에는 영향을 주지 않고 Duress 인시던트를 변경합니다: 이름 지정, 직원 메모 추가, 인시던트 전후의 CCTV 영상 보관 또는 해제. 아무에게도 알림이 전송되지 않습니다. 확인, 해결 또는 대응자에게 알리려면 duress_acknowledge_incident, duress_resolve_incident 또는 duress_post_update를 사용하십시오.

작업:

• rename: 인시던트 이름을 지정합니다. 나중에 쉽게 찾을 수 있도록 인시던트에 이름을 지정합니다(예: "프런트 카운터의 공격적인 방문자"). 빈 이름이나 null은 이름을 제거합니다. 이름은 Duress 콘솔과 보고서에 표시됩니다. incidentId가 필요합니다.
• add_note: 메모를 추가합니다. 인시던트 타임라인에 메모를 추가합니다(예: 사용자가 확인한 내용이나 출동한 사람). 모든 상태에서 가능합니다. 메모는 직원만 볼 수 있으며 인시던트를 변경하지 않습니다. 사용자의 표현으로 작성하고 먼저 사용자에게 문구를 확인하십시오. incidentId, note가 필요합니다.
• keep_footage: 알람 영상을 보관합니다. 해결된 실제 알람 전후의 CCTV 영상을 대응 계획의 시간(분)과 카메라 설정에 따라 보관하여 일반 녹화와 함께 삭제되지 않도록 합니다. 업로드가 완료되면 몇 분 후에 적용됩니다. 테스트, 열린 알람, 이미 보관되었거나 해제된 영상에는 사용할 수 없습니다. incidentId가 필요합니다.
• release_footage: 보관된 영상을 해제합니다. 알람에 대해 보관된 영상을 해제합니다: 클립은 일반 보존 기간으로 돌아가고 보관된 프레임은 삭제되므로, 일반 녹화가 만료되면 더 이상 볼 수 없습니다. 시설에서 Duress Configuration이 필요합니다. incidentId가 필요합니다. 확인을 요청합니다.

Duress 알람의 잠금(lockdown)을 해제합니다: 알람으로 잠긴 문이 다시 출입을 허용합니다. 알람 상태와 관계없이 작동합니다.

먼저 확인하십시오. confirm 없이 호출하여 잠금 상태를 확인하고 사용자에게 알린 후, 동의하면 confirm: true로 다시 호출하십시오.

Duress 알람에 대응 중인 사람들에게 업데이트를 게시합니다(예: "경찰이 오고 있습니다" 또는 "상황 종료, 해당 인물이 떠났습니다"). 업데이트는 대응자의 알람 페이지와 Duress 앱에 표시되며, 실제 알람의 경우 대응 계획에 따라 이미 알람 문자를 받은 모든 사람에게 문자로도 보낼 수 있습니다. 업데이트는 알람이 해결된 후 24시간까지 게시할 수 있습니다.

먼저 확인하십시오. confirm 없이 호출하여 인시던트를 확인하고, 사용자에게 정확한 문구를 보여 준 후, 동의하면 confirm: true로 다시 호출하십시오. 직원만 봐야 하는 내용은 대신 duress_incidents_write add_note를 사용하십시오.

버튼을 누른 것처럼 시설에서 실제 Duress 알람을 발생시킵니다: 대응 계획이 실행되며(사람들에게 알림 전송, 에스컬레이션 및 리마인더, 대응 작업 실행), 알람에는 이 워크플로가 발생시켰다는 사실과 이유가 표시됩니다.

• reason: 발생한 상황, 예: "후문 출구가 강제로 열림"(최대 200자).
• deviceSerialNumber: 선택 사항입니다. 위치를 사용할 버튼입니다. 이 값을 지정한 경우에만 해당 버튼의 구역과 함께 모니터링 센터에도 알립니다.

대응 계획이 워크플로의 알람 확인, 해결 및 발생을 허용하는 시설에서 워크플로 단계로만 사용할 수 있습니다. 이 워크플로의 알람이 열려 있는 동안에는 새 알람을 발생시키지 않고 기존 알람을 반환합니다.

시설, 브랜드 또는 조직의 Duress 규정 준수 보고: 응답 시간(P50/P95), 처리 결과별 인시던트와 오경보 비율, 테스트 범위와 테스트 기한이 지난 시설, 버튼 가동률, 모니터링 센터 전송 성공률, 인시던트별 내보내기입니다. 또한 한 시설에서 가장 최근 알람의 전송되지 않은 알림도 제공합니다.

날짜는 시설 현지 기준이며, 400일을 초과하는 기간은 단축됩니다(range.capped). 실제 인시던트와 테스트 인시던트는 별도로 집계됩니다. 기간은 ms 단위입니다(p50Ms, p95Ms). 조직 전체 접근 권한이 없으면 브랜드 보고서에는 접근할 수 있는 시설만 포함됩니다(scope.restrictedToAccessibleFacilities).

작업:

• overview: Duress 보고서 개요입니다. 합계, 월별 추세, 조직별, 브랜드별 및 시설별 지표(incidents, testCoverage, deviceUptime, deliveries)입니다. 시설은 페이지 단위로 반환됩니다.
• compliance_summary: Duress 규정 준수 요약입니다. 규정 준수 PDF에 표시되는 내용: 테스트 기한이 지난 시설을 포함한 테스트 범위, 버튼 가동률, 전송 성공률, 최근 테스트(testHistory), 그리고 시설별 마지막 테스트, 훈련 및 실제 알람과 각 버튼의 가동률입니다. 시설은 페이지 단위로 반환됩니다.
• incident_export: Duress 인시던트 내보내기입니다. 인시던트당 한 행, 오래된 순이며 CSV 내보내기와 같은 열을 포함합니다: 시설, 테스트 또는 실제, 상태, 처리 결과, 현지 시간, 확인 및 해결까지 걸린 시간(초), 확인 및 해결한 사람, 버튼 및 전송 수.
• delivery_problems: 전송되지 않은 알람 알림입니다. 시설의 가장 최근 알람 또는 테스트(전체 테스트 기간 포함)와 채널별로 도착하지 않은 알림입니다. 모두 전달된 경우 problems는 null입니다. 해당 시설에서 Duress 또는 Duress Configuration이 필요합니다.

Duress 인시던트를 해결합니다: 알람을 종료하고 에스컬레이션을 중지하며 처리 결과를 기록합니다. 열린 인시던트와 확인된 인시던트를 해결할 수 있습니다.

• disposition: genuine(실제 비상 상황), false_alarm, test 또는 unknown.
• note: 발생한 상황입니다. 실제 알람에는 필수입니다.

항상 먼저 확인하십시오. confirm 없이 호출하여 인시던트를 가져오고, 사용자에게 종료할 알람과 처리 결과를 알린 후, 동의한 경우에만 confirm: true로 다시 호출하십시오.

워크플로나 에이전트에서는 시설의 대응 계획이 워크플로의 알람 확인, 해결 및 발생을 허용하는 경우에만 작동합니다.

Duress 설정을 읽습니다: 대응 계획(시설 또는 브랜드 템플릿에서 누구에게, 어떤 순서로, 어떤 방법으로 알리는지), 알람 엔진이 실제로 사용하는 확정된 계획, 추가할 수 있는 사람과 역할, 기기 알림(배터리, 오프라인, 커버리지 및 전송 문제), 브랜드 연락처 규칙과 계획 상태, 브랜드 또는 조직의 버튼 개요, 그리고 모니터링 센터로 알람이 전달되는 경로입니다.

시설은 브랜드(없으면 조직)의 템플릿을 따르거나, 추가 연락처로 템플릿을 확장하거나(mode extend), 자체 계획으로 대체합니다(mode replace). 설정은 duress_settings_write로 변경하십시오. 시간은 ISO 형식입니다.

작업:

• response_plan: 대응 계획입니다. 시설에 적용 중인 계획(effective)과 각 수준의 내용(sources: facility, brand, organisation), 또는 brandId만 지정한 경우 브랜드 템플릿입니다. 연락처는 저장된 그대로이므로 편집하여 다시 저장할 수 있습니다.
• resolved_plan: 확정된 계획입니다. 알람 엔진이 시설에서 단계별로 연락하는 대상: 사람으로 확장된 역할, 각 사람에게 연락할 수 있는 채널, 지연 시간, 알람 전에 해결해야 할 경고입니다. 이름만 포함되며 전화번호나 이메일은 포함되지 않습니다.
• contact_options: 연락처 옵션입니다. 브랜드의 연락처 규칙을 적용한 후 시설의 계획(해당 시설에서 Duress Configuration 필요) 또는 brandId만 지정한 경우 브랜드 템플릿에 추가할 수 있는 사람과 역할입니다.
• device_alerts: 기기 알림입니다. 배터리 부족, 오프라인 버튼, 커버리지 손실 및 전송 실패를 누구에게 알리는지: 각 수준의 규칙과 시설의 확정된 수신자, 또는 brandId만 지정한 경우 브랜드의 규칙입니다.
• contact_rules: 브랜드 연락처 규칙입니다. 브랜드의 시설이 계획에 추가할 수 있는 역할입니다: allowAllExcept는 나열된 역할을 숨기고, manual은 나열된 역할만 제공합니다. 브랜드 계획 편집에 필요한 권한이 필요합니다. brandId가 필요합니다.
• plan_status: 브랜드 계획 상태입니다. 브랜드의 각 시설이 템플릿을 따르는지, 확장하는지, 자체 계획이 있는지, 추가한 연락처 수, 계획의 경고입니다. brandId가 필요합니다.
• buttons_summary: 버튼 개요입니다. 브랜드 또는 조직의 모든 시설: 버튼, 배터리 및 오프라인 수, 다음 및 마지막 테스트입니다. Brands & Customisation 및 조직 개요의 데이터입니다.
• monitoring: 모니터링 센터 라우팅입니다. 알람이 시설 밖으로 전달되는 방식: eaAlarmType none, cid(eaAlarmProvider를 통한 모니터링 센터 호출) 또는 relay(eaRelayModel을 통한 유선 패널), 그리고 사용할 수 있는 공급자입니다.

Duress 설정을 변경합니다: 대응 계획(시설, 또는 브랜드나 조직의 템플릿), 기기 알림, 브랜드 연락처 규칙, 모니터링 센터로 알람이 전달되는 경로입니다. 알림 대상이 바뀌므로 모든 변경에 확인을 요청합니다.

facilityId(기본값: 연결된 시설), brandId 또는 organisationId 중 하나를 전달하십시오. 시설 계획에는 해당 시설에서 Duress Configuration이 필요하고, 템플릿에는 Duress Configuration이 있는 조직 관리자가 필요하며, 브랜드의 경우 브랜드에 속한 모든 시설에서 Duress Configuration이 필요합니다. 먼저 duress_settings_read로 확인하십시오.

작업:

• save_response_plan: 대응 계획을 저장합니다. 누름 후 afterSeconds가 지나면 알림을 받는 연락처 단계(오름차순, 첫 단계는 보통 0), ackRequired, reminders, responseActions입니다. 시설은 대신 추가 연락처로 템플릿을 확장할 수 있습니다(mode extend). 지정하지 않은 필드는 저장된 값을 유지하며, responseActions는 작업별로 병합됩니다. 확인을 요청합니다.
• remove_response_plan: 대응 계획을 제거합니다. 이 수준에 저장된 계획을 삭제하므로 시설은 다시 템플릿을 따르고 브랜드는 조직의 템플릿으로 돌아갑니다. 확인을 요청합니다.
• save_device_alerts: 기기 알림을 저장합니다. 이 수준의 기기 알림 규칙을 대체합니다: 최대 10개 규칙이며, 각 규칙은 이벤트와 연락처(push, sms 또는 email)의 집합입니다. duress_settings_read device_alerts에서 읽은 규칙 ID를 유지하십시오. rules가 필요합니다. 확인을 요청합니다.
• remove_device_alerts: 기기 알림을 제거합니다. 이 수준의 기기 알림 규칙을 삭제하여 다시 상위 수준을 따르도록 합니다. 확인을 요청합니다.
• save_contact_rules: 브랜드 연락처 규칙을 저장합니다. 브랜드의 시설이 계획에 추가할 수 있는 역할입니다: allowAllExcept는 roleIds를 숨기고, manual은 roleIds만 제공합니다. 이미 저장된 연락처는 유지되며, 확정된 계획은 새로 고쳐집니다. brandId, mode, roleIds가 필요합니다. 확인을 요청합니다.
• save_monitoring: 모니터링 센터 라우팅을 저장합니다. 알람이 전달되는 경로: eaAlarmType none, cid(duress_settings_read monitoring에 나열된 공급자 중 하나인 eaAlarmProvider 필요) 또는 relay(eaRelayModel). 시설에서 Duress Configuration이 필요합니다. eaAlarmType이 필요합니다. 확인을 요청합니다.

Duress 알람에 대해 시설을 잠급니다: 잠금이 해제될 때까지(duress_lift_lockdown 또는 콘솔에서) 모든 문이 출입을 허용하지 않습니다. 알람당 잠금은 한 번만 실행됩니다.

테스트 알람이나 해결된 알람에는 절대 사용하지 마십시오. 시설에서 Door/Gate Access가 필요합니다.

먼저 확인하십시오. confirm 없이 호출하여 인시던트를 확인하고, 사용자에게 모든 문이 잠긴다는 사실을 알린 후, 동의하면 confirm: true로 다시 호출하십시오.

시설에서 Duress 테스트를 즉시 시작합니다. 테스트가 끝날 때까지 모든 누름은 실제 알람이 아닌 테스트로 처리됩니다:

• walk: 직원이 각 버튼을 누르며, 대응 계획의 첫 번째 단계에만 TEST 표시와 함께 알림이 전송됩니다.
• drill: 전체 대응 계획이 TEST 표시와 함께 실행됩니다.

시설의 테스트 연락처에는 테스트 시작이 알려지며, 테스트가 끝나고 약 10분 후에 결과를 받습니다. 시설당 한 번에 하나의 테스트만 실행할 수 있습니다. duress_end_test로 일찍 종료하고, duress_tests_write로 테스트를 미리 예약하십시오.

먼저 확인하십시오. confirm 없이 호출하고, durationMinutes 동안 누름이 실제 알람을 발생시키지 않는다는 사실을 사용자에게 알린 후, 동의하면 confirm: true로 다시 호출하십시오. 워크플로나 에이전트에서는 시설의 대응 계획이 워크플로의 알람 확인, 해결 및 발생을 허용하는 경우에만 작동합니다.

Duress 버튼 테스트를 읽습니다: 테스트를 예약하는 일정(walk, comms 또는 drill, 한 번 또는 반복, 조직, 브랜드 또는 시설 대상), 일정에 따라 각 시설에 생성되는 테스트 기간(scheduled, active, completed, cancelled 및 임시 테스트), 그리고 기간별 결과(눌렸거나 누락된 버튼, 알림을 받은 사람, 모니터링 센터 신호, 확인 시간)입니다.

테스트를 예약, 변경 또는 취소한 사람은 제외되며, 전송 수신자는 가려집니다. 시간은 ISO 형식이며, localDate와 localStartTime은 시설 시간대 기준입니다. 테스트 예약이나 변경은 duress_tests_write로, 즉시 시작은 duress_start_test로 하십시오.

작업:

• schedules: 테스트 일정입니다. scope facility(기본값, 공유 일정 중 건너뛰거나 대체하는 일정을 포함하여 해당 시설에 적용되는 모든 일정), brand(brandId) 또는 organisation(기본값: 시설의 조직). 최근 변경 순입니다.
• windows: 테스트 기간입니다. from부터 to까지의 시설 테스트 기간(기본값은 약 1주 전부터 1개월 후까지), 또는 organisationId만 지정한 경우 조직의 모든 시설에 걸친 예정된 기간입니다.
• results: 테스트 결과입니다. 기간과 그 결과: 전송 후 저장된 결과, 테스트 진행 중에는 실시간 계산 결과(walk 테스트 체크리스트), 예약되었거나 취소된 기간은 null입니다. 시설에서 Duress가 필요합니다. startsAtKey가 필요합니다.

Duress 테스트 일정을 예약, 변경, 취소하고, 한 시설이 공유 일정을 따르는 방식을 설정하며, 예정된 테스트 시간 창 하나를 취소합니다. 모든 변경은 향후 시간 창을 예약하거나 다시 작성하고 이해관계자에게 이메일을 보내므로 각 작업은 확인을 요청합니다.

일정에는 대상 전체에 대한 Duress Configuration 권한이 필요합니다(조직 전체 일정은 조직 관리자 권한). 시간은 각 시설의 시간대를 기준으로 합니다. 먼저 duress_tests_read로 일정과 시간 창을 확인하고, 지금 테스트를 시작하려면 duress_start_test를 사용하십시오.

작업:

• create_schedule: 테스트 일정을 예약합니다. target의 모든 시설에 약 1년 앞까지 시간 창을 예약하고 예약 확인 이메일을 보냅니다. name, type, target, startDate, localStartTime, recurrence가 필요합니다. 필요한 값: name, type, target, startDate, localStartTime, recurrence. 확인을 요청합니다.
• update_schedule: 테스트 일정을 변경합니다. 생략한 필드는 기존 값을 유지합니다. 향후 시간 창이 다시 작성되고(이미 시작된 시간 창은 유지) 이해관계자에게 변경 알림이 전송됩니다. 이후에는 결과의 ownerScope를 사용하십시오. 필요한 값: ownerScope, scheduleId. 확인을 요청합니다.
• cancel_schedule: 테스트 일정을 취소합니다. 일정과 향후 시간 창을 취소하고 취소 이메일을 보냅니다. 자체 사본이 있는 시설은 그 사본을 유지합니다. 필요한 값: ownerScope, scheduleId. 확인을 요청합니다.
• set_facility_override: 한 시설에 대해 공유 일정을 변경합니다. mode는 follow(이 시설에서 공유 일정을 다시 실행), skip(이 시설에서 중지) 또는 own(schedule로 만든 사본으로 이 시설의 일정을 대체)입니다. 해당 시설에 대한 Duress Configuration 권한만 필요합니다. 필요한 값: ownerScope, scheduleId, mode. 확인을 요청합니다.
• cancel_window: 테스트 시간 창 하나를 취소합니다. 한 시설의 예정된 테스트 하나를 취소하고(일정은 계속 유지) 이해관계자에게 이메일을 보냅니다. 해당 시설에 대한 Duress 권한이 필요하며, 진행 중인 테스트는 대신 duress_end_test로 종료합니다. 필요한 값: startsAtKey. 확인을 요청합니다.

Duress 경보에 대해 출입문 잠금을 해제합니다. 예를 들어 경찰이나 응급 처치 요원이 들어올 수 있도록 할 때 사용합니다. 대상은 눌린 버튼에 연결된 출입문이며, 없으면 대응 계획의 출입문입니다. 모든 출입문을 대상으로 하려면 doorIds를 생략하고, 일부만 대상으로 하려면 목록으로 지정하십시오. 모든 잠금 해제는 사건 타임라인과 접근 로그에 기록됩니다.

테스트 경보나 해결된 경보에는 절대 사용하지 마십시오. 해당 시설에 대한 Door/Gate Access 권한이 필요합니다.

먼저 확인하십시오. confirm 없이 호출하여 잠금 해제될 출입문을 확인하고 사용자에게 알린 다음, 사용자가 동의하면 confirm: true로 다시 호출하십시오.