Posizione delle persone con Home Assistant

Autore dell'articolo:Henrik Sozzi
Articolo pubblicato:6 Maggio 2021
Categoria dell'articolo:Articoli su Home Assistant / Home Assistant
Commenti dell'articolo:138 commenti
Ultima modifica dell'articolo:12 Febbraio 2023

In questo articolo parleremo della posizione delle persone con Home Assistant: come definire la presenza a casa in modo sicuro e come gestire in modo veloce l’entrata e l’uscita dalle zone configurate.

Home Assistant ci da un ventaglio enorme di possibilità per tracciare la posizione delle persone e sta quindi a noi utilizzare le possibilità giuste per i nostri scopi nel modo migliore.
Lo stesso risultato, infatti, lo possiamo ottenere in modi diversi ma con velocità e affidabilità differenti.

Questo articolo vuole quindi essere una guida per gestire la posizione delle persone con modalità che si sono rivelate molto stabili e attendibili così che ognuno non debba reinventarsi la ruota ma possa partire da una soluzione funzionante, comprendendola e adattandola alle proprie specifiche necessità.

Con le informazioni di questo articolo sarai in grado di sapere chi c’è a casa in modo sicuro, configurare delle notifiche su Alexa e/o su App Home Assistant quando una persona entra o esce da una zona definita (con funzionamento rapido!) e creare gli eventi “ultimo esce da casa” e “primo entra a casa” che ti permetteranno di effettuare azioni automatiche in modo semplice come spegnere tutte le luci, attivare/disattivare l’antifurto, abbassare le tapparelle e tutto quel che hai in mente.

Ogni casa, conformazione, abitudini, esigenze sono differenti dalle altre. Questo non vuole essere una guida “fai così per” bensì spiegare i metodi che uso personalmente capendone il funzionamento così da poterlo adattare alle tue specifiche esigenze.

Se è un argomento che può interessarti allaccia la cintura e partiamo, sono certo che troverai diversi spunti interessanti!

Consiglio caldamente la lettura anche di questo articolo per sapere come configurare al meglio l’app su smartphone e le relative impostazioni del sistema operativo per ottenere una posizione affidabile, sicura e che non consumi la batteria.

Sommario

1 Princìpi di base
2 Tracking diverso per persone diverse
3 Tre package per migliorare notevolmente la rilevazione
4 Conclusione
5 Ti va di darmi una mano?

Princìpi di base

Con Home Assistant abbiamo la possibilità di tracciare non solo lo stato di a casa / non a casa ma anche la presenza nelle zone configurate (è possibile inserirle in Impostazioni -> Zone ) e addirittura la posizione GPS, che potremo tracciare su una mappa.

Mentre la presenza o meno a casa e nelle zone configurate ci sarà utile per le nostre automazioni la posizione GPS può essere un utile alleato per sapere dove sono i componenti della famiglia (che chiaramente devono essere consenzienti a condividervi la loro posizione) ed anche un utile strumento di debug per capire se la posizione di un dispositivo viene acquisita in modo regolare e corretto.

Potremo infine creare delle card di questo tipo utili, oltre che a livello informativo, anche a scopo di debug nel caso qualcosa non sia come ci aspettiamo:

Card di ausilio alla posizione delle persone con Home Assistant

Configuriamo le zone

Come prima cosa configuriamo le zone che ci interesserà tracciare e di cui creare automazioni che interagiscano con la presenza in esse.

Per farlo andiamo in Impostazioni -> Zone e creiamo tutte le zone che ci interessano.

Configurazione delle zone per individuare la posizione delle persone con Home Assistant — Interfaccia di modifica di una zona. Consiglio di non usare un raggio troppo stretto, quando il GPS è al chiuso la precisione cala notevolmente e rischiate che l’app creda di essere uscita dalla zona ripetutamente durante la permanenza.

Acquisiamo lo stato dei dispositivi con device_tracker

In Home Assistant la localizzazione delle persone viene effettuata con sensori nel dominio device_tracker. Di seguito un elenco di quelli che ritengo più interessanti per il nostro scopo:

Home Assistant Mobile AppAVM FRITZ!BoxNmap TrackerPing (ICMP)Life360Tado

L’app ufficiale di Home Assistant è per me il mezzo migliore di rilevare la posizione delle persone, permette l’uso del GPS e imposta automaticamente il geofencing in background delle zone configurate in Home Assistant. Permette la configurazione della frequenza e precisione richieste così che ognuno possa fare fine tuning di tali parametri, se desiderato (io mi trovo bene a default).
Ricordati di disabilitare le ottimizzazioni della batteria e ogni funzione conservativa per evitare che il sistema operativo dello smartphone non permetta l’aggiornamento della posizione in background!
Leggi la documentazione ufficiale

Chi possiede un router Fritz! come me non può non utilizzare questa ottima integrazione! Essa sfrutta infatti la tabella di presenza in rete dei dispositivi che il router Fritz gestisce già internamente per ogni device connesso in wifi o via cavo alla nostra rete. In tal modo facciamo totale offload di questo carico sul router, senza inondare la rete di pacchetti ICMP per sapere chi è presente. Ottima per sapere velocemente quale smartphone è collegato alla rete wifi di casa in modo stabile ed efficiente. Esistono altre integrazioni di router di altre marche ma non avendoli mai testati non posso consigliarli.
Leggi la documentazione ufficiale

Questa integrazione utilizza NMAP, un potente tool esistente per Linux e Windows che effettua una scansione dei dispositivi presenti in rete con possibilità di utilizzare diverse tecniche di rilevazione. Fa il suo dovere ma per come vedo le cose io preferisco usare i dati, se possibile, che il router già mantiene al suo interno. Se non hai un router integrabile, comunque, questa può essere una utile opzione.
Leggi la documentazione ufficiale

Una semplice integrazione che permette di interrogare degli IP noti (sarà quindi necessario avere un IP statico o prenotato con IP fisso tramite DHCP per i dispositivi da tracciare). L’integrazione è leggera e versatile ma per tracciare gli smartphone, in particolare gli iPhone, rischia di non essere adeguata in quanto i telefoni tendono a disattivare temporaneamente il wifi per risparmiare batteria. Resta una strada da provare, comunque.
Leggi la documentazione ufficiale

Questa è l’integrazione che si interfaccia con l’app Life360 presente per Android e iOS che permette di tracciare i componenti della famiglia. Alcuni utenti si trovano meglio con questa app riportandone la precisione.
l contro, a mio avviso, sono di avere un’ulteriore app che effettua operazioni in background riducendo la batteria e il fatto che l’integrazione sfrutta delle API non ufficiali. Life360 potrebbe interromperne il funzionamento in ogni momento.
Ad ogni modo se hai difficoltà con la posizione di Home Assistant questa è una soluzione da provare.
Leggi la documentazione ufficiale

Se utilizzi Tado come sistema di riscaldamento (qui un articolo se ti interessa capire come funziona) hai installato sugli smartphone dei componenti familiari l’app Tado, che effettua la loro geolocalizzazione e lo fa bene. Con questa integrazione puoi quindi utilizzare l’informazione che i server Tado già acquisiscono ma tieni conto dei seguenti limiti: il polling sul cloud di Tado avviene ogni 30 secondi al massimo, puoi rilevare solo l’informazione home / not-home in quanto per ragioni di privacy Tado non condivide la posizione GPS. Può comunque essere una strada percorribile per aumentare la sicurezza della presenza.
Leggi la documentazione ufficiale

Puoi configurare una o più di una delle integrazioni sopra elencate. Ognuna di esse ti potrà fornire tre tipi di stato diversi:

home: quando il dispositivo tracciato viene rilevato come “a casa“
<nome_zona>: quando il dispositivo tracciato viene rilevato come all’interno di una zona configurata in Home Assistant il device_tracker restituirà come stato il nome della zona stessa. Chiaramente questo vale per le integrazioni che usano il GPS come l’app di Home Assistant o Life360.
not_home: quando il dispositivo tracciato risulta non a casa. Per le integrazioni che rilevano il collegamento alla rete di casa come Fritz, Nmap quando il dispositivo non risulta connesso.
Per le integrazioni che fanno uso del GPS come l’app Home Assistant e Life360, invece, quando la posizione risulta fuori dalla zona di casa ma anche fuori dalle zone definite. Ad esempio durante il tragitto tra casa e il lavoro.

Accorpiamo più informazioni nell’entità Person

E’ una buona idea utilizzare più di un device tracker (in questo articolo io utilizzerò Fritz! e Home Assistant Mobile App), ognuno dei quali viene esposto con una propria entità, che può essere in disaccordo con le altre. A venirci in soccorso c’è l’oggetto Person, configurabile in Impostazioni -> Persone in cui possiamo associare ad ogni persona i propri device_tracker che concorrono alla determinazione della sua posizione.

Impostare i device_tracker nell'entità person per acquisire la posizione delle persone con Home Assistant

Ogni persona può infatti avere uno o più device_tracker associati (potenzialmente anche nessuno). In tal modo Home Assistant applicherà dei criteri piuttosto sofisticati per determinare nel migliore dei modi la posizione più probabile della persona, soprattutto quando i tracker non sono in accordo. Consiglio a tal proposito di leggere con attenzione la pagina di documentazione ufficiale che descrive molto bene questo aspetto con un esempio concreto.

Se hai anche un solo device_tracker usa lo stesso l’oggetto Person e crea le tue automazioni su di esso, non direttamente sul device_tracker!
Potrebbe sembrarti superfluo ma in questo modo disaccoppi il concetto di “persona” da quello di “dispositivi della persona”. Come conseguenza se cambierai o aggiungerai modalità di tracciamento ti basterà modificare i tracker della persona e le tue automazioni continueranno a funzionare senza alcuna modifica.

Gli oggetti person possono quindi assumere lo stato di home, not_home e <nome_zona> esattamente come i device_tracker, solo che lo stato è determinato dall’aggiornamento migliore/più recente.

Nota: l’oggetto person, fortunatamente, è molto conservativo nel determinare lo stato di home. Se quindi anche uno solo dei sensori risulta home l’oggetto person sarà esso stesso home. Questo è utilissimo perchè se mentre siamo a casa il GPS avesse una posizione molto imprecisa perchè siamo all’interno della casa e credesse di trovarsi fuori casa, ci sarebbe sempre l’integrazione locale (del router o NMAP/ping) a ricordare all’oggetto person che in realtà noi siamo a casa.

Poco più avanti aggiungeremo anche un terzo device tracker per velocizzare i cambi di zona in alcuni frangenti.

Tracking diverso per persone diverse

Non necessariamente per tutte le persone dobbiamo utilizzare le stesse tipologie di device_tracker. Nella mia configurazione, ad esempio, ho due categorie di persone: quelle appartenenti alla mia famiglia che hanno installato l’app Home Assistant e quelle che possono venire a casa mia ed ha senso tracciarne la presenza.

Nel primo caso, per i componenti della famiglia, traccio la posizione GPS, le zone e la presenza o meno a casa (vedremo meglio in seguito come).

Per tutti gli altri, invece, mi limito a tracciarne il fatto che il loro smartphone sia collegato alla mia rete wifi. In questo modo basta che abbiano con sé il telefono per far sapere al mio Home Assistant che sono a casa mia.

Per esempio gestisco la presenza della nonna quando io e mia moglie non ci siamo per configurarlo lo stato del riscaldamento automaticamente. O ancora gestisco anche la presenza della nonna per l’attivazione / disattivazione automatica dell’antifurto.

Attenzione! Per rispettare la privacy è necessario avere un esplicito consenso delle persone tracciate indicando loro lo scopo del tracciamento, le esatte modalità, dove risiedono i dati tracciati e chi è il responsabile della privacy. Bisogna anche essere pronti a rimuovere un tracciamento qualora la persona lo richieda.

Tre package per migliorare notevolmente la rilevazione

Compresi i concetti di base passerò ora a descrivere tre dei package che ho creato per migliorare sensibilmente la velocità e la precisione delle rilevazioni.

DOWNLOAD packages

Il file che hai appena scaricato persone-base-packages-v2.zip contiene una cartella Persone da scompattare all’interno della tua cartella packages, così da ottenere una struttura come questa:

Struttura dei packages di questo articolo per acquisire la posizione delle persone con Home Assistant

Ricordo che non sono packages che puoi copiare e sei pronto ma andranno adattati alle tue specifiche esigenze. Servono per illustrare un metodo e imparare magari delle cose lungo il percorso.
Se te lo stai chiedendo, inoltre, gli altri packages dello screenshot li discuteremo in un altro articolo 😉

Per comprendere i packages e adattarli alle tue esigenze è bene che tu capisca com’è la mia configurazione.
In questi packages sono coinvolte tre entità person:

person.henrik: sono io, tracciato dall’app e da Fritz e dal wifi (vedi in seguito)
person.antonella: mia moglie, tracciata dall’app e da Fritz e dal wifi (vedi in seguito)
person.ankie mia mamma, tracciata solo da Fritz

Io lavoro nella zona chiamata ufficio, mia moglie lavora nella zona chiamata negozio. Dal lockdown ho iniziato a tornare a casa a pranzo, prima andavo a mangiare in un locale vicino, per questo c’è una configurazione apposita per escludere o meno la possibilità.

Per le notifiche utilizzo lo script multinotify che permette di inviare notifiche alle app e ad Alexa contemporaneamente, oltre che gestire diversi comodi aspetti come un volume notifica separato.
Se non lo conosci ti consiglio caldamente il seguente articolo: Multinotify: il package per le notifiche su Alexa e App

Passiamo ora alla descrizione dei tre package così da capirne i concetti che ne stanno alla base.

Package wifi.yaml: rendiamo istantaneo il passaggio tra zone

Ora che abbiamo configurato i nostri oggetti person e le zone che ci interessa tracciare (come il luogo di lavoro dei componenti familiari, i genitori / suoceri ed ogni luogo che vogliamo utilizzare come identificazione dello stato al fine di farne delle automazioni) possiamo procedere a creare delle automazioni al passaggio dentro e fuori le zone. C’è un “però”…

La prima cosa di cui ci accorgeremmo, infatti, è che le automazioni al cambio stato delle entità person (e uguale sarebbe usando i device_tracker) risultano a volte in ritardo rispetto alle aspettative. Questo perchè l’app non interroga la posizione GPS di continuo per risparmiare batteria e dovrà quindi avere il tempo di “accorgersi” che si è entrati o usciti da una determinata zona.

Tanto lavoro è stato fatto sul geofencing delle app da quando avevo steso questo articolo originalmente e devo dire che il tracker GPS dell’app companion, almeno su Android, funziona ora piuttosto bene. Molto dipende però dallo smartphone e dalle personalizzazioni del suo produttore che possono modificare piuttosto considerevolmente la velocità di aggiornamento / refresh della posizione GPS.

Possiamo però usare un trucchetto per velocizzare parecchio questi passaggi: sfruttare il collegamento a un SSID specifico di quella zona. L’app invia infatti in modo quasi immediato le connessioni o disconnessioni dalle reti Wifi.

Per attivare questo sensore andare dal’app premendo sull’hamburger menu , Configurazioni -> App complementare -> Gestione dei sensori -> sezione Sensori di rete e abilitiamo il sensore Connessione WiFi. Questa operazione creerà un sensore il cui stato sarà l’SSID (il nome della rete wifi) a cui il telefono è collegato oppure <not connected> se non collegato ad alcuna rete WiFi.

Per fare un esempio in ufficio ho uno specifico SSID wifi. Quando arrivo in ufficio il mio telefono si connette all’access point ancor prima che sia entrato dalla porta d’ingresso. Mentre il GPS deve ancora aggiornarsi il telefono informa la mia istanza di Home Assistant che si è collegato a quella specifica rete WiFi e uso questa opportunità per impostare lo stato del device_tracker alla zona dell’ufficio.
Stesso discorso all’uscita: il telefono si scollegherà dal WiFi ben prima che il GPS se ne accorga. E anche in questo caso sfrutto questo evento per impostare lo stato del device_tracker a not_home prima che lo faccia il GPS.

Sebbene usare il wifi può velocizzare la rilevazione dei cambi zona, in particolare delle zone esterne a casa e del rientro all’abitazione, c’è anche un contro. Limitatamente a quando siamo fuori casa, se spegniamo il wifi del telefono, viene spento/riavviato l’access point della zona in cui siamo o ci spostiamo fuori portata wifi, il tracker passerà a not_home, facendo scattare le automazioni di uscita dalla zona. Valuta bene se questa soluzione può essere adatta alle tue abitudini ed eventualmente escludila dalle zone dove potrebbe non funzionare bene. Nei miei casi d’uso ne sono davvero soddisfatto.
(quando sei a casa, invece, l’oggetto person non cambia da home finché un sensore, specialmente quello del router, rimane su home)

Come funziona l’impostazione del device_tracker in base all’SSID

Analizzando il package wifi.yaml scaricato precedentemente ci accorgiamo che è composto da una sola automazione che gestisce tutti i tracker e tutte le reti wifi che vogliamo gestire. Di seguito l’automazione che poi andiamo ad analizzare per capirne il funzionamento ed adattarla alla tua configurazione. Gli SSID e le zone sono inventati a scopo didattico.

automation:
  # Rilevazione della zona in base all'SSID a cui è collegato lo smartphone
  - id: 48d481d3-9051-443b-a8ea-3e698f99f560
    alias: Tracker - Wifi - Telefoni
    trace:
      stored_traces: 20
    trigger:
      - platform: state
        entity_id: 
          - sensor.tel_henrik_wifi
          - sensor.tel_anto_wifi
          - sensor.tel_erica_wifi_connection
        to:
    action:
      - variables:
          tracker: "{{ trigger.from_state.object_id }}"
          zona: >
            {% set zone =
              [
                {'ssid': '<not connected>', 'zona': 'not_home'},
                {'ssid': 'ssid-casa',          'zona': 'home'},
                {'ssid': 'ssid-guests',   'zona': 'home'},
                {'ssid': 'altro-ssid',    'zona': 'negozio'},
                {'ssid': 'ssid-ufficio',   'zona': 'ufficio'},
                {'ssid': 'ssid-ufficio-guests', 'zona': 'ufficio'},
                {'ssid': 'ssid-casa-amici', 'zona': 'mariorossi'},
                {'ssid': 'ssid-casa-amici-5g',   'zona': 'mariorossi'},
                {'ssid': 'ssid-suocera',       'zona': 'suocera'},
                {'ssid': 'ssid-nonni',       'zona': 'nonni'}
              ]
            %}
            {{zone | selectattr('ssid', 'eq', trigger.to_state.state) | map(attribute='zona') | first | default('not_home')}}
      - alias: "Imposta la zona"
        service: device_tracker.see
        data:
          dev_id: "{{tracker}}"
          location_name: "{{zona}}"

Analizziamo pezzo per pezzo l’automazione per capirne il funzionamento.

    trace:
      stored_traces: 20

Tramite questo semplice attributo indichiamo ad Home Assistant di conservare le ultime 20 tracce di esecuzione dell’automazione, che possono venirci estremamente utili per effettuare il debug dell’entrata/uscita dalle zone.

    trigger:
      - platform: state
        entity_id: 
          - sensor.tel_henrik_wifi
          - sensor.tel_anto_wifi
          - sensor.tel_erica_wifi_connection
        to:

Nel trigger indichiamo ad Home Assistant tutti i sensori wifi degli smartphone che abbiamo attivato precedentemente e to: così che l’automazione venga eseguita ogni volta che lo stato di uno di questi sensori cambi.

    action:
      - variables:
          tracker: "{{ trigger.from_state.object_id }}"

Nella prima azione impostiamo delle variabili che useremo in seguito. La prima, chiamata tracker, conterrà l’object_id dell’entità che ha fatto scattare l’automazione. L’oggetto speciale trigger, infatti, rappresenta il trigger che ha fatto scattare l’automazione tra tutti quelli configurati e ci permette di acquisirne lo stato precedente, successivo al trigger e, chiaramente, i dati identificativi come entity_id (per esempio sensor.tel_henrik_wifi) o object_id (nell’esempio precedente sarebbe tel_henrik_wifi)

          zona: >
            {% set zone =
              [
                {'ssid': '<not connected>',     'zona': 'not_home'},
                {'ssid': 'ssid-casa',           'zona': 'home'},
                {'ssid': 'ssid-guests',         'zona': 'home'},
                {'ssid': 'altro-ssid',          'zona': 'negozio'},
                {'ssid': 'ssid-ufficio',        'zona': 'ufficio'},
                {'ssid': 'ssid-ufficio-guests', 'zona': 'ufficio'},
                {'ssid': 'ssid-casa-amici',     'zona': 'mariorossi'},
                {'ssid': 'ssid-casa-amici-5g',  'zona': 'mariorossi'},
                {'ssid': 'ssid-suocera',        'zona': 'suocera'},
                {'ssid': 'ssid-nonni',          'zona': 'nonni'}
              ]
            %}
            {{zone | selectattr('ssid', 'eq', trigger.to_state.state) | map(attribute='zona') | first | default('not_home')}}

L’assegnazione della variabile zona è il cuore dell’automazione. Tramite template, infatti, dichiariamo un array di dizionari da assegnare alla variabile interna zone. In ogni record dell’array delimitato da [], infatti, dichiariamo un dizionario delimitato da {} che dichiara l’attributo ssid (che definisce il nome della rete che vogliamo gestire) e l’attributo zona che definisce il nome della zona che vogliamo attribuire a quello specifico nome rete wifi.
Sostituisci quindi i tuoi SSID che vuoi gestire con i nomi delle zone che hai definito in Home Assistant.

Un grazie a Massimiliano Albani che mi ha introdotto agli array di dizionari. Metodo preziosissimo per automazioni che possono gestire dati variabili senza dover creare automazioni multiple.

L’ultima riga è la selezione effettiva che restituisce il nome della zona a partire dall’array di dizionari definita e dallo stato del sensore che ha fatto scattare il trigger.

Seguiamone il flusso:

zone è l’array di dizionari
tramite pipe | lo diamo in pasto alla funzione selectattr('ssid', 'eq', trigger.to_state.state) che seleziona il record avente l’attributo ssid uguale (eq sta per equal) al valore dello stato dell’entità che ha fatto scattare il trigger (trigger.to_state.state). Il risultato è un array dei dizionari che rispettano la condizione specificata.
tramite pipe | processiamo il risultato con map(attribute='zona') che estrae dai dizionari di ogni record il solo attributo zona restituendo un array di stringhe contenenti le zone dei record filtrati precedentemente.
tramite pipe | processiamo quindi l’array precedente con first che ci restituirà la sola stringa corrispondente al primo record dell’array in ingresso (la selezione restituisce un record solo ma selectattr restituisce un array quindi per avere un valore singolo è necessario prendere un solo elemento con first)
infine tramite ancora pipe | processiamo il risultato con default('not_home') così che se il dato in arrivo è nullo restituiamo il valore not_home che corrisponde a quando non siamo né a casa né in una zona definita. Quando questo può accadere? Quando siamo connessi ad una rete wifi avente SSID non definito nell’elenco precedente!

      - alias: "Imposta la zona"
        service: device_tracker.see
        data:
          dev_id: "{{tracker}}"
          location_name: "{{zona}}"

Definiti i valori delle due variabili spiegate sopra non ci resta che effettuare la magia. Con il servizio device_tracker.see, infatti, possiamo impostare un device_tracker (se non esiste lo crea!) avente entity_id device_tracker.QUEL_CHE_PASSIAMO_A_DEV_ID e come stato quel che passiamo a location_name.

A dev_id passiamo il valore della variabile tracker, definita al principio, contenente l’object_id del sensore, ad esempio sensor.tel_henrik_wifi corrispondente a tel_henrik_wifi che quindi creerà o aggiornerà l’entità device_tracker.tel_henrik_wifi avente lo stato passato a location_name.

Le entità create con device_tracker.see saranno visibili al primo cambio di rete wifi del dispositivo e non esisteranno, pertanto, prima che questa operazione avvenga. Per forzarla al momento si può disattivare il wifi del telefono per impostare lo stato del sensore a <not connected>

Aggiungere i device_tracker wifi ognuno al relativo oggetto person di appartenenza

Una volta creati i device_tracker wifi come spiegato nel capitolo precedente dobbiamo modificare gli oggetti person relativi ad ognuno di essi ed includere tali device_tracker in essi come spiegato nel capitolo relativo.

In tal modo sarà la logica presente in Home Assistant ad accorpare le informazioni derivanti da GPS, device_tracker locale (quale Fritz) e device_tracker wifi nel migliore dei modi, valutando qual è l’informazione più aggiornata tra quelle presenti, quando discordi, e aggiornando lo stato dell’oggetto person di conseguenza. Vedrai che tale logica farà un buon lavoro e genererà un risultato affidabile.

Nell’immagine che segue ti mostro un esempio reale del mio sistema che mette a confronto la posizione (a partire dall’alto) dei seguenti elementi:

Oggetto person
Posizione del device_tracker dell’app companion
device_tracker di FritzBox che determina la connessione alla rete di casa
device tracker wifi come creato precedentemente
sensore SSID usato dal device_tracker wifi a scopo di controllo
source, attributo dell’oggeto person che determina da cosa Home Assistant sta prendendo la posizione

Rilevazione posizione delle varie entità definite nell'oggetto person di Home Assistant

Possiamo notare come in diverse occasioni la connessione o sconnessione alla rete wifi abbia impostato una posizione che altrimenti non avremmo potuto avere.

Package auto_detect.yaml

In questo package ci sono varie utilità. Vediamole insieme pezzo per pezzo.

Rilevare la prima persona che si alza la mattina

input_boolean:
  primo_sceso_scale_today:
    name: La prima persona è scesa dalle scale oggi?

automation:
# Primo che scende le scale della giornata
  - id: 47182d5e-8f95-43f2-9503-fca9dd5fcd3c
    alias: Persone - Evento - Primo che scende le scale della giornata
    description: Chiama l'evento quando il primo scende le scale della giornata (presumibilmente la mattina)
    trigger:
      - platform: state
        entity_id: binary_sensor.motion_soggiorno
        to: 'on'
      - platform: state
        entity_id: binary_sensor.motion_cucina
        to: 'on'
    condition:
      - condition: state
        entity_id: input_boolean.primo_sceso_scale_today
        state: 'off'
    action:
      - alias: "Imposto flag primo_sceso_scale_today"
        service: input_boolean.turn_on
        target:
          entity_id: input_boolean.primo_sceso_scale_today
      - event: primo_sceso_scale

  # Alle 6:20 di mattina resetta lo stato di "primo sceso dalle scale oggi", così alla mattina scatta di nuovo scendendo le scale
  - id: d617f7ff-28eb-4255-9926-b8ead30700b7
    alias: 'Persone - Logica - Reset flag primo sceso dalle scale oggi'
    trigger:
      - platform: time
        at: '06:20:00'
    action:
      - service: input_boolean.turn_off
        target:
          entity_id: input_boolean.primo_sceso_scale_today

Questa automazione, che ha poco a che fare con la posizione, può essere però di ispirazione per diversi utilizzi uguali o simili.

In sostanza, avendo casa su più piani e la zona notte è al primo piano, determino il momento in cui il primo componente della famiglia scende a pian terreno dopo la notte. In quel momento genero l’evento primo_sceso_scale che uso in diverse automazioni definite in altri package: un briefing di Alexa che dà il buongiorno, fa gli auguri se è il compleanno di qualcuno, se fuori c’è luce del sole alza le tapparelle e mette musica di sottofondo (a seconda di vari parametri).

Alle 6:20 di mattina resetto lo stato di “primo sceso dalle scale” così che l’automazione sopra sia pronta a scattare quando il PIR a pian terreno rileva la presenza di qualcuno.

Sensori più esteticamente gradevoli da mettere in UI

binary_sensor:
  - platform: template
    sensors:
      # Stato di "a casa" di Henrik basato sul suo oggetto Person
      # un falso "non a casa" dovuto ad un bounce della presenza dell'entità person. L'arrivo a casa è immediato tanto quanto la rilevazione di Fritz,
      # mentre l'uscita necessita che sia Fritz che il sensore dell'app, ritardato 10 minuti, concordino nello stato di "non a casa"
      henrik_at_home:
        friendly_name: "Henrik a casa?"
        unique_id: "henrik_at_home"
        device_class: presence
        value_template: "{{ is_state('person.henrik_sozzi', 'home')}}"
        entity_picture_template: "/local/henrik{% if not(is_state('person.henrik_sozzi', 'home')) %}_off{% endif %}.jpg"

Questi sensori binari (sopra ne è riportato uno solo sui tre definiti in quanto il principio di funzionamento è identico) servono per utilizzare l’informazione di persona a casa nell’interfaccia utente in quanto creano un sensore di presenza con stato on / off (a casa, fuori casa), con immagine henrik.jpg quando a casa e henrik_off.jpg quando fuori casa. Tramite un software di fotoritocco ho generato la seconda immagine modificando la prima in bianco e nero e schiarendola un po’, così che sia evidente anche graficamente lo stato di ogni persona.

L’impostazione di device_class al valore presence permette ad Home Assistant di sapere che lo stato di on e off si riferiscono alla presenza nominando tale valore in modo opportuno.

Questi sensori sono pratici da inserire nelle card o nei badge delle viste, ottenendo un risultato come questo:

Posizione delle persone con Home Assistant tramite l'utilizzo di badge con i sensori creati

Quale device_tracker sta determinando la posizione dell’oggetto person?

template:
  - sensor:
      # Sensori person_NAME_source che determinano nel tempo quale sorgente viene usata dall'oggetto person per determinare la posizione
      - name: Person Henrik Source
        unique_id: 8693c26f-d00d-493b-b129-f79a03d97deb
        state: "{{ state_attr('person.henrik_sozzi', 'source')[15:] }}"

Anche in questo caso riporto uno solo dei sensori template in quanto gli altri funzionano allo stesso modo. Le entità create (sensor.person_henrik_source nel codice sopra) contengono il valore dell’attributo source dell’oggetto person, che contiene il nome del device_tracker usato per determinare la posizione dell’oggetto person. Il codice [15:0] serve a prelevare da tale valore dal quindicesimo carattere così da saltare il dominio del sensore. In tal modo il valore restituito è più compatto e sarà, per esempio, tel_henrik_wifi e non device_tracker.tel_henrik_wifi.

Questo sensore è usato nella vista grafica dello stato dei device_tracker mostrata al termine del capitolo riguardante il tracker wifi.

Switch per impostare lo stato della posizione ad alta accuratezza dell’app

switch:
  - platform: template
    switches:
      # Swtich tel_NOME_hq_gps per rilevare e modificare lo stato di alta qualità nella rilevazione della posizione dei telefoni
      tel_henrik_hq_gps:
        friendly_name: Tel Henrik HQ GPS
        unique_id: e67c8229-65f9-40b1-9f6c-c8c983ccb69d
        value_template: "{{ is_state('binary_sensor.tel_henrik_high_accuracy_mode', 'on') }}"
        availability_template: "{{ states.binary_sensor.tel_henrik_high_accuracy_mode.state is defined }}"
        turn_on:
          service: notify.mobile_app_tel_henrik
          data:
            message: "command_high_accuracy_mode"
            title: "turn_on"
        turn_off:
          service: notify.mobile_app_tel_henrik
          data:
            message: "command_high_accuracy_mode"
            title: "turn_off"

Di nuovo questo è uno degli switch dichiarati per ogni persona, tutti funzionano allo stesso modo.

Questi switch permettono, inserendoli in interfaccia grafica, di mostrare se la posizione dell’app della persona sta usando la posizione di alta accuratezza oppure quella normale. Premendo è possibile inoltre impostarne lo stato così da specificare in casi particolari se si desidera una posizione più precisa.

Il comportamento di questo switch è molto bizzarro in quanto quando ci clicchiamo per cambiarne stato il suo stato torna graficamente immediatamente quello che aveva prima ma il comando è stato inviato. Quando finalmente l’app l’avrà presa in considerazione lo stato dello switch tornerà nello stato che abbiamo impostato.
Ricorda anche che attivando la posizione ad alta accuratezza il consumo della batteria sarà più elevato.

Definizione del gruppo “Qualcuno è a casa?”

group:
  # Gruppo per determinare se qualcuno è a casa (contiene solo i telefoni che certamente non sono lasciati a casa)
  anyone_at_home:
    name: Qualcuno è a casa?
    entities:
      - binary_sensor.henrik_at_home
      - binary_sensor.antonella_at_home
      - binary_sensor.ankie_at_home

Questo è un semplice gruppo che contiene tutti i binary sensor dichiarati sopra relativi a tutti i telefoni tenuti sempre con sè. Attenzione a ragionare bene su quali dispositivi includere: lo smartphone di mia figlia, ad esempio, non l’ho incluso in quanto quando lei è a scuola il telefono è a casa (e farebbe risultare qualcuno a casa, se incluso nel gruppo).

Questo gruppo può poi essere utilizzato per qualunque tipo di automazione in altri package, ad esempio per modificare la temperatura delle zone di casa quando qualcuno rientra e viceversa abbassarle quando non c’è nessuno a casa.

Il suo stato, infatti, diventa on se lo stato di almeno una qualsiasi delle entità definite è on.

Generiamo eventi “ultimo esce da casa” e “primo entra a casa”

automation:
  # Chiama l'evento uscita ultimo da casa
  - id: 86680100-fb55-4867-9f24-e8133ccc74e4
    alias: Persone - Evento - Generazione - Uscita ultimo da casa
    description: Chiama l'evento uscita ultimo da casa
    trigger:
      - platform: state
        entity_id: group.anyone_at_home
        to: 'off'
    action:
      - event: uscita_ultimo_da_casa

  # Chiama l'evento arrivo del primo a casa
  - id: cd3842d0-39d6-45a9-8f0c-6d18852e32fa
    alias: Persone - Evento - Rientro del primo a casa
    description: Chiama l'evento rientro del primo a casa
    trigger:
      - platform: state
        entity_id: group.anyone_at_home
        to: 'on'
    action:
      - event: arrivo_primo_a_casa

Queste due automazioni generano gli eventi uscita_ultimo_da_casa e arrivo_primo_a_casa.
Tali eventi possono essere utilizzati da qualunque altro package per effettuare delle automazioni in questi due specifici casi, ovvero quando l’ultima persona esce da casa (lasciandola quindi vuota) e quando il primo rientra a casa.
Pensiamo ad esempio allo spegnimento delle luci in modo automatico quando tutti sono fuori casa. O all’inserimento / disinserimento automatico dell’antifurto. O ancora ad alzare / abbassare le tapparelle in modo automatico.

Gestire tutti questi casi con trigger basati su questi eventi ci permette di tenere separati i package di luci, antifurto e tapparelle da questo e utilizzare un evento che ha una specifica logica definita una volta sola.

Altro vantaggio è rendere molto chiara e comprensibile la condizione di attivazione del trigger in altri package sulla base delle logiche definite qui. uscita_ultimo_da_casa, infatti, è auto esplicativo.

Se in futuro volessimo modificare la logica di definizione di “a casa” o il numero delle persone gestite sarà sufficiente modificare questo package e tutti gli altri che fanno uso di questi eventi non dovranno essere modificati! Un bel vantaggio!
Consiglio questo approccio a livello generale dove abbia senso creare degli eventi logici disgiunti dalle automazioni sottostanti.

Un aiuto dalla telecamera per rilevare lo stato di “a casa” prima di arrivare alla porta

automation:
  # Quando rilevo movimento dalla telecamera frontale forzo una rilevazione della posizione GPS delle app di chi non risulta a casa
  # (perchè potrebbe essere lui/lei che sta entrando. Così facendo l'app rileverà la posizione prima di arrivare alla porta di casa)
  - id: 18b09f9d-7d52-4d09-9d8a-42d789ffcc80
    alias: "Persone - Logica - Forzo rilevazione GPS quando movimento da cam front"
    trigger:
      - platform: state
        entity_id: binary_sensor.front_cam_motion
        from: "off"
        to: "on"
    action:
      - alias: "Se Henrik non è a casa forza un rilevamento GPS"
        choose:
        - conditions:
            - condition: not
              conditions:
                - alias: "Henrik è a casa?"
                  condition: state
                  entity_id: person.henrik_sozzi
                  state: "home"
          sequence:
            - service: notify.mobile_app_tel_henrik
              data:
                message: "request_location_update"
      - alias: "Se Antonella non è a casa forza un rilevamento GPS"
        choose:
        - conditions:
            - condition: not
              conditions:
                - alias: "Antonella è a casa?"
                  condition: state
                  entity_id: person.antonella
                  state: "home"
          sequence:
            - service: notify.mobile_app_smartphone_antonella
              data:
                message: "request_location_update"

Ultima automazione definita in questo package è un helper che funziona abbastanza bene nel mio caso.

Quel che fa, in sostanza, è forzare una rilevazione della posizione delle persone che non risultano a casa (e che possono far cambiare lo stato di group.anyone_at_home definito sopra) quando viene rilevato un movimento dalla telecamera che inquadra il mio vialetto di ingresso.

In tal modo, se l’app companion non ha ancora rilevato il rientro a casa prima di entrare dal cancello di casa, sarà il movimento della telecamera ad imporre un refresh della posizione a chi non risulta a casa, facilitando la possibilità di essere rilevato a casa PRIMA di arrivare alla porta di ingresso di casa.

Chiaramente è una condizione particolare che può andar bene solo se hai una abitazione indipendente come la mia ma è un concetto che può essere utilizzato a più ampio spettro.

Perchè questa accortezza? Perchè quando una persona rientra a casa l’antifurto viene automaticamente disinserito, le tapparelle (se fuori c’è luce), si accende la luce frontale di casa e quando apriamo la porta di casa Alexa ci saluta per nome e accende la luce dell’ingresso, mettendo poi una musica di sottofondo (e facendoci gli auguri se è il compleanno di chi sta entrando).

E’ quindi importante fare il possibile affinchè lo stato di “a casa” venga rilevato a tutti i costi prima di entrare in casa. E posso dire che tra rilevazione tramite wifi, come spiegato sopra, app companion e questa accortezza il 99,9% delle volte funziona senza problemi.

Package zone_notify.yaml: notifiche all’arrivo / rientro dal lavoro

L’ultimo package che prendiamo in esame gestisce le notifiche tramite Alexa e app (sempre tramite multinotify) quando un componente della famiglia arriva o esce dal lavoro.

Magari ad alcuni può sembrare una violazione della privacy ma io e mia moglie le troviamo molto comode in quanto chi di noi è a casa riesce ad organizzarsi meglio con i tempi di preparazione pranzo / cena e gestione delle bambine. Se si è tutti d’accordo (e non c’è niente da nascondere 😉 ) credetemi che è una bella comodità. Inoltre abbiamo dei super device_tracker potenziati con il wifi, perchè non sfruttarli?!

Il primo blocco definisce due input_boolean:

input_boolean:
  notifiche_lavoro:
    name: Notifiche and/rit lavoro
    icon: mdi:briefcase-outline
  henrik_ritorno_a_pranzo:
    name: Henrik ritorna a casa a pranzo
    icon: mdi:pasta

notifiche_lavoro è pensato per essere inserito nell’interfaccia grafica e poter quindi abilitare o disabilitare tutte le notifiche di questo package.

henrik_ritorna_a_pranzo è anch’esso pensato da inserire in una card e serve per determinare se io rientro a pranzo oppure no (prima della pandemia difficilmente rientravo a pranzo ma con i ristoranti chiusi ho iniziato a farlo e lascio quindi questo flag impostato, attivando la notifica del rientro al pranzo).

L’automazione di rientro dal lavoro (variante semplice)

Iniziamo con analizzare l’automazione più semplice: quella di mia moglie che esce dal negozio (l’altra di mia moglie ha lo stesso principio):

automation:
  - id: 489203b7-4720-4e73-8801-e130c889dfe9
    alias: "Persone - Notifica - Antonella esce dal negozio"
    description: "Avvisa tramite Alexa quando Anto esce dal negozio"
    trigger:
      - entity_id: person.antonella
        from: Negozio
        platform: state
    condition:
      - condition: template
        value_template: "{{ (as_timestamp(now()) - as_timestamp(state_attr('automation.persone_notifica_antonella_arriva_in_negozio', 'last_triggered') | default(0)) | int > 1800)}}"  
      - condition: template
        value_template: "{{ (as_timestamp(now()) - as_timestamp(state_attr('automation.persone_notifica_antonella_esce_dal_negozio', 'last_triggered') | default(0)) | int > 1800)}}"  
      - condition: state
        entity_id: input_boolean.notifiche_lavoro
        state: 'on'
    action:
      - service: script.multinotify
        data:
          title: Antonella sta tornando
          message: Antonella è uscita dal negozio!
          alexa_message: '<say-as interpret-as="interjection">yippii</say-as>. La mamma è uscita dal negozio!'
          alexa_target: media_player.ovunque
          notify_app: notify.all_devices
          channel: people-fromwork
          group: people
          tag: "{{trigger.to_state.name}} home"

Partiamo dal trigger: sull’oggetto person di mia moglie quando lo stato passa da Negozio a qualunque altra cosa.

Ci sono tre condizioni. L’ultima è quella più semplice: se le notifiche di questo tipo sono attivate tramite l’input_boolean configurato all’inizio.
Le prima due, invece, sono due template che permettono l’esecuzione dell’automazione solo se il tempo trascorso dall’ultima volta che questa o l’automazione di arrivo in negozio di mia moglie è più di 1800 secondi (mezz’ora).

Ricorda questo “trucchetto” che puoi usare in molti altri contesti dove non vuoi che un’automazione venga attivata più volte di seguito in un lasso temporale a scelta. Sfruttiamo l’attributo last_triggered che restituisce la data/ora dell’ultima volta che l’automazione è stata valutata, ovvero in cui un trigger è scattato. Prendiamo la data/ora corrente now() , l’attributo last_triggered, li trasformiamo in timestamp e sottraendo il secondo dal primo otterremo il numero di secondi trascorsi.

Questo evita i possibili bounce di stato possibili per diverse ragioni o ad esmepio che l’automazione riscatti se di ritorna indietro a prendere una cosa dimenticata e si esce di nuovo.

Nell’action richiamiamo lo script multinotify usando un testo per l’app e uno con una interiezione da far pronunciare a tutti i dispositivi Alexa di casa ed inviare a tutte le app.

L’automazione di rientro dal lavoro (variante più complessa)

Vediamo ora l’automazione che notifica il rientro a casa della mia persona, con qualche condizione in più che può risultare utile anche a te:

automation:
  # Arrivo al lavoro / rientro dal lavoro
  - id: 49f72ed4-1b6c-4729-baf9-edaa86fd072f
    alias: "Persone - Notifica - Henrik ritorna dal lavoro"
    description: "Quando Henrik esce dalla zona lavoro dopo le ore 19:00 annuncia il ritorno a casa con Alexa"
    trigger:
      - entity_id: person.henrik_sozzi
        from: Ufficio
        platform: state
    condition:
      - condition: template
        value_template: "{{ (as_timestamp(now()) - as_timestamp(state_attr('automation.persone_notifica_henrik_ritorna_dal_lavoro', 'last_triggered') | default(0)) | int > 1800)}}"  
      - condition: state
        entity_id: input_boolean.notifiche_lavoro
        state: 'on'
      - condition: or
        conditions:
          - condition: time
            after: '19:00:00'
            before: '22:00:00'
            weekday:
              - mon
              - tue
              - wed
              - thu
              - fri
          - condition: and
            conditions:
              - condition: state
                entity_id: input_boolean.henrik_ritorno_a_pranzo
                state: 'on'
              - condition: time
                after: '11:40:00'
                before: '14:00:00'
                weekday:
                  - mon
                  - tue
                  - wed
                  - thu
                  - fri
    action:
      - service: script.multinotify
        data:
          title: "Henrik sta tornando"
          message: "Henrik sta tornando dall'ufficio!"
          alexa_message: '<say-as interpret-as="interjection">yippii</say-as>. Papà sta tornando dall ufficio!'
          alexa_target: media_player.ovunque
          notify_app: notify.all_devices
          channel: people-fromwork
          group: people
          tag: "{{trigger.to_state.name}} home"

La sostanza è uguale alla precedente ma in più ha delle finestre temporali espresse nelle condizioni così riassumibili:

Se esco dal lavoro dal lunedì al venerdì tra le 19:00 e le 22:00 oppure
Se esco dal lavoro dal lunedi al venerdi tra le 11:40 e le 14:00 e l'input_boolean henrik_ritorno_a_pranzo è on

Questo perchè a me capita di uscire dal lavoro durante la giornata per interventi presso clienti o commissioni, in questo modo mi assicuro che l’orario sia uno di quelli dove rientro a casa.

Una notifica generica ogni volta che una persona monitorata entra o esce da casa

  # Qualcuno arriva a casa o parte da casa
  - id: 0bb4febe-f9b1-445c-9b27-ac9793c4a617
    alias: "Persone - Notifica - Qualcuno arriva o parte da casa"
    trigger:
      # To: home
      - platform: state
        entity_id: person.henrik_sozzi
        to: "home"
      - platform: state
        entity_id: person.antonella
        to: "home"
      - platform: state
        entity_id: person.erica
        to: "home"
      - platform: state
        entity_id: person.angelo
        to: "home"
      - platform: state
        entity_id: person.ankie
        to: "home"
      - platform: state
        entity_id: person.anna
        to: "home"
      - platform: state
        entity_id: person.giuseppe
        to: "home"
      - platform: state
        entity_id: person.paola
        to: "home"
      # From: home
      - platform: state
        entity_id: person.henrik_sozzi
        from: "home"
      - platform: state
        entity_id: person.antonella
        from: "home"
      - platform: state
        entity_id: person.erica
        from: "home"
      - platform: state
        entity_id: person.angelo
        from: "home"
      - platform: state
        entity_id: person.ankie
        from: "home"
      - platform: state
        entity_id: person.anna
        from: "home"
      - platform: state
        entity_id: person.giuseppe
        from: "home"
      - platform: state
        entity_id: person.paola
        from: "home"
    action:
      - service: script.multinotify
        data:
          notify_app: notify.mobile_app_tel_henrik
          title: >
            {% if trigger.to_state.state == 'home' %}
              {{trigger.to_state.name}} è a casa
            {% else %}
              {{trigger.to_state.name}} non è più a casa
            {% endif %}
          message: >
            {% if trigger.to_state.state == 'home' %}
              {{trigger.to_state.name}} è ora entrato/a a casa
            {% else %}
              {{trigger.to_state.name}} è ora uscito/a da casa
            {% endif %}
          channel: >
            {% if trigger.to_state.state == 'home' %}
              people-tohome
            {% else %}
              people-fromhome
            {% endif %}
          group: people
          tag: "{{trigger.to_state.name}} home"

Con questa automazione, che ha come trigger il passaggio da home a qualunque altro valore o da qualunque altro valore ad home delle persone monitorate (tramite app o anche solo tramite device_tracker locale come Fritz che rileva il collegamento alla propria rete dello smartphone), possiamo ricevere una notifica contenente il nome della persona che è arrivata o è appena andata via da casa nostra.

Questa automazione, nata a scopo di debug, l’ho poi trovata utile per diversi motivi. La notifica inviata tramite l’app ha title e message contenenti il nome della persona e channel differente a seconda che sia un ingresso o un’uscita. In tal modo possiamo assegnare una suoneria differente ai due tipi di notifica.
Il group è sempre people, così che questo tipo di notifiche si raggruppi con le altre notifiche dello stesso tipo.
Infine il tag è composto dal nome della persona più la scritta home, così che sia la stessa per persona, sia per l’ingresso che per l’uscita. Tramite questo stratagemma se una persona va e viene diverse volte da casa sul telefono vedremo solo la notifica dell’ultima azione e non tutta la storia della giornata.

Conclusione

Ricordando la premessa che queste automazioni potrebbero non andar bene a tutti per diversi motivi come il momento in cui il tracker Fritz (o similare) si accorge della vostra presenza a casa o della presenza o meno di access point Wifi da tracciare o altre particolarità ancora, proprie di ogni differente abitazione, spero però di aver condiviso un modo di approcciarsi alla questione che ti abbia dato degli spunti per aiutarti a costruire le automazioni più idonee alla tua specifica situazione.

Nel mio caso posso garantire che quanto spiegato in questo articolo è in uso da oltre un anno e funziona davvero bene!
Ti auguro che anche nel tuo specifico caso riesca a trovare un equilibrio tra tempi ed esigenze come nel mio così da poter utilizzare le informazioni circa la posizione di ognuno in specifiche automazioni di casa tua.

Ti va di darmi una mano?

Il contenuto di questo sito è completamente gratuito senza pubblicità invasive e il fine non è certo guadagnare …ma mantenere un sito ha un costo. Se ti va di darmi una mano per sostenere le spese o ti va di sostenere questo progetto hai le seguenti modalità:

Donazione con Paypal:

Regalami un caffè su Buymeacoffee:

Effettua i tuoi acquisti Amazon a partire da QUESTO LINK (o tramite i prodotti sotto)

Acquistare i tuoi prodotti Shelly usando QUESTO LINK

Effettuare i tuoi acquisti AliExpress usando QUESTO LINK

Shelly Plus 2PM è un interruttore a relè intelligente con 2 canali, fino a 16 A (max 18 A), e due misuratori di consumo; Può funzionare in due modalità: modalità relè e modalità motorizzazione tapparelle; Traccia i consumi e controlla qualsiasi elett...

Shelly Plus 2PM, Interruttore Intelligente Relé WiFi & Bluetooth, 2 Prese Elettriche - 16A, Monitora i Consumi, Tende/Persiane/Tapparelle, Domotica, Nessun Hub, Alexa/Google Home, iOS Android, 2 Pezzi

~~59,99 €~~ 44,99 €

Shelly Plus 2PM è un interruttore a relè intelligente con 2 canali, fino a 16 A (max 18 A), e due misuratori di consumo; Può funzionare in due modalità: modalit... altre informazioni

(a partire da 19 Luglio 2025 16:14 GMT +02:00 - )

𝗣𝗮𝗻𝗻𝗲𝗹𝗹𝗼 𝗱𝗶 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗼 𝗦𝗺𝗮𝗿𝘁 𝗰𝗼𝗻 𝗧𝗼𝘂𝗰𝗵𝘀𝗰𝗿𝗲𝗲𝗻 𝗱𝗮 𝟰”: Gestisci e monitora l’intero ecosistema Shelly tramite un intuitivo touchscreen a colori da 4 pollici, con accesso centralizzato a dispositivi e scene 𝗜𝗻𝘁𝗲𝗿𝗿𝘂𝘁𝘁𝗼𝗿𝗲 𝗮 𝗥𝗲𝗹è 𝗱𝗮 𝟱𝗔 𝗜𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗼: Sostituisci...

Shelly Wall Display Nero + Blu H&T Nero, Pannello di Controllo Wi-Fi Smart Home, Termostato, Relè 5A Integrato, Conduttore Neutro Richiesto, Dati Ambientali, Domotica, Alexa e Google Home

~~119,99 €~~ 111,11 €

𝗣𝗮𝗻𝗻𝗲𝗹𝗹𝗼 𝗱𝗶 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗼 𝗦𝗺𝗮𝗿𝘁 𝗰𝗼𝗻 𝗧𝗼𝘂𝗰𝗵𝘀𝗰𝗿𝗲𝗲𝗻 𝗱𝗮 𝟰”: Gestisci e monitora l’intero ecosistema Shelly tramite un intuitivo touchscreen a colori da 4 pollici, con ac... altre informazioni

(a partire da 19 Luglio 2025 16:34 GMT +02:00 - )

Shelly Plus 1PM è un interruttore a relè intelligente progettato per automatizzare luci, elettrodomestici e apparecchiature elettriche e per misurarne il consumo allo stesso tempo; Dotato di un wattmetro preciso, Shelly Plus 1PM ha anche una funzione...

Shelly Plus 1PM, Interruttore a Relè, Wi-Fi e Bluetooth, Misurazione della Potenza, Domotica, Casa Intelligente, Alexa e Google Home, iOS e Android, Nessun Hub Richiesto (4 Pezzi), Rosso

69,99 € (17,50 € / unità)

Shelly Plus 1PM è un interruttore a relè intelligente progettato per automatizzare luci, elettrodomestici e apparecchiature elettriche e per misurarne il consum... altre informazioni