community italiana di domotica personale
 
Integrare un sistema d’allarme eTiger S5 su Home Assistant via radiofrequenza e MQTT

Integrare un sistema d’allarme eTiger S5 su Home Assistant via radiofrequenza e MQTT

13 minuti di lettura
Scopi del PROGETTO:
  • Integrare un sistema d’allarme eTiger S5 a Home Assistant
  • Livello di difficoltà: medio
  • Categoria d’integrazione: Local Push
Concetti affrontati:
  • Configurazione software
Componenti software utilizzate:
Prerequisiti:
Dispositivi fisici utilizzati:
GUIDA maggiormente indicatA per:

Tutti gli ambienti

Note e disclaimer
  • qualsiasi eventuale modifica agli impianti domestici dev'essere progettata ed realizzata SOLO da personale qualificato;
  • qualsiasi modifica attuata in proprio è a propria responsabilità personale nonché a proprio rischio e pericolo (i contenuti della presenta pagina hanno puro scopo didattico);
  • qualsiasi modifica attuata in proprio a un dispositivo ne fa decadere garanzia, omologazioni e certificazioni di qualità.
Revisione progetto: 1.0

eTiger - Home Assistant

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.

DISCLAIMER

Il progetto ha puro scopo didattico: non vengono infatti divulgati codici radiofrequenza reali o funzionanti ma solo la tecnica esemplificativa: i codici specifici appartenenti al proprio impianto, come vedremo, andranno scoperti da sé e tenuti ovviamente privati. Qualsiasi commento al presente progetto contenente codici propri, reali, non verrà pubblicato a tutela dello stesso utente.

Le tecniche descritte, se attuate, non violano in alcun modo il contratto di garanzia del prodotto (in quanto nessuna modifica, di alcun tipo, viene attuata) né riducono il livello di sicurezza (solo il possessore fisico dei radiocomandi, ovvero l’utente finale, può essere a conoscenza dei propri codici).

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

Sonoff RF BridgeIl 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 di presenza 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 presenza 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 presenza 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:

alarm_control_panel:
  - platform: mqtt
    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 web Lovelace UI sia tramite servizi previsti dalla piattaforma che l’ha generata, ovvero “MQTT Alarm Control Panel“.

Home Assistant - eTiger S5 - Alarm Control Panel
il pannello di controllo presso l’interfaccia web.
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:

binary_sensor:
  platform: mqtt
  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: false

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:

binary_sensor:
  platform: mqtt
  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 web Lovelace UI 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 🙂


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

   
Telegram News Channel