Coacción

Confirma un incidente de coacción abierto en nombre del usuario: registra que está respondiendo y puede detener el escalamiento. Solo se pueden confirmar los incidentes abiertos.

Confirma siempre primero. Llama sin confirm para obtener el incidente, dile al usuario qué está confirmando y vuelve a llamar con confirm: true solo después de que acepte.

En un flujo de trabajo, o desde un agente, solo funciona donde el plan de respuesta de la instalación permite que los flujos de trabajo confirmen, resuelvan y activen alarmas. Para cerrar un incidente, usa duress_resolve_incident.

Lee los botones de coacción de una instalación: su estado (batería, última señal recibida, última prueba), sus perfiles completos (etiqueta, sala, zona, ubicación, cámaras, puertas y pantallas vinculadas, alertas silenciadas, estado de la supervisión), a qué se pueden vincular, las pantallas que retransmiten sus pulsaciones y la prueba de configuración de un botón recién agregado.

Batería: low es 30% o menos (reemplázala pronto), critical es 20% o menos (reemplázala ahora). Si battery y lastSeenAt son null, ninguna pantalla ha recibido todavía la señal del botón. Las horas están en formato ISO.

Acciones:

• status: Estado de los botones. Cada botón con su zona, sala, batería, cuándo una pantalla recibió su señal por última vez y cuándo se probó por última vez. "¿Funcionan los botones de coacción?", "¿Cuáles necesitan baterías nuevas?"
• list: Perfiles de los botones. El perfil completo de cada botón: lo que cambia duress_buttons_write update, además de la señal, las pantallas que lo recibieron en el último día, el estado de la supervisión y una prueba de configuración pendiente.
• link_options: Opciones de vinculación. Las cámaras, puertas, pantallas y zonas de acceso de la instalación a las que se puede vincular un botón (ID para duress_buttons_write update).
• receivers: Receptores de los botones. Las pantallas de la instalación que reciben la señal de los botones y retransmiten las pulsaciones, y si cada una está en línea. ready es false cuando nada podría recibir la señal de un botón.
• setup_test: Prueba de configuración. La prueba de configuración de un botón recién agregado: waiting (su primera pulsación es solo una prueba), received, expired, ended o none, y si alguna pantalla ha recibido su señal desde que se agregó. Requiere deviceSerialNumber.

Cambia los botones de coacción de una instalación: agrega un botón nuevo, cambia su perfil (etiqueta, sala, zona, ubicación, notas, cámaras, puertas, pantallas y zona de acceso vinculadas, alertas del dispositivo silenciadas), hace que uno emita un pitido para que el personal lo encuentre, termina la prueba de configuración de un botón nuevo para que entre en funcionamiento y quita un botón.

Los campos que se omiten en update conservan sus valores; null los borra. Consulta el perfil actual con duress_buttons_read list.

Acciones:

• update: Actualizar un botón. Guarda el perfil del botón en la instalación donde está registrado (requiere Duress Configuration en ella). zone va de 001 a 999 y es único en la instalación. alertsMutedUntil (ISO, máximo 30 días de anticipación) silencia sus alertas de batería y de desconexión. Requiere deviceSerialNumber.
• locate: Hacer que un botón emita un pitido. Hace que el botón emita un pitido y parpadee durante 30 segundos para que el personal lo encuentre, p. ej., uno que sigue informando batería baja. Una pantalla cercana envía el comando, así que debe estar dentro del alcance de una. No funciona mientras tenga una alarma abierta. Requiere deviceSerialNumber.
• go_live: Poner en funcionamiento un botón nuevo. Termina ahora la prueba de configuración de un botón recién agregado, para que su próxima pulsación sea una alarma real. Comprueba primero duress_buttons_read setup_test. Requiere Gestión de dispositivos o Duress Configuration en la instalación. Requiere deviceSerialNumber. Pide confirmación.
• remove: Quitar un botón. Desvincula el botón de la instalación y elimina su perfil, lo que libera su zona. No funciona mientras tenga una alarma abierta. Requiere Gestión de dispositivos en la instalación. Requiere deviceSerialNumber. Pide confirmación.
• add: Agregar un botón. Registra un botón de coacción nuevo en la instalación con el número de serie impreso en él. De forma predeterminada, su primera pulsación en los próximos 30 minutos es solo una prueba (setupTest). La instalación necesita una pantalla con Duress alarm monitoring activado o un IoT Gateway. Requiere Gestión de dispositivos en la instalación. Requiere deviceSerialNumber. Pide confirmación.

Termina ahora la prueba de coacción en curso en una instalación, para que la próxima pulsación sea una alarma real. Los resultados llegan unos 10 minutos después, como en cualquier prueba.

Lee los incidentes de alarma de coacción (el personal pulsó un botón de coacción o un flujo de trabajo activó una alarma): listas, la línea de tiempo y los envíos de un incidente, un informe posterior al incidente y las grabaciones de CCTV en torno a una alarma.

Estados: open (nadie lo ha confirmado todavía), acknowledged (alguien está respondiendo), resolved (cerrado, con un resultado: genuine, false_alarm, test o unknown). active significa abierto o confirmado. Los incidentes de prueba (isTest) provienen de pruebas de botones; testType 'unplanned' es una alarma activada como real que un respondedor resolvió como prueba.

Estado del envío: sent, acknowledged (el receptor lo confirmó), failed (consulta error), shadow (simulación, no se envió nada). Los envíos a la central de monitoreo también se totalizan en monitoringCentre. Los resultados nombran a las personas, pero nunca incluyen números de teléfono ni direcciones de correo electrónico. Las horas están en formato ISO.

Acciones:

• list: Listar los incidentes. Los más recientes primero. scope: facility (predeterminado; la instalación indicada o la conectada) u organisation (todas las instalaciones de la organización que puedes ver; de forma predeterminada, la organización de la instalación).
• get: Obtener un incidente. El estado, los botones pulsados, la línea de tiempo (pulsaciones, escalamientos, confirmaciones, notas) y cada intento de envío de notificaciones o a la central de monitoreo con su resultado. Requiere incidentId.
• report: Informe del incidente. Para un análisis posterior: el incidente, los segundos hasta la confirmación y la resolución, los pasos alcanzados, cada entrada de la línea de tiempo, lo que se envió por canal y lo que falló, y si se conservaron las grabaciones. Combínalo con duress_incidents_write add_note para agregar el análisis posterior al incidente. Requiere incidentId.
• footage_previews: Grabaciones de la alarma. Cada cámara de las grabaciones de la alarma: su estado, el número de fotogramas y clips, los clips subidos y el fotograma más cercano a la pulsación (posterSeconds). Con cameraId, solo esa cámara, además de los segundos Unix de cada fotograma (frameSeconds). Requiere CCTV en la instalación. Requiere incidentId.
• footage_frame: Fotograma de las grabaciones de la alarma. Un fotograma de timelapse de las grabaciones de la alarma, devuelto como imagen: una copia conservada cuando las grabaciones se conservaron o, si no, el fotograma en vivo dentro del período de la alarma. seconds es un valor de posterSeconds o frameSeconds de footage_previews. Requiere incidentId, cameraId, seconds.

Cambia un incidente de coacción sin modificar la alarma en sí: le pone nombre, agrega notas del personal y conserva o libera las grabaciones de CCTV en torno a él. No se alerta a nadie. Para confirmar, resolver o informar a los respondedores, usa duress_acknowledge_incident, duress_resolve_incident o duress_post_update.

Acciones:

• rename: Ponerle nombre a un incidente. Le pone nombre al incidente para que sea fácil de encontrar más tarde, p. ej., "Visitante agresivo en el mostrador de entrada". Un nombre vacío o null lo quita. Los nombres se muestran en la consola de Duress y en los informes. Requiere incidentId.
• add_note: Agregar una nota. Agrega una nota a la línea de tiempo del incidente, p. ej., lo que encontró el usuario o quién acudió. Con cualquier estado; solo el personal ve las notas y no cambian el incidente. Escríbela con las palabras del usuario y confirma primero la redacción con él. Requiere incidentId, note.
• keep_footage: Conservar las grabaciones de la alarma. Conserva las grabaciones de CCTV en torno a una alarma real resuelta para que no se eliminen con las grabaciones normales, según los minutos y las cámaras del plan de respuesta. Ocurre unos minutos después, una vez subidas. No se aplica a pruebas, alarmas abiertas ni grabaciones ya conservadas o liberadas. Requiere incidentId.
• release_footage: Liberar las grabaciones conservadas. Renuncia a las grabaciones conservadas de una alarma: los clips vuelven a la retención normal y los fotogramas conservados se eliminan, así que ya no se podrán ver cuando caduquen las grabaciones normales. Requiere Duress Configuration en la instalación. Requiere incidentId. Pide confirmación.

Levanta el bloqueo de una alarma de coacción: las puertas que bloqueó vuelven a dejar entrar a las personas. Funciona sea cual sea el estado de la alarma.

Confirma primero. Llama sin confirm para ver el bloqueo, informa al usuario y vuelve a llamar con confirm: true cuando acepte.

Publica una actualización para las personas que responden a una alarma de coacción, p. ej., "La policía está en camino" o "Todo despejado, la persona se fue". Aparece en su página de la alarma y en la app de Duress y, en una alarma real, el plan de respuesta también puede enviarla por SMS a todas las personas que ya recibieron un SMS sobre la alarma. Se pueden publicar actualizaciones hasta 24 horas después de que se resuelva la alarma.

Confirma primero. Llama sin confirm para comprobar el incidente, muéstrale al usuario la redacción exacta y vuelve a llamar con confirm: true cuando acepte. Para algo que solo debe ver el personal, usa duress_incidents_write add_note en su lugar.

Activa una alarma de coacción real en la instalación, como si se hubiera pulsado un botón: se ejecuta el plan de respuesta (se alerta a las personas, siguen el escalamiento y los recordatorios, se ejecutan las acciones de respuesta) y la alarma indica que la activó este flujo de trabajo, con el motivo.

• reason: qué ocurrió, p. ej., "Puerta forzada en la salida trasera" (hasta 200 caracteres).
• deviceSerialNumber: opcional. Un botón cuya ubicación se usará; solo entonces se avisa también a la central de monitoreo, con la zona de ese botón.

Solo como paso de un flujo de trabajo, en instalaciones cuyo plan de respuesta permite que los flujos de trabajo confirmen, resuelvan y activen alarmas. Mientras la alarma de este flujo de trabajo esté abierta, no activará otra; en su lugar, devuelve esa alarma.

Informes de cumplimiento de Duress para una instalación, marca u organización: tiempos de respuesta (P50/P95), incidentes por resultado y tasa de falsas alarmas, cobertura de pruebas e instalaciones con pruebas vencidas, tiempo de actividad de los botones, éxito de los envíos a la central de monitoreo y una exportación incidente por incidente. Además, las alertas no entregadas de la última alarma en una instalación.

Los días son locales de la instalación; los períodos de más de 400 días se acortan (range.capped). Los incidentes reales y de prueba se cuentan por separado. Las duraciones están en ms (p50Ms, p95Ms). Los informes de marca solo abarcan las instalaciones a las que tienes acceso, a menos que tengas acceso a toda la organización (scope.restrictedToAccessibleFacilities).

Acciones:

• overview: Resumen del informe de Duress. Totales, tendencia mensual y métricas por organización, por marca y por instalación (incidents, testCoverage, deviceUptime, deliveries). Las instalaciones están paginadas.
• compliance_summary: Resumen de cumplimiento de Duress. Lo que muestra el PDF de cumplimiento: la cobertura de pruebas con las instalaciones con pruebas vencidas, el tiempo de actividad de los botones, el éxito de los envíos, las pruebas recientes (testHistory) y, por instalación, su última prueba, su último simulacro y su última alarma real, con el tiempo de actividad de cada botón. Las instalaciones están paginadas.
• incident_export: Exportación de incidentes de Duress. Una fila por incidente, los más antiguos primero, con las columnas de la exportación CSV: instalación, prueba o real, estado, resultado, horas locales, segundos hasta la confirmación y la resolución, quién confirmó y resolvió, botones y número de envíos.
• delivery_problems: Alertas de alarma no entregadas. La última alarma o prueba de la instalación (con todo su período de prueba) y las alertas que nunca llegaron, por canal. problems es null cuando todo llegó. Requiere Duress o Duress Configuration en esa instalación.

Resuelve un incidente de coacción: cierra la alarma, detiene el escalamiento y registra el resultado. Se pueden resolver los incidentes abiertos y confirmados.

• disposition: genuine (una emergencia real), false_alarm, test o unknown.
• note: qué ocurrió. Obligatorio para una alarma real.

Confirma siempre primero. Llama sin confirm para obtener el incidente, dile al usuario qué alarma está cerrando y con qué resultado, y vuelve a llamar con confirm: true solo después de que acepte.

En un flujo de trabajo, o desde un agente, solo funciona donde el plan de respuesta de la instalación permite que los flujos de trabajo confirmen, resuelvan y activen alarmas.

Lee la configuración de Duress: los planes de respuesta (a quién se alerta, en qué orden y cómo, en una instalación o como plantilla de marca), el plan resuelto que usa realmente el motor de alarmas, las personas y los roles que se pueden agregar, las alertas de dispositivos (problemas de batería, desconexión, cobertura y envío), las reglas de contacto y el estado de los planes de una marca, un resumen de los botones de una marca u organización, y adónde se envían las alarmas en la central de monitoreo.

Una instalación sigue la plantilla de su marca (o, si no, la de su organización), la amplía con contactos adicionales (mode extend) o la reemplaza con su propio plan (mode replace). Cambia la configuración con duress_settings_write. Las horas están en formato ISO.

Acciones:

• response_plan: Plan de respuesta. El plan vigente en una instalación (effective) y lo que contiene cada nivel (sources: facility, brand, organisation) o, solo con brandId, la plantilla de la marca. Los contactos se muestran tal como se guardaron, listos para editarlos y volver a guardarlos.
• resolved_plan: Plan resuelto. A quién contacta el motor de alarmas en la instalación, nivel por nivel: los roles desglosados en personas, los canales por los que se puede contactar a cada una, los retrasos y las advertencias que se deben corregir antes de una alarma. Solo nombres, sin números de teléfono ni correos electrónicos.
• contact_options: Opciones de contacto. Las personas y los roles que se pueden agregar al plan de la instalación (requiere Duress Configuration en ella) o, solo con brandId, a la plantilla de la marca, según las reglas de contacto de la marca.
• device_alerts: Alertas de dispositivos. A quién se avisa de baterías bajas, botones desconectados, pérdida de cobertura y envíos fallidos: las reglas de cada nivel y los destinatarios resueltos de la instalación o, solo con brandId, las reglas de la marca.
• contact_rules: Reglas de contacto de la marca. Qué roles pueden agregar a los planes las instalaciones de la marca: allowAllExcept oculta los roles indicados y manual ofrece solo esos. Requiere lo mismo que editar el plan de la marca. Requiere brandId.
• plan_status: Estado de los planes de la marca. Cada instalación de la marca: si sigue la plantilla, la amplía o tiene su propio plan, cuántos contactos agregó y las advertencias de su plan. Requiere brandId.
• buttons_summary: Resumen de los botones. Todas las instalaciones de una marca u organización: botones, número de baterías bajas y de botones desconectados, y la próxima y la última prueba. Los datos de los resúmenes de Brands & Customisation y de la organización.
• monitoring: Enrutamiento a la central de monitoreo. Cómo salen las alarmas de la instalación: eaAlarmType none, cid (una llamada a la central de monitoreo a través de eaAlarmProvider) o relay (un panel cableado a través de eaRelayModel), y los proveedores que puede usar.

Cambia la configuración de Duress: los planes de respuesta (en una instalación o la plantilla de una marca u organización), las alertas de dispositivos, las reglas de contacto de la marca y adónde se envían las alarmas en la central de monitoreo. Cada cambio pide confirmación porque cambia a quién se alerta.

Pasa uno de facilityId (predeterminado: la instalación conectada), brandId u organisationId. Los planes de instalación requieren Duress Configuration en ella; las plantillas requieren un administrador de la organización con Duress Configuration o, para una marca, Duress Configuration en todas sus instalaciones. Consulta primero con duress_settings_read.

Acciones:

• save_response_plan: Guardar un plan de respuesta. Niveles de contactos alertados afterSeconds después de la pulsación (en orden ascendente, el primero suele ser 0), ackRequired, reminders y responseActions. En su lugar, una instalación puede ampliar su plantilla (mode extend) con adiciones. Los campos omitidos conservan sus valores guardados; responseActions se combina por acción. Pide confirmación.
• remove_response_plan: Quitar un plan de respuesta. Elimina el plan guardado en este nivel, de modo que una instalación vuelve a seguir su plantilla y una marca vuelve a la de la organización. Pide confirmación.
• save_device_alerts: Guardar las alertas de dispositivos. Reemplaza las reglas de alertas de dispositivos de este nivel: hasta 10 reglas, cada una con un conjunto de eventos y contactos (push, sms o email). Conserva los ID de regla leídos de duress_settings_read device_alerts. Requiere rules. Pide confirmación.
• remove_device_alerts: Quitar las alertas de dispositivos. Elimina las reglas de alertas de dispositivos de este nivel, de modo que vuelve a seguir el nivel superior. Pide confirmación.
• save_contact_rules: Guardar las reglas de contacto de la marca. Qué roles pueden agregar a los planes las instalaciones de la marca: allowAllExcept oculta roleIds y manual ofrece solo roleIds. Los contactos ya guardados se mantienen; los planes resueltos se actualizan. Requiere brandId, mode, roleIds. Pide confirmación.
• save_monitoring: Guardar el enrutamiento a la central de monitoreo. Adónde van las alarmas: eaAlarmType none, cid (requiere eaAlarmProvider, uno de los proveedores que lista duress_settings_read monitoring) o relay (eaRelayModel). Requiere Duress Configuration en la instalación. Requiere eaAlarmType. Pide confirmación.

Bloquea la instalación por una alarma de coacción: ninguna puerta deja entrar a nadie hasta que se levante el bloqueo (duress_lift_lockdown o desde la consola). Una alarma solo tiene un bloqueo.

Nunca para alarmas de prueba o resueltas. Requiere Door/Gate Access en la instalación.

Confirma primero. Llama sin confirm para comprobar el incidente, dile al usuario que se bloquearán todas las puertas y vuelve a llamar con confirm: true cuando acepte.

Inicia ahora una prueba de coacción en una instalación. Hasta que termine, cada pulsación es una prueba, no una alarma real:

• walk: el personal pulsa cada botón; solo se alerta al primer paso del plan de respuesta, con la etiqueta TEST.
• drill: se ejecuta todo el plan de respuesta, con la etiqueta TEST.

Se avisa a los contactos de prueba de la instalación de que la prueba comenzó y reciben los resultados unos 10 minutos después de que termine. Una prueba a la vez por instalación. Termínala antes con duress_end_test; programa pruebas con anticipación con duress_tests_write.

Confirma primero. Llama sin confirm, dile al usuario que las pulsaciones no activarán alarmas reales durante durationMinutes y vuelve a llamar con confirm: true cuando acepte. En un flujo de trabajo, o desde un agente, solo funciona donde el plan de respuesta de la instalación permite que los flujos de trabajo confirmen, resuelvan y activen alarmas.

Lee las pruebas de los botones de coacción: las programaciones que las reservan (walk, comms o drill, una vez o repetidas, para una organización, marcas o instalaciones), los períodos de prueba que crean en cada instalación (programados, activos, completados, cancelados, además de las pruebas puntuales) y los resultados de un período (qué botones se pulsaron o faltaron, a quién se avisó, las señales a la central de monitoreo y los tiempos de confirmación).

Se omite quién reservó, cambió o canceló una prueba; los receptores de los envíos se ocultan. Las horas están en formato ISO; localDate y localStartTime están en la zona horaria de la instalación. Reserva o cambia pruebas con duress_tests_write; inicia una ahora con duress_start_test.

Acciones:

• schedules: Programaciones de pruebas. scope facility (predeterminado; todas las programaciones que la abarcan, incluidas las compartidas que omite o reemplaza), brand (brandId) u organisation (predeterminado: la de la instalación). El cambio más reciente primero.
• windows: Períodos de prueba. Los períodos de prueba de una instalación de from a to (predeterminado: desde aproximadamente una semana atrás hasta un mes adelante) o, solo con organisationId, los próximos períodos de la organización en todas sus instalaciones.
• results: Resultados de las pruebas. Un período y sus resultados: se almacenan una vez enviados, se calculan en tiempo real mientras se ejecuta una prueba (la lista de verificación de la prueba de recorrido) y son null para los períodos programados o cancelados. Requiere Duress en la instalación. Requiere startsAtKey.

Programa, cambia y cancela calendarios de pruebas de Duress, define cómo una instalación sigue un calendario compartido y cancela una única ventana de prueba próxima. Cada cambio programa o reescribe ventanas futuras y envía un correo electrónico a las partes interesadas, por lo que cada acción pide confirmación.

Los calendarios requieren Duress Configuration en todo su destino (un administrador de la organización para los de toda la organización). Las horas están en la zona horaria de cada instalación. Lee primero los calendarios y las ventanas con duress_tests_read; inicia una prueba ahora con duress_start_test.

Acciones:

• create_schedule: Programar un calendario de pruebas. Programa ventanas hasta aproximadamente un año por adelantado en cada instalación del destino y envía por correo electrónico una confirmación de la programación. Requiere name, type, target, startDate, localStartTime y recurrence. Requiere name, type, target, startDate, localStartTime, recurrence. Pide confirmación.
• update_schedule: Cambiar un calendario de pruebas. Los campos que omitas conservan sus valores. Las ventanas futuras se reescriben (las ya iniciadas se mantienen) y las partes interesadas reciben un aviso del cambio. Usa después el ownerScope del resultado. Requiere ownerScope, scheduleId. Pide confirmación.
• cancel_schedule: Cancelar un calendario de pruebas. Cancela el calendario y sus ventanas futuras, y envía la cancelación por correo electrónico. Las instalaciones con su propia copia la conservan. Requiere ownerScope, scheduleId. Pide confirmación.
• set_facility_override: Cambiar un calendario compartido para una instalación. mode follow (vuelve a ejecutar aquí el calendario compartido), skip (lo detiene aquí) u own (lo reemplaza aquí con una copia creada a partir de schedule). Solo requiere Duress Configuration en esa instalación. Requiere ownerScope, scheduleId, mode. Pide confirmación.
• cancel_window: Cancelar una ventana de prueba. Cancela una prueba programada en una instalación (el calendario continúa) y lo notifica por correo electrónico a sus partes interesadas. Requiere Duress en la instalación; una prueba activa se termina con duress_end_test. Requiere startsAtKey. Pide confirmación.

Desbloquea las puertas para una alarma de Duress, p. ej., para dejar entrar a la policía o a primeros auxilios: las puertas vinculadas al botón presionado o, si no hay, las puertas del plan de respuesta. Omite doorIds para todas ellas o indica algunas. Cada desbloqueo queda en la línea de tiempo del incidente y en Registros de acceso.

Nunca para alarmas de prueba o resueltas. Requiere Door/Gate Access en la instalación.

Confirma primero. Llama sin confirm para ver qué puertas se desbloquearían, informa al usuario y vuelve a llamar con confirm: true una vez que esté de acuerdo.