SCOPI DEL PROGETTO:
CONCETTI AFFRONTATI:
|
COMPONENTI SOFTWARE UTILIZZATE:
DISPOSITIVI FISICI UTILIZZATI:
|
PROGETTO INDICATO a UTENTI CON ISTALLAZIONE: |
|
NOTE E DISCLAIMER
|
|
| Revisione progetto: 2.1 | |
Abstract
I robot aspirapolvere (e/o lavapavimenti) sono delle appliance domestiche sempre più apprezzate nelle nostre case: fanno infatti le pulizie per noi, o quantomeno ci sgravano dalla necessità di rimuovere quotidianamente polvere e detriti dai nostri pavimenti. Molti soggetti allergici – e non solo – beneficiano di questa nuova tecnologia che si fa ogni giorno più evoluta: robot che sanno riconoscere i dislivelli e le diverse tipologie di superficie, scanner laser per riconoscere ed evitare gli ostacoli, motori di aspirazione sempre più potenti, filtri HEPA e molto altro ancora.
La gamma dei prezzi varia molto: da unità acquistabili con una spesa sotto i 100 euro si può arrivare anche a prezzi che si avvicinano ai 1000: questi ultimi modelli dispongono del non-plus-ultra della tecnologia robotica, inclusa – spesso – la possibilità di controllare il dispositivo tramite app mobile, come per esempio gli ECOVACS.
Molti altri, invece, condividono solitamente un elemento semplice ma potente: un telecomando infrarossi.
La comodità di controllare un robot aspirapolvere tramite cellulare/tablet/computer è evidente: non solo programmare l’unità è particolarmente semplice ed agevole, ma spesso consente anche di avviare (anche automaticamente) la pulizia in assenza degli inquilini, annullando così il fastidio di avere un oggetto semovente – a volte rumoroso – per casa. Purtroppo, di base, queste funzionalità sono presenti solo nei più costosi modelli top di gamma.
Il presente progetto illustrerà come riuscire a domotizzare un robot aspirapolvere non-domotico (ovvero non dotato di fabbrica delle capacità di collegarsi alla Wi-Fi ed essere controllato tramite app e tutto ciò che ne consegue) al fine di poterne gestire il comportamento in modo manuale e/o automatico tramite la propria domotica personale basata su Home Assistant.
| N.b Questo progetto, per essere attuato, prevede da parte dell’utente un minimo di cultura sul protocollo MQTT e sul funzionamento Node-RED. In merito a quest’ultimo tema specifico, consigliamo la lettura di questo progetto. |
Si parte
- Logica del progetto
- Assunti
- Analisi
- Home Assistant
- Definire l’entità
- Creazione TOKEN lunga vita
- Servizio “Broadlink”
- Cattura dei codici di comando
- Home Assistant e Node-RED
- Node-RED
- Perfezionamenti
- Ritorno alla base
- Percentuale carica batteria
- Uso
Logica del progetto
Partiamo da un elementare sillogismo. Dato che:
- Home Assistant è il nostro “ponte di comando” per il controllo della domotica (non sai cos’è? guarda, è fatto così);
- Home Assistant, tramite un attuatore Broadlink (eg. RM3 Mini) può inviare segnali infrarossi/radiofrequenza;
- il robot aspirapolvere e/o lavapavimento è controllabile tramite i segnali infrarossi del proprio telecomando,
è di conseguenza possibile controllare il robot attraverso Home Assistant, integrandolo così al resto della domotica, automazioni incluse.
Per tradurre questo sillogismo in fatti concreti abbiamo bisogno di un elemento che “traduca” i comandi da Home Assistant in segnali infrarossi – in pratica, che sostituisca la nostra mano e il telecomando del robot.
Per provvedere a questa funzione ci verrà in aiuto, ancora una volta, quella magia applicativa che è Node-RED.
Ciò che andremo a realizzare sarà:
- definire un’entità “Vacuum” utilizzando la piattaforma “MQTT Vacuum“;
- attivare l’azione remote.send_command presso Home Assistant e registrare i comandi del telecomando;
- definire, tramite, Node-RED un “dispositivo virtuale” il quale traduca i comandi MQTT inviati Home Assistant (tramite l’entità “Vaccum” di cui sopra) in chiamate all’azione remote.send_command al fine di inviare i codici infrarossi.
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;
- Node-RED 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. |
Per quanto riguarda Node-RED, gli utenti Home Assistant OS possono installarlo come semplice add-on, mentre per gli utenti Home Assistant Core@Raspberry Pi OS possono seguire questa guida.
Analisi
La prima cosa da fare è analizzare il telecomando del robot aspirapolvere (e/o lavapavimenti che sia).
Ogni appliance di questo tipo, infatti, prevede diverse funzioni legate al suo livello di evoluzione; le funzioni più tipiche sono l’avvio della pulizia in varie modalità (normale, pulizia spot, pulizia perimetri/bordi eccetera), l’interruzione della pulizia, il parcheggio automatico alla propria stazione di ricarica ed altro.
Quel che è necessario fare è “mappare” queste funzioni con i comandi effettivamente gestibili dall’entità modellabile tramite la piattaforma “MQTT Vacuum” di Home Assistant, i quali sono:
- start – avvio pulizia
- pause – interruzione temporanea della pulizia
- return_home – ritorno alla base di ricarica
- stop – interruzione della pulizia
- clean_spot – avvio pulizia su un punto predeterminato della casa
- locate – localizza il robot (solitamente tramite riproduzione da parte sua di un suono)
- status – stato del robot
Inoltre è prevista anche la funzionalità “send_command“, la quale permette – solo programmaticamente e non da interfaccia Home Assistant – di inviare comandi personalizzati (la vedremo in chiusura di progetto).
Per effettuare la mappatura è necessario prendere come riferimento il telecomando del robot e cercare di capire quali tasti si avvicinino o corrispondano a una delle funzioni elencate sopra.
Home Assistant
Definire l’entità
Per questo progetto assumeremo (a mo’ di esempio) che il nostro telecomando – e quindi il nostro robot – supporti le seguenti quattro funzioni:
| Funzione telecomando | Funzione componente “MQTT Vacuum” | Payload MQTT |
| Pulisci la stanza | start | start |
| Interrompi la pulizia | stop | stop |
| Torna alla base | return_home | return_to_base |
| Pulisci il perimetro* | clean_spot | clean_spot |
*Dato che “MQTT Vacuum” non prevede la funzione “pulisci perimetro”, per scelta arbitraria mapperemo questa funzione con la funzione clean_spot“.
A questo punto il codice da aggiungere in configurazione su Home Assistant sarà:
mqtt:
vacuum:
- name: "ROBOT Aspirapolvere"
schema: state
supported_features:
- start
- stop
- return_home
- clean_spot
- status
command_topic: "vacuum/command"
state_topic: "vacuum/state"
Dopo il riavvio di Home Assistant, una nuova entità sarà apparsa su Home Assistant: vacuum.robot_aspirapolvere la quale, presso l’interfaccia dell’HUB, apparirà grossomodo così:
A questo punto ogni azione attuata su tale entità innescherà la pubblicazione di topic MQTT verso il broker, topic che intercetteremo con Node-RED in modo da trasformarli in impulsi infrarossi inviati tramite uno o più attuatori Broadlink e in topic MQTT telemetrici di ritorno, a conferma dell’esecuzione dell’azione.
Creazione TOKEN lunga vita
A questo punto è necessario creare un “TOKEN a lunga vita“, ovvero una chiave d’accesso valida per 10 anni.
Per far ciò, da interfaccia Home Assistant cliccare sul circolo colorato contenente la prima lettera del vostro username posta in basso a sinistra nella colonna dell’interfaccia Home Assistant:
Una volta acceduto alla pagina, scollare sul fondo fino a trovare la seguente box:
Cliccare ora su “CREA TOKEN” e, alla richiesta del nome del token da creare, inserire “node-red“.
A questo punto salvare da qualche parte la stringa che verrà prodotta da Home Assistant (attenzione: non sarà possibile recuperarla successivamente, quindi salvarsela subito da parte).
Azione “Remote”
A questo punto è necessario che l’azione “remote.send_command” sia presente su Home Assistant. Per farlo è necessario, in breve, che:
- l’unità (o le unità) Broadlink sia configurate sulla Wi-Fi domestica;
- l’integrazione presso Home Assistant sia stata opportunamente effettuata.
Sarebbe ridondante riportare qui ciò che è descritto nel dettaglio nella guida di implementazione del Broadlink presso Home Assistant. Qualora non si fosse già provveduto a configurare sia il Broadlink che il relativo componente presso Home Assistant, la guida di riferimento è quindi questa:
Integrare attuatori a infrarossi/radiofrequenza Broadlink a Home Assistant
Cattura dei codici comando
Arrivati a questo punto sarà necessario catturare i codici infrarossi , registrandoli su Home Assistant sotto forma di comandi di device virtuali.
Gestire telecomandi virtuali su Home Assistant via Broadlink (parte 1)
Home Assistant su Node-RED
Affinché il progetto possa essere attuato è necessario dotare il proprio Node-RED dei nodi aggiuntivi necessari per collegare Node-RED a Home Assistant. Per far ciò è necessario installare il pacchetto “Node-RED integration with Home Assistant through the WebSocket and HTTP API“.
Per installarlo su Raspberry Pi OS (Raspbian), il comando è semplicissimo:
cd ~/.node-red
sudo npm install node-red-contrib-home-assistant-websocket
sudo systemctl restart nodered.service
Per gli utenti Home Assistant OS che abbiano implementato Node-RED come add-on la cosa è ancora più facile: non c’è bisogno di far nulla. I sopracitati nodi sono infatti già disponibili a bordo.
Chi utilizza Node-RED sotto Docker, accedere al container (si assume si chiami “nodered“) con:
docker exec -it nodered sh
poi:
cd node_modules
npm install node-red-contrib-home-assistant-websocket
exit
infine
docker restart nodered
Node-RED
Ora che Home Assistant è stato configurato (sia per l’integrazione del componente “MQTT Vacuum” sia “Broadlink”) e che siamo nella disponibilità dei codici infrarossi necessari, quel che dobbiamo fare in ultimo è realizzare, tramite Node-RED, una black-box tale da trasformare i comandi MQTT provenienti dall’entità definita su Home Assistant in un invio di codici infrarossi e di relativi topic MQTT telemetrici di risposta (di avvenuta esecuzione della sequenza).
Per far questo utilizzeremo la tecnica già precedentemente descritta presso “Trasformare più elementi MQTT in un unico dispositivo virtuale tramite Node-RED” guida che si consiglia vivamente di leggere prima di proseguire oltre. Quel che segue ricalca quella guida, ma dà per scontato che i concetti che sono alla base si siano già fatti propri, almeno sul piano teorico.
Realizzeremo pertanto dei flussi su Node-RED tali da gestire le seguenti sequenze di azioni (basandoci sull’esempio che portiamo avanti nel progetto, ma che andranno eventualmente personalizzate) a partire dalla ricezione dei topic inviati da Home Assistant:
| Topic MQTT inviato da Home Assistant | Azione | Topic telemetrico MQTT di risposta |
| vacuum/command start | invio codice che avvia la pulizia | vacuum/state cleaning |
| vacuum/command stop | invio codice che interrompe la pulizia | vacuum/state idle |
| vacuum/command return_to_base | invio codice che comunica al robot di tornare alla base di ricarica | vacuum/state docked* |
| vacuum/command clean_spot | invio codice che interrompe la pulizia in un punto specifico | vacuum/state cleaning |
*vedi, in fondo al progetto, il paragrafo “perfezionamenti“.
Apriamo dunque Node-RED e, in alto a destra, premeremo su “+” per creare un nuovo flusso che chiameremo “Flow 1” (o come meglio si crede).
La colonna a sinistra rappresenta l’elenco delle tipologie di “nodi” disponibili. Cerchiamo e troviamo nell’elenco (sotto la voce “Input”) un nodo “mqtt in“:
trasciniamolo nello spazio vuoto della dashboard e clicchiamoci sopra due volte per aprire sulla destra la dialog box relativa alla sua configurazione, denominata “Edit mqtt in node“:
A questo punto è necessario indicare:
- a quale server (broker MQTT) collegarsi (se Node-RED è in esecuzione sul medesimo computer di Home Assistant, indicare “127.0.0.1”);
- a quale topic iscriversi, ovvero su quale topic “far stare in ascolto” il nostro nodo.
Iniziamo col definire un nuovo server (broker mqtt).
Clicchiamo su “Add new mqtt:broker“:
Nel campo “Name” indichiamo un nome qualunque, nel caso dell’esempio “Mosquitto LOCAL” (per per caso il broker in uso sia Mosquitto, magari installato sullo stesso computer in cui è in esecuzione Node-RED).
indichiamo poi, alla voce “Server“, l’IP del broker (se è in esecuzione sullo stesso computer di Node_RED, ovviamente indicheremo “127.0.0.1“, altrimenti l’IP del nostro broker esterno a Node-RED). Indicheremo poi la porta ed eventuali credenziali d’accesso presso la tab “Security“.
Al termine della configurazione, clicchiamo su “Update“.
Tornati alla dialog “Edit mqtt in node” è il momento di indicare al nodo “mqtt ip” appena aggiunto alla dashboard quale topic monitorare.
Nel campo “topic” inseriremo quindi il topic che utilizzeremo per comandare sul piano logico il nostro dispositivo virtuale, ovvero (come da configurazione dell’esempio):
vacuum/command
Impostiamo QoS a “1” e, nel campo “Name“, sempre “vacuum/command“.
Al termine della configurazione, clicchiamo su “Done” per tornare alla dashboard.
Se tutto è corretto, il nodo “mqtt in” acquisirà nome “vacuum/command” e sparirà il triangolo rosso, segno che la connessione verso l’MQTT Broker sia andata a buon fine.
Ora è necessario identificare e trascinare in dashboard un nodo di tipo “Switch” il quale, in sostanza, permette di introdurre delle logiche condizionali. Una volta posizionato il nuovo nodo sulla dashboard, lo colleghiamo al primo nodo trascinando il circolo grigio posto sul lato destro del primo (l’output) al circoletto grigio posto sul lato sinistro del nodo del secondo (l’input).
Clicchiamo ora due volte sul nodo appena trascinato per aprire la relativa dialog box di configurazione chiamata “Edit switch node“: qui definiremo il nome del nodo, quale proprietà “valutare” al suo ingresso, infine quale condizione considerare corretta.
Nel campo nome indichiamo “AZIONE” lasciando invariata la proprietà da valutare in ingresso (ovvero msg.payload); nel riquadro sotto “Property” indichiamo poi quattro condizioni valorizzate rispettivamente “start” e “stop“, “return_to_base” e “clean_spot” (ovvero i payload che ci aspettiamo arrivino da Home Assistant insieme al topic vacuum/command)
Clicchiamo infine su “Done“.
A questo punto Node-RED avrà modificato il nodo switch (“AZIONE“) fornendogli quattro uscite (quattro pallini grigi sul bordo destro del nodo stesso), le quali rappresenteranno i due punti d’uscita (output) presso il quale il flusso si canalizzerà in base al payload.
In primo pallino grigio in alto rappresenta l’uscita in caso presenza di payload “start“, il secondo “stop“, il terzo “return_to_base” e infine il quarto, “clean_spot“.
Arrivati qui è necessario identificare il nodo di tipo “call service” nel sottoinsieme dei nodi “Home Assistant“, il quale serve fondamentalmente ad evocare l’azione remote.send_command, ovvero per inviare i codici infrarossi. Trascinarne quattro in dashboard e collegarne l’input ai quattro output del nodo “AZIONE” (uno per ciascuno):
Come si nota è presente un triangolo rosso su ciascuno: questo perché il nodo non è ancora stato opportunamente configurato. Quel che andremo a fare è quindi indicare a ciascun nodo “call service” quale sia l’istanza Home Assistant al quale far riferimento, quale sia l’azione da evocare (“remote.send_command“), quale sia l’attuatore Broadlink da usare e infine il codice infrarosso da fargli inviare.
Effettuare doppio clicco sul primo in alto (quello collegato al ramo relativo al payload “start“) e configurare come segue:
- Name: Start
- Server: Add new server…
- Name: Home Assistant
- Base URL: l’indirizzo del proprio Home Assistant (tipicamente l’indirizzo locale, inclusivo di “http(s)://“)
- Access Token: il token lunga-vita precedentemente definito
- Cache Autocomplete Results: no
- Domain: remote
- Service: send_command
- Data: dati strutturati spiegati a seguire
Per “dati strutturati” si intende un payload in formato JSON che contenga:
- il nome dell’entità “Remote” dell’attuatore Broadlink da usare (generata in fase di integrazione);
- il codice infrarosso da fargli inviare, ovvero il binomio telecomando virtuale/comando.
Un esempio è il seguente:
{"entity_id":"remote.NOME_DEL_BROADLINK","device":"nome_del_device","command":"nome_del_comando"}
tenendo a mente che:
- nel campo entity_id va indicato il nome dell’entità remote (eg. “remote.broadlink_sala“);
- nel campo device va indicato il nome dele telecomando virtuale precedentemente registrato su Home Assistant (eg. “robot_aspirapolvere“);
- nel campo device va indicato il nome dele telecomando virtuale precedentemente registrato su Home Assistant (eg. “ritorno_alla_base“).
Nei quattro nodi che andremo quindi a definire, nel primo andrà quello dell’avvio pulizia, il secondo l’interruzione, nel terzo quello di ritorno alla base, nel quarto quello di pulizia di un punto preciso della casa.
Provvedere a configurare i quattro nodi come spiegato per il primo (“Start”), variando il nome del nodo (“Stop”, “Return Home”, “Clean Spot”) e la configurazione appropriata nel campo “Data“.
A questo punto, tra i nodi di tipologia “Function” troviamo quello di tipo “Change” e trasciniamone quattro sulla dashboard, collegandone l’input ad ognuno degli output:
Effettuare doppio click su ognuno e configurarli come segue:
- il primo dall’alto (collegato a “Start“)
- Name: Cleaning
- to: {“state”: “cleaning”}
- il secondo (collegato a “Stop“)
- Name: Idle
- to: {“state”: “idle”}
- il terzo (collegato a “Return Home“)
- Name: Returned Home
- to: {“state”: “docked”}
- il quarto (collegato a “Clean Spot“)
- Name: Cleaning spot
- to: {“state”: “cleaning”}
Trattandosi il quarto sostanzialmente della stessa cosa del primo, è possibile non usarlo e collegare direttamente l’output del quarto nodo “call service” al primo nodo “change” appena creato.
| N.b. così facendo l’attuatore Broadlink che invierà i codici sarà uno e uno solo. Trattandosi il robot di un’appliance che si muove autonomamente per casa è facile che servano più Broadlink per coprire più stanze. In questo caso il passaggio sopra prevederà un raddoppio, un triplicare e via così di nodi di tipo “call service” per far sì che tutti i Broadlink inviino contemporaneamente lo stesso codice. Basterà creare gruppi di nodi “call service” (i quali nodi differiscano nella configurazione solo nel campo “host” del campo “Data“, non nel campo “packet“) collegati ai singoli output del nodo “Change”.
|
Ultimo passo: far sì che i payload definiti nei nodi “change” (“cleaning“, “idle“, “docked“) vengano inviati come payload di un topic telemetrico MQTT chiamato “vacuum/state“.
A questo punto, nella lista delle tipologie di nodi, troviamo e trasciniamo in dashboard un nodo di tipo “MQTT out” e collegarne l’input ai quattro output dei quattro nodi di tipo “change” appena configurati:
effettuiamo doppio click sul nodo appena aggiunto e configuriamolo come segue:
- Server: lo stesso indicato nel primo nodo del flusso
- Topic: vacuum/state
- QoS: 1
- Name: vacuum/state
Fine!
Infine, per rendere operativo il flusso – che ora spiegheremo riassumendolo – cliccare in alto a destra il tasto “Deploy“.
Da qui in poi ogni topic di comando vacuum/command ricevuto sul broker (inviato da Home Assistant tramite l’uso dell’entità di tipo “MQTT Vacuum”, o da qualunque client MQTT ad esso collegato) che presenti un payload a scelta tra “start“, “stop“, “return_to_base” e “clean_spot” verrà tradotto nell’azione di inviare il corretto codice infrarosso e di inviare un topic telemetrico di conferma (con paylod appropriato tra “cleaning“, “idle“, “docked“) che, a sua volta, verrà ricevuto da Home Assistant, il quale lo interpreterà come un “comando eseguito”, variando di conseguenza lo stato dell’entità.
Perfezionamenti
Ritorno alla base
Il presente progetto è una versione semplificata di ciò che si può ottenere utilizzando queste tecniche miste. Banalmente, abbiamo assunto che all’invio del comando “return_to_home” l’entità assuma direttamente lo stato “Docked“, quando in realtà sarebbe stato più corretto fargli assumere lo stato “returning“, previsto dalla piattaforma “MQTT Vacuum” e, successivamente, al rilevamento dell’avvenuto docking – e solo in quel momento – variarlo a “Docked“.
Si può realizzare facilmente: è sufficiente posizionare uno strumento di rilevazione di assorbimento elettrico a monte della stazione di ricarica e, tramite tecniche come quelle descritte qui, definire un’entità “Binary Sensor” il cui stato diventi “on” quando viene rilevato un certo assorbimento (il che deduca che il robot si stia ricaricando – e quindi sia tornato alla base). Analogamente potrebbe essere una buona idea ottenere il medesimo risultato utilizzando un sensore di vibrazione per capire se l’aspirapolvere stia lavorando o meno in base alle sue vibrazioni.
A questo punto sarebbe sufficiente definire una banale automazione su Home Automation (oppure un flusso Node-RED) che, al cambio dello stato del “Binary Sensor” (da “off” a “on“), pubblichi un topic MQTT “vacuum/state docked“. Ovviamente andrebbe modificato anche il flusso principale Node-RED al fine di correggere il payload del topic telemetrico (del ramo dedicato al “Return Home”) da “docked” a “returning“.
Ipotizziamo quindi che il “Binary Sensor”, definito (tramite la misurazione di assorbimento elettrico o delle vibrazioni dell’aspirapolvere, è indifferente) si chiami binary_sensor.vacuum_status:
- alias: "Vacuum dock"
trigger:
platform: state
entity_id: binary_sensor.vacuum_status
condition: []
action:
- action: mqtt.publish
data:
topic: vacuum/state
payload: >
{% if trigger.to_state.state == 'on' %}
{"state": "cleaning"}
{% else %}
{"state": "docked"}
{% endif %}
retain: true
| N.b. Inoltre, dopo aver inviato il comando di avvio pulizie e lasciando l’aspirapolvere lavorare autonomamente (cioè fino a fine batteria/fine programma) non si potrebbe solitamente conoscere il termine pulizia: introdurre un “Binary Sensor” che rilevi lo stato operativo permetterebbe di aggiornare, come spiegato sopra, lo stato da “Cleaning” a “Docked” e viceversa (sempre tramite la pubblicazione di un topic MQTT “vacuum/state“), come nell’automazione illustrata qui sopra. |
Ulteriori perfezionamenti possono essere ottenuti tramite l’adozione della funzionalità “send_command” prevista dalla piattaforma “MQTT Vacuum”, la quale permette di inviare comandi extra i quali possono tornare utili in presenza di funzionalità evolute attivabili tramite telecomando le quali non mappino non quelle, di base, presenti sull’entità.
Percentuale carica batteria
Analogamente al “ritorno alla base”, la percentuale di carica della batteria è un parametro accettato dalla piattaforma “MQTT Vacuum“. Ovviamente anche in questo caso andrebbe utilizzato un sensore che, su base deduttiva, calcoli empiricamente la quantità di carica della batteria in base al tempo trascorso dall’ultimo “Docked”.
Uso
L’entità vacuum.robot_aspirapolvere sarà ora pienamente operativa: se si è configurato tutto correttamente, usandola tutti i comandi verranno eseguiti in modo corretto, inviando i codici infrarossi opportuni.
Ovviamente, come spiegato nell’abstract, la cosa forse più interessante del domotizzare un robot aspirapolvere è quella di poter programmare tramite le automazioni la sua attivazione/disattivazione sfruttando le azioni tipiche del componente Home Assistant dal quale tale entità deriva, ovvero “Vacuum”.
Poniamo per esempio il caso di voler attivare la pulizia tutti i giorni alle 8:00 del mattino. L’automazione sarebbe a grandi linee la seguente:
automation:
alias: "Auto-start ROBOT"
trigger:
platform: time
at: '08:00:00'
condition: []
action:
action: vacuum.start
entity_id: vacuum.robot_aspirapolvere
Un’altra interessante possibilità è quella di innescare la pulizia (magari utilizzando la funzione “Clean Spot”) quando la famiglia esce di casa.
Assumendo di avere a disposizione un gruppo di entità di tipo “Device Tracker” (che determinino quindi lo stato di presenza degli inquilini) chiamato group.awesome_people, l’automazione sarebbe la seguente:
automation:
alias: "Auto-start ROBOT"
trigger:
platform: state
entity_id: group.awesome_people
from: 'home'
condition: []
action:
action: vacuum.clean_spot
entity_id: vacuum.robot_aspirapolvere
e così via. Il limite, come sempre, è la fantasia.
Integrare un climatizzatore tradizionale a Home Assistant via Broadlink e SmartIIR (v2)
|
⚠️ Se di Home Assistant ne sai poco ma sei interessato a capirne di più, ti suggeriamo di partire da qui. |
| Questa pagina è redatta, manutenuta e aggiornata dallo staff di inDomus, un gruppo di persone molto diverse tra loro che trovi, per domande e supporto, sul forum e sulla chat del sito. Alcuni link sono taggati in qualità di affiliati Amazon e riceviamo un compenso dagli acquisti idonei, utile al sostenimento del sito, ma le nostre recensioni sono tutte indipendenti e non sponsorizzate. Se ti sei perso, a tua disposizione c'è la mappa. |