SCOPI DEL PROGETTO:
CONCETTI AFFRONTATI:
|
COMPONENTI SOFTWARE UTILIZZATE:
DISPOSITIVI FISICI UTILIZZATI:
|
GUIDA maggiormente DEDICATA A utenti: |
|
NOTE E DISCLAIMER
|
|
| Revisione progetto: 1.2 | |
Abstract
Prima di cominciare, qualche importante precisazione.
Riuscire a domotizzare un impianto tradizionale di sicurezza, antieffrazione, d’allarme o come lo si voglia chiamare (magari già presente nell’ambiente e non dotato di alcun interfaccia informatica) rappresenta forse il Santo Graal della domotica personale. Bisogna mettersi d’accordo anche sulla definizione: che significa domotizzarlo? Ottenere il controllo domotico dei singoli elementi che lo compongono (sensori, centraline, sirene, logica)? Riuscire ad armarlo e disarmarlo? Conoscerne lo stato istantaneo, le anomalie? Venir notificati in caso di intrusione o di altri stati?
Un’unica risposta semplicemente non esiste. Il tema dei sistemi d’allarme – al di là della domotica – è talmente vasto e sfumato da meritare decine di pagine ad esso dedicate; questo progetto inDomus propone una chiave di lettura tra le tante possibili, suggerisce delle soluzioni per ottenere il massimo col minimo sforzo, sia esso tecnico che economico. Non ha la pretesa di essere LA soluzione: offre degli spunti, innesca il pensiero, porta – si spera – al ragionamento rispetto a come risolvere, in casa propria, la questione.
Altra doverosa precisazione: in linea di massima alcuni concetti espressi in questo progetto sono da considerarsi, per l’utente medio, abbastanza complessi. Prima di affrontarlo, pertanto, l’utente si accerti di padroneggiare concetti quali l’MQTT, il contatto pulito in domotica, il funzionamento di massima di Node-RED.
Lo scopo del presente progetto è dunque quello di rendere possibile l’armo, il disarmo e l’innesco di un sistema di allarme tradizionale tramite domotica personale. Come si vedrà, utilizzeremo diverse tecniche precedentemente illustrate per assemblare un’unico progetto funzionale.
| N.b. Questo progetto si articola in due parti: la prima (questa), dedicata ai passi in comune a prescindere dall’HUB implementato per la propria domotica personale; la seconda (pubblicata in seguito) illustra come configurare il proprio HUB personale per controllare quanto realizzato nella prima parte (un articolo per ogni HUB). |
Si parte
- Approccio
- Analisi
- Procedimento
- Identificare i contatti sui quali agire
- Scegliere e attestare gli attuatori sui contatti
- Configurare l’inching
- Assemblare una scatola murale
- Definire con Node-RED un dispositivo virtuale MQTT
- Integrare il dispositivo virtuale in domotica
- Home Assistant
- Homebridge
Approccio
La cosa che rende arduo descrivere un progetto di questo tipo sta nelle profonde differenze che esistono tra i vari impianti di allarmistica presenti al mondo.
Malgrado queste grandi differenze, esistono certamente dei minimi comuni denominatori, quali:
- servono a identificare un’effrazione;
- possono essere armati/disarmati;
- innescano una sirena quando entrano in allarme.
Quello che proporremo in questo progetto è di utilizzare gli elementi di controllo nativi dell’antifurto per riuscire, tramite altri elementi (degli attuatori), a renderlo domotico, nel senso di riuscire quantomeno a controllarne l’armo, il disarmo e l’innesco. Rispetto allo stato, faremo un ragionamento a sé stante.
Analisi
La prima cosa da fare è osservare il proprio sistema d’allarme – possibilmente manuali alla mano – per poi domandarsi: “come si arma/disarma?”
Le risposte solitamente sono:
- tramite tag RFID;
- tramite tastierino numerico;
- tramite telecomando codificato.
Mentre nei primi due casi la questione si fa più complicata, la presenza di un telecomando codificato – dotato magari di più pulsanti (uno 
per funzione) – apre a una facile domotizzazione (a seguire vedremo il perché). Alcune soluzioni di mercato sono “componibili” (vedi per esempio le soluzioni Diagral, per citare una marca a caso), pertanto anche non avendo un telecomando è talvolta possibile valutare di acquistarne uno ad hoc allo scopo di domotizzare l’impianto. Tutto dipende dalla marca e dal tipo di sistema antifurto a disposizione.
Alcuni allarmi – solitamente i più evoluti – presentano centraline “complesse” le quali dispongono al proprio interno di una o più morsettiere sulle quali si attestano i vari componenti dell’allarme (sensori, sirene ecc.). Alcuni contatti, talvolta, rappresentano “contatti puliti” utili magari proprio all’armo/disarmo/innesco dell’allarme – il che, al pari della presenza di un telecomando, apre a una facile domotizzazione.
ATTUATORI
L’idea di questo progetto, quindi, è quella di utilizzare degli attuatori domotici a contatto pulito (poche decine di euro) attestandoli proprio sui quei contatti elettronici offerti dal sistema d’allarme stesso (sul telecomando, oppure sulla centralina).
Per sommi capi, tali attuatori domotici permettono di aprire/chiudere i contatti su quali siano attestati; se ciò viene fatto sui due contatti relativi al pulsante di un telecomando, tale azione “simula” la pressione del dito umano sul pulsante del telecomando. Analogamente, attestando un attuatore domotico sui contatti di una centralina che permetta questo tipo di controllo, il risultato sarà quello di controllare via domotica la funzione prevista dalla centralina.
Affronteremo dunque il solo esempio del telecomando in quanto perfettamente mutuabile, con i medesimi concetti, ad un’eventuale centralina dotata di contatti puliti dedicata all’armo/disarmo e/o innesco dell’impianto.
| N.b. È vitale capire come il presente progetto lasci 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 faremo sarà dotarci della possibilità di armarlo, disarmarlo e innescarlo dalla nostra domotica personale (il che apre a tutta una serie di scenari di automazione non da poco – il che motiverà, come vedremo, l’impresa). |
Procedimento
I passi che andremo ad effettuare saranno i seguenti:
- identificare i contatti sui quali agire;
- scegliere e attestare gli attuatori sui contatti;
- assemblare una scatola murale;
- configurare l’inching;
- definire, tramite Node-RED, un dispositivo virtuale MQTT che rappresenti il sistema d’allarme controllato dagli attuatori.
Identificare i contatti
Ipotizziamo dunque di avere a disposizione un telecomando di controllo dell’allarme dotato di almeno due pulsanti (funzioni) fondamentali, ovvero armo e disarmo e, possibilmente, di una terza (tasto panico, il quale se premuto innesca l’allarme).
Assumeremo quindi che:
- pulsante 1: armo
- pulsante 2: disarmo
- pulsante 3: modalità panico (innesco forzato dell’allarme).
Ciò che dovremo fare sarà attestare tre attuatori a contatto pulito su altrettanti pulsanti. Facendo ciò l’atto di attivare un attuatore causerebbe la chiusura dei contatti del relativo pulsante sul quale sia stato attestato, “simulando” pertanto la pressione del tasto sul telecomando e quindi comandando la funzione relativa.
Analogamente, ciò che descriviamo funzionerebbe anche con degli attuatori attestati sulle coppie di contatti sulla morsettiera di una eventuale centralina dedicate al controllo delle funzionalità di cui sopra. Ovviamente in questo sarà di grande aiuto la documentazione del sistema d’allarme.
Scegliere e attestare gli attuatori sui contatti
Questa è la fase cruciale – nonché forse quella più complicata – che prevede di attestare le uscite di più attuatori a contatto pulito sui contatti che si vogliono controllare, nella fattispecie quelli dei pulsanti di un telecomando oppure sulla morsettiera della centralina.
Sì, ma quali attuatori dobbiamo usare?
Il requisito per l’attuatore “tipo” da attestare su un contatto da controllare è il seguente:
- dev’essere un attuatore domotico che fornisca supporto MQTT;
- deve esser fornito di contatto pulito.
Per portare degli esempi, sono validi:
- Shelly Plus 1 o lo Shelly 1 Mini: attuatori semplice, singolo canale, dotati nativamente di singolo contatto pulito;
- ITEAD Sonoff Basic (che sia stato modificato a contatto pulito): attuatore semplice, singolo canale;
- ITEAD Sonoff Dual R2 (che sia stato modificato a contatto pulito): attuatore a doppio canale;
- ITEAD Sonoff 4CH PRO: attuatore a quattro canali nativamente dotato di quattro canali a contatto pulito;
| N.b. Quale sia la scelta, i Sonoff citati si intendono riprogrammati con firmware Tasmota (o analoghi – per far sì che siano dotati di protocollo MQTT. Qui è disponibile un approfondimento). Nessuno vieta di usare Sonoff Basic e/o Sonoff Dual: noi però consigliamo di utilizzare il Sonoff 4CH PRO per il semplice fatto che è dotato di fabbrica di quattro canali a contatto pulito e non ha quindi bisogno di modifiche hardware per funzionare in questa modalità.
Gli Shelly, invece, sono dotati nativamente di supporto MQTT, quindi non necessitano di alcuna riprogrammazione. |
Per questo progetto sceglieremo di utilizzare un Sonoff 4CH PRO:
Come spiegato nell’abstract, questo progetto è, de facto, l’insieme di più progetti e tecniche: ecco perché a questo punto del progetto faremo una deviazione verso il progetto di domotizzazione di un telecomando tramite contatto pulito, ovvero il link che segue:
Integrare in domotica qualsiasi telecomando (anche rolling-code) tramite contatto pulito
| N.b. Tale deviazione non interessa direttamente chi volesse comandare i contatti puliti presenti sulla morsettiera di una centralina, ma una lettura è comunque consigliata, dato che concettualmente si tratta della stessa logica di funzionamento. |
Configurare l’inching
Affinché tutto funzioni correttamente è necessario configurare l’inching – ovvero l’effetto “pulsante“. Gli attuatori (o i canali singoli di un multicanale), infatti, quando attivati provvedono a chiudere il contatto pulito e… a lasciarlo tale: chiuso.
Un pulsante di un telecomando invece funziona diversamente: lo si preme (chiude) per un decimo di secondo circa per inviare il comando radio e poi lo si rilascia (apre).
Per far sì che all’attivazione un attuatore dotato di firmware Tasmota chiuda il contatto per riaprirlo immediatamente dopo, è necessario utilizzare il comando PULSETIME. Tale comando permette di configurare l’attuatore proprio in questa modalità.
Come configurare questo comando è spiegato nel dettaglio in questa guida dedicata.
Scatola murale
Bene: abbiamo provveduto ad attestate gli attuatori (o i singoli canali di un attuatore multicanale come il Sonoff 4Ch PRO, o il Dual) sui vari pulsanti da controllare e abbiamo configurato l’inching. A questo punto attivando i vari canali dell’attuatore (o i vari attuatori) il telecomando reagirà come se venisse premuto materialmente da un essere umano, di fatto domotizzando le funzioni di armo, disarmo e innesco dell’allarme tradizionale.
A questo punto il consiglio è di chiudere tutto in una scatola murale, nasconderla in qualche punto appropriato della casa e, fondamentalmente, dimenticarsi dell’aspetto “fisico” di questo progetto. Bisognerà soltanto aver cura di sostituire le batterie al telecomando di tanto in tanto.
Node-RED
A questo punto avremo sulla nostra rete Wi-Fi privata tre topic MQTT ai quali inviare un payload di accensione, il quale corrisponderà alla “pressione” simulata di un tasto del telecomando, e quindi all’esecuzione della funzione ad esso collegata.
Ipotizziamo che i le accoppiate funzione/comando siano le seguenti:
| Funzione | Comando MQTT (ipotetico per Sonoff 4Ch PRO) |
| ARMO (Pulsante 1) | cmnd/Sonoff/POWER1 ON |
| DISARMO (Pulsante 2) | cmnd/Sonoff/POWER2 ON |
| INNESCO PANICO (Pulsante 3) | cmnd/Sonoff/POWER3 ON |
Si noti come, dato che stiamo ipotizzando l’uso di un Sonoff 4Ch PRO con firmware Tasmota, il nome dell’attuatore cablato nel topic MQTT sia sempre lo stesso (“Sonoff“): a cambiare è il suffisso del topic “POWER“, il quale è numerato in base al canale dell’attuatore.
In caso avessimo utilizzato tre Sonoff Basic, probabilmente si sarebbe presentato uno scenario come segue:
| Funzione | Comando MQTT (ipotetico per Sonoff Basic x3) |
| ARMO (Pulsante 1) | cmnd/Sonoff1/POWER ON |
| DISARMO (Pulsante 2) | cmnd/Sonoff2/POWER ON |
| INNESCO PANICO (Pulsante 3) | cmnd/Sonoff3/POWER ON |
A cambiare sarebbe stato il nome dell’attuatore (“SonoffX“), mentre il canale (singolo) non sarebbe stato indicato come suffisso al comando “POWER“.
Ciò detto, in entrambi casi il problema è sempre lo stesso: invece di avere un unico topic di comando utile, in base al suo payload, ad armare, disarmare e/o innescare l’allarme, ne abbiamo tre diversi con payload sempre uguale (“ON“). Questo non è positivo, in quanto gli HUB personali questa logica non sono concepiti per capirla: per pilotare un elemento MQTT hanno bisogno di topic MQTT univoci.
Per risolvere ci viene in aiuto Node-RED.
Ipotizziamo infatti di ambire ad avere un unico topic di comando MQTT così definito:
| Funzione | Topic MQTT | Payload |
| Armo | cmnd/Allarme | armed_away |
| Disarmo | disarmed | |
| Innesco | triggered |
Questo significa che potremmo inviare un comando di armo “cmnd/Allarme armed_away“, uno di disarmo “cmnd/Allarme disarmed” e uno di innesco (panico) “cmnd/Allarme triggered“.
L’entità “Allarme” la possiamo creare virtualizzando il tutto tramite dei flussi da e per Node-RED i quali “convertano” i comandi singoli da e per i vari attuatori in un unico topic MQTT “virtuale” (“cmnd/Allarme“).
TELEMETRIE
Anche le telemetrie (topic MQTT contenenti uno stato operativo inviato ciclicamente) non fanno eccezione. Sarà infatti necessario creare, a partire dalle telemetrie naturalmente ricevute dai vari attuatori (o dal multi-canale), un unico topic telemetrico “virtuale” utile all’HUB personale che utilizziamo per comprendere quale sia lo stato operativo (di ritorno da un comando) dell’impianto.
Per esempio:
| Telemetria MQTT (ipotetico per Sonoff Basic x3) | Telemetria virtuale corrispondente |
| stat/Sonoff1/POWER ON | stat/Allarme armed_away |
| stat/Sonoff2/POWER ON | stat/Allarme disarmed |
| stat/Sonoff3/POWER ON | stat/Allarme triggered |
| N.b. Ovviamente questa soluzione non fornisce all’HUB lo stato effettivo di armo/disarmo/innesco dell’allarme, ma solo la risposta MQTT dell’attuatore che ha presumibilmente (quindi in optimistic mode) provveduto a ingaggiare la funzione. Per ottenere lo stato effettivo è necessario ingegnarsi ancora di più – ma qui si entra in un ginepraio dato dalla natura stessa dell’allarme – la quale varia da soluzione a soluzione. Chi di noi ha redatto questo progetto, per esempio, deduce lo stato di armo/disarmo del proprio impianto tramite un relè collegato nativamente alla centralina dall’allarme il quale chiude i propri contatti quando l’impianto viene armato. Tale chiusura dei contatti viene letta da un sensore domotico il quale riporta tale stato allo domotica basata su Home Assistant tramite un flusso Node-RED come sopra spiegato.
Ogni allarme tradizionale fa storia a sé: diciamo che per questi tipo di impianti il riuscire ad ottenere armo, disarmo e innesco via domotica è già di per sé un ottimo risultato. |
Per realizzare questi due topic “virtuali” deviamo dal progetto per atterrare su un altro, il quale spiega esattamente quale sia la logica di quanto appena descritto e come realizzarla con Node-RED.
Trasformare più elementi MQTT in un unico dispositivo virtuale tramite Node-RED
Integrare il dispositivo virtuale in domotica
In conclusione di questa prima parte, siamo riusciti a:
- applicare degli attuatori a dei contatti al fine di domotizzare il funzionamento dell’allarme;
- definire un’entità virtuale MQTT.
A questo punto siamo pronti ad integrare questo “allarme virtuale MQTT” sul nostro HUB personale. Dato che gli HUB trattano questi oggetti in modalità diverse, abbiamo deciso di redigere guide diverse per ognuno di essi.
HOME ASSISTANT
Come abbiamo spiegato anche sulla “Panoramica: i sistemi d’allarme, la domotica e Home Assistant“, Home Assistant è un HUB personale che consente di gestire le funzioni principali dei un sistema di allarme ad esso integrabile.
Tra le varie possibilità per l’integrazione di un sistema d’allarme, il presente progetto si canalizza verso l’adozione del componente “MQTT Alarm Control Panel”, il quale consente appunto l’integrazione di un sistema d’allarme controllabile via protocollo MQTT – ovvero uno come quello che, virtualizzandolo, abbiamo realizzato in questa prima parte di progetto.
La seconda parte, quella appunto dedicata all’integrazione presso Home Assistant, è disponibile qui.
HOMEBRIDGE
Anche Homebridge, come Home Assistant, è un buon candidato per l’integrazione di un sistema d’allarme MQTT, il quale abilita il controllo e la gestione del sistema d’allarme tramite Apple HomeKit.
La guida relativa a questo HUB personale è disponibile qui.
OPEN BOARD: i sistemi anti-intrusione/d’allarme e la domotica personale 🚨
| 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. |