Coação

Reconhece um incidente de coação em aberto em nome do usuário: registra que ele está respondendo e pode interromper o escalonamento. Somente incidentes em aberto podem ser reconhecidos.

Sempre confirme antes. Chame sem confirm para obter o incidente, diga ao usuário o que ele está reconhecendo e chame de novo com confirm: true somente depois que ele concordar.

Em um workflow, ou a partir de um Agente, isso só funciona onde o plano de resposta da instalação permite que workflows reconheçam, resolvam e acionem alarmes. Para encerrar um incidente, use duress_resolve_incident.

Lê os botões de coação de uma instalação: o status (bateria, último sinal recebido, último teste), os perfis completos (rótulo, sala, zona, posicionamento, câmeras, portas e telas vinculadas, alertas silenciados, saúde da supervisão), o que pode ser vinculado a eles, as telas que retransmitem os acionamentos e o teste de configuração de um botão recém-adicionado.

Bateria: low é 30% ou menos (substitua em breve), critical é 20% ou menos (substitua agora). Bateria e lastSeenAt nulos significam que nenhuma tela recebeu sinal do botão ainda. Os horários são ISO.

Ações:

• status: Status dos botões. Cada botão com zona, sala, bateria, quando uma tela recebeu o último sinal dele e quando foi testado pela última vez. "Os botões de coação estão funcionando?", "Quais precisam de baterias novas?"
• list: Perfis dos botões. O perfil completo de cada botão: o que duress_buttons_write update altera, além do sinal, das telas que o receberam no último dia, da saúde da supervisão e de um teste de configuração pendente.
• link_options: Opções de vínculo. As câmeras, portas, telas e zonas de acesso da instalação às quais um botão pode ser vinculado (ids para duress_buttons_write update).
• receivers: Receptores dos botões. As telas da instalação que recebem os botões e retransmitem os acionamentos, e se cada uma está on-line. ready é false quando nada conseguiria receber um botão.
• setup_test: Teste de configuração. O teste de configuração de um botão recém-adicionado: waiting (o primeiro acionamento é apenas um teste), received, expired, ended ou none, e se alguma tela recebeu sinal dele desde que foi adicionado. Requer deviceSerialNumber.

Altera os botões de coação de uma instalação: adicionar um botão novo, o perfil deles (rótulo, sala, zona, posicionamento, observações, câmeras, portas, telas e zona de acesso vinculadas, alertas de dispositivo silenciados), fazer um deles apitar para a equipe encontrá-lo, encerrar o teste de configuração de um botão novo para que ele entre em operação e remover um botão.

Os campos omitidos em update mantêm os valores; null os limpa. Leia o perfil atual com duress_buttons_read list.

Ações:

• update: Atualizar um botão. Salva o perfil do botão na instalação em que ele está registrado (requer Duress Configuration nela). zone vai de 001 a 999 e é única na instalação. alertsMutedUntil (ISO, no máximo 30 dias à frente) silencia os alertas de bateria e de off-line. Requer deviceSerialNumber.
• locate: Fazer um botão apitar. Faz o botão apitar e piscar por 30 segundos para a equipe encontrá-lo, por exemplo um que continua informando bateria fraca. Uma tela próxima envia o comando, então ele precisa estar no alcance de uma. Não enquanto ele tiver um alarme em aberto. Requer deviceSerialNumber.
• go_live: Colocar um botão novo em operação. Encerra agora o teste de configuração de um botão recém-adicionado, para que o próximo acionamento seja um alarme real. Verifique antes duress_buttons_read setup_test. Requer Gerenciamento de dispositivos ou Duress Configuration na instalação. Requer deviceSerialNumber. Pede confirmação.
• remove: Remover um botão. Desemparelha o botão da instalação e exclui o perfil dele, o que libera a zona. Não enquanto ele tiver um alarme em aberto. Requer Gerenciamento de dispositivos na instalação. Requer deviceSerialNumber. Pede confirmação.
• add: Adicionar um botão. Registra um botão de coação novo na instalação pelo número de série impresso nele. Por padrão, o primeiro acionamento nos próximos 30 minutos é apenas um teste (setupTest). A instalação precisa de uma tela com Duress alarm monitoring ativado ou de um IoT Gateway. Requer Gerenciamento de dispositivos na instalação. Requer deviceSerialNumber. Pede confirmação.

Encerra agora o teste de coação em andamento em uma instalação, para que o próximo acionamento seja um alarme real. Os resultados chegam cerca de 10 minutos depois, como em qualquer teste.

Lê incidentes de alarme de coação (alguém da equipe acionou um botão de coação ou um workflow acionou um alarme): listas, a linha do tempo e as entregas de um incidente, um relatório pós-incidente e as imagens de CFTV em torno de um alarme.

Status: open (ninguém o reconheceu ainda), acknowledged (alguém está respondendo), resolved (encerrado, com uma disposição: genuine, false_alarm, test ou unknown). active significa open ou acknowledged. Incidentes de teste (isTest) vêm de testes de botões; testType 'unplanned' é um alarme acionado como real que um responsável resolveu como teste.

Status de entrega: sent, acknowledged (o destinatário confirmou), failed (veja error), shadow (simulação, nada foi enviado). As entregas para a central de monitoramento também são totalizadas em monitoringCentre. Os resultados citam pessoas, mas nunca incluem números de telefone ou endereços de e-mail. Os horários são ISO.

Ações:

• list: Listar incidentes. Mais recentes primeiro. scope: facility (padrão; a instalação informada ou conectada) ou organisation (todas as instalações dela que você pode ver; padrão é a organização da instalação).
• get: Obter um incidente. Status, os botões acionados, a linha do tempo (acionamentos, escalonamentos, reconhecimentos, observações) e cada tentativa de notificação ou de entrega à central de monitoramento com o resultado. Requer incidentId.
• report: Relatório do incidente. Para uma análise pós-incidente: o incidente, segundos até o reconhecimento e a resolução, etapas alcançadas, cada entrada da linha do tempo, o que foi enviado por canal e o que falhou, e se as imagens foram mantidas. Use junto com duress_incidents_write add_note para registrar a análise no incidente. Requer incidentId.
• footage_previews: Imagens do alarme. Cada câmera nas imagens do alarme: status, contagens de quadros e clipes, clipes enviados e o quadro mais próximo do acionamento (posterSeconds). Com cameraId, somente essa câmera, mais os segundos Unix de cada quadro (frameSeconds). Requer CFTV na instalação. Requer incidentId.
• footage_frame: Quadro das imagens do alarme. Um quadro de timelapse das imagens do alarme, retornado como imagem: uma cópia mantida depois que as imagens são mantidas; caso contrário, o quadro ao vivo dentro da janela do alarme. seconds é um valor posterSeconds ou frameSeconds de footage_previews. Requer incidentId, cameraId, seconds.

Altera um incidente de coação sem mexer no alarme em si: dá um nome a ele, adiciona observações da equipe e mantém ou libera as imagens de CFTV em torno dele. Ninguém é alertado. Para reconhecer, resolver ou informar os responsáveis, use duress_acknowledge_incident, duress_resolve_incident ou duress_post_update.

Ações:

• rename: Dar nome a um incidente. Dá um nome ao incidente para que seja fácil encontrá-lo depois, por exemplo "Visitante agressivo no balcão da recepção". Um nome vazio ou null o remove. Os nomes aparecem no console de Duress e nos relatórios. Requer incidentId.
• add_note: Adicionar uma observação. Adiciona uma observação à linha do tempo do incidente, por exemplo o que o usuário encontrou ou quem atendeu. Qualquer status; somente a equipe vê as observações e elas não alteram o incidente. Escreva com as palavras do usuário e confirme o texto com ele antes. Requer incidentId, note.
• keep_footage: Manter as imagens do alarme. Mantém as imagens de CFTV em torno de um alarme real resolvido para que não sejam excluídas com as gravações normais, usando os minutos e as câmeras do plano de resposta. Acontece alguns minutos depois, após o envio. Não vale para testes, alarmes em aberto ou imagens já mantidas ou liberadas. Requer incidentId.
• release_footage: Liberar as imagens mantidas. Abre mão das imagens mantidas de um alarme: os clipes voltam à retenção normal e os quadros mantidos são excluídos, então não podem mais ser vistos depois que as gravações normais expirarem. Requer Duress Configuration na instalação. Requer incidentId. Pede confirmação.

Suspende o bloqueio de um alarme de coação: as portas que ele trancou voltam a deixar as pessoas entrarem. Funciona qualquer que seja o status do alarme.

Confirme antes. Chame sem confirm para ver o bloqueio, informe o usuário e chame de novo com confirm: true quando ele concordar.

Publica uma atualização para as pessoas que estão respondendo a um alarme de coação, por exemplo "A polícia está a caminho" ou "Tudo resolvido, a pessoa foi embora". Ela aparece na página do alarme delas e no app Duress e, em um alarme real, o plano de resposta também pode enviá-la por SMS a todos que já receberam SMS sobre o alarme. É possível publicar atualizações até 24 horas depois que o alarme é resolvido.

Confirme antes. Chame sem confirm para verificar o incidente, mostre ao usuário o texto exato e chame de novo com confirm: true quando ele concordar. Para algo que só a equipe deve ver, use duress_incidents_write add_note.

Aciona um alarme de coação real na instalação, como se um botão fosse pressionado: o plano de resposta é executado (as pessoas são alertadas, seguem-se escalonamento e lembretes, as ações de resposta são executadas) e o alarme informa que foi acionado por este workflow, com o motivo.

• reason: o que aconteceu, por exemplo "Porta forçada na saída dos fundos" (até 200 caracteres).
• deviceSerialNumber: opcional. Um botão cuja localização deve ser usada; somente nesse caso a central de monitoramento também é avisada, com a zona desse botão.

Somente como etapa de um workflow, em instalações cujo plano de resposta permite que workflows reconheçam, resolvam e acionem alarmes. Enquanto o alarme deste workflow estiver em aberto, ele não aciona outro; em vez disso, retorna esse alarme.

Relatórios de conformidade de Duress para uma instalação, marca ou organização: tempos de resposta (P50/P95), incidentes por disposição e taxa de alarmes falsos, cobertura de testes e instalações com teste atrasado, disponibilidade dos botões, sucesso das entregas à central de monitoramento e uma exportação incidente por incidente. Além disso, os alertas não entregues do último alarme em uma instalação.

Os dias seguem o horário local da instalação; períodos acima de 400 dias são encurtados (range.capped). Incidentes reais e de teste são contados separadamente. As durações estão em ms (p50Ms, p95Ms). Os relatórios de marca só abrangem as instalações que você pode acessar, a menos que você tenha acesso a toda a organização (scope.restrictedToAccessibleFacilities).

Ações:

• overview: Visão geral do relatório de Duress. Totais, tendência mensal e métricas por organização, por marca e por instalação (incidents, testCoverage, deviceUptime, deliveries). As instalações são paginadas.
• compliance_summary: Resumo de conformidade de Duress. O que o PDF de conformidade mostra: cobertura de testes com as instalações atrasadas, disponibilidade dos botões, sucesso das entregas, testes recentes (testHistory) e, por instalação, o último teste, simulado e alarme real, com a disponibilidade de cada botão. As instalações são paginadas.
• incident_export: Exportação de incidentes de Duress. Uma linha por incidente, do mais antigo para o mais recente, com as colunas da exportação CSV: instalação, teste ou real, status, disposição, horários locais, segundos até o reconhecimento e a resolução, quem reconheceu e resolveu, botões e contagens de entregas.
• delivery_problems: Alertas de alarme não entregues. O último alarme ou teste da instalação (com toda a janela do teste) e os alertas que nunca chegaram, por canal. problems é null quando tudo foi entregue. Requer Duress ou Duress Configuration nela.

Resolve um incidente de coação: encerra o alarme, interrompe o escalonamento e registra o resultado. Incidentes em aberto e reconhecidos podem ser resolvidos.

• disposition: genuine (uma emergência real), false_alarm, test ou unknown.
• note: o que aconteceu. Obrigatório para um alarme genuíno.

Sempre confirme antes. Chame sem confirm para obter o incidente, diga ao usuário qual alarme ele está encerrando e o resultado, e chame de novo com confirm: true somente depois que ele concordar.

Em um workflow, ou a partir de um Agente, isso só funciona onde o plano de resposta da instalação permite que workflows reconheçam, resolvam e acionem alarmes.

Lê as configurações de Duress: planos de resposta (quem é alertado, em que ordem e como, em uma instalação ou como modelo da marca), o plano resolvido que o mecanismo de alarmes realmente usa, as pessoas e funções que podem ser adicionadas, alertas de dispositivo (bateria, off-line, cobertura e problemas de entrega), regras de contato e status dos planos da marca, uma visão geral dos botões de uma marca ou organização e para onde os alarmes vão na central de monitoramento.

Uma instalação segue o modelo da marca (ou, na falta dele, o da organização), o amplia com contatos extras (mode extend) ou o substitui por um plano próprio (mode replace). Altere as configurações com duress_settings_write. Os horários são ISO.

Ações:

• response_plan: Plano de resposta. O plano em vigor em uma instalação (effective) e o que cada nível contém (sources: facility, brand, organisation) ou, somente com brandId, o modelo da marca. Os contatos aparecem como foram salvos, prontos para editar e salvar de volta.
• resolved_plan: Plano resolvido. Quem o mecanismo de alarmes contata na instalação, nível por nível: funções expandidas em pessoas, os canais pelos quais cada uma pode ser contatada, atrasos e avisos a corrigir antes de um alarme. Somente nomes, sem números de telefone ou e-mails.
• contact_options: Opções de contato. Pessoas e funções que podem ser adicionadas ao plano da instalação (requer Duress Configuration nela) ou, somente com brandId, ao modelo da marca, após as regras de contato da marca.
• device_alerts: Alertas de dispositivo. Quem é avisado sobre baterias fracas, botões off-line, perda de cobertura e entregas com falha: as regras de cada nível e os destinatários resolvidos da instalação ou, somente com brandId, as regras da marca.
• contact_rules: Regras de contato da marca. Quais funções as instalações da marca podem adicionar aos planos: allowAllExcept oculta as funções listadas, manual oferece somente elas. Requer o mesmo que a edição do plano da marca. Requer brandId.
• plan_status: Status dos planos da marca. Cada instalação da marca: se segue o modelo, o amplia ou tem plano próprio, quantos contatos adicionou e os avisos do plano. Requer brandId.
• buttons_summary: Visão geral dos botões. Todas as instalações de uma marca ou organização: botões, contagens de bateria e off-line, o próximo e o último teste. Os dados das visões gerais de Brands & Customisation e da organização.
• monitoring: Encaminhamento para a central de monitoramento. Como os alarmes saem da instalação: eaAlarmType none, cid (uma chamada à central de monitoramento por meio de eaAlarmProvider) ou relay (um painel com fio por meio de eaRelayModel), e os provedores que ela pode usar.

Altera as configurações de Duress: planos de resposta (em uma instalação ou no modelo de uma marca ou organização), alertas de dispositivo, regras de contato da marca e para onde os alarmes vão na central de monitoramento. Toda alteração pede confirmação porque muda quem é alertado.

Informe um de facilityId (padrão: a instalação conectada), brandId ou organisationId. Planos de instalação requerem Duress Configuration nela; modelos requerem um administrador da organização com Duress Configuration ou, para uma marca, Duress Configuration em todas as instalações dela. Leia antes com duress_settings_read.

Ações:

• save_response_plan: Salvar um plano de resposta. Níveis de contatos alertados afterSeconds após o acionamento (em ordem crescente, o primeiro geralmente 0), ackRequired, reminders e responseActions. Uma instalação pode, em vez disso, ampliar o modelo (mode extend) com additions. Os campos omitidos mantêm os valores salvos; responseActions são mescladas por ação. Pede confirmação.
• remove_response_plan: Remover um plano de resposta. Exclui o plano salvo neste nível, para que uma instalação volte a seguir o modelo e uma marca volte ao da organização. Pede confirmação.
• save_device_alerts: Salvar alertas de dispositivo. Substitui as regras de alertas de dispositivo neste nível: até 10 regras, cada uma com um conjunto de eventos e contatos (push, sms ou email). Mantenha os ids das regras lidos de duress_settings_read device_alerts. Requer rules. Pede confirmação.
• remove_device_alerts: Remover alertas de dispositivo. Exclui as regras de alertas de dispositivo neste nível, para que ele volte a seguir o nível acima. Pede confirmação.
• save_contact_rules: Salvar as regras de contato da marca. Quais funções as instalações da marca podem adicionar aos planos: allowAllExcept oculta roleIds, manual oferece somente roleIds. Os contatos já salvos permanecem; os planos resolvidos são atualizados. Requer brandId, mode, roleIds. Pede confirmação.
• save_monitoring: Salvar o encaminhamento para a central de monitoramento. Para onde os alarmes vão: eaAlarmType none, cid (requer eaAlarmProvider, um dos provedores listados por duress_settings_read monitoring) ou relay (eaRelayModel). Requer Duress Configuration na instalação. Requer eaAlarmType. Pede confirmação.

Bloqueia a instalação por causa de um alarme de coação: todas as portas deixam de permitir a entrada de pessoas até o bloqueio ser suspenso (duress_lift_lockdown ou pelo console). Um alarme só recebe um bloqueio.

Nunca para alarmes de teste ou resolvidos. Requer Door/Gate Access na instalação.

Confirme antes. Chame sem confirm para verificar o incidente, avise o usuário de que todas as portas serão trancadas e chame de novo com confirm: true quando ele concordar.

Inicia agora um teste de coação em uma instalação. Até ele terminar, todo acionamento é um teste, não um alarme real:

• walk: a equipe aciona cada botão; somente a primeira etapa do plano de resposta é alertada, com o rótulo TEST.
• drill: o plano de resposta inteiro é executado, com o rótulo TEST.

Os contatos de teste da instalação são avisados de que ele começou e recebem os resultados cerca de 10 minutos depois que ele termina. Um teste por vez por instalação. Encerre antes com duress_end_test; agende testes com duress_tests_write.

Confirme antes. Chame sem confirm, avise o usuário de que os acionamentos não vão gerar alarmes reais durante durationMinutes e chame de novo com confirm: true quando ele concordar. Em um workflow, ou a partir de um Agente, isso só funciona onde o plano de resposta da instalação permite que workflows reconheçam, resolvam e acionem alarmes.

Lê os testes de botões de coação: as programações que os agendam (walk, comms ou drill, uma vez ou recorrentes, para uma organização, marcas ou instalações), as janelas de teste que elas criam em cada instalação (scheduled, active, completed, cancelled, além de testes avulsos) e os resultados de uma janela (quais botões foram acionados ou não, quem foi avisado, sinais da central de monitoramento, tempos de reconhecimento).

Quem agendou, alterou ou cancelou um teste fica de fora; os destinatários das entregas são ocultados. Os horários são ISO; localDate e localStartTime estão no fuso horário da instalação. Agende ou altere testes com duress_tests_write; inicie um agora com duress_start_test.

Ações:

• schedules: Programações de testes. scope facility (padrão; todas as programações que a abrangem, incluindo as compartilhadas que ela ignora ou substitui), brand (brandId) ou organisation (padrão: a da instalação). Alteração mais recente primeiro.
• windows: Janelas de teste. As janelas de teste de uma instalação de from até to (padrão de cerca de uma semana atrás até um mês à frente) ou, somente com organisationId, as próximas janelas da organização em todas as instalações dela.
• results: Resultados do teste. Uma janela e seus resultados: armazenados depois de enviados, calculados ao vivo enquanto um teste está em andamento (a checklist do teste de percurso), null para janelas agendadas ou canceladas. Requer Duress na instalação. Requer startsAtKey.

Agenda, altera e cancela cronogramas de teste de Duress, define como uma instalação segue um cronograma compartilhado e cancela uma única janela de teste futura. Cada alteração agenda ou reescreve janelas futuras e envia e-mail às partes interessadas, por isso cada uma pede confirmação.

Os cronogramas exigem Duress Configuration em todo o seu alvo (um administrador da organização para os que abrangem toda a organização). Os horários estão no fuso horário de cada instalação. Leia antes os cronogramas e as janelas com duress_tests_read; inicie um teste agora com duress_start_test.

Ações:

• create_schedule: Agendar um cronograma de teste. Agenda janelas com até cerca de um ano de antecedência em cada instalação do target e envia uma confirmação de agendamento por e-mail. Exige name, type, target, startDate, localStartTime e recurrence. Exige name, type, target, startDate, localStartTime, recurrence. Pede confirmação.
• update_schedule: Alterar um cronograma de teste. Os campos omitidos mantêm seus valores. As janelas futuras são reescritas (as já iniciadas são mantidas) e as partes interessadas recebem um aviso de alteração. Use depois o ownerScope do resultado. Exige ownerScope, scheduleId. Pede confirmação.
• cancel_schedule: Cancelar um cronograma de teste. Cancela o cronograma e suas janelas futuras e envia o cancelamento por e-mail. As instalações com cópia própria a mantêm. Exige ownerScope, scheduleId. Pede confirmação.
• set_facility_override: Alterar um cronograma compartilhado para uma instalação. mode follow (volta a executar o cronograma compartilhado aqui), skip (interrompe-o aqui) ou own (substitui-o aqui por uma cópia criada a partir de schedule). Exige Duress Configuration apenas nessa instalação. Exige ownerScope, scheduleId, mode. Pede confirmação.
• cancel_window: Cancelar uma janela de teste. Cancela um teste agendado em uma instalação (o cronograma continua) e envia e-mail às partes interessadas. Exige Duress na instalação; um teste ativo é encerrado com duress_end_test. Exige startsAtKey. Pede confirmação.

Destrava as portas para um alarme de Duress, por exemplo para permitir a entrada da polícia ou dos primeiros socorros: as portas vinculadas ao botão pressionado ou, se não houver, as portas do plano de resposta. Omita doorIds para todas elas ou liste algumas delas. Cada destravamento aparece na linha do tempo do incidente e em Registros de acesso.

Nunca para alarmes de teste ou resolvidos. Exige Door/Gate Access na instalação.

Confirme primeiro. Chame sem confirm para ver quais portas seriam destravadas, informe o usuário e chame novamente com confirm: true quando ele concordar.