Domotizzare un sistema d’allarme tradizionale con MQTT e Home Assistant (parte 2)

8 minuti di lettura
SCOPI DEL PROGETTO:
  • Domotizzare un impianto d’allarme tradizionale con Home Assistant
  • Livello di difficoltà: alto
  • Costo: nullo
CONCETTI AFFRONTATI:
COMPONENTI SOFTWARE UTILIZZATE:
  • Home Assistant configurato e funzionante
  • Componente Home Assistant “MQTT Alarm Control Panel”
DISPOSITIVI FISICI UTILIZZATI:
  • Un sistema d’allarme tradizionale dotato di interfaccia MQTT tramite le tecniche spiegate nella “parte 1” di questo progetto (oppure un sistema d’allarme domotico dotato di interfaccia MQTT nativa).
PROGETTO MAGGIORMENTE INDICATO PER:

Tutti gli ambienti

Note e disclaimer
  • qualsiasi modifica all'impianto elettrico dev'essere effettuata da personale qualificato
  • qualsiasi modifica attuata in proprio è a propria responsabilità personale nonché a proprio rischio e pericolo (la presente guida ha puro scopo didattico)
  • qualsiasi modifica attuata in proprio a un dispositivo ne fa decadere la garanzia.
Revisione progetto: 1.1

Abstract

L’HUB personale Home Assistant, come noto, permette di dotarsi di un ambiente operativo per la gestione, organizzazione e automazione della propria domotica personale a partire da componenti di diversi produttori, tecnologie e funzioni presenti sul mercato.

Uno degli aspetti più interessanti è quello di poter integrare alla configurazione di questo potente HUB personale anche i sistemi d’allarme, in modo da poterne gestire le funzionalità in modo manuale, automatico e sopratutto in concerto con le altre entità presenti in configurazione.

Lo scopo del presente progetto è quello di integrare a Home Assistant un tradizionale impianto di sicurezza, antieffrazione, d’allarme – o come lo si voglia chiamare – che sia stato virtualizzato in questo senso con le tecniche descritte nella parte 1 del progetto (oppure il quale sia dotato di suo di un’interfaccia MQTT).

Il risultato finale sarà quello di definire in configurazione un’entità di tipo “Alarm” la quale possa per l’appunto essere gestita tramite Home Assistant nelle consuete modalità manuali e automatiche.

N.b. Prima di affrontare questa seconda parte di progetto si consiglia un ripasso (o uno studio mediamente approfondito) del tema MQTT.

Si parte

Prerequisiti

Si dà per scontato che il sistema d’allarme che si va ad integrare sia dunque dotato di topic MQTT di comando e di telemetria – nativi o virtualizzati come spiegato nell’abstract.

Per questo progetto assumeremo che tali topic siano:

Tipologia topicTopic MQTTTipo comandoPayload
COMANDO (Command topic)cmnd/AlarmARMOarmed_away
ARMO PRESENZAarmed_home
ARMO NOTTURNOarmed_night
IN FASE DI ARMOpending
DISARMOdisarmed
INNESCOtriggered
TELEMETRIA (State topic)stat/AlarmARMATOarmed_away
ARMATO PRESENZAarmed_home
ARMATO NOTTURNOarmed_night
IN FASE DI ARMOpending
DISARMATOdisarmed
INNESCATOtriggered

Questo significa, tradotto in parole povere, che inviando (utilizzando l’entità Home Assistant che andremo a definire oppure tramite un client MQTT) un topic così formato:

cmnd/Alarm armed_away

questo scaturisca nell’armo dell’allarme, il quale dovrebbe rispondere con un ok formale tramite una telemetria come questa:

stat/Alarm armed_away

telemetria la quale, ricevuta da Home Assistant, gli confermerebbe l’avvenuto armo – e quindi la bontà dello stato assunto.

Ovviamente gli stati minimi obbligatori (altrimenti che allarme sarebbe?) sono:

  • armed (armato)
  • disarmed (disarmato)

mentre quelli opzionali sono:

  • triggered (innescato)
  • armed_night (armato notturno)
  • armed_home (armato presenza)
  • pending (in fase di armo)

Definizione degli stati

Prima di proseguire è necessario spiegare cosa significhino, per Home Assistant, i vari stati disponibili presso un’entità di tipo “Alarm”. Non è difficile farlo: di fatto si tratta della rappresentazione linguistica di un comando inviato e di un relativa risposta ricevuta, e niente di più – il che semplifica di molto la comprensione di quello che stiamo realizzando con questo progetto.

Di fatto, quando detto sopra vale per qualsiasi entità di Home Assistant. Prendiamo una luce accesa tramite un attuatore posto a monte della lampadina e integrato in domotica: comandando l’accensione tramite Home Assistant quello che facciamo è comandare l’attuatore di erogare la tensione a valle, verso la lampadina, aspettando poi che lui risponda “ok, fatto“. Questo non significa che la lampadina si sia accesa davvero: potrebbe essere bruciata, oppure non ben avvitata sul porta lampada.

Nel presente contesto il concetto è precisamente il medesimo. Un’entità di tipo “Alarm” può essere infatti configurata e successivamente comandata (da servizi o da interfaccia web/app) in modo da inviare dei comandi MQTT verso un dispositivo virtuale (come realizzato tramite la parte 1 del presente progetto) o verso uno fisico (un sistema d’allarme con supporto nativo MQTT) i quali rispondano a loro volta con un ok formale all’esecuzione del comando.

Gli stati previsti da questo componente, come detto, sono:

  • armed (armato)
  • disarmed (disarmato)
  • triggered (innescato)
  • armed_night (armato notturno)
  • armed_home (armato presenza)
  • pending (in fase di armo)

Quello che è importante conoscere a monte è il comportamento dell’impianto (virtualizzato MQTT o nativamente MQTT) alla ricezione di specifici topic di comando MQTT.

Ipotizziamo per esempio di aver virtualizzato (tramite la parte 1 del progetto) un impianto e che si comporti come segue:

  • se riceve un comando “cmnd/Alarm armed_away“, si arma normalmente;
  • se riceve un comando “cmnd/Alarm armed_home“, si arma in modalità presenza (si innesca l’allarme solo, per esempio, in caso di effrazione ma non tramite sensori volumetrici;
  • se riceve un comando “cmnd/Alarm disarmed“, si disarma;
  • se riceve un comando “cmnd/Alarm triggered“, innesca l’allarme

dovrò dunque cablare questi comandi nella configurazione di Home Assistant per l’entità “Alarm” che vogliamo definire. Va da sé che tutti i comportamenti relativi al funzionamento intrinseco del sistema d’allarme (se e quando innescarsi, quali siano i sensori ecc.) rimangano isolati e relativi all’allarme stesso.

Integrazione

A questo punto è possibile configurare l’integrazione con Home Assistant.
La configurazione più elementare, la quale utilizza la piattaforma Home Assistant “MQTT Alarm Control Panel, è piuttosto semplice:

alarm_control_panel:
  - platform: mqtt
    name: Allarme
    code: 1106
    state_topic: stat/Alarm
    command_topic: cmnd/Alarm
    payload_arm_home: armed_home
    payload_arm_away: armed_away
    payload_disarm: disarmed
    qos: 2

Spiegazione dei campi, presenti e non:

name(Stringa, opzionale) Nome dell’entità. Default: MQTT Alarm
state_topic(Stringa, obbligatoria) Topic MQTT al quale iscrivere Home Assistant al fine di ricevere lo stato operativo dell’impianto.
command_topic(Stringa, obbligatoria) Topic MQTT inviato da Home Assistant al fine di comandare lo stato operativo dell’impianto.
command_template(Stringa, opzionale) Template relativo al payload del comando. Può assumere valore action (default) o code.
value_template(Stringa, opzionale) Template relativo all’estrazione del valore.
qos(Intero, opzionale) Quality Of Service MQTT. Si consiglia si impostare “2“. (Cos’è QoS?)
payload_disarm(Stringa, opzionale) Payload relativo all’armo.
payload_arm_home(Stringa, opzionale) Payload relativo all’armo-presenza.
payload_arm_night(Stringa, opzionale) Payload relativo all’armo-notturno.
code(Stringa, opzionale) Codice per l’armo/disarmo dell’impianto. Nell’esempio è stato impostato a “1-1-0-6”.
code_arm_required(Booleano, opzionale) Se impostato a true, obbliga l’inserimento del codice per l’armo. Default: true
code_disarm_required(Booleano, opzionale) Se impostato a true, obbliga l’inserimento del codice per il disarmo. Default: true
availability_topic(Stringa, obbligatoria) Topic MQTT al quale iscrivere Home Assistant al fine di ricevere lo stato d’esercizio dell’impianto (funzionante/non funzionante).
payload_available(Stringa, opzionale) Payload relativo alla segnalazione da parte dell’impianto di esercizio funzionante.
payload_not_available(Stringa, opzionale) Payload relativo alla segnalazione da parte dell’impianto di esercizio non funzionante.

esiste anche qualche altro campo per configurazioni più puntuali; per eventuali necessità diverse da quelle espresse in questo progetto, far direttamente riferimento alla pagina dedicata al componente.

A valle della configurazione di cui sopra, post riavvio Home Assistant genererà un’entità di tipo “Alarm” chiamata “alarm_control_panel.allarme” la quale potrà esser utilizzata per innescare e disarmare l’allarme, nonché armarlo in modalità normale (“away”, assenza) nonché “notturna”.

Uso ordinario

VIA FRONTEND

Il componente “Alarm” consente di definire un’entità che potrà essere configurata come “Alarm Panel Card” presso il frontend Lovelace.
Rimanendo nel solco del nostro esempio, la configurazione sarebbe la seguente:

type: alarm-panel
entity: alarm_control_panel.allarme
states:
  - arm_home
  - arm_away

il che darebbe vita a un vero e proprio pannello per la gestione del sistema d’allarme:

Home Assistant MQTT Alarm Control Panel

Alternativamente, l’entità può essere visualizzata in modo tradizionale, come widget o nei suoi dettagli:

Home Assistant - Alarm

VIA AUTOMAZIONE/I

Ovviamente anche questo tipo di entità – come qualunque altra – può essere utilizzato in ambito automazione come elemento trigger, condition e/o action.

Come trigger, l’uso più classico è quello di sfruttarne lo stato al fine di effettuare qualche azione specifica, per esempio l’invio di una notifica:

automation:
- alias: "Notifica su armo allarme"
  trigger:
    platform: state
    entity_id: alarm_control_panel.allarme
    to: "armed_away"
  condition: []
  action:
    service: notify.marco
    data:
      data:
        push:
          badge: 1
      title: Domotica
      message: Allarme armato.

Come contition e action, invece, proponiamo un’automazione che suggerisce un uso interessante di questo tipo di entità, ovvero l’ampliamento delle funzionalità nativamente previste per il sistema antifurto.

Mettiamo infatti di aver integrato a Home Assistant un sensore di fumo – non facente parte dei componenti dell’allarme – e di voler definire un’automazione che, in presenza dell’allarme armato (sia “armo normale” che “armo presenza”), provveda ad innescarlo a fronte della rilevazione fumi, oltre che inviare una notifica. Assumeremo che l’entità rappresentante il sensore di fumo si chiami “binary_sensor.smoke_sensor“:

automation:
- alias: "Notifica su armo allarme"
  trigger:
    platform: state
    entity_id: binary_sensor.smoke_sensor
    to: 'on'
  condition:
    condition: or
    conditions:
      - condition: state
        entity_id: alarm_control_panel.allarme
        state: 'armed_away'
      - condition: state
        entity_id: alarm_control_panel.allarme
        state: 'armed_home'
  action:
    - service: alarm_control_panel.alarm_trigger
      entity_id: alarm_control_panel.allarme
    - service: notify.marco
      data:
        data:
          push:
            badge: 1
        title: Domotica
        message: Rilevata presenza fumo! Allarme in corso!

Infine, proponiamohedue classica automazioni, quella che provveda all’armo e quella che provveda al disarmo a fronte dell’abbandono/rientro a casa:

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.allarme
    - service: notify.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.allarme
    state: 'armed_away'
  action:
    - service: alarm_control_panel.alarm_disarm
      entity_id: alarm_control_panel.allarme
    - service: notify.marco
      data:
        data:
          push:
            badge: 1
        title: Domotica
        message: "Allarme DISARMATO. Bentornato."

P.S. Fate 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 🙂

INNESCO DA ALTRE FONTI esterne

Come spiegato anche nella prima parte del progetto, l’approccio seguito lascia al sistema d’allarme l’onere della gestione, completa, dei meccanismi, delle logiche e dei sistemi di rilevamento. In sostanza l’allarme continuerà a fare il proprio mestiere: quello che permette il presente progetto è di dotarci della possibilità di armarlo, disarmarlo e innescarlo.

Il problema nasce quando l’innesco avviene extra-domotica, perché appunto il sistema – facendo il proprio mestiere – abbia innescato l’allarme per un’avvenuta effrazione. In sostanza, potremmo aver ottenuto il risultato di riuscire ad armare, disarmare e innescare l’allarme dalla domotica, ma non sapere – sempre dalla domotica – quando l’impianto si sia innescato per i fatti propri.

Come intercettare questo stato di innesco in modo che anche la domotica ne sia allertata  (e quindi, magari, notificare la cosa all’utente) non è oggetto del presente progetto. Un suggerimento però non costa nulla fornirlo: nel momento in cui “in qualche modo” tale stato di avvenuto innesco esterno sia stato veicolato verso la propria domotica (un esempio stupido? un sensore di pressione acustica che rilevi un picco di decibel – mentre l’allarme è armato – e faccia quindi assumere l’avvenuto innesco dell’allarme), per far sì che anche l’entità “Allarme” passi a stato “innescato” sarà sufficiente far pubblicare – dalla domotica, o tramite Node-RED – un comando MQTT come questo:

cmnd/Alarm triggered

il quale, appunto, verrà interpretato – sulla base di quanto illustrato in questo progetto – come “allarme innescato”, con tutto ciò che ne consegue.


Home Assistant Official LogoATTENZIONE: 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.

🔻 Clicca QUI per commentare l'articolo. 🔻