Integraciones de alarmas

Conecta una instalación a la plantilla de un socio de monitoreo y administra esa conexión: guardar (plantilla, número de cuenta, mapa de zonas, eventos, campos de la instalación), quitar, solicitar aprobación, enviar una señal de prueba, activar después de una prueba exitosa y descartar un cambio preparado.

Una conexión en vivo (activa o con fallas) solo cambia con applyMode: staged mantiene las alarmas con la configuración en vivo hasta que una prueba del cambio preparado tenga éxito y lo actives; immediate lo aplica ahora. Los campos secretos se aceptan, pero nunca se devuelven. Requiere External Integrations en la instalación. Lee primero con alarm_integrations_read connections.

Acciones:

• save: Guardar una conexión. Se necesita templateId para una conexión nueva. fields define los campos de la instalación por clave (null borra uno; los secretos se sellan). En una conexión en vivo, pasa applyMode o la llamada falla con apply-mode-required. Requiere partnerId. Pide confirmación.
• remove: Quitar una conexión. Quita la conexión de la instalación con el socio, junto con cualquier cambio preparado; las alarmas dejan de enviarse desde aquí a ese centro de monitoreo. Requiere partnerId. Pide confirmación.
• request_approval: Solicitar aprobación. Pide al centro de monitoreo que apruebe la conexión o asigne un número de cuenta (plantillas con aprobación del socio). Requiere partnerId.
• send_test_signal: Enviar una señal de prueba. Pone en cola una señal de prueba real al centro de monitoreo; consulta test_signal_status. staged: true prueba el cambio preparado en lugar de la configuración en vivo. Requiere partnerId. Pide confirmación.
• activate: Activar una conexión o un cambio. Pone en vivo una conexión pendiente, promueve un cambio preparado o confirma uno no probado. Para activar se necesita el requestId de una prueba que haya tenido éxito después del último cambio: una prueba preparada (staged: true) promueve un cambio preparado y una prueba en vivo confirma uno no probado. Requiere partnerId, requestId. Pide confirmación.
• discard_pending_change: Descartar un cambio preparado. Elimina el cambio preparado; la configuración en vivo no se modifica. discarded es false cuando no había nada preparado. Requiere partnerId. Pide confirmación.

Agrega, cambia, elimina y prueba destinos de alarma personalizados: tu propio receptor de monitoreo, una placa de relés, SMS, voz, correo electrónico, webhooks, chat de equipo o un servicio de localización de guardia (la lista de canales), en una instalación (predeterminado), marca u organización.

La configuración no secreta va en config; los secretos (contraseñas, URL de webhooks, claves) van en fields por ruta de configuración y se sellan, nunca se devuelven. Los destinos habilitados necesitan una config completa. Los destinos de una instalación requieren External Integrations o Duress Configuration allí; los de marca y organización requieren acceso a toda la organización. Lee primero con alarm_integrations_read destinations.

Acciones:

• save: Guardar un destino. Sin connectionId agrega uno (se necesitan channel y name); con él cambia uno (el canal se mantiene). config, cuando se envía, reemplaza la configuración no secreta; los secretos omitidos en fields se conservan. Pide confirmación.
• remove: Eliminar un destino. Elimina el destino; un relé de instalación también deja de accionar el relé de alarma. Requiere connectionId. Pide confirmación.
• send_test_signal: Enviar una prueba a un destino. Pone en cola un mensaje de prueba real al destino; consulta alarm_integrations_read test_signal_status con la instalación. Los destinos de marca y organización se prueban desde facilityId. Requiere connectionId. Pide confirmación.

Lee adónde van las alarmas de Duress de una instalación fuera de Performance Hub: sus conexiones con centros de monitoreo (socio, plantilla, número de cuenta, mapa de zonas, estado, requisitos pendientes, cambios preparados), destinos personalizados (receptores de monitoreo, relés, SMS, voz, correo electrónico, webhooks, chat, localización) en la instalación, su marca y su organización, una vista previa del enrutamiento, el registro de entregas y los resultados de las señales de prueba.

Requiere External Integrations o Duress Configuration en la instalación. Los secretos y los valores sellados nunca se muestran, solo { key, secret, hasValue }; los números y las direcciones de las personas se ocultan en el enrutamiento y las entregas. Las horas están en formato ISO. Cámbialos con alarm_integrations_connections_write y alarm_integrations_destinations_write.

Acciones:

• connections: Conexiones con centros de monitoreo. Las conexiones de la instalación con socios: plantilla, número de cuenta (linkingIdentifier), mapa de zonas, eventos, connectionStatus, missing (lo que impide ponerla en vivo), pendingChange (preparado, aún no en vivo) y untestedChange. canEdit: External Integrations aquí.
• destinations: Destinos personalizados. Los destinos que pueden activarse para la instalación (los propios, los de su marca y los de su organización, cada uno con canEdit) o, con ownerScope, los de un ámbito. La configuración va en config; los secretos, como fields { key, secret, hasValue }.
• routing: Vista previa del enrutamiento. Adónde iría una alarma en este momento (solo configuración en vivo), tal como lo resuelve universal-api: destinos con lane, events y config sin secretos, problems que explican lo que se omitió y pendingChanges aún no enrutados. eventType conserva solo lo que recibe ese evento.
• deliveries: Registro de entregas. Entregas de alarmas de la más reciente a la más antigua (estado, canal, receptor, latencia, texto de error público). Una página filtrada puede ser corta y aun así tener nextCursor. Las alertas de dispositivos aparecen como kind alert.
• test_signal_status: Resultado de la señal de prueba. queued hasta que universal-api registra un intento; luego succeeded (un receptor la confirmó o se envió) o failed, con las filas de entrega. Usa la instalación desde la que se envió la prueba. Requiere requestId.