Integrações de alarme

Conecta uma instalação ao modelo de um parceiro de monitoramento e gerencia essa conexão: salvar (modelo, número da conta, mapa de zonas, eventos, campos da instalação), remover, solicitar aprovação, enviar um sinal de teste, ativar após um teste bem-sucedido e descartar uma alteração preparada.

Uma conexão ativa (active ou failing) só muda com applyMode: staged mantém os alarmes nas configurações ativas até que um teste preparado seja bem-sucedido e você o ative; immediate aplica agora. Campos secretos são aceitos, mas nunca retornados. Exige External Integrations na instalação. Leia antes com alarm_integrations_read connections.

Ações:

• save: Salvar uma conexão. templateId é necessário para uma nova conexão. fields define campos da instalação por chave (null limpa um; os segredos são protegidos). Em uma conexão ativa, passe applyMode, ou a chamada falha com apply-mode-required. Exige partnerId. Pede confirmação.
• remove: Remover uma conexão. Remove a conexão da instalação com o parceiro, com qualquer alteração preparada; os alarmes deixam de ir para essa central de monitoramento a partir daqui. Exige partnerId. Pede confirmação.
• request_approval: Solicitar aprovação. Pede à central de monitoramento que aprove a conexão ou atribua um número de conta (modelos com aprovação do parceiro). Exige partnerId.
• send_test_signal: Enviar um sinal de teste. Coloca na fila um sinal de teste real para a central de monitoramento; consulte test_signal_status. staged: true testa a alteração preparada em vez das configurações ativas. Exige partnerId. Pede confirmação.
• activate: Ativar uma conexão ou alteração. Torna ativa uma conexão pendente, promove uma alteração preparada ou confirma uma não testada. A ativação exige o requestId de um teste bem-sucedido após a última alteração: um teste preparado (staged: true) promove uma alteração preparada, um teste ativo confirma uma não testada. Exige partnerId, requestId. Pede confirmação.
• discard_pending_change: Descartar uma alteração preparada. Descarta a alteração preparada; as configurações ativas não são alteradas. discarded é false quando nada estava preparado. Exige partnerId. Pede confirmação.

Adiciona, altera, exclui e dispara testes de destinos de alarme personalizados: seu próprio receptor de monitoramento, uma placa de relés, SMS, voz, e-mail, webhooks, chat de equipe ou um serviço de acionamento de plantão (a lista de canais), em uma instalação (padrão), marca ou organização.

As configurações não secretas ficam em config; os segredos (senhas, URLs de webhook, chaves) ficam em fields por caminho de configuração e são protegidos, nunca retornados. Destinos habilitados exigem um config completo. Destinos da instalação exigem External Integrations ou Duress Configuration nela; os de marca e de organização exigem acesso a toda a organização. Leia antes com alarm_integrations_read destinations.

Ações:

• save: Salvar um destino. Sem connectionId, adiciona um (channel e name necessários); com ele, altera um (o canal permanece). config, quando enviado, substitui as configurações não secretas; os segredos omitidos de fields são mantidos. Pede confirmação.
• remove: Excluir um destino. Exclui o destino; um relé da instalação também deixa de acionar o relé de alarme. Exige connectionId. Pede confirmação.
• send_test_signal: Enviar um teste para um destino. Coloca na fila uma mensagem de teste real para o destino; consulte alarm_integrations_read test_signal_status com a instalação. Destinos de marca e de organização são testados a partir de facilityId. Exige connectionId. Pede confirmação.

Lê para onde vão os alarmes de Duress de uma instalação fora do Performance Hub: suas conexões com centrais de monitoramento (parceiro, modelo, número da conta, mapa de zonas, status, pendências para ativação, alterações preparadas), destinos personalizados (receptores de monitoramento, relés, SMS, voz, e-mail, webhooks, chat, acionamento) na instalação, em sua marca e organização, uma prévia do roteamento, o registro de entregas e os resultados dos sinais de teste.

Exige External Integrations ou Duress Configuration na instalação. Segredos e valores protegidos nunca são mostrados, apenas { key, secret, hasValue }; números e endereços das pessoas são ocultados no roteamento e nas entregas. Os horários estão em ISO. Altere-os com alarm_integrations_connections_write e alarm_integrations_destinations_write.

Ações:

• connections: Conexões com centrais de monitoramento. As conexões de parceiros da instalação: modelo, número da conta (linkingIdentifier), mapa de zonas, eventos, connectionStatus, missing (o que impede a ativação), pendingChange (preparada, ainda não ativa) e untestedChange. canEdit: External Integrations aqui.
• destinations: Destinos personalizados. Destinos que podem disparar para a instalação (os próprios, os da marca e os da organização, cada um com canEdit) ou, com ownerScope, os de um escopo. Configurações em config; segredos como fields { key, secret, hasValue }.
• routing: Prévia do roteamento. Para onde um alarme iria agora (somente configurações ativas), conforme resolvido pela universal-api: destinos com faixa, eventos e config sem os segredos, problems explicando o que ficou de fora e pendingChanges ainda não roteadas. eventType mantém apenas o que recebe esse evento.
• deliveries: Registro de entregas. Entregas de alarme, das mais recentes para as mais antigas (status, canal, receptor, latência, texto de erro público). Uma página filtrada pode ser curta e ainda ter nextCursor. Os alertas de dispositivo aparecem como kind alert.
• test_signal_status: Resultado do sinal de teste. queued até a universal-api registrar uma tentativa; depois succeeded (um receptor confirmou ou ele foi enviado) ou failed, com as linhas de entrega. Use a instalação a partir da qual o teste foi enviado. Exige requestId.