Anticoercizione

Prende in carico un incidente di emergenza aperto per conto dell'utente: registra che sta intervenendo e può fermare l'ulteriore escalation. Si possono prendere in carico solo gli incidenti aperti.

Chiedi sempre prima conferma. Chiama senza confirm per ottenere l'incidente, comunica all'utente cosa sta prendendo in carico e chiama di nuovo con confirm: true solo dopo il suo consenso.

In un workflow, o da un Agente, funziona solo dove il piano di risposta della struttura consente ai workflow di prendere in carico, risolvere e generare allarmi. Per chiudere un incidente usa duress_resolve_incident.

Legge i pulsanti di emergenza di una struttura: il loro stato (batteria, ultimo segnale ricevuto, ultimo test), i profili completi (etichetta, stanza, zona, posizionamento, telecamere, porte e schermi collegati, avvisi silenziati, stato della supervisione), a cosa possono essere collegati, gli schermi che inoltrano le loro pressioni e il test di configurazione di un pulsante appena aggiunto.

Batteria: low significa 30% o meno (da sostituire a breve), critical 20% o meno (da sostituire subito). Batteria e lastSeenAt null significano che nessuno schermo ha ancora ricevuto il segnale del pulsante. Gli orari sono in formato ISO.

Azioni:

• status: stato dei pulsanti. Ogni pulsante con zona, stanza, batteria, quando uno schermo ne ha ricevuto l'ultimo segnale e quando è stato testato l'ultima volta. "I pulsanti di emergenza funzionano?", "Quali hanno bisogno di batterie nuove?"
• list: profili dei pulsanti. Il profilo completo di ogni pulsante: ciò che modifica duress_buttons_write update, più segnale, gli schermi che lo hanno ricevuto nell'ultimo giorno, stato della supervisione e un eventuale test di configurazione in attesa.
• link_options: opzioni di collegamento. Le telecamere, le porte, gli schermi e le zone di accesso della struttura a cui si può collegare un pulsante (ID per duress_buttons_write update).
• receivers: ricevitori dei pulsanti. Gli schermi della struttura che ricevono i segnali dei pulsanti e inoltrano le pressioni, e se ciascuno è online. ready è false quando nessun dispositivo potrebbe ricevere un pulsante.
• setup_test: test di configurazione. Il test di configurazione di un pulsante appena aggiunto: waiting (la sua prima pressione è solo un test), received, expired, ended o none, e se uno schermo lo ha ricevuto da quando è stato aggiunto. Richiede deviceSerialNumber.

Modifica i pulsanti di emergenza di una struttura: aggiunge un nuovo pulsante, ne modifica il profilo (etichetta, stanza, zona, posizionamento, note, telecamere, porte, schermi e zona di accesso collegati, avvisi del dispositivo silenziati), ne fa suonare uno perché il personale possa trovarlo, termina il test di configurazione di un nuovo pulsante per attivarlo e rimuove un pulsante.

I campi omessi in update mantengono i loro valori; null li cancella. Leggi il profilo attuale con duress_buttons_read list.

Azioni:

• update: aggiorna un pulsante. Salva il profilo del pulsante nella struttura in cui è registrato (richiede Duress Configuration in quella struttura). zone va da 001 a 999 ed è unica nella struttura. alertsMutedUntil (ISO, massimo 30 giorni in avanti) silenzia i suoi avvisi di batteria e offline. Richiede deviceSerialNumber.
• locate: fa suonare un pulsante. Fa suonare e lampeggiare il pulsante per 30 secondi perché il personale possa trovarlo, ad esempio uno che continua a segnalare la batteria scarica. Il comando viene inviato da uno schermo vicino, quindi il pulsante deve essere nel raggio di uno schermo. Non mentre ha un allarme aperto. Richiede deviceSerialNumber.
• go_live: attiva un nuovo pulsante. Termina subito il test di configurazione di un pulsante appena aggiunto, così la sua prossima pressione sarà un allarme reale. Controlla prima duress_buttons_read setup_test. Richiede Gestione dei dispositivi o Duress Configuration nella struttura. Richiede deviceSerialNumber. Chiede conferma.
• remove: rimuove un pulsante. Dissocia il pulsante dalla struttura ed elimina il suo profilo, liberandone la zona. Non mentre ha un allarme aperto. Richiede Gestione dei dispositivi nella struttura. Richiede deviceSerialNumber. Chiede conferma.
• add: aggiunge un pulsante. Registra un nuovo pulsante di emergenza nella struttura tramite il numero di serie stampato sul pulsante. Per impostazione predefinita, la sua prima pressione nei 30 minuti successivi è solo un test (setupTest). La struttura ha bisogno di uno schermo con Duress alarm monitoring attivo o di un IoT Gateway. Richiede Gestione dei dispositivi nella struttura. Richiede deviceSerialNumber. Chiede conferma.

Termina subito il test di emergenza in corso in una struttura, così la prossima pressione sarà un allarme reale. I risultati arrivano circa 10 minuti dopo, come per qualsiasi test.

Legge gli incidenti di allarme di emergenza (il personale ha premuto un pulsante di emergenza o un workflow ha generato un allarme): elenchi, timeline e invii di un incidente, un report post-incidente e le riprese TVCC attorno a un allarme.

Stati: open (nessuno lo ha ancora preso in carico), acknowledged (qualcuno sta intervenendo), resolved (chiuso, con un esito: genuine, false_alarm, test o unknown). active significa open o acknowledged. Gli incidenti di test (isTest) provengono dai test dei pulsanti; testType 'unplanned' è un allarme generato come reale che un soccorritore ha risolto come test.

Stato degli invii: sent, acknowledged (il destinatario ha confermato), failed (vedi error), shadow (prova a vuoto, non è stato inviato nulla). Gli invii alla centrale di monitoraggio sono anche totalizzati in monitoringCentre. I risultati indicano i nomi delle persone ma non includono mai numeri di telefono o indirizzi email. Gli orari sono in formato ISO.

Azioni:

• list: elenca gli incidenti. Dal più recente. scope: facility (predefinito; la struttura indicata o quella connessa) o organisation (ogni struttura dell'organizzazione che puoi vedere; predefinito l'organizzazione della struttura).
• get: recupera un incidente. Stato, pulsanti premuti, timeline (pressioni, escalation, prese in carico, note) e ogni tentativo di notifica o di invio alla centrale di monitoraggio con il relativo esito. Richiede incidentId.
• report: report dell'incidente. Per un'analisi post-incidente: l'incidente, i secondi per la presa in carico e la risoluzione, i livelli raggiunti, ogni voce della timeline, cosa è stato inviato per canale e cosa non è riuscito, e se le riprese sono state conservate. Abbinalo a duress_incidents_write add_note per allegare l'analisi all'incidente. Richiede incidentId.
• footage_previews: riprese dell'allarme. Ogni telecamera nelle riprese dell'allarme: stato, numero di fotogrammi e clip, clip caricate e il fotogramma più vicino alla pressione (posterSeconds). Con cameraId, solo quella telecamera più i secondi Unix di ogni fotogramma (frameSeconds). Richiede la TVCC nella struttura. Richiede incidentId.
• footage_frame: fotogramma delle riprese dell'allarme. Un fotogramma timelapse delle riprese dell'allarme, restituito come immagine: una copia conservata se le riprese sono state conservate, altrimenti il fotogramma live all'interno della finestra dell'allarme. seconds è un valore posterSeconds o frameSeconds da footage_previews. Richiede incidentId, cameraId, seconds.

Modifica un incidente di emergenza senza toccare l'allarme stesso: gli assegna un nome, aggiunge note del personale e conserva o rilascia le riprese TVCC che lo riguardano. Non viene avvisato nessuno. Per prendere in carico, risolvere o informare i soccorritori usa duress_acknowledge_incident, duress_resolve_incident o duress_post_update.

Azioni:

• rename: assegna un nome a un incidente. Assegna un nome all'incidente per ritrovarlo facilmente in seguito, ad esempio "Visitatore aggressivo al bancone d'ingresso". Un nome vuoto o null lo rimuove. I nomi compaiono nella console Duress e nei report. Richiede incidentId.
• add_note: aggiunge una nota. Aggiunge una nota alla timeline dell'incidente, ad esempio cosa ha trovato l'utente o chi è intervenuto. Qualsiasi stato; solo il personale vede le note e non modificano l'incidente. Scrivila con le parole dell'utente e confermane prima il testo con lui. Richiede incidentId, note.
• keep_footage: conserva le riprese dell'allarme. Conserva le riprese TVCC attorno a un allarme reale risolto perché non vengano eliminate con le registrazioni normali, usando i minuti e le telecamere del piano di risposta. Avviene qualche minuto dopo, una volta completato il caricamento. Non per test, allarmi aperti o riprese già conservate o rilasciate. Richiede incidentId.
• release_footage: rilascia le riprese conservate. Rinuncia alle riprese conservate per un allarme: le clip tornano alla conservazione normale e i fotogrammi conservati vengono eliminati, quindi non sarà più possibile visualizzarle quando scadranno le registrazioni normali. Richiede Duress Configuration nella struttura. Richiede incidentId. Chiede conferma.

Revoca il blocco totale di un allarme di emergenza: le porte bloccate tornano a consentire l'ingresso. Funziona qualunque sia lo stato dell'allarme.

Chiedi prima conferma. Chiama senza confirm per vedere il blocco, informa l'utente e chiama di nuovo con confirm: true dopo il suo consenso.

Pubblica un aggiornamento per le persone che stanno intervenendo su un allarme di emergenza, ad esempio "La polizia sta arrivando" o "Cessato allarme, la persona se n'è andata". Compare nella loro pagina dell'allarme e nell'app Duress e, per un allarme reale, il piano di risposta può anche inviarlo via SMS a tutti coloro che hanno già ricevuto un SMS sull'allarme. Gli aggiornamenti possono essere pubblicati fino a 24 ore dopo la risoluzione dell'allarme.

Chiedi prima conferma. Chiama senza confirm per controllare l'incidente, mostra all'utente il testo esatto e chiama di nuovo con confirm: true dopo il suo consenso. Per qualcosa che deve vedere solo il personale, usa invece duress_incidents_write add_note.

Genera un allarme di emergenza reale nella struttura, come se fosse stato premuto un pulsante: il piano di risposta viene eseguito (le persone vengono avvisate, seguono escalation e promemoria, vengono eseguite le azioni di risposta) e l'allarme indica che è stato generato da questo workflow, con il motivo.

• reason: cosa è successo, ad esempio "Porta forzata all'uscita posteriore" (fino a 200 caratteri).
• deviceSerialNumber: facoltativo. Un pulsante di cui usare la posizione; solo in questo caso viene informata anche la centrale di monitoraggio, con la zona di quel pulsante.

Solo come passaggio di un workflow, nelle strutture il cui piano di risposta consente ai workflow di prendere in carico, risolvere e generare allarmi. Finché l'allarme di questo workflow è aperto non ne genera un altro; restituisce invece quell'allarme.

Report di conformità Duress per una struttura, un brand o un'organizzazione: tempi di risposta (P50/P95), incidenti per esito e tasso di falsi allarmi, copertura dei test e strutture in ritardo, uptime dei pulsanti, esito degli invii alla centrale di monitoraggio ed esportazione incidente per incidente. In più, gli avvisi non recapitati dell'ultimo allarme in una struttura.

I giorni sono nell'ora locale della struttura; i periodi superiori a 400 giorni vengono accorciati (range.capped). Gli incidenti reali e di test vengono conteggiati separatamente. Le durate sono in ms (p50Ms, p95Ms). I report di brand coprono solo le strutture a cui puoi accedere, a meno che tu non abbia l'accesso a livello di organizzazione (scope.restrictedToAccessibleFacilities).

Azioni:

• overview: panoramica dei report Duress. Totali, andamento mensile e metriche per organizzazione, brand e struttura (incidents, testCoverage, deviceUptime, deliveries). Le strutture sono paginate.
• compliance_summary: riepilogo di conformità Duress. Ciò che mostra il PDF di conformità: copertura dei test con le strutture in ritardo, uptime dei pulsanti, esito degli invii, test recenti (testHistory) e, per ogni struttura, l'ultimo test, l'ultima esercitazione e l'ultimo allarme reale con l'uptime di ogni pulsante. Le strutture sono paginate.
• incident_export: esportazione degli incidenti Duress. Una riga per incidente, dal meno recente, con le colonne dell'esportazione CSV: struttura, test o reale, stato, esito, orari locali, secondi per la presa in carico e la risoluzione, chi ha preso in carico e risolto, pulsanti e numero di invii.
• delivery_problems: avvisi di allarme non recapitati. L'ultimo allarme o test della struttura (con l'intera finestra di test) e gli avvisi mai arrivati, per canale. problems è null quando tutto è stato recapitato. Richiede Duress o Duress Configuration in quella struttura.

Risolve un incidente di emergenza: chiude l'allarme, ferma l'escalation e registra l'esito. Si possono risolvere gli incidenti aperti e presi in carico.

• disposition: genuine (un'emergenza reale), false_alarm, test o unknown.
• note: cosa è successo. Obbligatoria per un allarme reale.

Chiedi sempre prima conferma. Chiama senza confirm per ottenere l'incidente, comunica all'utente quale allarme sta chiudendo e con quale esito, e chiama di nuovo con confirm: true solo dopo il suo consenso.

In un workflow, o da un Agente, funziona solo dove il piano di risposta della struttura consente ai workflow di prendere in carico, risolvere e generare allarmi.

Legge le impostazioni di Duress: i piani di risposta (chi viene avvisato, in quale ordine e come, in una struttura o come modello del brand), il piano risolto effettivamente usato dal motore degli allarmi, le persone e i ruoli che si possono aggiungere, gli avvisi dei dispositivi (problemi di batteria, offline, copertura e recapito), le regole di contatto e lo stato dei piani del brand, la panoramica dei pulsanti di un brand o di un'organizzazione e dove vengono inviati gli allarmi alla centrale di monitoraggio.

Una struttura segue il modello del suo brand (altrimenti quello della sua organizzazione), lo estende con contatti aggiuntivi (mode extend) o lo sostituisce con un proprio piano (mode replace). Modifica le impostazioni con duress_settings_write. Gli orari sono in formato ISO.

Azioni:

• response_plan: piano di risposta. Il piano in vigore in una struttura (effective) e cosa contiene ogni livello (fonti: facility, brand, organisation), oppure, con il solo brandId, il modello del brand. I contatti sono come salvati, pronti da modificare e salvare di nuovo.
• resolved_plan: piano risolto. Chi il motore degli allarmi contatta nella struttura, livello per livello: ruoli espansi in persone, canali su cui ciascuno è raggiungibile, ritardi e avvisi da correggere prima di un allarme. Solo nomi, nessun numero di telefono o indirizzo email.
• contact_options: opzioni di contatto. Le persone e i ruoli che si possono aggiungere al piano della struttura (richiede Duress Configuration in quella struttura) oppure, con il solo brandId, al modello del brand, nel rispetto delle regole di contatto del brand.
• device_alerts: avvisi dei dispositivi. Chi viene informato di batterie scariche, pulsanti offline, perdita di copertura e invii non riusciti: le regole di ogni livello e i destinatari risolti della struttura, oppure, con il solo brandId, le regole del brand.
• contact_rules: regole di contatto del brand. Quali ruoli le strutture del brand possono aggiungere ai piani: allowAllExcept nasconde i ruoli elencati, manual propone solo quelli. Richiede gli stessi permessi necessari per modificare il piano del brand. Richiede brandId.
• plan_status: stato dei piani del brand. Ogni struttura del brand: se segue il modello, lo estende o ha un proprio piano, quanti contatti ha aggiunto e gli avvisi del suo piano. Richiede brandId.
• buttons_summary: panoramica dei pulsanti. Ogni struttura di un brand o di un'organizzazione: numero di pulsanti, di batterie scariche e di pulsanti offline, il prossimo e l'ultimo test. I dati delle panoramiche di Brands & Customisation e dell'organizzazione.
• monitoring: instradamento verso la centrale di monitoraggio. Come gli allarmi escono dalla struttura: eaAlarmType none, cid (una chiamata alla centrale di monitoraggio tramite eaAlarmProvider) o relay (un pannello cablato tramite eaRelayModel), e i provider che può usare.

Modifica le impostazioni di Duress: i piani di risposta (in una struttura, o il modello di un brand o di un'organizzazione), gli avvisi dei dispositivi, le regole di contatto del brand e dove vengono inviati gli allarmi alla centrale di monitoraggio. Ogni modifica chiede conferma perché cambia chi viene avvisato.

Passa uno tra facilityId (predefinito: la struttura connessa), brandId o organisationId. I piani delle strutture richiedono Duress Configuration in quella struttura; i modelli richiedono un amministratore dell'organizzazione con Duress Configuration oppure, per un brand, Duress Configuration in ogni sua struttura. Leggi prima con duress_settings_read.

Azioni:

• save_response_plan: salva un piano di risposta. Livelli di contatti avvisati afterSeconds dopo la pressione (in ordine crescente, il primo di solito 0), ackRequired, reminders e responseActions. Una struttura può invece estendere il suo modello (mode extend) con aggiunte. I campi omessi mantengono i valori salvati; responseActions viene unito per azione. Chiede conferma.
• remove_response_plan: rimuove un piano di risposta. Elimina il piano salvato a questo livello, così una struttura torna a seguire il suo modello e un brand torna a quello dell'organizzazione. Chiede conferma.
• save_device_alerts: salva gli avvisi dei dispositivi. Sostituisce le regole degli avvisi dei dispositivi a questo livello: fino a 10 regole, ciascuna un insieme di eventi e contatti (push, sms o email). Mantieni gli ID delle regole letti da duress_settings_read device_alerts. Richiede rules. Chiede conferma.
• remove_device_alerts: rimuove gli avvisi dei dispositivi. Elimina le regole degli avvisi dei dispositivi a questo livello, che torna così a seguire il livello superiore. Chiede conferma.
• save_contact_rules: salva le regole di contatto del brand. Quali ruoli le strutture del brand possono aggiungere ai piani: allowAllExcept nasconde roleIds, manual propone solo roleIds. I contatti già salvati restano; i piani risolti si aggiornano. Richiede brandId, mode, roleIds. Chiede conferma.
• save_monitoring: salva l'instradamento verso la centrale di monitoraggio. Dove vanno gli allarmi: eaAlarmType none, cid (richiede eaAlarmProvider, uno dei provider elencati da duress_settings_read monitoring) o relay (eaRelayModel). Richiede Duress Configuration nella struttura. Richiede eaAlarmType. Chiede conferma.

Attiva il blocco totale della struttura per un allarme di emergenza: nessuna porta consente più l'ingresso finché il blocco non viene revocato (duress_lift_lockdown, o dalla console). Un allarme può avere un solo blocco totale.

Mai per allarmi di test o già risolti. Richiede Door/Gate Access nella struttura.

Chiedi prima conferma. Chiama senza confirm per controllare l'incidente, comunica all'utente che tutte le porte verranno bloccate e chiama di nuovo con confirm: true dopo il suo consenso.

Avvia subito un test di emergenza in una struttura. Finché non termina, ogni pressione è un test e non un allarme reale:

• walk: il personale preme ogni pulsante; viene avvisato solo il primo livello del piano di risposta, con l'etichetta TEST.
• drill: viene eseguito l'intero piano di risposta, con l'etichetta TEST.

I contatti di test della struttura vengono informati dell'avvio e ricevono i risultati circa 10 minuti dopo la fine. Un solo test alla volta per struttura. Terminalo in anticipo con duress_end_test; pianifica i test in anticipo con duress_tests_write.

Chiedi prima conferma. Chiama senza confirm, comunica all'utente che per durationMinutes le pressioni non genereranno allarmi reali e chiama di nuovo con confirm: true dopo il suo consenso. In un workflow, o da un Agente, funziona solo dove il piano di risposta della struttura consente ai workflow di prendere in carico, risolvere e generare allarmi.

Legge i test dei pulsanti di emergenza: le pianificazioni che li prenotano (walk, comms o drill, una tantum o ricorrenti, per un'organizzazione, brand o strutture), le finestre di test che creano in ogni struttura (programmate, attive, completate, annullate, più i test ad hoc) e i risultati di una finestra (quali pulsanti sono stati premuti o mancati, chi è stato informato, segnali alla centrale di monitoraggio, tempi di presa in carico).

Chi ha prenotato, modificato o annullato un test non viene indicato; i destinatari degli invii sono oscurati. Gli orari sono in formato ISO; localDate e localStartTime sono nel fuso orario della struttura. Prenota o modifica i test con duress_tests_write; avviane uno subito con duress_start_test.

Azioni:

• schedules: pianificazioni dei test. scope facility (predefinito; ogni pianificazione che la riguarda, comprese quelle condivise che salta o sostituisce), brand (brandId) o organisation (predefinito: quella della struttura). Dalla modifica più recente.
• windows: finestre di test. Le finestre di test di una struttura da from a to (predefinito da circa una settimana prima a un mese dopo), oppure, con il solo organisationId, le prossime finestre dell'organizzazione in tutte le sue strutture.
• results: risultati dei test. Una finestra e i suoi risultati: memorizzati una volta inviati, calcolati in tempo reale mentre un test è in corso (la checklist del walk test), null per le finestre programmate o annullate. Richiede Duress nella struttura. Richiede startsAtKey.

Prenota, modifica e annulla le pianificazioni dei test di Duress, imposta come una struttura segue una pianificazione condivisa e annulla una singola finestra di test imminente. Ogni modifica prenota o riscrive le finestre future e invia un'email agli stakeholder, quindi ognuna chiede conferma.

Le pianificazioni richiedono Duress Configuration sull'intero target (un amministratore dell'organizzazione per quelle a livello di organizzazione). Gli orari sono nel fuso orario di ciascuna struttura. Leggi prima pianificazioni e finestre con duress_tests_read; avvia subito un test con duress_start_test.

Azioni:

• create_schedule: Prenota una pianificazione di test. Prenota finestre fino a circa un anno in anticipo in ogni struttura del target e invia un'email di conferma della prenotazione. Richiede name, type, target, startDate, localStartTime e recurrence. Richiede name, type, target, startDate, localStartTime, recurrence. Chiede conferma.
• update_schedule: Modifica una pianificazione di test. I campi omessi mantengono i loro valori. Le finestre future vengono riscritte (quelle già iniziate restano invariate) e gli stakeholder ricevono un avviso di modifica. Usa poi l'ownerScope restituito nel risultato. Richiede ownerScope, scheduleId. Chiede conferma.
• cancel_schedule: Annulla una pianificazione di test. Annulla la pianificazione e le sue finestre future e invia l'annullamento via email. Le strutture con una propria copia la mantengono. Richiede ownerScope, scheduleId. Chiede conferma.
• set_facility_override: Modifica una pianificazione condivisa per una struttura. mode follow (esegui di nuovo qui la pianificazione condivisa), skip (interrompila qui) oppure own (sostituiscila qui con una copia creata da schedule). Richiede Duress Configuration solo presso quella struttura. Richiede ownerScope, scheduleId, mode. Chiede conferma.
• cancel_window: Annulla una finestra di test. Annulla un test pianificato in una struttura (la pianificazione continua) e invia un'email ai suoi stakeholder. Richiede Duress presso la struttura; un test attivo si termina invece con duress_end_test. Richiede startsAtKey. Chiede conferma.

Sblocca le porte per un allarme Duress, ad es. per far entrare la polizia o il primo soccorso: le porte collegate al pulsante premuto, altrimenti le porte del piano di risposta. Ometti doorIds per sbloccarle tutte, oppure elencane alcune. Ogni sblocco compare nella cronologia dell'incidente e nei Registri di accesso.

Mai per allarmi di test o risolti. Richiede Door/Gate Access presso la struttura.

Conferma prima. Chiama senza confirm per vedere quali porte verrebbero sbloccate, informa l'utente e chiama di nuovo con confirm: true quando è d'accordo.