Avere un indicatore che ci restituisca il numero di luci accese in casa può essere utile in diverse circostanze.
Possiamo, ad esempio, usare il conteggio per realizzare una card sulla plancia Lovelace a puro scopo informativo, oppure usarlo nelle logiche di script e automazioni per una qualsiasi esigenza.
In questo articolo vediamo come scrivere il codice YAML per la creazione del sensore (in due varianti) e come presentarlo in una plancia.
Il codice YAML del sensore
Questo tipo di sensore non lo troviamo bello pronto (out of the box) su Home Assistant ma ottenerlo è molto semplice, ci basta usare i template per creare un sensore custom attraverso la piattaforma Template Sensor in questo modo:
sensor: - platform: template sensors: luci_accese: friendly_name: 'Luci Accese' icon_template: 'mdi:lightbulb-group-outline' value_template: "{{ states.light | selectattr('state', 'eq', 'on') | list | count }}"
Analizziamo le operazioni che esegue il template:
states.light
=> recupera gli stati delle entità del dominio light.
selectattr('state', 'eq', 'on')
=> filtra le entità dove lo stato è uguale a on.
list | count
=> costruisce una lista e conta gli elementi.
Con questo codice avremo un’entità chiamata sensor.luci_accese
dove nello stato sarà riportato il conteggio di tutte le entità light in stato on.
Questo approccio ha il notevole vantaggio di essere completamente dinamico: ogni nuova entità che entra nel dominio light sarà presa in considerazione senza fare nulla.
Ma, ahimè, potrebbe anche rappresentare un problema, come nel mio caso ad esempio.
Se nella nostra configurazione di Home Assistant utilizziamo le entità light di tipo gruppo (piattaforma Light Group), queste entreranno di diritto nel dominio light, falsando il calcolo del sensore in positivo.
Facciamo un esempio.
Ipotizziamo di avere un’abitazione su due livelli, dove sono presenti due luci nella scala, una al piano di sotto e una al piano di sopra, ognuna con la sua entità light.
A partire dalle singole entità possiamo creare un gruppo che rappresenti la scala come entità light virtuale.
light: - platform: group name: Scala entities: - light.scala_sopra - light.scala_sotto
Questo codice genera l’entità light.scala
, non group.scala
come saremmo portati a pensare dato che si tratta di un gruppo.
A me piace molto usare questo tipo di gruppo, perchè eredita i servizi di una classica entità light, ad esempio light.turn_on
con tutte le sue opzioni disponibili.
Ma cosa succede se viene accesa una delle due luci?
Naturalmente la relativa entità va in stato on, ma, di conseguenza, anche lo stato del gruppo va in stato on.
E qui nasce il problema: abbiamo detto che il gruppo di luci fa parte del dominio light, per cui entrerà nel conteggio del sensore aumentando di una unità il risultato, falsando il valore finale.
Il problema, per fortuna, si risolve facilmente cambiando approccio con il template.
Invece di recuperare tutte le entità del dominio light possiamo usare un gruppo creato da noi e con la funzione expand leggere le entità membro.
sensor: - platform: template sensors: luci_accese: friendly_name: 'Luci Accese' icon_template: 'mdi:lightbulb-group-outline' value_template: "{{ expand('group.all_lights') | selectattr('state', 'eq', 'on') | list | count }}"
La funzione expand viene applicata all’entità group.all_lights
.
Questo gruppo deve essere creato precedentemente con all’interno tutte le luci che abbiamo domotizzato in casa.
Lo svantaggio rispetto al primo metodo è quello di dover tenere aggiornato il gruppo quando aggiungiamo una nuova luce nella nostra configurazione. Ma è anche vero che non è un operazione molto frequente, quindi non mi sembra un dramma.
Se proprio vogliamo automatizzare possiamo usare meccanismi di generazione automatica del gruppo con script AppDaemon, oppure uno script che esegue il servizio group.set
all’avvio del sistema, ma sono altri discorsi da approfondire.
Ora sta a te valutare quale di questi due metodi usare, in base alle caratteristiche della tua configurazione.
Una Card informativa
Ok, abbiamo creato un sensore custom chiamato sensor.luci_accese
che ci restituisce in tempo reale il numero totale di luci accese nella nostra abitazione.
Ipotizziamo di avere una vista nella plancia di Home Assistant dedicata all’illuminazione e di voler creare una card informativa con il sensore creato. Per non complicarci troppo la vita potremmo usare una semplice card sensor di Lovelace, ma le cose semplici non sono molto interessanti.
Io sono un convinto sostenitore del custom component Button Card, lo utilizzo praticamente in ogni situazione, anche per creare card di tipo “sensore”.
type: 'custom:button-card' entity: sensor.luci_accese name: LUCI ACCESE layout: icon_name_state2nd show_state: true styles: card: - padding-top: 2% - padding-bottom: 2% - height: 80px - width: 300px state: - font-size: 140% - font-weight: bold - justify-self: start - align-self: center name: - font-size: 85% - justify-self: start - color: var(--secondary-text-color) state: - value: 0 operator: '>' styles: icon: - color: var(--paper-item-icon-active-color) tap_action: action: none

Per un approfondimento generale sul discorso plancia di Home Assistant ti consiglio di partire da qui.
Contare qualsiasi cosa
Per spiegare il concetto l’articolo si focalizza su un sensore per contare le luci accese, ma in realtà lo stesso approccio può essere usato per contare qualsiasi tipo di entità in un determinato stato.
Per esempio con questo codice si ottiene un sensore che conta i media player del gruppo echo in riproduzione, che hanno assunto quindi lo stato playing.
sensor: - platform: template sensors: player_attivi: friendly_name: 'Player Attivi' value_template: "{{ expand('group.echo') | selectattr('state', 'eq', 'playing') | list | count }}"
Approfondimenti
Se qualche argomento dell’articolo non ti è chiaro ti lascio qualche lettura di approfondimento sui temi trattati.
- Interessante guida ai template prodotta da Saggiamente. La più completa che ho trovato in italiano.
I Template, parte uno: introduzione, sintassi e prima applicazione
I Template, parte due: i modelli nelle automazioni
I Template, parte tre: modelli avanzati con Jinja2 su Home Assistant - Guida di inDomus sulla piattaforma Template Sensor.
Piattaforma Home Assistant “Template Sensor” - Guida di inDomus sulla piattaforma Light Group.
Come raggruppare luci domotiche integrate su Home Assistant
Ciao, grazie e ci vediamo al prossimo articolo.
Max
Se apprezzi i miei contenuti puoi stimolare nuove idee sostenendo il progetto con una buona birra!
Ciao,
ho eseguito la tua guida ma mi da sempre attiva una luce e non capisco perchè.
dove sbaglio?
Ciao Andrea, perchè evidentemente hai applicato il primo metodo dove viene esaminato states.light che include tutte le entità light, anche quelle che non rappresentano un punto luce vero e proprio.
Devi usare il secondo metodo spiegato nell’articolo
CIAO Max
per prima cosa voglio ringraziarti per la condivisione di questi Tuoi lavori che trovo bellissimi
infatti la mia dashboard sulla base della tua qui postata.
Cmq ti scrivo su questa pagina perchè ho trovato molto bello questo sensore che io ho “girato” sugli switch invece che sulle luci, Ho molte luci sotto switch
Volevo farti una domanda, siccome io ho molti switch che mi accendono delle lampade ma ho anche della lampade (light), si puo creare un gruppo “misto”
dove inserire le Light e gli switch, solo gli switch che comandano le lampade ? e cosi avere un totale.
In un primo momento avevo pensato…faccio 2 sensori uno light e uno switch ma poi mi farà il totale?
GRAZIE MILLE.
Ciao Carlo, si nel gruppo puoi mettere sia switch che light perchè tanto sono sempre entità con stato on/off quindi va bene.
Grazie
FANTASTICO 🙂