community italiana di domotica personale
 
Realizzare un proprio sistema d’allarme antifurto domotico con Home Assistant

Realizzare un proprio sistema d’allarme antifurto domotico con Home Assistant

10 minuti di lettura
Scopi del PROGETTO:
  • Realizzare un sistema antifurto personale tramite la domotica di Home Assistant 
  • Livello di difficoltà: medio
  • Costo: nullo (al netto dei sensori/attuatori necessari)
Concetti affrontati:
  • Configurazione software
Componenti software utilizzate:
Prerequisiti:
Dispositivi fisici utilizzati:
GUIDA maggiormente indicatA per:

Tutti gli ambienti

Note e disclaimer
  • qualsiasi eventuale modifica agli impianti domestici dev'essere progettata ed realizzata SOLO da personale qualificato;
  • qualsiasi modifica attuata in proprio è a propria responsabilità personale nonché a proprio rischio e pericolo (i contenuti della presenta pagina hanno puro scopo didattico);
  • qualsiasi modifica attuata in proprio a un dispositivo ne fa decadere garanzia, omologazioni e certificazioni di qualità.
Revisione progetto: 1.1

Abstract

Non è certo una novità il fatto che, per proteggere la propria casa, tra le varie cose sia necessario anche un sistema antifurto/anti-effrazione, ovvero un sistema che consenta da una parte di dissuadere eventuali malintenzionati (leggasi ladri), da una parte rilevare eventuali tentativi di effrazioni o effettive intrusioni ai proprietari.

A tal scopo esistono moltissimi impianti e diverse tecnologie. Per lo più si tratta di soluzioni proprietarie, che vincolano al proprio ecosistema; pochi poi sono quegli impianti dotati di declinazione e integrabilità domotica, vale a dire in grado di comunicare con l’utente e di prevedere logiche di funzionamento anche complesse.

Gli utenti che si siano dotati dell’HUB domotico personale Home Assistant sanno come centralizzare il tutto sotto “unico tetto” sia una benedizione in termini di versatilità e sicurezza. Va da se che sia importante integrare sotto di esso anche il proprio sistema di sicurezza: le modalità sono diverse, come abbiamo descritto qui.

Ma cosa fare se non si possiede un sistema d’allarme (e non se ne voglia acquistare uno)?

Fermo restando che le scelte professionali possono essere molte altre, Home Assistant consente, anche in modo piuttosto semplice, di dar vita a un proprio sistema d’allarme. In sostanza, la “centralina” dell’allarme (contenente tutte le logiche di funzionamento) viene impersonata Home Assistant esso stesso, a differenza degli esempi di cui sopra, nei quali si va a integrare all’HUB una pre-esistente centralina esterna.

In pratica in questa modalità il cervello dell’allarme è Home Assistant, il quale ovviamente utilizzerà sensori e attuatori a loro volta integrati come sistema nervoso e muscolare per rilevare e dissuadere.


Scopo di questo progetto è quindi quello di creare un proprio sistema antifurto domotico basato su Home Assistant a partire da sensori e attuatori integrati su di esso. Questo consentirà di definire un’entità di tipo “Alarm Control Panel” la quale potrà essere:

  • armata in modalità assenza / presenza
  • disarmata
  • innescata per allarme

Ovviamente tutto questo, come vedremo, anche in modo del tutto automatizzato.

Si parte

Assunti

Si assume, ovviamente, di possedere già Home Assistant operativo e funzionante. Inoltre, si assume anche che sia raggiungibile da remoto (altrimenti il controllo manuale del proprio sistema d’allarme non sarà possibile).

Sensori

Ogni sistema antifurto/anti-effrazione, va da sé, dispone di una rete nervosa più o meno ampia in grado di “percepire” il mondo fisico. Tali sensori solitamente vengono utilizzati per rilevare la presenza di individui laddove non debbano essercene, oppure rilevare degli stati specifici, come per esempio l’apertura di varchi o la rottura di finestre, e molto altro.

LUMI Aqara Sensore rilevazione presenza PIR

Home Assistant può integrare sensori in centinaia di modi diversi, quindi è impensabile illustrare tutte le possibile modalità.

Quel che possiamo fare noi di inDomus è spiegare al lettore che, indipendentemente dalla tecnologia e alla modalità di integrazione scelte, lo scopo finale (per rendere possibile l’attuazione il presente progetto) è quello di ottenere tante entità di tipo “Sensor” o “Binary Sensors” quanti siano i sensori di sicurezza implementati nel proprio ambiente domestico domotizzato.

Per il presente progetto ipotizzeremo di esser dotati di almeno:

Essendo tutti basati su tecnologia ZigBee, immagineremo di averli integrati in una delle tante modalità possibili ottenendo quindi le seguenti entità:

  • binary_sensor.presence_1  e  binary_sensor.presence_2;
  • binary_sensor.vibration;
  • binary_sensor.opening_1  e  binary_sensor.binary_2.

Altri sensori potrebbero essere:


Immaginiamo infine di avere anche, per esempio, una telecamera integrata all’HUB tramite NVR motionEye la quale fornisca – tramite motionEye, appunto – il riconoscimento del movimento tramite analisi dell’immagine:

  • binary_sensor.ipcamera
N.b. Va da sé che la sicurezza di un impianto antifurto così realizzato è tanto più robusto e sicuro tanto più robuste e sicure saranno le tecnologie dei sensori e delle componenti complessivamente utilizzate nella sua realizzazione.

Attuatori

Va bene rilevare gli stati fisici, ma cosa fare quando e se l’allarme dovesse “scattare” rilevando un tentativo o un’effrazione vera e propria? Ovviamente anche in questo caso il limite è la fantasia: è infatti possibile innescare una o più sirene, attivare un generatore di fumo per ridurre la visibilità, accendere tutte le luci di casa lampeggianti…

Quel che conta è, come sempre, che gli attuatori che innescano gli scenari citati (e molti altri) siano, come sempre, integrati a Home Assistant. Anche qui le modalità sono le più disparate.

sirena

Per quanto riguarda il più classico dei casi, ovviamente ciò che serve è una sirena. Ovviamente acquistarne una direttamente integrabile, quindi già domotica di per sé, è la scelta più facile: esempi validi, rimanendo sul diffusissimo standard ZigBee di cui sopra, sono:

Ma ne esistono altre, come la Z-Wave Aeotec Siren 6 da interni, e altre.

Una soluzione banale e semplice è applicare un semplicissimo attuatore relè a singolo canale 220v (per esempio Sonoff Basic) a una semplicissima sirena a motore.

Ora, quale che sia il sistema di dissuasione che si scelga, ipotizziamo di avere integrato sul nostro HUB le seguenti entità:

  • switch.siren (la sirena, quale che sia)
  • light.externals (il raggruppamento di tutte le luci esterne integrate all’HUB).

Configureremo il tutto in modo da innescare queste due entità laddove l’allarme rilevi un tentativo o una vera propria effrazione. Ovviamente è solo un esempio: il limite sta nella fantasia e nella disponibilità di servizi e dispositivi integrati nella propria domotica.


Ipotizziamo altresì di aver a disposizione un servizio di notifica d’esempio (notify.mobile_app_marco) scaturito dall’integrazione dell’app mobile Home Assistant Companion alla quale inviare eventuali notifiche

Home Assistant

Chiarito ciò che ci serve per realizzare un sistema d’allarme, proponiamo un po’ di configurazioni per far capire l’utente quale sia l’approccio e come poi personalizzare il tutto da sé in base alle proprie esigenze e disponibilità tecnologiche.

Centralina (pannello) allarme

La prima cosa da fare (fondamentale) è definire l’entità allarme dotandola di una sua propria configurazione di funzionamento. Per farlo, si aggiunge un blocco “alarm_control_panel:” al propri file di configurazione configuration.yaml.

Un esempio:

alarm_control_panel:
  - platform: manual
    name: Home
    code: "1234"
    arming_time: 30
    delay_time: 20
    trigger_time: 180
    disarmed:
      trigger_time: 0
    armed_home:
      arming_time: 0
      delay_time: 0 

Tale configurazione – dopo l’inserimento e il riavvio di Home Assistant – genererà un’entità chiamata alarm_control_panel.home, la quale sarà dotata di una serie di caratteristiche.

Spieghiamo alcuni campi sopra configurati (i dettagli e le spiegazioni complete delle configurazioni possibili sono disponibili qui):

code Rappresenta il codice per armare e disarmare l’allarme. Si usa tipicamente inserendolo presso l’interfaccia Lovelace UI di Home Assistant, manualmente.
arming_time Il tempo che trascorre tra l’armo dell’allarme e l’effettività di tale stato. In pratica, è il tempo che si ha a disposizione per abbandonare l’ambiente, dopo l’attivazione, prima che l’allarme entri effettivamente in armo.
delay_time Il tempo di innesco dell’allarme, in caso di rilevazione (quando armato). Se impostato a 0, all’atto della rilevazione l’allarme scatta immediatamente.
trigger_time La durata, in secondi, dell’allarme in caso di innesco.

La macchina a stati dell’integrazione è complessa ma potente. Le transizioni di stato sono temporizzate secondo tre valori, delay_time, arming_time e trigger_time. I valori a loro volta possono provenire dalla variabile di configurazione predefinita o da un override specifico dello stato.

Quando l’allarme è inserito, il suo stato prima va all’inserimento per un numero di secondi pari all’arming_time dello stato di destinazione, quindi passa ad uno degli stati “armato”. Quando l’allarme viene innescato, il suo stato passa in attesa per un numero di secondi pari al delay_time dello stato precedente. Quindi l’allarme passa allo stato “triggered“.

L’allarme rimane nello stato “triggered” per un numero di secondi pari al trigger_time dello stato precedente. Quindi, a seconda di disarm_after_trigger, torna allo stato precedente o disarmato. Se il trigger_time dello stato precedente è 0, il passaggio a “triggered” è bloccato e l’allarme rimane nello stato inserito.

Home Assistant - Manual Alarm
la rappresentazione presso Lovelace UI.

Ciò che comunque è fondamentale capire è che tre sono gli stati che l’entità allarme può assumere:

  • armed_away
  • armed_home
  • triggered
  • disarmed
Arm_away vs Arm_home

Si tratta di due modalità di armo molto diverse e molto pratiche. La prima, arm_away, si utilizza solitamente quando nessuno è in casa: qualsiasi rilevazione da parte del parco sensori innesca l’allarme (che passa quindi a “triggered“); arm_home, invece, si attiva quando si è a casa, magari di notte, dormendo: l’allarme è armato, ma solo determinati sensori vengono presi in considerazione: magari non quelli di rilevazione presenza, consentendoci di muoverci liberamente per casa, ma piuttosto quelli di apertura varchi, laddove qualche malintenzionato forzasse un varco mentre dormiamo.

Automazioni

Capito il funzionamento dell’allarme, non c’è che da scrivere le automazioni che ne definiscano il comportamento operativo.

Rilevazione

Prima automazione da definirsi è quella che innesca (triggera) l’allarme in caso di rilevazione da parte di uno dei sensori.
Ecco una configurazione d’esempio per l’innesco in caso di armo “armed_away“:

automation:
- alias: "Rilievo allarme assenza"
  id: "rilievo_allarme_assenza"
  trigger:
    - platform: state
      entity_id: binary_sensor.presence_1, binary_sensor.presence_2
      to: "on"
    - platform: state
      entity_id: binary_sensor.vibration
      to: "on"
    - platform: state
      entity_id: binary_sensor.opening_1, binary_sensor.opening_2
      to: "on"
    - platform: state
      entity_id: sensor.ipcam
      to: "on"
  condition:
    - condition: state
      entity_id: alarm_control_panel.home
      state: armed_away
  action:
    service: alarm_control_panel.alarm_trigger
    target:
      entity_id: alarm_control_panel.home

Questa automazione altro non fa, ogni volta che uno dei sensori si innesca, verificare se l’allarme è in stato armed_away: qualora lo sia, evoca il servizio alarm_control_panel.alarm_trigger associato all’entità dell’allarme alarm_control_panel.home.

Analogamente, l’automazione per lo stato “away_home”:

automation:
- alias: "Rilevo allarme presenza"
  id: "rilievo_allarme_presenza"
  trigger:
    - platform: state
      entity_id: binary_sensor.opening_1, binary_sensor.opening_2
      to: "on"
  condition:
    - condition: state
      entity_id: alarm_control_panel.home
      state: armed_home
  action:
    service: alarm_control_panel.alarm_trigger
    target:
      entity_id: alarm_control_panel.home

In questo caso vengono presi in considerazione solo i sensori di apertura varchi (binary_sensor.opening_1 e binary_sensor.opening_2).

Innesco

Quando viene evocato il servizio alarm_control_panel.alarm_trigger, l’allarme passa in stato “triggered“. E qui viene il bello: va definita un’automazione che rilevi questo cambio di stato e provveda, quindi, a scatenare une effetto reale, come per esempio l’attivazione della sirena, l’accensione delle luci, l’invio di una notifica:

automation:
  - alias: 'Innesco'
    id: "innesco"
    trigger:
      - platform: state
        entity_id: alarm_control_panel.home_alarm
        to: "triggered"
    action:
      - service: switch.turn_on
        entity_id: switch.siren
      - service: light.turn_on
        entity_id: light.externals
      - service: notify.mobile_app_marco
        data:
          data:
            push:
              badge: 1
          title: Domotica
          message: "ATTENZIONE: allarme innescato!"

Così facendo, per la durata indicata nel campo trigger_time precedentemente innescato, la sirena e le luci rimarranno attive (oltre a inviare singola notifica al proprio smartphone).

Armo e disarmo assenza

Ovviamente grande comodità di avere un allarme integrato su Home Assistant è quello di poterlo armare/disarmare a fronte dell’abbandono/rientro a casa. Ipotizziamo infatti di aver raggruppato tutti i “Device Tracker” degli inquilini sotto il gruppo group.awesome_people: sarebbe facile realizzare un’automazione come la seguente.

automation:
- alias: "Abbandono di casa"
  trigger:
    platform: state
    entity_id: group.awesome_people
    from: 'home'
  condition: []
  action:
    - service: alarm_control_panel.alarm_arm_away
      entity_id: alarm_control_panel.home
    - service: notify.mobile_app_marco
      data:
        data:
          push:
            badge: 1
        title: Domotica
        message: "Allarme ARMATO. Arrivederci a casa."

- alias: "Ritorno a casa"
  trigger:
    platform: state
    entity_id: group.awesome_people
    to: 'home'
  condition: state
    entity_id: alarm_control_panel.home
    state: 'armed_away'
  action:
    - service: alarm_control_panel.alarm_disarm
      entity_id: alarm_control_panel.home
    - service: notify.mobile_app_marco
      data:
        data:
          push:
            badge: 1
        title: Domotica
        message: "Allarme DISARMATO. Bentornato."

P.S. È necessario fare molta attenzione con questo tipo di automazioni! Sono solo a scopo didattico: è chiaro che sì, se un ladro vi rubasse il cellulare e si avvicinasse a casa col telefono in tasca, ovviamente l’allarme si disattiverebbe da solo 🙂

Armo/disarmo notturno

Analogamente, non è difficile realizzare automazioni per l’armo (e disarmo) notturno “armed_home“:

automation:
- alias: "Armo notturno"
  id: "armo_notturno"
  trigger:
    - platform: time
      at: '1:30:00'
  condition: []
  action:
    - service: alarm_control_panel.alarm_arm_home
      entity_id: alarm_control_panel.home
    - service: notify.mobile_app_marco
      data:
        data:
          push:
            badge: 1
        title: Domotica
        message: "Allarme notturno ARMATO. Buonanotte."

- alias: "Disarmo notturno"
  id: "disarmo_notturno"
  trigger:
    - platform: time
      at: '6:30:00'
  condition: state
    entity_id: alarm_control_panel.home
    state: 'armed_home'
  action:
    - service: alarm_control_panel.alarm_disarm
      entity_id: alarm_control_panel.home
    - service: notify.mobile_app_marco
      data:
        data:
          push:
            badge: 1
        title: Domotica
        message: "Allarme notturno DISARMATO. Buongiorno."

In questo caso, l’allarme si armerà in modalità armed_home solo dalle 1:30 della notte alle 6:30 del mattino.

Zone

Sebbene il “Manual Alarm” di Home Assistant non preveda le “zone” (la suddivisione in aree della propria abitazione, come garage, primo piano, secondo piano eccetera), nulla vieta di creare più entità allarme (eg. alarm_control_panel.zone_1, alarm_control_panel.zone_2 ecc.) relative alle varie zone nelle quali si vuole suddividere l’abitazione. Va da sé che le automazioni di gestione andranno configurate coerentemente (ogni sensore associato alle zone corrette), ma per il resto la gestione rimane la stessa.

Considerazioni finali

In termini di efficacia – per quanto sappiamo che ci sarebbe ci avrebbe da ridire – un sistema così concepito non ha molto da invidiare a sistemi ben più evoluti. 

Considerazioni varie:

  • utilizzare sensori il più possibile a batteria, che non possano quindi essere disattivati levando corrente all’appartamento (meglio ZigBee o ancora meglio Z-Wave);
  • sostenere l’host che ospita Home Assistant e il router (nonché altre eventuali componenti cruciali) con un gruppo di continuità (UPS), per garantire la comunicazione remota in caso di assenza (voluta da terzi o meno) di tensione;
  • se si desidera controllare il sistema così configurato tramite Apple HomeKit, utilizzare l’apposito componente di Home Assistant che consente di esporre le sue entità verso quell’ecosistema.

Ovviamente poi la robustezza del tutto è data anche dalla qualità dei sensori, dalla complessità della configurazione e dalla sua affidabilità (vedi, appunto, la presenza di un gruppo di continuità o meno). Facendo un buon lavoro di progettazione, è possibile dotarsi di un ottimo sistema.

Il limite, come sempre, è la fantasia.


Home Assistant Official Logo ATTENZIONE: ricorda che sul nostro community FORUM c'è una sezione ad hoc dedica a Home Assistant, per qualsiasi dubbio, domanda, informazione nel merito specifico di queste componenti.

   
Telegram News Channel