SCOPI DEL PROGETTO:
CONCETTI AFFRONTATI:
|
COMPONENTI SOFTWARE UTILIZZATE:
DISPOSITIVI FISICI UTILIZZATI: |
PROGETTO INDICATO a UTENTI CON ISTALLAZIONE: |
|
NOTE E DISCLAIMER
|
|
| Revisione progetto: 1.3 | |
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
- Definizione degli stati
- Integrazione
- Uso ordinario
- Via frontend
- Via automazione/i
- Innesco da altre fonti esterne
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 topic | Topic MQTT | Tipo comando | Payload |
| COMANDO (Command topic) | cmnd/Alarm | ARMO | armed_away |
| ARMO PRESENZA | armed_home | ||
| ARMO NOTTURNO | armed_night | ||
| IN FASE DI ARMO | pending | ||
| DISARMO | disarmed | ||
| INNESCO | triggered | ||
| TELEMETRIA (State topic) | stat/Alarm | ARMATO | armed_away |
| ARMATO PRESENZA | armed_home | ||
| ARMATO NOTTURNO | armed_night | ||
| IN FASE DI ARMO | pending | ||
| DISARMATO | disarmed | ||
| INNESCATO | triggered |
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 azioni 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:
mqtt: alarm_control_panel: - 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. |
| payload_arm_vacation | (Stringa, opzionale) Payload relativo all’armo-in ferie. |
| payload_custom_bypass | (Stringa, opzionale) Payload relativo alla custom bypass. |
| 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 (operativo/non operativo). Solitamente si indica il topic LWT. |
| payload_available | (Stringa, opzionale) Payload relativo alla segnalazione da parte dell’impianto di esercizio funzionante. Solitamente si indica il payload LWT. |
| payload_not_available | (Stringa, opzionale) Payload relativo alla segnalazione da parte dell’impianto di esercizio non funzionante. Solitamente si indica il payload LWT. |
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 l’interfaccia dell’HUB.
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:
Alternativamente, l’entità può essere visualizzata in modo tradizionale, come widget o nei suoi dettagli:
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:
action: notify.edoardo
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:
- action: alarm_control_panel.alarm_trigger
entity_id: alarm_control_panel.allarme
- action: notify.edoardo
data:
data:
push:
badge: 1
title: Domotica
message: Rilevata presenza fumo! Allarme in corso!
Infine, proponiamo anche la più classica delle 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:
- action: alarm_control_panel.alarm_arm_away
entity_id: alarm_control_panel.allarme
- action: notify.edoardo
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:
- action: alarm_control_panel.alarm_disarm
entity_id: alarm_control_panel.allarme
- action: notify.edoardo
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.
OPEN BOARD: i sistemi anti-intrusione/d’allarme e la domotica personale 🚨
|
⚠️ Se di Home Assistant ne sai poco ma sei interessato a capirne di più, ti suggeriamo di partire da qui. |
| Questa pagina è redatta, manutenuta e aggiornata dallo staff di inDomus, un gruppo di persone molto diverse tra loro che trovi, per domande e supporto, sul forum e sulla chat del sito. Alcuni link sono taggati in qualità di affiliati Amazon e riceviamo un compenso dagli acquisti idonei, utile al sostenimento del sito, ma le nostre recensioni sono tutte indipendenti e non sponsorizzate. Se ti sei perso, a tua disposizione c'è la mappa. |