Simulazione di presenza in Home Assistant: la casa sembra abitata in vacanza

Introduzione

Secondo l’Osservatorio sulla Sicurezza della Casa realizzato dal Censis per Verisure, i furti in abitazione crescono in modo costante nei mesi estivi. Non è il picco isolato di un anno particolare: il dato si ripete quasi identico in due rilevazioni consecutive, e ad agosto arriva a sfiorare il 50% in più rispetto a maggio.

Fonte: Osservatorio sulla Sicurezza della Casa, Censis-Verisure — 3° Rapporto (dati 2023) e 4° Rapporto (dati 2024), elaborazione su dati SDI/SSD del Ministero dell’Interno.

C’è un secondo dato che spiega perché la simulazione di presenza ha senso: il 68,9% di chi ha subito un furto dichiara che al momento del reato in casa non c’era nessuno.

Questa configurazione gira sulla mia installazione di Home Assistant, e l’ho chiamata “modalità vacanza” per comodità — ma il nome è riduttivo. A me non serve solo d’estate: per lavoro capita spesso di stare via qualche giorno anche durante l’anno, e la casa resta vuota esattamente allo stesso modo. Il ragionamento che segue vale in entrambi i casi, e io la tengo attiva ogni volta che esco per più di una notte.

La domanda quindi è pratica: come simulare la presenza in casa con luci e tapparelle, usando solo quello che è già installato in Home Assistant, per rendere l’abitazione un bersaglio meno ovvio?

Perché “tutto acceso alle 20 in punto” non inganna nessuno

L’approccio più diffuso è anche il più debole: un’automazione che accende le luci ogni sera alle 20:00 esatte. Il problema è che un pattern regolare è esattamente ciò che un osservatore attento cerca, e bastano pochi giorni per riconoscerlo. Una casa in cui la luce del soggiorno si accende e si spegne allo stesso minuto per due settimane non comunica presenza: comunica automazione.

Quello che fa davvero la differenza è un altro tipo di variabilità, quella tipica del comportamento umano. Nessuno accende la luce alla stessa ora ogni sera, nessuno chiude tutte le tapparelle nello stesso istante, e nessuno usa sempre la stessa lampada. Serve quindi una simulazione che non segua uno schema fisso ma resti coerente con le abitudini reali della famiglia, e che coinvolga sia le luci sia le tapparelle.

È esattamente quello che costruiremo in questo articolo: una modalità vacanza in Home Assistant basata su tre principi — un interruttore generale, ritardi casuali, e pattern indipendenti tra luci e tapparelle.

Il metodo nativo: automazioni e helper, senza integrazioni esterne

In questo capitolo useremo solo componenti nativi di Home Assistant, senza dipendenze esterne e senza componenti HACS (di cui parleremo comunque più avanti). Servono tre ingredienti: un helper di tipo interruttore, il concetto di ritardo randomizzato, e trigger che cambiano naturalmente giorno per giorno.

L’interruttore di comando: input_boolean per attivare tutto in un colpo

La prima cosa da creare è un interruttore generale che accenda e spenga l’intera modalità vacanza. Senza di questo dovresti attivare e disattivare ogni singola automazione a mano, con il rischio concreto di dimenticarne una e rompere l’effetto.

Vai in Impostazioni → Dispositivi e servizi → scheda Helper → Crea Helper.

Cerca Interruttore (Toggle) nell’elenco, poi assegna un nome e, se vuoi, un’icona.

Lo stesso helper può essere scritto direttamente in configuration.yaml, ma ormai l’interfaccia visuale è più comoda e immediata:

input_boolean:
modalita_vacanza:
  name: Modalità Vacanza
  icon: mdi:bag-suitcase

Nota: se crei l’helper in YAML invece che da interfaccia, non lo vedrai comparire nella pagina Helper di Home Assistant. Quella pagina mostra soltanto gli helper creati dall’interfaccia, mentre quelli definiti in YAML esistono e funzionano ma restano invisibili lì. Non è un errore: dopo averlo scritto ti basta ricaricare la configurazione da Impostazioni → Sistema → Ricarica configurazione YAML. Tutti i dettagli sono nella documentazione ufficiale di Input Boolean.

A questo punto useremo l’helper come condizione in tutte le automazioni, così ogni automazione parte solo se l’interruttore generale è attivo:

conditions:
- condition: state
  entity_id: input_boolean.modalita_vacanza
  state: "on"

L’interruttore che trovi nella pagina Helper può essere inserito in dashboard come un normale toggle, così lo attivi e lo disattivi con un tocco senza andare a cercare automazioni e helper nei menu di sistema. Se non hai ancora familiarità con l’aggiunta di elementi alla dashboard, il procedimento è spiegato in Aggiungere una card alla dashboard di Home Assistant.

Randomizzare l’orario: il pattern del delay casuale

Siamo al cuore del problema. L’obiettivo non è accendere le luci a un orario fisso, ma fare in modo che si accendano una sera alle 20:00, quella dopo alle 20:10, quella dopo ancora alle 19:45 — mai allo stesso minuto.

Ci sono due strade per ottenerlo, e la terza è combinarle. La prima è mantenere un trigger a orario fisso e aggiungere un ritardo casuale nell’azione. La seconda è sfruttare l’integrazione Sun, dato che l’orario del tramonto cambia naturalmente ogni giorno. La combinazione delle due è la soluzione migliore, e per questo un trigger puramente fisso (at: "20:00:00", senza ritardo) non lo prendiamo nemmeno in considerazione.

Partiamo dalla versione più semplice, testata sulla mia installazione:

alias: Vacanza - Test delay casuale
description: ""
triggers:
- trigger: time
  at: "19:00:00"
conditions:
- condition: state
  entity_id: input_boolean.modalita_vacanza
  state: "on"
actions:
- delay:
    minutes: "{{ range(5, 40) | random }}"
- action: light.turn_on
  target:
    entity_id: light.soggiorno
  data:
    brightness_pct: 100
mode: single

Il trigger scatta alle 19:00 in punto, la condizione verifica che la modalità vacanza sia attiva, e il delay posticipa l’azione di un valore casuale compreso tra 5 e 40 minuti. L’accensione reale avviene quindi a un orario variabile, per esempio alle 19:35.

È la soluzione più facile da implementare, ma anche la meno efficace delle tre: l’orario di partenza resta comunque sempre lo stesso, e la finestra di variabilità è limitata verso l’alto dal valore massimo del range.

Attenzione — il delay casuale si scrive solo in YAML, e in una forma precisa. È il punto su cui ho perso più tempo, quindi te lo segnalo prima che ci sbatta anche tu. Primo: l’editor grafico delle automazioni non gestisce il valore casuale nel campo delay, devi passare alla modalità YAML — se di solito lavori con l’editor visuale senza scrivere codice, questo è uno dei casi in cui devi per forza mettere mano al testo. Secondo: va scritto su due righe, con minutes come chiave separata.

Questa è la forma corretta, quella che uso e che funziona:

- delay:
    minutes: "{{ range(5, 40) | random }}"

Questa invece non funziona e restituisce un errore:

- delay: "{{ range(5, 40) | random }} minutes"

L’errore che ottieni è offset 1 minutes should be format 'HH:MM', 'HH:MM:SS' or 'HH:MM:SS.F', e sulle prime confonde parecchio, perché parla di “offset” mentre tu stai scrivendo un delay. Il motivo è che il template viene risolto in un numero (1) a cui si concatena la parola minutes, e Home Assistant si ritrova a validare la stringa "1 minutes", che non è un periodo di tempo valido. La parola “offset” nel messaggio è solo il testo generico del validatore, non ha niente a che vedere con l’offset dei trigger. La sintassi completa di delay e dei template è descritta nella documentazione degli script.

Nota: un’automazione con un delay lungo resta “in esecuzione” per tutto il tempo dell’attesa. Se riavvii Home Assistant durante quella finestra, il conto alla rovescia si interrompe e l’azione non viene mai eseguita. È un comportamento normale, ma è bene saperlo prima di partire per due settimane.

Automazione luci: tramonto, luce casuale e spegnimento variabile

Questa versione non usa più un orario prestabilito ma si appoggia all’integrazione Sun, nativa di Home Assistant, che permette di usare l’evento sunset come trigger. Il tramonto cambia ogni giorno, quindi il punto di partenza è già variabile per costruzione.

alias: Vacanza - Luci serali con sunset
description: ""
triggers:
- trigger: sun.sunset
  options: {}
conditions:
- condition: state
  entity_id: input_boolean.modalita_vacanza
  state: "on"
actions:
- delay:
    minutes: "{{ range(5, 40) | random }}"
- action: light.turn_on
  target:
    entity_id: >
      {{ ['light.0xa4c138a8a6dcca56',
          'light.0xa4c1380a031cae28',
          'light.0xa4c13849ee028be9'] | random }}
- delay:
    minutes: "{{ range(4, 37) | random }}"
- action: light.turn_off
  target:
    entity_id: light.luci_tutte
mode: single

Qui la casualità agisce su tre livelli diversi, ed è questo che rende il risultato credibile: varia l’orario di accensione (tramonto più ritardo casuale), varia quale luce si accende (la lista viene pescata a caso), e varia la durata dell’accensione prima dello spegnimento.

Nota — due modi di usare il tramonto: qui il trigger è scritto come sun.sunset, uno dei trigger “purpose-specific” più recenti di Home Assistant. È la forma che genera l’editor visuale, si attiva nell’istante esatto del tramonto e non accetta opzioni. Se invece ti serve far scattare l’automazione a una distanza fissa dal tramonto — per esempio venti minuti dopo — devi usare il trigger sun classico, che accetta il parametro offset. Lo vedrai nel capitolo sulle tapparelle.

Il secondo punto è quello che quasi nessuno considera. Accendere sempre la stessa lampada è un pattern riconoscibile tanto quanto un orario fisso: se ogni sera si illumina solo la finestra del soggiorno e mai quella della camera, l’informazione che stai dando dall’esterno è che nessuno si sta muovendo per casa.

Nota: gli entity_id di questo esempio sono quelli reali della mia rete Zigbee2MQTT, quindi corrispondono agli indirizzi IEEE dei dispositivi. Sostituiscili con i nomi delle tue entità.

All’integrazione Sun abbiamo dedicato un articolo intero: se vuoi capire come funzionano sunset, sunrise, elevazione e azimut, trovi tutto in Automazione con il Sole in Home Assistant.

Altri trigger: la luminosità esterna come innesco

Alcuni dispositivi rilevano la luminosità ambientale e permettono di innescare l’accensione in base alla luce reale invece che a un calcolo astronomico. Nel mio caso uso il radar mmWave Wenzhi WZ-M100, che espone un sensore di illuminance: quando la luce esterna scende sotto una certa soglia, l’automazione parte.

È sufficiente sostituire (o affiancare) il trigger precedente con questo:

alias: Vacanza - Luci serali con luminosità
description: ""
triggers:
- trigger: numeric_state
  entity_id: sensor.0xa4c138e9e1c7c89d_illuminance
  below: 50
conditions:
- condition: state
  entity_id: input_boolean.modalita_vacanza
  state: "on"
actions:
- delay:
    minutes: "{{ range(3, 43) | random }}"
- action: light.turn_on
  target:
    entity_id: >
      {{ ['light.0xa4c138a8a6dcca56',
          'light.0xa4c1380a031cae28',
          'light.0xa4c13849ee028be9'] | random }}
- delay:
    minutes: "{{ range(5, 40) | random }}"
- action: light.turn_off
  target:
    entity_id: light.luci_tutte
mode: single

Questa è la versione che uso davvero a casa mia, e ho smesso di usare il tramonto proprio per questo: la luminosità reale è molto più casuale di un calcolo astronomico. Una giornata di maltempo fa scendere la luce prima, una serata limpida la ritarda, e il risultato è che l’accensione si sposta di parecchio da un giorno all’altro senza che io debba fare niente. È esattamente quello che farebbe una persona in casa.

Una cosa da sapere sui radar, ed è nota a chiunque li usi: la misurazione della luminosità non è precisa in senso assoluto, questi sensori non sono strumenti da laboratorio. Ma non è un problema, perché quello che conta qui non è la precisione, è la ripetibilità. Una volta che hai osservato che per il tuo dispositivo 50 lux corrispondono alla penombra della tua facciata, quel valore resta valido nel tempo. Il numero da usare non lo trovi in un manuale: lo ricavi guardando lo storico del tuo sensore per qualche giorno e scegliendo la soglia che corrisponde al momento in cui accenderesti la luce.

Se ti interessa l’hardware, il radar che uso è recensito in Wenzhi WZ-M100: radar mmWave Zigbee da 15 €.

Automazione tapparelle: un pattern indipendente da quello delle luci

Le automazioni sulle tapparelle seguono la stessa logica di quelle delle luci, ma con un accorgimento importante: non vanno messe nella stessa automazione. Se l’accensione della luce e la chiusura della tapparella avvengono in sequenza dentro lo stesso blocco, ricrei esattamente il pattern che stai cercando di evitare — accendo le luci, chiudo le tapparelle, sempre in quest’ordine e sempre a distanza fissa. Prevedibile.

La soluzione è creare automazioni separate, ognuna con il proprio ritardo casuale. Nota che qui il trigger torna a essere sun nella forma classica, con event e offset: è l’unica delle due che accetta uno scostamento fisso rispetto all’alba o al tramonto.

alias: Vacanza - Apertura tapparelle mattutina
description: ""
triggers:
- trigger: sun
  event: sunrise
  offset: "00:20:00"
conditions:
- condition: state
  entity_id: input_boolean.modalita_vacanza
  state: "on"
actions:
- delay:
    minutes: "{{ range(3, 43) | random }}"
- action: cover.open_cover
  target:
    entity_id:
      - cover.soggiorno
      - cover.camera
mode: single

alias: Vacanza - Chiusura tapparelle serale
description: ""
triggers:
- trigger: sun
  event: sunset
  offset: "00:30:00"
conditions:
- condition: state
  entity_id: input_boolean.modalita_vacanza
  state: "on"
actions:
- delay:
    minutes: "{{ range(3, 43) | random }}"
- action: cover.close_cover
  target:
    entity_id:
      - cover.soggiorno
      - cover.camera
mode: single

Un ultimo dettaglio che vale la pena curare: chiudere insieme soggiorno, camera e bagno non è quello che faresti normalmente. Anche in una casa completamente automatizzata, le tapparelle si chiudono una alla volta, seguendo gli spostamenti delle persone. Se vuoi spingere il realismo, separa anche queste in automazioni per stanza, ognuna con il proprio range casuale.

Perché in questo articolo non parliamo di clima e valvole

La modalità vacanza applicata al riscaldamento — temperatura ridotta durante l’assenza, riattivazione programmata al rientro — è un tema a sé, che abbiamo già trattato in modo approfondito. Trattarlo di nuovo qui significherebbe solo duplicare contenuto già esistente, quindi ti lascio i riferimenti diretti:

• Riscaldamento smart con Home Assistant: guida completa
• Automazioni riscaldamento avanzate: finestre, meteo e sensori

Il componente Presence Simulation: perché non l’ho usato

Per onestà te lo segnalo comunque: esiste un componente dedicato, Presence Simulation, presente nell’indice ufficiale di HACS (non è quindi un custom repository da aggiungere a mano). Il suo approccio è diverso da tutto quello che abbiamo visto finora: invece di generare orari casuali, rilegge dal database lo storico reale delle tue entità di un certo numero di giorni fa e lo riapplica identico. In pratica non simula un comportamento plausibile: riproduce il tuo comportamento vero.

Il vantaggio è evidente, ma c’è un vincolo da conoscere prima di installarlo: il componente ha bisogno che il database conservi uno storico più lungo del delta di giorni impostato, e la configurazione predefinita del recorder in Home Assistant tiene solo 10 giorni. Chi parte per tre settimane con le impostazioni di fabbrica ottiene una simulazione che si esaurisce e ricomincia da capo a metà vacanza — l’esatto contrario dell’effetto desiderato.

Sinceramente io non l’ho installato, e non per pigrizia. Quando una cosa si può fare con gli strumenti nativi di Home Assistant preferisco farla così, e questo è un caso in cui la logica da costruire è davvero minima: un helper e tre automazioni. Aggiungere una dipendenza esterna per ottenere lo stesso risultato mi sembrava sproporzionato. Se invece hai già mesi di storico nel database e vuoi il massimo realismo possibile, è un componente ben fatto e ha senso valutarlo.

Se vuoi installarlo, la guida a HACS è qui: Come installare HACS su Home Assistant.

Cosa non fa la simulazione di presenza

Vale la pena essere onesti sui limiti, perché una simulazione ben fatta riduce il rischio ma non lo annulla.

Non rileva nulla: se qualcuno entra davvero in casa, queste automazioni continuano ad accendere e spegnere luci come se niente fosse. Non ti avvisa: per quello servono sensori porta e finestra e un sistema di notifica. E se un dispositivo Zigbee va offline mentre sei via, l’automazione fallisce in silenzio, perché nessuno è lì a notare che la tapparella non si è mossa.

Proprio per questo ha senso affiancare almeno una notifica push che ti confermi che le automazioni stanno girando, e un accesso remoto per controllare lo stato della casa quando vuoi:

• Notifiche avanzate in Home Assistant
• Home Assistant da remoto con Cloudflare Tunnel

Conclusioni

Simulare la presenza in casa è un metodo in più per dissuadere chi sta valutando quale abitazione colpire. Da solo non basta, e non va venduto come un sistema di sicurezza: è un deterrente, e come tale funziona meglio quando è credibile che quando è complesso.

La cosa che mi convince di più di questo approccio è che non richiede di comprare nulla. Tutta la logica nasce da un helper, da qualche riga di YAML e da dispositivi che con ogni probabilità hai già collegato a Home Assistant. Le automazioni che trovi qui le ho testate personalmente sulla mia installazione, e sono tutte molto semplici: l’unico punto su cui ho dovuto ragionare è la scrittura del delay casuale, che va fatta in YAML e non dall’editor grafico.

I valori di casualità che trovi nei blocchi qui sopra sono quelli che uso davvero: finestre di trenta o quaranta minuti, diverse tra un’automazione e l’altra, abbastanza ampie da spostare l’accensione in modo percepibile da un giorno all’altro. E da quando ho il radar con la misura della luminosità esterna ho abbandonato del tutto il trigger sul tramonto: preferisco che siano le condizioni di luce vere a decidere quando la casa si illumina.