Urgence

Prend en charge un incident Duress ouvert au nom de l'utilisateur : enregistre qu'il intervient, ce qui peut arrêter la poursuite de l'escalade. Seuls les incidents ouverts peuvent être pris en charge.

Confirmez toujours d'abord. Appelez sans confirm pour obtenir l'incident, indiquez à l'utilisateur ce qu'il prend en charge, puis appelez de nouveau avec confirm: true uniquement après son accord.

Dans un workflow, ou depuis un Agent, cela ne fonctionne que si le plan d'intervention de l'installation autorise les workflows à prendre en charge, résoudre et déclencher des alarmes. Pour clôturer un incident, utilisez duress_resolve_incident.

Lit les boutons Duress d'une installation : leur statut (batterie, dernier signal reçu, dernier test), leurs profils complets (libellé, pièce, zone, emplacement, caméras, portes et écrans associés, alertes désactivées, état de la supervision), ce à quoi ils peuvent être associés, les écrans qui relaient leurs pressions et le test de configuration d'un bouton nouvellement ajouté.

Batterie : low correspond à 30 % ou moins (à remplacer bientôt), critical à 20 % ou moins (à remplacer maintenant). Une batterie et un lastSeenAt null signifient qu'aucun écran n'a encore capté le bouton. Les heures sont au format ISO.

Actions :

• status : statut des boutons. Chaque bouton avec sa zone, sa pièce, sa batterie, le moment où un écran l'a capté pour la dernière fois et la date de son dernier test. "Les boutons Duress fonctionnent-ils ?", "Lesquels ont besoin de piles neuves ?"
• list : profils des boutons. Le profil complet de chaque bouton : ce que modifie duress_buttons_write update, ainsi que le signal, les écrans qui l'ont capté au cours du dernier jour, l'état de la supervision et un test de configuration en attente.
• link_options : options d'association. Les caméras, portes, écrans et zones d'accès de l'installation auxquels un bouton peut être associé (ID pour duress_buttons_write update).
• receivers : récepteurs des boutons. Les écrans d'affichage de l'installation qui captent les boutons et relaient les pressions, et si chacun est en ligne. ready vaut false lorsque rien ne peut capter un bouton.
• setup_test : test de configuration. Le test de configuration d'un bouton nouvellement ajouté : waiting (sa première pression n'est qu'un test), received, expired, ended ou none, et si un écran l'a capté depuis son ajout. Nécessite deviceSerialNumber.

Modifie les boutons Duress d'une installation : ajouter un nouveau bouton, modifier leur profil (libellé, pièce, zone, emplacement, notes, caméras, portes, écrans et zone d'accès associés, alertes d'appareil désactivées), en faire biper un pour que le personnel le retrouve, terminer le test de configuration d'un nouveau bouton pour le mettre en service, et retirer un bouton.

Les champs omis dans update conservent leur valeur ; null les efface. Lisez le profil actuel avec duress_buttons_read list.

Actions :

• update : mettre à jour un bouton. Enregistre le profil du bouton dans l'installation où il est enregistré (nécessite Duress Configuration dans celle-ci). zone va de 001 à 999 et est unique dans l'installation. alertsMutedUntil (ISO, 30 jours à l'avance au maximum) désactive ses alertes de batterie et de déconnexion. Nécessite deviceSerialNumber.
• locate : faire biper un bouton. Fait biper et clignoter le bouton pendant 30 secondes pour que le personnel le retrouve, par exemple un bouton qui signale sans cesse une batterie faible. Un écran proche envoie la commande ; le bouton doit donc être à portée d'un écran. Impossible tant qu'il a une alarme ouverte. Nécessite deviceSerialNumber.
• go_live : mettre en service un nouveau bouton. Termine immédiatement le test de configuration d'un bouton nouvellement ajouté, de sorte que sa prochaine pression déclenche une véritable alarme. Vérifiez d'abord duress_buttons_read setup_test. Nécessite Gestion d'appareils ou Duress Configuration dans l'installation. Nécessite deviceSerialNumber. Demande une confirmation.
• remove : retirer un bouton. Dissocie le bouton de l'installation et supprime son profil, ce qui libère sa zone. Impossible tant qu'il a une alarme ouverte. Nécessite Gestion d'appareils dans l'installation. Nécessite deviceSerialNumber. Demande une confirmation.
• add : ajouter un bouton. Enregistre un nouveau bouton Duress dans l'installation grâce au numéro de série imprimé dessus. Par défaut, sa première pression dans les 30 minutes suivantes n'est qu'un test (setupTest). L'installation doit disposer d'un écran avec Duress alarm monitoring activé ou d'un IoT Gateway. Nécessite Gestion d'appareils dans l'installation. Nécessite deviceSerialNumber. Demande une confirmation.

Termine immédiatement le test Duress en cours dans une installation, de sorte que la prochaine pression déclenche une véritable alarme. Les résultats suivent environ 10 minutes plus tard, comme pour tout test.

Lit les incidents d'alarme Duress (un membre du personnel a appuyé sur un bouton Duress, ou un workflow a déclenché une alarme) : listes, chronologie et envois d'un incident, rapport post-mortem et images de vidéosurveillance autour d'une alarme.

Statuts : open (personne ne l'a encore pris en charge), acknowledged (quelqu'un intervient), resolved (clôturé, avec une issue : genuine, false_alarm, test ou unknown). active signifie open ou acknowledged. Les incidents de test (isTest) proviennent des tests de boutons ; testType 'unplanned' désigne une alarme déclenchée comme réelle qu'un intervenant a résolue comme test.

Statut d'envoi : sent, acknowledged (le destinataire a confirmé), failed (voir error), shadow (simulation, rien n'a été envoyé). Les envois au centre de télésurveillance sont aussi totalisés sous monitoringCentre. Les résultats nomment les personnes mais n'incluent jamais de numéros de téléphone ni d'adresses e-mail. Les heures sont au format ISO.

Actions :

• list : lister les incidents. Les plus récents en premier. scope : facility (par défaut ; l'installation indiquée ou connectée) ou organisation (toutes les installations de celle-ci que vous pouvez voir ; par défaut l'organisation de l'installation).
• get : obtenir un incident. Statut, boutons pressés, chronologie (pressions, escalades, prises en charge, notes) et chaque tentative d'envoi de notification ou au centre de télésurveillance avec son résultat. Nécessite incidentId.
• report : rapport d'incident. Pour un post-mortem : l'incident, les secondes avant prise en charge et résolution, les étapes atteintes, chaque entrée de la chronologie, ce qui a été envoyé par canal et ce qui a échoué, et si les images ont été conservées. Associez-le à duress_incidents_write add_note pour ajouter le post-mortem à l'incident. Nécessite incidentId.
• footage_previews : images de l'alarme. Chaque caméra des images de l'alarme : son statut, le nombre d'images et de clips, les clips téléversés et l'image la plus proche de la pression (posterSeconds). Avec cameraId, uniquement cette caméra, avec les secondes Unix de chaque image (frameSeconds). Nécessite la vidéosurveillance dans l'installation. Nécessite incidentId.
• footage_frame : image des enregistrements de l'alarme. Une image de timelapse des enregistrements de l'alarme, renvoyée sous forme d'image : une copie conservée une fois les images conservées, sinon l'image en direct dans la fenêtre de l'alarme. seconds est une valeur posterSeconds ou frameSeconds issue de footage_previews. Nécessite incidentId, cameraId, seconds.

Modifie un incident Duress sans toucher à l'alarme elle-même : lui donne un nom, ajoute des notes du personnel, et conserve ou libère les images de vidéosurveillance associées. Personne n'est alerté. Pour prendre en charge, résoudre ou informer les intervenants, utilisez duress_acknowledge_incident, duress_resolve_incident ou duress_post_update.

Actions :

• rename : nommer un incident. Donne un nom à l'incident pour le retrouver facilement, par exemple "Visiteur agressif au comptoir d'accueil". Un nom vide ou null le supprime. Les noms s'affichent dans la console Duress et les rapports. Nécessite incidentId.
• add_note : ajouter une note. Ajoute une note à la chronologie de l'incident, par exemple ce que l'utilisateur a constaté ou qui est intervenu. Quel que soit le statut ; seul le personnel voit les notes, qui ne modifient pas l'incident. Rédigez-la avec les mots de l'utilisateur et faites-lui d'abord confirmer la formulation. Nécessite incidentId, note.
• keep_footage : conserver les images de l'alarme. Conserve les images de vidéosurveillance autour d'une véritable alarme résolue pour qu'elles ne soient pas supprimées avec les enregistrements habituels, selon les minutes et les caméras du plan d'intervention. L'opération a lieu quelques minutes plus tard, une fois les images téléversées. Pas pour les tests, les alarmes ouvertes, ni les images déjà conservées ou libérées. Nécessite incidentId.
• release_footage : libérer les images conservées. Renonce aux images conservées pour une alarme : les clips reviennent à la conservation habituelle et les images conservées sont supprimées ; elles ne peuvent donc plus être consultées une fois les enregistrements habituels expirés. Nécessite Duress Configuration dans l'installation. Nécessite incidentId. Demande une confirmation.

Lève le confinement d'une alarme Duress : les portes qu'il a verrouillées laissent de nouveau entrer les personnes. Fonctionne quel que soit le statut de l'alarme.

Confirmez d'abord. Appelez sans confirm pour voir le confinement, informez l'utilisateur, puis appelez de nouveau avec confirm: true une fois son accord obtenu.

Publie une mise à jour à l'intention des personnes qui interviennent sur une alarme Duress, par exemple "La police arrive" ou "Fin d'alerte, la personne est partie". Elle s'affiche sur leur page d'alarme et dans l'app Duress, et, pour une véritable alarme, le plan d'intervention peut aussi l'envoyer par SMS à toutes les personnes déjà prévenues par SMS de l'alarme. Les mises à jour peuvent être publiées jusqu'à 24 heures après la résolution de l'alarme.

Confirmez d'abord. Appelez sans confirm pour vérifier l'incident, montrez à l'utilisateur la formulation exacte, puis appelez de nouveau avec confirm: true une fois son accord obtenu. Pour une information réservée au personnel, utilisez plutôt duress_incidents_write add_note.

Déclenche une véritable alarme Duress dans l'installation, comme si un bouton avait été pressé : le plan d'intervention s'exécute (les personnes sont alertées, l'escalade et les rappels suivent, les actions d'intervention s'exécutent) et l'alarme indique qu'elle a été déclenchée par ce workflow, avec la raison.

• reason : ce qui s'est passé, par exemple "Porte forcée à la sortie arrière" (200 caractères au maximum).
• deviceSerialNumber : facultatif. Un bouton dont l'emplacement doit être utilisé ; dans ce cas seulement, le centre de télésurveillance est aussi prévenu, avec la zone de ce bouton.

Uniquement comme étape d'un workflow, dans les installations dont le plan d'intervention autorise les workflows à prendre en charge, résoudre et déclencher des alarmes. Tant que l'alarme de ce workflow est ouverte, il n'en déclenche pas d'autre ; il renvoie cette alarme à la place.

Rapports de conformité Duress pour une installation, une marque ou une organisation : temps de réponse (P50/P95), incidents par issue et taux de fausses alarmes, couverture des tests et installations en retard, disponibilité des boutons, taux de réussite des envois au centre de télésurveillance et export incident par incident. S'y ajoutent les alertes non remises de la dernière alarme dans une installation.

Les jours sont en heure locale de l'installation ; les périodes de plus de 400 jours sont raccourcies (range.capped). Les incidents réels et de test sont comptés séparément. Les durées sont en ms (p50Ms, p95Ms). Les rapports de marque ne couvrent que les installations auxquelles vous avez accès, sauf si vous disposez d'un accès à l'échelle de l'organisation (scope.restrictedToAccessibleFacilities).

Actions :

• overview : vue d'ensemble du rapport Duress. Totaux, tendance mensuelle et indicateurs par organisation, par marque et par installation (incidents, testCoverage, deviceUptime, deliveries). Les installations sont paginées.
• compliance_summary : synthèse de conformité Duress. Le contenu du PDF de conformité : couverture des tests avec les installations en retard, disponibilité des boutons, taux de réussite des envois, tests récents (testHistory) et, pour chaque installation, son dernier test, son dernier exercice et sa dernière véritable alarme, avec la disponibilité de chaque bouton. Les installations sont paginées.
• incident_export : export des incidents Duress. Une ligne par incident, les plus anciens en premier, avec les colonnes de l'export CSV : installation, test ou réel, statut, issue, heures locales, secondes avant prise en charge et résolution, auteurs de la prise en charge et de la résolution, nombre de boutons et d'envois.
• delivery_problems : alertes d'alarme non remises. La dernière alarme ou le dernier test de l'installation (avec toute sa fenêtre de test) et les alertes qui ne sont jamais arrivées, par canal. problems vaut null lorsque tout a été remis. Nécessite Duress ou Duress Configuration dans l'installation.

Résout un incident Duress : clôture l'alarme, arrête l'escalade et enregistre l'issue. Les incidents ouverts et pris en charge peuvent être résolus.

• disposition : genuine (une véritable urgence), false_alarm, test ou unknown.
• note : ce qui s'est passé. Obligatoire pour une véritable alarme.

Confirmez toujours d'abord. Appelez sans confirm pour obtenir l'incident, indiquez à l'utilisateur quelle alarme il clôture et avec quelle issue, puis appelez de nouveau avec confirm: true uniquement après son accord.

Dans un workflow, ou depuis un Agent, cela ne fonctionne que si le plan d'intervention de l'installation autorise les workflows à prendre en charge, résoudre et déclencher des alarmes.

Lit les paramètres Duress : plans d'intervention (qui est alerté, dans quel ordre et comment, dans une installation ou en tant que modèle de marque), le plan résolu réellement utilisé par le moteur d'alarme, les personnes et rôles pouvant être ajoutés, les alertes d'appareil (problèmes de batterie, de déconnexion, de couverture et d'envoi), les règles de contact et le statut des plans de la marque, la vue d'ensemble des boutons d'une marque ou d'une organisation, et l'acheminement des alarmes vers le centre de télésurveillance.

Une installation suit le modèle de sa marque (sinon celui de son organisation), le complète avec des contacts supplémentaires (mode extend) ou le remplace par son propre plan (mode replace). Modifiez les paramètres avec duress_settings_write. Les heures sont au format ISO.

Actions :

• response_plan : plan d'intervention. Le plan en vigueur dans une installation (effective) et le contenu de chaque niveau (sources : facility, brand, organisation), ou, avec seulement brandId, le modèle de la marque. Les contacts sont tels qu'enregistrés, prêts à être modifiés et réenregistrés.
• resolved_plan : plan résolu. Les personnes que le moteur d'alarme contacte dans l'installation, palier par palier : rôles développés en personnes, canaux par lesquels chacune peut être jointe, délais et avertissements à corriger avant une alarme. Noms uniquement, sans numéros de téléphone ni e-mails.
• contact_options : options de contact. Les personnes et rôles pouvant être ajoutés au plan de l'installation (nécessite Duress Configuration dans celle-ci), ou, avec seulement brandId, au modèle de la marque, après application des règles de contact de la marque.
• device_alerts : alertes d'appareil. Qui est prévenu des batteries faibles, des boutons hors ligne, des pertes de couverture et des échecs d'envoi : les règles de chaque niveau et les destinataires résolus de l'installation, ou, avec seulement brandId, les règles de la marque.
• contact_rules : règles de contact de la marque. Les rôles que les installations de la marque peuvent ajouter aux plans : allowAllExcept masque les rôles listés, manual ne propose que ceux-ci. Nécessite les mêmes droits que la modification du plan de la marque. Nécessite brandId.
• plan_status : statut des plans de la marque. Pour chaque installation de la marque : si elle suit le modèle, le complète ou a son propre plan, combien de contacts elle a ajoutés, et les avertissements de son plan. Nécessite brandId.
• buttons_summary : vue d'ensemble des boutons. Chaque installation d'une marque ou d'une organisation : nombre de boutons, de batteries faibles et de boutons hors ligne, prochain et dernier test. Les données des vues d'ensemble Brands & Customisation et de l'organisation.
• monitoring : acheminement vers le centre de télésurveillance. La façon dont les alarmes quittent l'installation : eaAlarmType none, cid (un appel au centre de télésurveillance via eaAlarmProvider) ou relay (une centrale filaire via eaRelayModel), et les fournisseurs utilisables.

Modifie les paramètres Duress : plans d'intervention (dans une installation, ou modèle d'une marque ou d'une organisation), alertes d'appareil, règles de contact de la marque et acheminement des alarmes vers le centre de télésurveillance. Chaque modification demande une confirmation, car elle change les personnes alertées.

Indiquez l'un des éléments suivants : facilityId (par défaut : l'installation connectée), brandId ou organisationId. Les plans d'installation nécessitent Duress Configuration dans celle-ci ; les modèles nécessitent un administrateur de l'organisation disposant de Duress Configuration ou, pour une marque, Duress Configuration dans chacune de ses installations. Lisez d'abord avec duress_settings_read.

Actions :

• save_response_plan : enregistrer un plan d'intervention. Paliers de contacts alertés afterSeconds après la pression (ordre croissant, le premier généralement à 0), ackRequired, reminders et responseActions. Une installation peut à la place compléter son modèle (mode extend) par des ajouts. Les champs omis conservent leur valeur enregistrée ; responseActions est fusionné action par action. Demande une confirmation.
• remove_response_plan : supprimer un plan d'intervention. Supprime le plan enregistré à ce niveau, de sorte qu'une installation suit de nouveau son modèle et qu'une marque revient à celui de l'organisation. Demande une confirmation.
• save_device_alerts : enregistrer les alertes d'appareil. Remplace les règles d'alerte d'appareil à ce niveau : jusqu'à 10 règles, chacune étant un ensemble d'événements et de contacts (push, sms ou email). Conservez les ID de règle lus avec duress_settings_read device_alerts. Nécessite rules. Demande une confirmation.
• remove_device_alerts : supprimer les alertes d'appareil. Supprime les règles d'alerte d'appareil à ce niveau, qui suit alors de nouveau le niveau supérieur. Demande une confirmation.
• save_contact_rules : enregistrer les règles de contact de la marque. Les rôles que les installations de la marque peuvent ajouter aux plans : allowAllExcept masque roleIds, manual ne propose que roleIds. Les contacts déjà enregistrés restent ; les plans résolus sont actualisés. Nécessite brandId, mode, roleIds. Demande une confirmation.
• save_monitoring : enregistrer l'acheminement vers le centre de télésurveillance. La destination des alarmes : eaAlarmType none, cid (nécessite eaAlarmProvider, l'un des fournisseurs listés par duress_settings_read monitoring) ou relay (eaRelayModel). Nécessite Duress Configuration dans l'installation. Nécessite eaAlarmType. Demande une confirmation.

Place l'installation en confinement pour une alarme Duress : aucune porte ne laisse plus entrer personne jusqu'à la levée du confinement (duress_lift_lockdown, ou depuis la console). Une alarme ne déclenche jamais plus d'un confinement.

Jamais pour les alarmes de test ou résolues. Nécessite Door/Gate Access dans l'installation.

Confirmez d'abord. Appelez sans confirm pour vérifier l'incident, indiquez à l'utilisateur que toutes les portes seront verrouillées, puis appelez de nouveau avec confirm: true une fois son accord obtenu.

Lance immédiatement un test Duress dans une installation. Jusqu'à la fin du test, chaque pression est un test et non une véritable alarme :

• walk : le personnel appuie sur chaque bouton ; seule la première étape du plan d'intervention est alertée, avec la mention TEST.
• drill : tout le plan d'intervention s'exécute, avec la mention TEST.

Les contacts de test de l'installation sont informés du début du test et reçoivent les résultats environ 10 minutes après sa fin. Un seul test à la fois par installation. Terminez-le plus tôt avec duress_end_test ; planifiez des tests à l'avance avec duress_tests_write.

Confirmez d'abord. Appelez sans confirm, indiquez à l'utilisateur que les pressions ne déclencheront pas de véritables alarmes pendant durationMinutes, puis appelez de nouveau avec confirm: true une fois son accord obtenu. Dans un workflow, ou depuis un Agent, cela ne fonctionne que si le plan d'intervention de l'installation autorise les workflows à prendre en charge, résoudre et déclencher des alarmes.

Lit les tests des boutons Duress : les planifications qui les programment (walk, comms ou drill, ponctuels ou récurrents, pour une organisation, des marques ou des installations), les fenêtres de test qu'elles créent dans chaque installation (scheduled, active, completed, cancelled, ainsi que les tests ponctuels) et les résultats d'une fenêtre (boutons pressés ou manqués, personnes prévenues, signaux du centre de télésurveillance, délais de prise en charge).

L'auteur de la planification, de la modification ou de l'annulation d'un test n'est pas indiqué ; les destinataires des envois sont masqués. Les heures sont au format ISO ; localDate et localStartTime sont dans le fuseau horaire de l'installation. Planifiez ou modifiez des tests avec duress_tests_write ; lancez-en un immédiatement avec duress_start_test.

Actions :

• schedules : planifications de tests. scope facility (par défaut ; toutes les planifications qui la couvrent, y compris les planifications partagées qu'elle ignore ou remplace), brand (brandId) ou organisation (par défaut : celle de l'installation). Modification la plus récente en premier.
• windows : fenêtres de test. Les fenêtres de test d'une installation de from à to (par défaut d'environ une semaine en arrière à un mois en avant), ou, avec seulement organisationId, les prochaines fenêtres de l'organisation dans toutes ses installations.
• results : résultats des tests. Une fenêtre et ses résultats : enregistrés une fois envoyés, calculés en direct pendant un test (la liste de contrôle du test walk), null pour les fenêtres planifiées ou annulées. Nécessite Duress dans l'installation. Nécessite startsAtKey.

Planifie, modifie et annule les calendriers de tests Duress, définit la façon dont une installation suit un calendrier partagé et annule une seule plage de test à venir. Chaque modification planifie ou réécrit les plages futures et envoie un e-mail aux parties prenantes ; chacune demande donc une confirmation.

Les calendriers requièrent Duress Configuration sur l'ensemble de leur cible (un administrateur de l'organisation pour ceux qui couvrent toute l'organisation). Les heures sont exprimées dans le fuseau horaire de chaque installation. Consultez d'abord les calendriers et les plages avec duress_tests_read ; lancez un test immédiatement avec duress_start_test.

Actions :

• create_schedule : Planifier un calendrier de tests. Planifie des plages jusqu'à environ un an à l'avance dans chaque installation de target et envoie une confirmation de réservation par e-mail. Requiert name, type, target, startDate, localStartTime et recurrence. Requiert name, type, target, startDate, localStartTime, recurrence. Demande une confirmation.
• update_schedule : Modifier un calendrier de tests. Les champs omis conservent leur valeur. Les plages futures sont réécrites (celles déjà commencées sont conservées) et les parties prenantes reçoivent un avis de modification. Utilisez ensuite le ownerScope du résultat. Requiert ownerScope, scheduleId. Demande une confirmation.
• cancel_schedule : Annuler un calendrier de tests. Annule le calendrier et ses plages futures, et envoie l'annulation par e-mail. Les installations qui ont leur propre copie la conservent. Requiert ownerScope, scheduleId. Demande une confirmation.
• set_facility_override : Modifier un calendrier partagé pour une installation. mode follow (appliquer de nouveau le calendrier partagé ici), skip (l'arrêter ici) ou own (le remplacer ici par une copie construite à partir de schedule). Requiert Duress Configuration dans cette installation uniquement. Requiert ownerScope, scheduleId, mode. Demande une confirmation.
• cancel_window : Annuler une plage de test. Annule un test planifié dans une installation (le calendrier continue) et envoie un e-mail à ses parties prenantes. Requiert Duress dans l'installation ; un test en cours se termine plutôt avec duress_end_test. Requiert startsAtKey. Demande une confirmation.

Déverrouille les portes pour une alarme Duress, p. ex. pour laisser entrer la police ou les secouristes : les portes liées au bouton actionné, sinon celles du plan d'intervention. Omettez doorIds pour toutes les déverrouiller, ou indiquez-en certaines. Chaque déverrouillage figure dans la chronologie de l'incident et dans les Journaux d'accès.

Jamais pour les alarmes de test ou résolues. Requiert Door/Gate Access dans l'installation.

Confirmez d'abord. Appelez sans confirm pour voir quelles portes seraient déverrouillées, informez-en l'utilisateur, puis appelez de nouveau avec confirm: true une fois qu'il a donné son accord.