Scopi del PROGETTO:
Concetti affrontati:
|
Componenti software utilizzate:
Prerequisiti:
Dispositivi fisici utilizzati:
|
GUIDA INDICATA A UTENTI CON ISTALLAZIONE: |
|
NOTE E DISCLAIMER
|
|
| Revisione progetto: 1.1 | |
Abstract
Quella di integrare un sistema d’allarme a Home Assistant è, tendenzialmente, è un’ottima idea. Il motivo è semplice: nel momento in cui il sistema è presente come entità all’interno della propria domotica integrata, esso può agire come trigger, come condition o come action nelle più diverse automazioni, lavorando così in concerto con tutto il resto della propria domotica, anche non appartenente allo stesso brand o linea prodotti del sistema in questione.
Si pensi per esempio all’opportunità di armare/disarmare l’allarme automaticamente in base alla propria presenza in casa, oppure quella di innescare l’allarme a partire da altre entità di diversa natura anch’esse integrate sull’HUB, di base non associabili all’allarme (eg. ho un sensore di allagamento ZigBee e voglio innescare l’allarme in momento in cui esso rileva la presenza di acqua). Il limite, come sempre, è la fantasia.
L’eTiger S5 è un interessante allarme entry-level che, di base, non prevede la possibilità di essere integrato a Home Assistant. Desiderosi di riuscire a farlo, siamo riusciti a definire una tecnica efficace allo scopo.
Il presente progetto illustra come, utilizzando varie tecniche, integrare pienamente tale sistema a Home Assistant, per altro nell’apprezzabile modalità Local Push.
Si parte
Approccio
Allo scopo di domotizzare in pieno un sistema d’allarme tradizionale (quindi di base non nativamente integrabile), ciò che è necessario avere a disposizione sono gli stati della centralina e dei sensori nonché delle interfacce di comando. Questi elementi, indipendentemente dalla loro natura, servono alla gestione completa del sistema.
Nel caso dell’eTiger S5, ciò che ci viene in soccorso sono le trasmissioni radio da e per la centralina. Analogamente a come si fa con l’infrarosso, sfrutteremo l’acquisizione di determinati codici radio per integrare il sistema presso Home Assistant. Il funzionamento è dunque: tramite un trasmettitore/ricevitore radio compatibile (il Sonoff RF Bridge) acquisiremo miratamente i codici, dopodiché provvederemo a “cablarli” nella configurazione il Home Assistant sfruttando i componenti “MQTT” e “Sensor” nonché le piattaforme “MQTT Alarm Control Panel” e “MQTT Binary Sensor“.
Questo ci consentirà di dotarci di tutte le entità necessarie per gestire e censire l’allarme presso Home Assistant, ottenendo così un’ottima e piena integrazione di tipo Local Push che consente, volendo, anche di abbandonare l’uso dell’app nativa, delegando in toto all’HUB personale la gestione dell’allarme.
Assunti
In questo progetto si assume che (maggiori spiegazioni a seguire):
- Home Assistant sia installato e funzionante;
- la configurazione del client MQTT su Home Assistant sia operativa;
- il broker MQTT sia operativo.
Per attivare broker e funzionalità MQTT su Home Assistant si rimanda a questa guida specifica.
| N.b. Per chiarimenti sul tema MQTT si consiglia di leggere la guida dedicata alla configurazione del protocollo MQTT per la propria domotica. |
Sonoff RF Bridge
Il Sonoff RF Bridge è una piccola unità in grado di ricevere e inviare codici in radiofrequenza a 433 MHz, alimentato via USB; riprogrammandone il firmware è possibile canalizzare la ricezione e l’invio di codici tramite lo standard MQTT (cosa non possibile con il firmware originale).
Per utilizzare questa unità al fine di integrare l’eTiger S5 è necessario quindi riprogrammarne il firmware adottando il progetto Tasmota; tale procedura – non particolarmente complessa ma come detto necessaria – è spiegata nel dettaglio in questa guida apposita.
| N.b. L’adozione del firmware Tasmota consente al Sonoff RF Bridge sì l’invio e la ricezione di diversi codici radiofrequenza; nel caso di questo progetto la necessità è però anche quella di inviare e ricevere codici “grezzi” (RAW) è allora necessario modificare il mini-firmware della sola componente radio del dispositivo tramite la versione specifica di mini-firmware realizzata da Portish, la quale consente l’uso nelle modalità descritte. La guida per installare tale mini-firmware è disponibile qui. |
Ciò che è necessario fare quindi è:
- riprogrammare il proprio Sonoff RF Bridge con firmware Tasmota;
- far accedere il Sonoff RF Bridge alla propria rete Wi-Fi;
- aggiungere il mini-firmware Portish;
- collegare il Sonoff RF Bridge al proprio broker MQTT.
Ciò fatto, l’unità è pronta per ricevere e inviare codici RF (anche RAW).
Proseguendo nella lettura del presente progetto, si assume quindi di aver provveduto ai passi sopra elencati.
Cattura dei codici
Con il Sonoff RF Bridge ora pronto, ciò che è necessario fare è catturare tutti i propri codici in radiofrequenza che ci servono per l’integrazione su Home Assistant, ovvero:
- tutti i codici di “risposta” della centralina, ovvero le telemetrie che essa invia quando attua un qualsiasi comando gli venga impartito (tramite la sua app mobile, tramite il tastierino, tramite pianificazione eccetera). Questo servirà per “far conoscere” all’entità allarme di Home Assistant il suo stato istantaneo;
- tutti i codici di “risposta” dei sensori wireless, ovvero le telemetrie che i singoli sensori inviano quando si attivano (per esempio quando il sensore PIR rileva del movimento, o quando quello di apertura rileva l’apertura del varco, eccetera). Questo servirà per “far conoscere” alle entità di Home Assistant relative ai sensori il suoi stati istantanei;
- tutti i codici di “attivazione” inviabili dal/dai radiocomando/i (per l’armo, il disarmo, l’attivazione della modalità panico). Questi serviranno per operare sull’allarme da Home Assistant.
I codici sono di due tipi, semplici o RAW. Nel caso dell’eTiger S5, i primi sono tutti quelli “di stato” (ovvero i primi due tipi elencati sopra), mentre i secondi sono quelli di attivazione prodotti dai radiocomandi.
I codici da raccogliere sul kit di base sono:
| Item | Tipologia codice | Evento |
| Centralina | Telemetria | Avvenuta disattivazione |
| Avvenuto armo assenza | ||
| Avvenuto armo presenza | ||
| Armo in corso | ||
| Radiocomando | Comando | Disattivazione |
| Armo assenza | ||
| Armo presenza | ||
| Modalità panico (attivazione sirena) | ||
| Sensore di apertura | Telemetria | Rilevazione avvenuta |
| Sensore di movimento | Telemetria | Rilevazione avvenuta |
COME CATTURARE I CODICI
Innanzitutto, per catturare i codici è necessario posizionare le fonti emittenti e il Sonoff RF Bridge il più possibile vicini, questo per evitare problemi di interferenze durante la lettura.
Recandosi presso l’interfaccia web Tasmota, cliccare su “Console“, dopodiché attivare l’emissione di un codice, uno qualunque: se per esempio si vuole rilevare la “rilevazione avvenuta”, attivare il sensore d’interesse; se si vuole rilevare la telemetria di avvenuta attivazione dell’allarme, attivarlo tramite l’app (o una delle altre modalità).
Quando riceve uno di questi segnali, Sonoff RF Bridge provvede alla pubblicazione di un topic telemetrico MQTT contenente nel payload (carico utile) il codice ricevuto, il che equivale alla “firma” dell’emettitore che l’ha inviato.
Solitamente il topic telemetrico è:
tele/BridgeRF/RESULT
dove ovviamente “BridgeRF” è il nome MQTT assegnato configurando MQTT sul firmware.
Il payload sarà grossomodo il seguente:
{“RfReceived”:{“Sync”:12610,”Low”:400,”High”:1250,”Data”:”XXXXXX“,”RfKey”:”None”}}
Nella chiave “Data” troveremo il codice, in questo caso (puramente esemplificativo) “XXXXXX“.
Per quanto riguarda i codici del radiocomando (forse i più importanti) è necessario utilizzare in console un comando specifico di Tasmota, atto ad attivare la ricezione dei codici RAW, ovvero:
RfRaw 117
questo comando, utilizzato sempre in “Console”, attiva la ricezione dei codici RAW, la tipologia per l’appunto utilizzata dal radiocomando. Andando a leggere i codici radiofrequenza dei quattro tasti del radiocomando, la risposta in console sarà di questo tipo:
{“RfRaw”:{“Data”:”AA B1 XXXXXXXXXXXXXXXXXXXXXXXX 55“}}
molto diversa da quella sopra illustrata relativa ai codici “normali”. Nella chiave “Data” troveremo sì il codice, ma in questo caso (puramente esemplificativo) in standard RAW: “AA B1 XXXXXXXXXXXXXXXXXXXXXXX 55” (codice puramente d’esempio).
| N.b. Nel caso dei codici RAW è consigliabile ripetere la lettura più volte: talvolta il codice grezzo letto non è corretto, quindi con più test si identifica empiricamente il codice corretto, che su più tentativi ricorre più volte. |
Conversione dei codici RAW
I codici RAW del radiocomando, una volta raccolti, vanno convertiti in modo che il Sonoff RB Bridge possa inviarli in luogo del radiocomando. Le tecniche sono diverse, ma l’unica che abbiamo appurato funzionare è quella di utilizzare uno script su sistema operativo Linux. L’esempio che segue è basato su test effettuati su Raspberry Pi OS di Raspberry Pi
Una volta collegati via SSH al proprio Raspberry, eseguire i seguenti comandi:
sudo pip install image
sudo pip install pycurl
wget https://raw.githubusercontent.com/Portisch/RF-Bridge-EFM8BB1/master/BitBucketConverter.py
sudo chmod +x ./BitBucketConverter.py
entrare poi in edit sullo script BitBucketConverter.py:
sudo nano BitBucketConverter.py
trovare la stringa raw_input (linea 64, per la precisione) e sostituirla con input. Poi, salvare e uscire (CTRL+X, y, invio).
La conversione si effettua lanciando il comando:
./BitBucketConverter.py
Alla richiesta dello script:
Enter B1 line:
inserire, copia incollandolo, il codice RAW da convertire. In risposta, verrà fornito il codice convertito in standard B0.
Provvedere quindi alla conversione di tutti i codici RAW precedentemente acquisiti.
Ipotizziamo infine di aver raccolto i seguenti codici (li useremo per spiegare l’integrazione che segue):
| Item | Tipologia codice | Evento | Codice |
| Centralina | Telemetria | Avvenuta disattivazione | XXXXX1 |
| Avvenuto armo assenza | XXXXX2 | ||
| Avvenuto armo presenza | XXXXX3 | ||
| Armo in corso | XXXXX4 | ||
| Radiocomando | Comando | Disattivazione | AA B0 XXXXXXXXXXXXXXXXXXXXXXX1 55* |
| Armo assenza | AA B0 XXXXXXXXXXXXXXXXXXXXXXX2 55* | ||
| Armo presenza | AA B0 XXXXXXXXXXXXXXXXXXXXXXX3 55* | ||
| Panico (attivazione sirena) | AA B0 XXXXXXXXXXXXXXXXXXXXXXX4 55* | ||
| Sensore di apertura | Telemetria | Rilevazione avvenuta | XXXXX4 |
| Sensore di movimento | Telemetria | Rilevazione avvenuta | XXXXX5 |
*Si assume siano codici RAW già convertiti dall’utente.
Integrazione Home Assistant
Con tutti i codici al proprio arco, siamo ora pronti a sfruttare diverse piattaforme MQTT di Home Assistant per definire le entità che ci servono per censire e gestire l’impianto sul nostro HUB personale, ovvero:
- un’entità di tipo “Alarm Control Panel”;
- tante entità “Binary Sensor” quanti sono i sensori inclusi nell’allarme e che si vogliono integrare.
Inoltre, definiremo uno script che fornisca la possibilità di innescare l’allarme (sirena).
CENTRALINA
Ovviamente, il cuore del sistema è la centralina, pertanto lo scopo è quello di dotarsi di un’entità di tipo “Alarm” che sia in grado al contempo di ricevere gli stati e di permettere il comando della stessa. Per farlo utilizzeremo la piattaforma Home Assistant “MQTT Alarm Control Panel“.
Ciò che ci serve è:
- quattro codici “normali” relativi a:
- avvenuta disattivazione
- armo assenza
- armo presenza
- armo in corso
- tre codici RAW (convertiti) relativi a:
- disattivazione
- armo assenza
- armo presenza
Il codice YAML da aggiungere al file di configurazione è sostanzialmente il seguente:
mqtt:
alarm_control_panel:
- name: eTiger_S5
state_topic: "tele/BridgeRF/RESULT"
value_template: >
{% if value_json['RfReceived'].Data == 'XXXXX2' %}
armed_away
{% elif value_json['RfReceived'].Data == 'XXXXX3' %}
armed_home
{% elif value_json['RfReceived'].Data == 'XXXXX1' %}
disarmed
{% elif value_json['RfReceived'].Data == 'XXXXX4' %}
arming
{% endif %}
command_topic: "cmnd/BridgeRF/Backlog"
payload_arm_home: "RfRaw AA B0 XXXXXXXXXXXXXXXXXXXXXXX3 55; RfRaw 0"
payload_arm_away: "RfRaw AA B0 XXXXXXXXXXXXXXXXXXXXXXX2 55; RfRaw 0"
payload_disarm: "RfRaw AA B0 XXXXXXXXXXXXXXXXXXXXXXX1 55; RfRaw 0"
code: 1234
code_arm_required: true
code_disarm_required: true
qos: 2
Spiegazione dei campi:
| name | (Stringa, opzionale) Nome dell’entità. |
| 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 |
Ovviamente la configurazione proposta dovrà essere corretta utilizzando i propri codici precedentemente acquisiti (e convertiti, nel caso dei RAW). Nel codice proponiamo anche la presenza del “code”, al fine di richiedere, lato Home Assistant, l’inserimento di un codice di attivazione (qui proposto come 1234, ovviamente personalizzabile).
Infine, notare la inusuale ma in questo caso necessaria impostazione a 2 per il Quality of Service MQTT.
Questa configurazione genererà un’entità chiamata alarm_control_panel.etiger_s5 la quale potrà essere utilizzata sia tramite interfaccia sia tramite servizi previsti dalla piattaforma che l’ha generata, ovvero “MQTT Alarm Control Panel“.
SENSORI
In realtà avremmo terminato (l’allarme è pienamente integrato), ma ciononostante potrebbe risultare utile acquisire anche gli stati dei vari sensori presenti nell’impianto. Per farlo è necessario aver a disposizione il solo elenco dei codici radio ad essi relativi precedentemente raccolti.
Precisamente come nella nostra guida “Integrare componenti a radiofrequenza con Home Assistant via Sonoff RF Bridge“, andremo a definire tanti “Binary Sensor” quanti sono i sensori (e relativi codici) che abbiamo a disposizione.
Per farlo, aggiungeremo in configurazione qualcosa di questo tipo:
mqtt:
binary_sensor:
- name: "sensore"
off_delay: 5
payload_on: "XXXXX4"
payload_off: ""
device_class: opening
state_topic: "tele/BridgeRF/RESULT"
value_template: "{{ value_json.RfReceived.Data }}"
Dopo aver salvato e riavviato l’HUB, apparirà un’entità chiamata binary_sensor.sensore la quale si attiverà quando il sensore, aprendolo, invierà il codice radiofrequenza che verrà raccolto da Sonoff RF Bridge e convertito nella telemetria attesa.
Dato però che i sensori eTigier non inviano un altro codice per segnalare l’avvenuto ritorno a riposo del sensore stesso, il sensore binary_sensor.sensore con la sola configurazione di cui sopra rimarrebbe sempre in stato “on” (ovvero “aperto”). È quindi necessario indicare alla configurazione di Home Assistant cosa fare a fronte del rilevamento.
Utilizzeremo quindi un’automazione che, a fronte del cambio di stato del sensore a “on” – aperto – provveda dopo tre secondi (un tempo arbitrario, configurabile a piacere) a inviare un topic telemetrico MQTT “fake” (uguale a quello inviato dal Sonoff RF Bridge) il quale contenga una chiave di reset, in questo caso “key_clean“:
automation:
alias: Apertura CONTATTO e reset
trigger:
platform: state
entity_id: binary_sensor.sensore
to: 'on'
for:
seconds: 3
condition: []
action:
service: mqtt.publish
data:
topic: tele/BridgeRF/RESULT
payload: '{"RfReceived":{"Data":"key_clean"}}'
retain: true
A questo punto, per completare l’opera andrà modificato il sensore precedentemente configurato:
- modificando il campo “payload_off” la chiave “key_reset“;
- modificando il “payload_off” con un valore generico “on“;
- inserendo nel campo “value_template” una specifica logica di valutazione dello stato.
Vediamo la configurazione rivista e definitiva:
mqtt:
binary_sensor:
- name: "sensore"
payload_on: "on"
payload_off: "off"
device_class: opening
state_topic: "tele/BridgeRF/RESULT"
value_template: >
{% if value_json['RfReceived'].Data == 'XXXXX4' %}
on
{% elif value_json['RfReceived'].Data == 'key_clean' %}
off
{% else %}
{{ states('binary_sensor.sensore') }}
{% endif %}
In caso invece il sensore sia di altro tipo e abbia la possibilità di fornire un diverso codice per comunicare l’avvenuta chiusura del varco, l’automazione di cui sopra non è necessaria, ma piuttosto è necessario correggere la configurazione e indicare nei campi “payload_on” e “payload_off” i valori corretti.
INNESCO SIRENA
Infine, potrebbe risultare comodo avere a disposizione un semplice script da evocare quando forzatamente si voglia innescare dalla domotica lo stato d’allarme (ovvero l’innesco della sirena). Questo, come vedremo a seguire, viene utile tra le altre cose per “ampliare” le funzioni dell’allarme.
Dato che per innescare l’allarme è sufficiente la pressione del tasto “panico” sul radiocomando, analogamente definiremo uno script che pubblichi un topic MQTT contenente il codice RAW (convertito) relativo a tale pulsante; Sonoff Bridge RF, ricevuto tale topic di comando, invierà il codice, innescando quindi l’allarme.
Definiamo quindi lo script:
script: sirena_s5: alias: "Sirena S5" sequence: - service: mqtt.publish data: topic: "cmnd/BridgeRF/Backlog" payload: "RfRaw AA B0 XXXXXXXXXXXXXXXXXXXXXXX4 55; RfRaw 0"
ovviamente il codice proposto è quello d’esempio, il quale andrà sostituito col proprio, raccolto e convertito come spiegato in precedenza.
Tale script, evocato tramite il servizio script.turn_on, si chiamerà script.sirena_s5.
Automazioni
Arrivati a questo punto il nostro Home Assistant è dotato di tutti gli elementi utili per gestire e censire l’allarme al punto, volendo, di poter completamente sostituire l’app cloud solitamente in uso:
- alarm_control_panel.etiger_s5
- binary_sensor.sensoreX
- script.sirena_s5
Ora andremo a elencare delle automazioni d’esempio per far capire come, al di là dell’interfaccia di Home Assistant, l’allarme possa essere utilizzato in modo automatico.
L’entità alarm_control_panel.etiger_s5 può essere utilizzata per esempio 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.etiger_s5
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 assenza” 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.etiger_s5
state: 'armed_away'
- condition: state
entity_id: alarm_control_panel.etiger_s5
state: 'armed_home'
action:
- service: script.turn_on
entity_id: script.sirena_5
- service: notify.marco
data:
data:
push:
badge: 1
title: Domotica
message: Rilevata presenza fumo! Allarme in corso!
Si noti come, per innescare l’allarme, di fatto lo mandiamo in “panico” usando lo script precedentemente creato, ovvero script.sirena_s5. Non solo questo innescherà l’allarme, ma dato che la centralina risponderà all’innesco con una telemetria radio, anche l’entità alarm_control_panel.etiger_s5 cambierà automaticamente stato in “triggered“.
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:
- service: alarm_control_panel.alarm_arm_away
entity_id: alarm_control_panel.etiger_s5
- 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.etiger_s5
state: 'armed_away'
action:
- service: alarm_control_panel.alarm_disarm
entity_id: alarm_control_panel.etiger_s5
- service: notify.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 🙂
|
⚠️ 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. |