Intégrations d'alarme

Connecte une installation au modèle d'un partenaire de télésurveillance et gère cette connexion : enregistrer (modèle, numéro de compte, correspondance des zones, événements, champs de l'installation), supprimer, demander une approbation, envoyer un signal de test, activer après un test réussi et abandonner une modification en attente.

Une connexion active (active ou en échec) ne change qu'avec applyMode : staged maintient les alarmes sur les paramètres actifs jusqu'à ce qu'un test de la modification en attente réussisse et que vous l'activiez ; immediate applique tout de suite. Les champs secrets sont acceptés mais jamais renvoyés. Requiert External Integrations dans l'installation. Consultez d'abord avec alarm_integrations_read connections.

Actions :

• save : Enregistrer une connexion. templateId est requis pour une nouvelle connexion. fields définit les champs de l'installation par clé (null en efface un ; les secrets sont scellés). Sur une connexion active, passez applyMode, sinon l'appel échoue avec apply-mode-required. Requiert partnerId. Demande une confirmation.
• remove : Supprimer une connexion. Supprime la connexion de l'installation au partenaire, ainsi que toute modification en attente ; les alarmes cessent d'être transmises à ce centre de télésurveillance depuis cette installation. Requiert partnerId. Demande une confirmation.
• request_approval : Demander une approbation. Demande au centre de télésurveillance d'approuver la connexion ou d'attribuer un numéro de compte (modèles avec approbation du partenaire). Requiert partnerId.
• send_test_signal : Envoyer un signal de test. Met en file d'attente un véritable signal de test vers le centre de télésurveillance ; interrogez test_signal_status. staged: true teste la modification en attente au lieu des paramètres actifs. Requiert partnerId. Demande une confirmation.
• activate : Activer une connexion ou une modification. Met en service une connexion en attente, promeut une modification en attente ou confirme une modification non testée. L'activation requiert le requestId d'un test réussi après la dernière modification : un test de la modification en attente (staged: true) promeut une modification en attente, un test des paramètres actifs confirme une modification non testée. Requiert partnerId, requestId. Demande une confirmation.
• discard_pending_change : Abandonner une modification en attente. Supprime la modification en attente ; les paramètres actifs restent inchangés. discarded vaut false lorsque rien n'était en attente. Requiert partnerId. Demande une confirmation.

Ajoute, modifie, supprime et teste des destinations d'alarme personnalisées : votre propre récepteur de télésurveillance, une carte relais, SMS, appel vocal, e-mail, webhooks, messagerie d'équipe ou un service d'astreinte (la liste channel), au niveau d'une installation (par défaut), d'une marque ou de l'organisation.

Les paramètres non secrets vont dans config ; les secrets (mots de passe, URL de webhook, clés) vont dans fields par chemin de paramètre et sont scellés, jamais renvoyés. Les destinations activées requièrent une config complète. Les destinations d'une installation requièrent External Integrations ou Duress Configuration dans celle-ci ; celles d'une marque ou de l'organisation requièrent un accès à toute l'organisation. Consultez d'abord avec alarm_integrations_read destinations.

Actions :

• save : Enregistrer une destination. Sans connectionId, en ajoute une (channel et name requis) ; avec, en modifie une (le channel ne change pas). config, s'il est envoyé, remplace les paramètres non secrets ; les secrets omis de fields sont conservés. Demande une confirmation.
• remove : Supprimer une destination. Supprime la destination ; un relais d'installation cesse aussi de piloter le relais d'alarme. Requiert connectionId. Demande une confirmation.
• send_test_signal : Envoyer un test à une destination. Met en file d'attente un véritable message de test vers la destination ; interrogez alarm_integrations_read test_signal_status avec l'installation. Les destinations d'une marque ou de l'organisation sont testées depuis facilityId. Requiert connectionId. Demande une confirmation.

Indique où vont les alarmes Duress d'une installation en dehors de Performance Hub : ses connexions aux centres de télésurveillance (partenaire, modèle, numéro de compte, correspondance des zones, statut, éléments manquants, modifications en attente), les destinations personnalisées (récepteurs de télésurveillance, relais, SMS, appel vocal, e-mail, webhooks, messagerie, astreinte) de l'installation, de sa marque et de l'organisation, un aperçu du routage, le journal de livraison et les résultats des signaux de test.

Requiert External Integrations ou Duress Configuration dans l'installation. Les secrets et valeurs scellées ne sont jamais affichés, seulement { key, secret, hasValue } ; les numéros et adresses des personnes sont masqués dans le routage et les livraisons. Les heures sont au format ISO. Modifiez-les avec alarm_integrations_connections_write et alarm_integrations_destinations_write.

Actions :

• connections : Connexions aux centres de télésurveillance. Les connexions partenaires de l'installation : modèle, numéro de compte (linkingIdentifier), correspondance des zones, événements, connectionStatus, missing (ce qui empêche la mise en service), pendingChange (en attente, pas encore active) et untestedChange. canEdit : External Integrations ici.
• destinations : Destinations personnalisées. Les destinations qui peuvent se déclencher pour l'installation (les siennes, celles de sa marque et de l'organisation, chacune avec canEdit), ou avec ownerScope celles d'une seule portée. Paramètres dans config ; secrets sous forme de fields { key, secret, hasValue }.
• routing : Aperçu du routage. Où une alarme serait transmise en ce moment (paramètres actifs uniquement), tel que universal-api le résout : destinations avec lane, événements et config sans les secrets, problems expliquant tout élément écarté, et pendingChanges pas encore routées. eventType ne conserve que ce qui reçoit cet événement.
• deliveries : Journal de livraison. Livraisons d'alarmes, des plus récentes aux plus anciennes (statut, canal, récepteur, latence, message d'erreur public). Une page filtrée peut être courte et avoir quand même un nextCursor. Les alertes d'appareils apparaissent avec kind alert.
• test_signal_status : Résultat du signal de test. queued jusqu'à ce que universal-api enregistre une tentative, puis succeeded (un récepteur a accusé réception ou le message a été envoyé) ou failed, avec les lignes de livraison. Utilisez l'installation depuis laquelle le test a été envoyé. Requiert requestId.