डुरेस

उपयोगकर्ता की ओर से किसी खुली duress घटना को स्वीकार करता है: यह दर्ज करता है कि वे प्रतिक्रिया दे रहे हैं और आगे का एस्केलेशन रोक सकता है। केवल खुली घटनाओं को स्वीकार किया जा सकता है।

हमेशा पहले पुष्टि करें। घटना प्राप्त करने के लिए confirm के बिना कॉल करें, उपयोगकर्ता को बताएँ कि वे क्या स्वीकार कर रहे हैं, और उनकी सहमति के बाद ही confirm: true के साथ दोबारा कॉल करें।

किसी workflow में, या किसी एजेंट से, यह केवल वहीं काम करता है जहाँ सुविधा की प्रतिक्रिया योजना workflow को अलार्म स्वीकार करने, हल करने और उठाने देती है। किसी घटना को बंद करने के लिए duress_resolve_incident का उपयोग करें।

किसी सुविधा के duress बटन पढ़ता है: उनकी स्थिति (बैटरी, अंतिम बार कब सुना गया, अंतिम परीक्षण), पूरी प्रोफ़ाइल (लेबल, कमरा, ज़ोन, स्थापना, जुड़े कैमरे, दरवाज़े और स्क्रीन, म्यूट किए गए अलर्ट, पर्यवेक्षण स्थिति), उन्हें किससे जोड़ा जा सकता है, उनके प्रेस रिले करने वाली स्क्रीन, और नए जोड़े गए बटन का सेटअप परीक्षण।

बैटरी: low 30% या उससे कम है (जल्द बदलें), critical 20% या उससे कम (अभी बदलें)। null बैटरी और lastSeenAt का अर्थ है कि किसी स्क्रीन ने अभी तक बटन को नहीं सुना है। समय 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 जाँचें। सुविधा में डिवाइस प्रबंधन या Duress Configuration आवश्यक है। deviceSerialNumber आवश्यक है। पुष्टि माँगता है।
• remove: बटन हटाएँ। बटन को सुविधा से अनपेयर करता है और उसकी प्रोफ़ाइल हटाता है, जिससे उसका ज़ोन मुक्त हो जाता है। जब उसका कोई अलार्म खुला हो, तब नहीं। सुविधा में डिवाइस प्रबंधन आवश्यक है। deviceSerialNumber आवश्यक है। पुष्टि माँगता है।
• add: बटन जोड़ें। उस पर छपे सीरियल से सुविधा में नया duress बटन पंजीकृत करता है। डिफ़ॉल्ट रूप से, अगले 30 मिनट में उसका पहला प्रेस केवल एक परीक्षण होता है (setupTest)। सुविधा में Duress alarm monitoring चालू वाली स्क्रीन या IoT Gateway होना चाहिए। सुविधा में डिवाइस प्रबंधन आवश्यक है। deviceSerialNumber आवश्यक है। पुष्टि माँगता है।

किसी सुविधा में चल रहे duress परीक्षण को अभी समाप्त करता है, ताकि अगला प्रेस वास्तविक अलार्म हो। किसी भी परीक्षण की तरह, परिणाम लगभग 10 मिनट बाद आते हैं।

duress अलार्म घटनाएँ पढ़ता है (स्टाफ़ ने duress बटन दबाया, या किसी workflow ने अलार्म उठाया): सूचियाँ, किसी एक घटना की टाइमलाइन और डिलीवरी, पोस्टमॉर्टम रिपोर्ट, और अलार्म के आसपास का सीसीटीवी फ़ुटेज।

स्थितियाँ: open (किसी ने अभी तक इसे स्वीकार नहीं किया है), acknowledged (कोई प्रतिक्रिया दे रहा है), resolved (बंद, एक disposition के साथ: 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)। सुविधा में सीसीटीवी आवश्यक है। incidentId आवश्यक है।
• footage_frame: अलार्म फ़ुटेज फ़्रेम। अलार्म फ़ुटेज से एक टाइमलैप्स फ़्रेम, छवि के रूप में लौटाया जाता है: फ़ुटेज रखे जाने के बाद रखी गई प्रति, अन्यथा अलार्म विंडो के भीतर का लाइव फ़्रेम। seconds, footage_previews से प्राप्त posterSeconds या frameSeconds मान है। incidentId, cameraId, seconds आवश्यक हैं।

अलार्म को छुए बिना किसी duress घटना को बदलता है: उसे नाम देता है, स्टाफ़ नोट जोड़ता है, और उसके आसपास का सीसीटीवी फ़ुटेज रखता या छोड़ता है। किसी को अलर्ट नहीं किया जाता। स्वीकार करने, हल करने या उत्तरदाताओं को बताने के लिए duress_acknowledge_incident, duress_resolve_incident या duress_post_update का उपयोग करें।

क्रियाएँ:

• rename: घटना को नाम दें। घटना को नाम देता है ताकि उसे बाद में ढूँढना आसान हो, जैसे "फ्रंट काउंटर पर आक्रामक आगंतुक"। खाली या null नाम उसे हटा देता है। नाम Duress कंसोल और रिपोर्ट में दिखते हैं। incidentId आवश्यक है।
• add_note: नोट जोड़ें। घटना की टाइमलाइन में एक नोट जोड़ता है, जैसे उपयोगकर्ता को क्या मिला या कौन पहुँचा। किसी भी स्थिति में; नोट केवल स्टाफ़ देखता है और वे घटना को नहीं बदलते। इसे उपयोगकर्ता के शब्दों में लिखें और पहले उनसे शब्दों की पुष्टि करें। incidentId, note आवश्यक हैं।
• keep_footage: अलार्म फ़ुटेज रखें। किसी हल किए गए वास्तविक अलार्म के आसपास का सीसीटीवी फ़ुटेज रखता है ताकि वह सामान्य रिकॉर्डिंग के साथ हटाया न जाए, प्रतिक्रिया योजना के मिनटों और कैमरों का उपयोग करके। यह कुछ मिनट बाद, अपलोड होने पर होता है। परीक्षणों, खुले अलार्म, या पहले से रखे या छोड़े गए फ़ुटेज के लिए नहीं। incidentId आवश्यक है।
• release_footage: रखा गया फ़ुटेज छोड़ें। किसी अलार्म के लिए रखे गए फ़ुटेज को छोड़ देता है: क्लिप सामान्य प्रतिधारण पर लौट आते हैं और रखे गए फ़्रेम हटा दिए जाते हैं, इसलिए सामान्य रिकॉर्डिंग की समय-सीमा समाप्त होने के बाद इसे देखा नहीं जा सकता। सुविधा में Duress Configuration आवश्यक है। incidentId आवश्यक है। पुष्टि माँगता है।

किसी duress अलार्म का लॉकडाउन हटाता है: उसके द्वारा लॉक किए गए दरवाज़े फिर से लोगों को अंदर आने देते हैं। अलार्म की स्थिति चाहे जो हो, काम करता है।

पहले पुष्टि करें। लॉकडाउन देखने के लिए confirm के बिना कॉल करें, उपयोगकर्ता को बताएँ, और उनकी सहमति के बाद confirm: true के साथ दोबारा कॉल करें।

किसी duress अलार्म पर प्रतिक्रिया दे रहे लोगों को अपडेट पोस्ट करता है, जैसे "पुलिस रास्ते में है" या "सब ठीक है, व्यक्ति जा चुका है"। यह उनके अलार्म पेज पर और Duress ऐप में दिखता है, और वास्तविक अलार्म पर प्रतिक्रिया योजना इसे उन सभी को टेक्स्ट भी कर सकती है जिन्हें अलार्म के बारे में पहले ही टेक्स्ट किया जा चुका है। अलार्म हल होने के 24 घंटे बाद तक अपडेट पोस्ट किए जा सकते हैं।

पहले पुष्टि करें। घटना जाँचने के लिए confirm के बिना कॉल करें, उपयोगकर्ता को सटीक शब्द दिखाएँ, और उनकी सहमति के बाद confirm: true के साथ दोबारा कॉल करें। जो केवल स्टाफ़ को दिखना चाहिए, उसके लिए इसके बजाय duress_incidents_write add_note का उपयोग करें।

सुविधा में एक वास्तविक duress अलार्म उठाता है, मानो कोई बटन दबाया गया हो: प्रतिक्रिया योजना चलती है (लोगों को अलर्ट किया जाता है, एस्केलेशन और रिमाइंडर होते हैं, प्रतिक्रिया क्रियाएँ चलती हैं) और अलार्म बताता है कि इसे इस workflow ने कारण सहित उठाया है।

• reason: क्या हुआ, जैसे "पिछले निकास पर दरवाज़ा ज़बरदस्ती खोला गया" (200 वर्णों तक)।
• deviceSerialNumber: वैकल्पिक। वह बटन जिसका स्थान उपयोग करना है; केवल तभी मॉनिटरिंग सेंटर को भी उस बटन के ज़ोन के साथ सूचित किया जाता है।

केवल workflow चरण के रूप में, उन सुविधाओं में जिनकी प्रतिक्रिया योजना workflow को अलार्म स्वीकार करने, हल करने और उठाने देती है। जब तक इस workflow का अलार्म खुला है, यह दूसरा अलार्म नहीं उठाएगा; इसके बजाय वही अलार्म लौटाता है।

किसी सुविधा, ब्रांड या संगठन के लिए Duress अनुपालन रिपोर्टिंग: प्रतिक्रिया समय (P50/P95), disposition के अनुसार घटनाएँ और झूठे अलार्म की दर, परीक्षण कवरेज और अतिदेय सुविधाएँ, बटन अपटाइम, मॉनिटरिंग सेंटर डिलीवरी की सफलता, और घटना-दर-घटना निर्यात। साथ ही एक सुविधा में नवीनतम अलार्म के अवितरित अलर्ट।

दिन सुविधा के स्थानीय समय के अनुसार हैं; 400 दिनों से अधिक की अवधि छोटी कर दी जाती है (range.capped)। वास्तविक और परीक्षण घटनाएँ अलग-अलग गिनी जाती हैं। अवधियाँ ms में हैं (p50Ms, p95Ms)। ब्रांड रिपोर्ट केवल उन सुविधाओं को कवर करती हैं जिन तक आपकी पहुँच है, जब तक आपके पास संगठन-व्यापी पहुँच न हो (scope.restrictedToAccessibleFacilities)।

क्रियाएँ:

• overview: Duress रिपोर्ट अवलोकन। कुल योग, मासिक रुझान और प्रति-संगठन, प्रति-ब्रांड और प्रति-सुविधा मेट्रिक्स (incidents, testCoverage, deviceUptime, deliveries)। सुविधाएँ पेज में दी जाती हैं।
• compliance_summary: Duress अनुपालन सारांश। अनुपालन PDF क्या दिखाता है: अतिदेय सुविधाओं के साथ परीक्षण कवरेज, बटन अपटाइम, डिलीवरी सफलता, हाल के परीक्षण (testHistory), और प्रति सुविधा उसका अंतिम परीक्षण, ड्रिल और वास्तविक अलार्म, प्रत्येक बटन के अपटाइम के साथ। सुविधाएँ पेज में दी जाती हैं।
• incident_export: Duress घटना निर्यात। प्रति घटना एक पंक्ति, सबसे पुरानी पहले, CSV निर्यात के कॉलम के साथ: सुविधा, परीक्षण या वास्तविक, स्थिति, disposition, स्थानीय समय, स्वीकार करने और हल करने में लगे सेकंड, किसने स्वीकार किया और हल किया, बटन और डिलीवरी की संख्या।
• delivery_problems: अवितरित अलार्म अलर्ट। सुविधा का नवीनतम अलार्म या परीक्षण (उसकी पूरी परीक्षण विंडो के साथ) और वे अलर्ट जो कभी नहीं पहुँचे, चैनल के अनुसार। सब कुछ पहुँच जाने पर problems null होता है। वहाँ Duress या Duress Configuration आवश्यक है।

किसी duress घटना को हल करता है: यह अलार्म बंद करता है, एस्केलेशन रोकता है और परिणाम दर्ज करता है। खुली और स्वीकार की गई घटनाओं को हल किया जा सकता है।

• disposition: genuine (वास्तविक आपातकाल), false_alarm, test या unknown।
• note: क्या हुआ। वास्तविक अलार्म के लिए आवश्यक।

हमेशा पहले पुष्टि करें। घटना प्राप्त करने के लिए confirm के बिना कॉल करें, उपयोगकर्ता को बताएँ कि वे कौन-सा अलार्म बंद कर रहे हैं और परिणाम क्या है, और उनकी सहमति के बाद ही confirm: true के साथ दोबारा कॉल करें।

किसी workflow में, या किसी एजेंट से, यह केवल वहीं काम करता है जहाँ सुविधा की प्रतिक्रिया योजना workflow को अलार्म स्वीकार करने, हल करने और उठाने देती है।

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। कोई सुविधा इसके बजाय additions के साथ अपने टेम्पलेट का विस्तार कर सकती है (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 (eaAlarmProvider आवश्यक, duress_settings_read monitoring द्वारा सूचीबद्ध प्रदाताओं में से एक) या 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 के साथ दोबारा कॉल करें। किसी workflow में, या किसी एजेंट से, यह केवल वहीं काम करता है जहाँ सुविधा की प्रतिक्रिया योजना workflow को अलार्म स्वीकार करने, हल करने और उठाने देती है।

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 तक किसी सुविधा की परीक्षण विंडो (डिफ़ॉल्ट लगभग एक सप्ताह पहले से एक महीने आगे तक), या केवल organisationId के साथ संगठन की सभी सुविधाओं की आगामी विंडो।
• results: परीक्षण परिणाम। एक विंडो और उसके परिणाम: भेजे जाने के बाद संग्रहीत, परीक्षण चलते समय लाइव गणना (walk-test चेकलिस्ट), शेड्यूल की गई या रद्द की गई विंडो के लिए null। सुविधा में Duress आवश्यक है। startsAtKey आवश्यक है।

Duress परीक्षण शेड्यूल बुक करता है, बदलता है और रद्द करता है, यह सेट करता है कि कोई एक सुविधा साझा शेड्यूल का पालन कैसे करती है, और किसी एक आगामी परीक्षण विंडो को रद्द करता है। हर बदलाव भविष्य की विंडो बुक करता है या दोबारा लिखता है और हितधारकों को ईमेल भेजता है, इसलिए हर बदलाव पुष्टि माँगता है।

शेड्यूल के लिए उनके पूरे लक्ष्य पर Duress Configuration आवश्यक है (संगठन-व्यापी शेड्यूल के लिए संगठन व्यवस्थापक)। समय हर सुविधा के अपने समय क्षेत्र में होते हैं। पहले duress_tests_read से शेड्यूल और विंडो पढ़ें; अभी परीक्षण शुरू करने के लिए duress_start_test का उपयोग करें।

कार्रवाइयाँ:

• create_schedule: परीक्षण शेड्यूल बुक करें। target की हर सुविधा पर लगभग एक वर्ष आगे तक की विंडो बुक करता है और बुकिंग की पुष्टि का ईमेल भेजता है। 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 के साथ फिर से कॉल करें।