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.scalacome 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
card sensore luci accese

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.

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!

Partecipa alla discussione 5 Commenti

  • Andrea ha detto:

    Ciao,
    ho eseguito la tua guida ma mi da sempre attiva una luce e non capisco perchè.
    dove sbaglio?

    • Max ha detto:

      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

  • Carlo ha detto:

    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.

Lascia un Commento