Domotizzare un sistema d’allarme tradizionale con MQTT e Apple HomeKit via Homebridge (parte 2)

6 minuti di lettura
SCOPI DEL PROGETTO:
  • Domotizzare un impianto d’allarme tradizionale con Apple HomeKit via Homebridge
  • Livello di difficoltà: alto
  • Costo: nullo (al netto del sistema d’allarme)
CONCETTI AFFRONTATI:
COMPONENTI SOFTWARE UTILIZZATE:
DISPOSTIVI 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:

Apple-200x200

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

Il programma Apple HomeKit, 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. Homebridge è un HUB personale che consente all’utente di rendere compatibili con tale standard componenti domotiche anche molto diverse tra loro le quali, nativamente, non lo sarebbero.

Uno degli aspetti più interessanti della domotica personale è quello di poter integrare al proprio ambiente operativo anche i sistemi d’allarme, in modo da poterne gestire le funzionalità in modo manuale, automatico e sopratutto in concerto con gli altri componenti presenti: lo scopo del presente progetto è quello di integrare a Homebridge (e quindi ad Apple HomeKit) 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 un elemento di tipo “Allarme” il quale possa per l’appunto essere gestita tramite Apple HomeKit 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 Homebridge.

Installazione del plugin

In primis è necessario installare il plugin “homebridge-mqttthing“, a meno che non sia già presente sul sistema. Il caso, passare al paragrafo successivo.

L’installazione, come tutti i plugin Homebridge – è semplicissima.
Eseguire il seguente comando – su sistemi unix-based (linux, Raspberry ecc.) da terminale, da sistemi Windows su prompt dei comandi:

sudo npm install -g homebridge-mqttthing

e attendere il termine della procedura. In caso di sistemi Windows, omettere la parola “sudo”.

N.b. In caso Homebridge sia già in esecuzione come servizio (come descritto nella nostra guida di installazione di Homebridge), provvedere a interromperlo prima dell’installazione tramite il comando:

sudo systemctl stop homebridge

Configurazione

La configurazione, la quale utilizza il plugin “homebridge-mqttthing, non è particolarmente complessa. Prevede l’aggiunta di uno (o più) elementi nella lista degli “accessory“:

{
	"accessory": "mqttthing",
	"type": "securitySystem",
	"name": "Allarme",
	"url": "mqtt://127.0.0.1:1883",
	"username": "",
	"password": "",
	"caption": "Sistema di allarme",
	"topics": {
		"setTargetState": "cmnd/Alarm",
		"getCurrentState": "stat/Alarm"
	},
	"targetStateValues": ["armed_away", "armed_away", "disarmed", "triggered"],
	"currentStateValues": ["armed_away", "armed_away", "disarmed", "triggered"]
}}

Spiegazione dei campi:

accessory(Stringa, obbligatoria) Deve necessariamente essere valorizzato a “mqttthing“.
type(Stringa, obbligatoria) Deve necessariamente essere valorizzato a “securitySystem“.
name(Stringa, obbligatoria) Contiene il nome dell’accessorio. In questo esempio è valorizzato ad “Allarme“.
url(Stringa, obbligatoria) L’indirizzo del proprio broker MQTT.
username(Stringa, opzionale) L’username d’accesso al broker MQTT, se necessario.
password(Stringa, opzionale) La password d’accesso al broker MQTT, se necessaria.
caption(Stringa, opzionale) Una descrizione dell’accessorio.
topic(Lista, obbligatoria) Contiene i topic MQTT per la gestione dell’accessorio.

setTargetState(Stringa, obbligatoria) Contiene il topic di comando MQTT utilizzato dall’accessorio per controllare l’impianto.
getTargetState(Stringa, opzionale) Contiene il topic di telemetria MQTT al quale iscriversi per rilevare il cambiamento di stato comandato manualmente, direttamente sull’impianto (se previsto).
getCurrentState(Stringa, opzionale) Contiene il topic di telemetria MQTT al quale iscriversi per rilevare l’effettivo cambiamento di stato comandato dalla domotica.
targetStateValues(Lista, obbligatoria) Contiene gli stati supportati dal topic di comando MQTT definito presso setTargetState, ovvero gli stati comandabili.
currentStateValues (Lista, obbligatoria) Contiene gli stati supportati dal topic definito presso getCurrentState, ovvero gli stati attuati e confermati tramite telemetria MQTT.

Una volta completata la configurazione e provveduto al riavvio di Homebridge, presso l’app “Casa” apparirà un accessorio come segue:

Apple HomeKit - Allarme

Uso

A questo punto sarà possibile utilizzare l’app “Casa” e Siri per controllare il sistema d’allarme.

In caso l’allarme venga innescato, Apple HomeKit riferirà tale stato presso l’app “Casa”, oltre ovviamente ad inviare una notifica:

Apple HomeKit - Allarme - dettagli - innescato

Trattandosi di un accessorio standard è possibile, sempre tramite l’app “Casa”, definire delle automazioni tra quelle previste dalle caratteristiche specifiche di questo standard. Una delle più tipiche potrebbe essere quella di provvedere all’auto-armo dell’allarme quando ci si allontana da casa e al relativo disarmo al rientro.

Innesco da 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.


Logo Apple HomeKitATTENZIONE: ricorda che sul nostro community FORUM c'è una sezione ad hoc dedica ad Apple Homekit, per qualsiasi dubbio, domanda, informazione nel merito specifico di queste componenti.

🔻 Clicca QUI per commentare l'articolo. 🔻