La scena mi è capitata centinaia di volte. Rientro a casa la sera, fuori dalla porta è buio, ho le mani occupate — chiavi di casa, chiavi dell’auto, buste della spesa, oggetti vari — e non posso premere l’interruttore della luce sul pianerottolo. Avevo provato a risolvere con un sensore PIR, ma l’esperienza è stata frustrante: troppi falsi positivi, troppe luci che si accendevano di notte senza motivo.
Alla fine ho cambiato approccio e ho installato un radar mmWave human presence, da non confondere con i radar a microonde che rilevano solo il movimento. Il risultato è esattamente quello che cercavo: la luce si accende quando arrivo davanti alla porta, resta accesa il tempo necessario, si spegne da sola.
In questo tutorial ti spiego perché ho scelto un radar mmWave invece di un PIR, ti mostro il dispositivo che uso a casa (un Wenzhi WZ-M100 da 15 euro), e ti do l’automazione completa in YAML — con tutti i dettagli che fanno la differenza tra una configurazione “che funziona” e una che si comporta bene anche nei casi limite. Se cerchi automazioni luci più generiche pensate per il risparmio energetico, ti rimando alla mia guida sulle automazioni luci per risparmiare in bolletta.
Prima di entrare nei dettagli, una precisazione che evita confusione più avanti. In commercio trovi tre famiglie di sensori che vengono spesso confuse: i PIR a infrarosso passivo (i classici sensori di movimento da 10-15 €), i radar a microonde a 5.8 GHz (presenti in molti dispositivi venduti come “mmWave” che in realtà non lo sono), e i veri radar mmWave a 24 GHz — categoria a cui appartiene il sensore di questo tutorial. La differenza la approfondisco più sotto: per ora basti sapere che solo l’ultimo riesce davvero a rilevare una persona ferma, e questo cambia tutto quando si tratta di automazioni d’ingresso.
Perché un radar mmWave e non un PIR per l’ingresso
Per la mia porta d’ingresso ho scelto un radar mmWave dopo mesi di problemi con i PIR. I sensori a infrarosso passivo che avevo installato accendevano la luce nei momenti sbagliati per quattro motivi che, all’esterno, sono praticamente impossibili da evitare:
- Animali: gatti, ricci, piccioni che attraversano il campo visivo del sensore. Di notte sul pianerottolo era una lotteria.
- Vento: muove oggetti scaldati dal sole — foglie, tendoni, panni stesi — e per il PIR queste variazioni termiche sono indistinguibili da una persona.
- Ombre e sole diretto: nuvole che passano, esposizioni a sud che scaldano il muro, falsi positivi diurni a ripetizione.
- Copertura conica con punto cieco frontale: il PIR rileva male chi avanza dritto verso il sensore. Una persona che cammina di lato lo attiva subito, una che arriva frontalmente può non essere rilevata finché non si stacca dalla porta.
C’è poi un limite strutturale che da solo motiva il cambio: i PIR non sanno gestire la distanza. Non hanno un controllo granulare sull’area di rilevamento. I radar invece sì, e per me questo è il vero punto di svolta — perché significa poter dire “accendi la luce solo se qualcuno è a meno di 4 metri dalla porta”, invece di “accendi se qualcosa di caldo si muove ovunque davanti al sensore”.
Su Amazon trovi radar mmWave dai 18-22 € fino ai 70 € dell’Aqara FP1. Io ho preso un modello economico su AliExpress (15 €) che funziona egregiamente. Te lo mostro tra poco.
In sintesi: un PIR è un sensore di “calore in movimento”, un radar mmWave è un sensore di “qualcosa che si trova nello spazio”. All’esterno, le sorgenti di calore in movimento non sono solo persone — ed è la radice di tutti i limiti del PIR su una porta d’ingresso. Se vuoi approfondire le automazioni dei sensori in generale, ho scritto una guida sull’automazione delle luci con Home Assistant.
PIR, microwave e mmWave: tre tecnologie diverse, non chiamarle tutte “radar”
Vediamo brevemente le tre categorie di sensori che spesso vengono confuse — è una distinzione che cambia quale dispositivo dovresti comprare.
PIR (Passive InfraRed)
È un sensore passivo: non emette nulla, si limita a misurare la radiazione infrarossa (il calore) emessa dagli oggetti che si muovono nel suo campo visivo. È la tecnologia più vecchia, più economica, e quella usata nei classici sensori di movimento da 10-15 €.
Il limite è strutturale: il PIR rileva variazioni di calore, non movimento in sé. All’esterno questo significa molti falsi positivi — vento caldo, foglie mosse, animali, sole diretto — e in molti casi peggiora la situazione invece di migliorarla. Sconsigliato per applicazioni d’ingresso esterno.
Radar a microonde a 5.8 GHz
È un sensore attivo: emette continuamente onde radio ad alta frequenza nell’ambiente e ne analizza il riflesso. Il principio è quello dell’effetto Doppler:
- Nessun movimento: le onde tornano indietro con la stessa frequenza con cui sono partite, il sensore non rileva nulla.
- In presenza di movimento: l’onda riflessa cambia frequenza, il sensore attiva l’uscita.
Il problema fondamentale è che se il soggetto è fermo, il radar non lo rileva. In Home Assistant l’entità motion torna a off anche se in realtà sei ancora lì — falsando le automazioni. Consigliato con riserva — fa il suo lavoro ma bisogna conoscerne i confini.
Radar mmWave a 24 GHz (vero millimeter wave)
È il livello successivo: se il PIR rileva il calore e il microonde 5.8 GHz rileva lo spostamento, il radar mmWave rileva la presenza assoluta — persino quando una persona è completamente immobile. Lo fa grazie alla tecnologia FMCW (Frequency-Modulated Continuous Wave) e a lunghezze d’onda nell’ordine dei millimetri, che permettono risoluzioni molto più fini.
I modelli più evoluti espongono tre informazioni preziose:
- Distanza esatta: il sensore sa a quanti metri e centimetri ti trovi.
- Velocità: capisce se ti stai avvicinando o allontanando, e a quale velocità.
- Angolo e direzione: nei modelli avanzati con più antenne riceventi, mappa la posizione nello spazio tridimensionale. Alcuni sono persino multipresenza, gestendo più soggetti contemporaneamente nella stessa stanza.
I mmWave non sono perfetti: la loro grande sensibilità è anche un problema, perché possono produrre falsi positivi su correnti d’aria o ventilatori. Ma a livello software, in Home Assistant, possono essere gestiti bene con automazioni mirate. Per la mia porta d’ingresso esterna sono di gran lunga la scelta migliore.
Tabella comparativa: PIR vs Microwave 5.8 GHz vs mmWave 24 GHz
| PIR | Microwave 5.8 GHz | mmWave 24 GHz | |
|---|---|---|---|
| Costo medio | 10–15 € | 12–20 € | 18–30 € / 70+ € premium |
| Principio fisico | Rileva variazioni IR | Radar Doppler | Radar FMCW |
| Rileva persona ferma | No | No | Sì |
| Misura distanza | No | No | Sì |
| Falsi positivi animali esterni | Alti | Medi | Bassi |
| Falsi positivi vento/foglie | Medi | Medi | Bassi |
| Falsi positivi ventilatori/HVAC | Bassi | Alti | Alti |
| Carico Zigbee | Trascurabile | Medio | Alto (richiede mitigazione) |
| Alimentazione a batterie | Sì | Difficile | No (5V costante) |
| Adatto a porta d’ingresso esterna | Sconsigliato | Con riserva | Scelta migliore |
Costo medio
Principio fisico
Rileva persona ferma
Misura distanza
Falsi positivi animali esterni
Falsi positivi vento/foglie
Falsi positivi ventilatori/HVAC
Carico Zigbee
Alimentazione a batterie
Adatto a porta d’ingresso esterna
Il radar Wenzhi WZ-M100 che uso a casa
Il dispositivo che ho scelto è un radar economico, ma all’interno di un ecosistema smart ben configurato e con buona compatibilità con Home Assistant fa egregiamente il suo lavoro. Costo: circa 15 € su AliExpress. Il modello esatto, una volta accoppiato, viene riconosciuto in Zigbee2MQTT come Wenzhi WZ-M100 — Human presence sensor. Puoi trovare la scheda tecnica ufficiale nella documentazione Zigbee2MQTT del WZ-M100.
L’ho installato vicino alla porta d’ingresso, alimentato a una presa a circa 10 cm da terra. Può sembrare un’altezza strana per un sensore di presenza, ma non è un problema: il radar ha un cono di rilevamento ampio (i 90° dichiarati sono in pratica anche di più, da esperienza) e arriva fino a 10 metri, configurabili. Per alimentarlo basta un comune alimentatore USB-C da 5 V.
Il dispositivo include anche un sensore di luminosità integrato, perfetto per condizioni del tipo “accendi le luci solo quando il lux è sotto una certa soglia”. Lo userò esattamente così nell’automazione.
Prima installazione: pairing in Zigbee2MQTT
L’installazione è semplicissima. Vai in Home Assistant nel pannello di Zigbee2MQTT e clicca su Permetti join.
Poi tieni premuto il tasto del dispositivo finché non viene riconosciuto. In una decina di secondi compare nella lista dei dispositivi accoppiati come Human presence sensor (WZ-M100) con manufacturer Wenzhi.
Funzioni esposte e parametri del radar
Una volta accoppiato, il dispositivo espone in Home Assistant queste informazioni:
Le entità di lettura principali sono tre:
- Illuminance (
sensor.0xa4c138e9e1c7c89d_illuminance): luminosità ambientale in lux. Nella mia installazione varia da 0 di notte fino a 2000 lx in pieno giorno. - Presence (
binary_sensor.0xa4c138e9e1c7c89d_presence): vero/falso, indica se il radar sta rilevando un soggetto. - Target distance (
sensor.0xa4c138e9e1c7c89d_target_distance): distanza in metri del soggetto rilevato.
I parametri configurabili — e come li ho impostati io — sono:
| Parametro | Range valido | Mio valore | A cosa serve |
|---|---|---|---|
| Sensitivity | 1 — 9 | 5 | Sensibilità del radar. Più alta = più sensibile (e più falsi positivi). |
| Minimum range | 0 — 10 m | 0.3 m | Distanza minima da cui il radar considera valido un rilevamento. |
| Maximum range | 0 — 10 m | 4.5 m | Distanza massima. Oltre questa soglia il radar ignora i soggetti. |
| Detection delay | 0 — 10 s | 1 s | Ritardo prima che il radar segnali presenza dopo aver visto qualcuno. |
| Fading time | 5 — 1500 s | 5 s | Quanto tempo il radar continua a dichiarare presenza dopo che il soggetto è uscito dall’area. |
| Interval time | 1 — 3600 s | 5 s | Intervallo tra le pubblicazioni MQTT. Fondamentale per evitare il flooding. |
Sensitivity
Minimum range
Maximum range
Detection delay
Fading time
Interval time
Questi sono i miei valori, ottenuti dopo alcune settimane di test sull’installazione reale. Tu adattali alla geometria del tuo ingresso. Maximum range è quello che più di tutti vale la pena calibrare: per una porta d’ingresso 3.5-4.5 metri è un buon punto di partenza, perché restringe l’area al solo vano davanti alla porta evitando di rilevare passanti sul pianerottolo.
In arrivo a breve: una recensione completa del Wenzhi WZ-M100 con test sul lungo periodo, confronto con altri mmWave e indicazioni d’acquisto.
L’automazione completa: accensione e spegnimento in un unico blocco
Invece di scrivere due automazioni separate — una per accendere e una per spegnere — gestisco tutto in un blocco unico con un doppio trigger. È più pulito da manutenere e più facile da disattivare “in massa” se serve sospendere la cortesia esterna per un periodo (ad esempio durante le vacanze, quando voglio che la luce resti spenta indipendentemente da chi passa).
La logica nell’editor UI
Vista nell’editor visuale di Home Assistant, l’automazione si struttura così:
Due trigger sullo stesso binary_sensor (uno per il passaggio a Detected, uno per Clear), una condizione sull’illuminance, e un blocco Choose between 2 options che instrada a “If triggered by on” o “If triggered by off”. Sotto i dettagli del primo trigger:
Lo YAML completo
Sostituisci i miei entity_id (quelli con il MAC 0xa4c138e9e1c7c89d per il radar e light.yeelight_color_0x3707763 per la lampadina) con quelli reali della tua installazione, e cambia scene.esterno_luce_di_cortesia con il nome della tua scena.
alias: Luce Di Cortesia Esterna
description: Accensione luce di cortesia esterna
triggers:
- trigger: state
entity_id:
- binary_sensor.0xa4c138e9e1c7c89d_presence
to: "on"
id: "on"
- trigger: state
entity_id:
- binary_sensor.0xa4c138e9e1c7c89d_presence
to: "off"
id: "off"
conditions:
- condition: numeric_state
entity_id: sensor.0xa4c138e9e1c7c89d_illuminance
below: 50
enabled: true
actions:
- choose:
- conditions:
- condition: trigger
id:
- "on"
sequence:
- action: scene.turn_on
metadata: {}
data: {}
target:
entity_id: scene.esterno_luce_di_cortesia
- conditions:
- condition: trigger
id:
- "off"
sequence:
- delay:
hours: 0
minutes: 0
seconds: 2
milliseconds: 0
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.yeelight_color_0x3707763
mode: singleCosa fa esattamente l’automazione
Ci sono alcuni pezzi che meritano attenzione, perché non sono ovvi e fanno la differenza tra un’automazione che “funziona” e una che si comporta bene anche nei casi limite.
Doppio trigger con id. I due trigger ascoltano la stessa entità (il binary_sensor del radar) ma su transizioni opposte: una verso on, una verso off. L’attributo id etichetta ciascun trigger così che più sotto possiamo capire quale dei due ha innescato l’esecuzione corrente. È il pattern standard quando vogliamo una sola automazione che gestisca due comportamenti distinti.
Condizione singola, applicata a entrambi. La condizione illuminance below 50 sta al livello principale dell’automazione — non dentro un ramo — quindi viene valutata prima della logica di scelta. Se rientro al buio (lux < 50) sia l’accensione che lo spegnimento sono autorizzati a procedere; di giorno (lux > 50) l’automazione non fa nulla, perché la luce naturale è già sufficiente.
C’è un piccolo edge case: se rientro di notte (luce accesa correttamente) ma il radar segnala off dopo l’alba, la condizione lux < 50 blocca lo spegnimento. In pratica succede solo se il fading time del radar è molto lungo e l’alba arriva proprio in quei minuti. Per setup standard con fading da 5 a 60 secondi non è un problema reale, ma è bene saperlo.
Il blocco choose come switch. È l’equivalente di uno switch/case in altri linguaggi: valuta in ordine le condizioni di ogni ramo ed esegue il primo che combacia. La condition: trigger controlla l’id del trigger e instrada al ramo “accendi scena” o “spegni luce”.
Perché una scena invece di light.turn_on? Definisco la scena scene.esterno_luce_di_cortesia una volta sola, con tutti i parametri che voglio — colore caldo, luminosità adeguata, temperatura colore. Richiamandola con scene.turn_on mantengo l’automazione pulita e ho un solo posto da modificare se cambio idea su come deve apparire la luce. È buona prassi separare il quando accendere (responsabilità dell’automazione) dal come accendere (responsabilità della scena).
Il delay di 2 secondi sullo spegnimento — il dettaglio che fa la differenza. Quando il radar segnala off, non spengo subito. Aspetto 2 secondi. Il motivo è che i radar mmWave, anche di buona qualità, possono produrre micro-oscillazioni on→off→on quando sei sulla soglia del cono di rilevamento — mentre frughi nello zaino, ti pieghi a raccogliere qualcosa, o resti immobile per qualche istante. Senza il delay vedresti la luce sfarfallare. Con due secondi di buffer, queste oscillazioni vengono assorbite e la luce resta stabile.
mode: single — perché non restart. Con mode: single, se durante il delay di spegnimento (i 2 secondi) il radar torna a on, il nuovo trigger viene ignorato. L’automazione completa il ramo OFF, spegne la luce, e se sei davvero ancora lì il radar continua a stare in on stabile. Con mode: restart invece ogni transizione del radar interromperebbe l’esecuzione in corso e farebbe ripartire da capo. Su un sensore che oscilla naturalmente, l’automazione entrerebbe e uscirebbe continuamente nei rami on e off, ricaricando la scena ogni volta. Risultato: più traffico nel motore di automazioni e — soprattutto con lampadine Yeelight che hanno un fade-in percettibile — flicker visibile della luce.
La regola pratica: mai usare restart su automazioni a doppio trigger ON/OFF con choose ramificato e azione di accensione idempotente. single è la scelta robusta. Per approfondire la struttura dei trigger consulta la documentazione ufficiale Home Assistant sulle automazioni.
Il problema del flooding Zigbee (e come l’ho risolto)
C’è una verità scomoda sui radar mmWave economici: floodano la rete Zigbee. Il sensore pubblica messaggi a ritmo costante — il target_distance aggiornato anche più volte al secondo — e se non gestito può intasare il coordinatore Zigbee, peggiorare la link quality di altri dispositivi e far crescere a dismisura il database di Home Assistant.
L’ho notato dopo qualche giorno dall’installazione: il file home-assistant_v2.db era cresciuto in modo anomalo, e nei log di Zigbee2MQTT il radar era il dispositivo di gran lunga più “chiacchierone” della rete.
La soluzione che ho adottato sfrutta tre parametri del radar stesso, senza dover toccare configurazioni esterne. Sono tutti già visibili nello screenshot dei parametri sopra:
- Maximum range a 4.5 m: il radar comunica messaggi di rilevamento solo quando qualcuno è entro 4.5 metri. Tutto ciò che è più lontano (passanti sul pianerottolo, gente che cammina nel corridoio del palazzo) viene ignorato. Per un ingresso non ha senso monitorare i 10 metri pieni che il sensore supporterebbe.
- Detection delay a 1 secondo: introduce un ritardo prima che il radar dichiari “presence detected”. Filtra le micro-rilevazioni e riduce il numero di transizioni
on/offspurie. - Interval time a 5 secondi: regola la frequenza con cui il radar pubblica gli aggiornamenti di stato sulla rete. Senza questa impostazione, di default il radar pubblica anche ogni 500 ms — ed è lì che inizia il problema.
Con questa configurazione il flooding è gestito direttamente a monte, sul dispositivo, senza dover ricorrere a debounce in Zigbee2MQTT o a exclude_entities nel recorder di Home Assistant. Soluzioni più aggressive (filtri lato MQTT, esclusione del target_distance dal database) sono possibili, ma nella mia esperienza non sono necessarie se tari bene questi tre parametri.
Estensioni utili dell’automazione
Quella che ti ho mostrato è la versione che uso ogni giorno, ma il radar e l’automazione si prestano a estensioni molto interessanti.
- Notifica push quando si accende la luce e non sono in casa: combinando il trigger del radar con lo stato di
person.massimo(not_home), posso ricevere una notifica sul telefono ogni volta che la luce si accende mentre sono fuori. Un proxy semplice e gratuito di “qualcuno è davanti alla mia porta”. - Adattamento della luce all’illuminance esterna: usando il sensore lux integrato del radar, posso modulare la luminosità della scena (più forte in piena notte, più morbida al crepuscolo) invece di accendere sempre allo stesso livello.
- Integrazione con campanello o videocitofono: se hai uno Shelly o un campanello Zigbee, puoi combinare il trigger del radar con l’evento del campanello per scenari più ricchi (es. registra automaticamente una clip video quando radar e campanello scattano insieme).
- Doppio sensore PIR più mmWave in AND: se vuoi essere paranoico anti-falsi-positivi, una condizione AND tra due sensori di tecnologia diversa elimina praticamente ogni rilevamento spurio. Costa qualcosa in reattività, ma rende l’automazione blindata.
Le combinazioni sono davvero tante — il radar è uno strumento versatile. Io ti ho mostrato la mia soluzione per la luce d’ingresso esterna, che risolveva un problema concreto. Parti da qui e implementa quello che davvero ti serve. Se vuoi costruire un setup completo di domotica fai-da-te, ho scritto una guida per iniziare con un budget contenuto in Italia.
Conclusioni
Il radar mmWave ha trasformato la mia esperienza di rientro a casa. Quello che con il PIR era una lotteria continua di falsi positivi, con il Wenzhi WZ-M100 è diventato un automatismo affidabile che non sbaglia praticamente mai. Tre cose da portare a casa da questo tutorial:
- Per esterno e ingressi, la famiglia giusta è il mmWave a 24 GHz — non i PIR, non i microwave 5.8 GHz venduti come “mmWave”.
- I parametri del radar vanno calibrati sulla geometria del proprio ingresso. Maximum range, detection delay e interval time sono i tre valori che fanno la maggiore differenza.
- Il flooding Zigbee è un problema reale, non un dettaglio teorico — ma si risolve agendo direttamente sui parametri del dispositivo, senza configurazioni esoteriche.
La prossima settimana pubblico la recensione completa del Wenzhi WZ-M100 con test sul lungo periodo e confronto con altri mmWave. Resta sintonizzato, e nel frattempo: sperimenta i parametri sulla tua installazione — ogni porta è diversa.

