Ottimizzare la conservazione dei dati di HA con InfluxDB

 

Argomento: InfluxDB

Livello: Esperto (Novizio,Esperto, Pro)

Difficoltà: Alta (Bassa, Media, Alta)

Introduzione

Abbiamo già parlato di InluxDB e Grafana come la perfetta accoppiata (vedi articolo: https://hassiohelp.eu/2018/11/27/grafana/) per mantenere per lungo tempo i dati memorizzati da Home Assistant e poter creare dei “cruscotti” con grafici e tabelle anche molto complessi, in questo articolo andremo ad analizzare un po’ più a fondo la configurazione di InfluxDB per realizzare un sistema leggero e scalabile in grado di memorizzare i nostri dati per anni.

Cosa è InfluxDB

InfluxDB è un Time Serie Database (TSDB) in italiano una base dati di serie temporali, ovvero una base dati ottimizzata per memorizzare informazioni con data e ora. I dati delle serie temporali sono semplicemente misurazioni o eventi che sono tracciati, monitorati, campionati e aggregati nel tempo. Potrebbe trattarsi di misurazioni fatte da un server, dati di monitoraggio delle prestazioni delle applicazioni, dati di networking, dati raccolti da sensori atmosferici, eventi, operazioni effettuate in un mercato titoli o azionario e molti altri tipi di dati.

Un TSDB è creato appositamente per la gestione di metriche ed eventi o misurazioni con un timestamp ed è ottimizzato per misurare il cambiamento nel tempo. Le proprietà che rendono i dati delle serie temporali molto diversi dagli altri carichi di lavoro sono la gestione del ciclo di vita dei dati, il riepilogo e le scansioni su ampio intervallo di molti record.

Facciamo un esempio relativo alla domotica: immaginiamo di avere un sensore che misura il nostro consumo di energia elettrica, avremo quindi un sensore che ci indica i kWh (kilowattora) in un determinato istante di tempo. Se volessimo visualizzare i consumi giornaliero, settimanali o mensile per un anno dovremmo analizzare ed elaborare migliaia di dati grezzi (cioè l’energia consumata ad un dato istante di tempo), questa elaborazione è particolarmente semplificata con InfluxDB.

Terminologia e concetti chiave di InfluxDB

Non voglio fare un trattato sui database però alcuni concetti vanno spiegati, per questo proverò ad essere sintetico e chiaro esponendo solo alcune informazioni, per il resto rimando alla documentazione ufficiale. Per i termini specifici di InfluxDB cercherò di usare la dizione inglese in modo da evitare fraitendimenti.

Termini base

• Measurement (obbligatorio): è un contenitore per tag, field e timestamp
• Tags(opzionale): i tag sono facoltativi ma la maggior parte delle serie include tag per differenziare le origini dati e per rendere le query facili ed efficienti. Sia le chiavi dei tag che i valori dei tag sono stringhe.
• Fields(obbligatorio): le chiavi dei campi sono obbligatorie e sono sempre stringhe e, per impostazione predefinita, i valori dei campi sono numeri float.
• Timestamp(opzionale): fornito alla fine della riga in tempo Unix (nanosecondi dal 1 gennaio 1970 UTC) è opzionale. Se non specifichi un timestamp, InfluxDB utilizza il timestamp locale in nanosecondi del server nell’epoca Unix. L’ora in InfluxDB è un formato UTC per impostazione predefinita.

Vediamo un esempio di misurazione (Measurement) chiamata “temperatura” legata al mondo Home Assistant, dove domain e entity sono tag, value è un field, time è il timestamp.

Time	domain	entity	friendly_name	value
2015-08-18T00:00:00Z	sensor	temperatura_camera	Temperatura in camera	10

Concetti Chiave

•  La continous query (CQ) è una query che viene eseguita automaticamente e periodicamente all’interno di un database. Le CQ richiedono una funzione nella clausola SELECT e devono includere una clausola GROUP BY time (). Qui i dettagl: https://docs.influxdata.com/influxdb/v1.8/query_language/continuous_queries/
• La retention policy (RP) è la parte della struttura dati di InfluxDB che descrive per quanto tempo InfluxDB conserva i dati. InfluxDB confronta il timestamp locale del server su cui sta girando, con i timestamp dei tuoi dati ed elimina i dati più vecchi della durata specificata nella RP. Un singolo database può avere diversi RP e gli RP sono unici per database. Qui i dettagli https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#retention-policy-management

Questi due costrutti sono essenziali per capire come lavora influxDB, andremo a chiarire meglio con un esempio legato ad Home Assistant, intanto specifichiamo che di default il database creato dall’integrazione HA crea anche una default RP di durata inifinita, questo vuol dire che i dati ricevuti da HA saranno salvati senza aggregazioni e senza cancellazioni sul DB.

Immaginiamo ora di avere un sensore di temperatura che che legge i dati ogni 5 minuti, questo significa che avremo 12 misurazioni in un’ora, in una giornata ne avremo 288 misurazioni, etc,. se abbiamo 10 sensori che misurano temperatura pressione e umidità il numero di misurazioni si moltiplica per 30; la domanda da farsi è ci interessa veramente sapere che temperatura c’era il 24 agosto 2019 alle 18:05, alle 18:10, etc? Se la risposta è si allora le potenzialità di un TSDB non vi servono, a voi interessa conservare dati grezzi all’infinito con tutte le problematiche che ne conseguono (spazio, tempo di elaborazione, etc), se invece la risposta è no potrebbe avere un senso conservare per un tempo lungo la media oraria (quindi la media delle 12 misurazioni tra le 18 e le 18:59) della temperatura e per un tempo più breve i dati grezzi.

Chronograph, interfaccia grafica per InfluxDB

Nell’addon per Home Asisstant è presente anche l’applicazione Chronograph  che ha una serie di funzionlità piuttosto utili tra cui:

• inserimento di query/comandi
• visualizzazione di dati e grafici
• console amministrativa

Per l’inserimento di query/comandi occorre posizionarsi sul tab laterale Explore e poi nello spazio destinato alle query come in figura sottostante.

Progettare la conservazione dei dati di HA

Dopo aver esposto alcune informazione di base su come funziona InfluxDB veniamo alla parte interessante e cioè come conservare i dati della domotica di Home Assistant, di seguito espongo alcune regole che sto utilizzando anche nella mia installazione.ovviamente ognuno è libero di adattare alla propria realtà queste regole.

Retention dei dati

Le regole base di retention che ho adottato sono le seguenti:

• Dati grezzi: sono i dati ricevuti da HA, per questi dati la mia regola è di conservare i dati grezzi per 2 o 4 settimane
• Dati con aggregazione oraria:  aggregazione ottenuta facendo la media dei campioni in un’ora, sono dati conservati per 1 anno
• Dati con aggregazione giornaliera: aggregazione ottenuta facendo la media dei campioni grezzi in un giorno, questi dati hanno durata infinita, cioè non sono cancellati mai.
  

Se necessario è posibile prevedere anche una aggregazione settimanale o mensile facendo la media dei campioni grezzi nell’intervallo di tempo desiderata sempre con durata infinita. Se invece si volesse optare per per una ulteriore aggegazione dei dati conservati con RP oraria o mensile, l’importante è ricordarsi che si sta facendo la media delle medie che è un operazione diversa dalla media dei dati grezzi.

Per i dati relativi all’energia elettrica (non la potenza, mi raccomando) o cmq relativi a misure cumulative, ad esempio la pioggia caduta, aqua e gas consumati, invece che procedere con le medie dei dati grezzi, occorre aggregare la grandezza in esame tramite somma, in questo modo avrò ad esempio il mio consumo di energia elettrica con campionatura oraria, settimanale, mensile, etc.

Creazione delle Retention Policy (RP)

Come indicato nel capitolo precedente, alle tre regole descritte corrispondono tre configurazioni da inserire in InfluxDB utilizzando ad esempio la GUI Chronograph:

• RP di 4 settimane di default (denominata “4_weeks”) in modo da sostituire la policy di default autogenerata creata dall’integrazione di HA che ha una retention infinita:
  
  CREATE RETENTION POLICY "4_weeks" ON "home_assistant" DURATION 4w REPLICATION 1 DEFAULT

  1	CREATE RETENTION POLICY "4_weeks" ON "home_assistant" DURATION 4w REPLICATION 1 DEFAULT

• RP di durata 1 anno (denominata “hour_year”) non di default con lo scopo di mantenere i dati orari dell’ultimo anno:
  
  CREATE RETENTION POLICY "hour_year" ON "home_assistant" DURATION 52w REPLICATION 1

  1	CREATE RETENTION POLICY "hour_year" ON "home_assistant" DURATION 52w REPLICATION 1

• RP con durata infinita (denominata “day_infinite”) non di default, utilizzata per mantenere i dati giornalieri:
  
  CREATE RETENTION POLICY "day_infinite" ON "home_assistant" DURATION 0s REPLICATION 1

  1	CREATE RETENTION POLICY "day_infinite" ON "home_assistant" DURATION 0s REPLICATION 1

Definizione delle misurazioni

Le misurazioni (“measurement“) come detto tengono conto di diversi parametri (tag, timestamp, field, etc), in Home Assistant il comportamento di base è quello di identificare ogni misurazione con l’unità di misura, per cui avremo misurazioni relative a Watt (potenza), kWh (energia), metri cubi (gas), Volt (tensione), °C (temperatura), % (umidità), etc. con i valori associati e le informazioni del sensore, del dominio, etc.

L’integrazione di InfluxDB permette sia di scegliere quali sensori considerare nelle varie misurazioni che di cambiare il nome della misurazione: ritengo molto importante procedere con entrambe le configurazioni poichè permettono di iniziare con una situazione pulita in cui registro solo i dati che mi interessano e ogni misurazione è immediatamente identificabile:

• default_measurement: identificativo della misurazione che viene usato quando non c’è unità di misura.
• include: con questa parte di configurazione includiamo solo entità di cui ci interessa conservare i dati.
• component_config_glob e component_config: identifichiamo quali entità andranno a confluire nella misurazione.
• tags: permette di aggiungere alla misurazione alcune informazioni accessorie.

Per le altre informazioni relative alla configurazione di InfluxDB in HA rimando ai nostri precedenti articoli e alla pagina ufficiale: https://www.home-assistant.io/integrations/influxdb/

Definizione delle Continous Query (CQ)

Le Continous Query, come detto, ci permettono di prelevare in maniera del tutto automatica i dati grezzi o già precedentemente elaborati e spostarli nelle RP che abbiamo definito in precedenza, vediamo alcuni esempi:

• CP che mediano in un’ora i dati grezzi delle misurazioni “temperature” e “humidity” e salvano il risultato nella RP “hour_year“.
  
  CREATE CONTINUOUS QUERY "cq_1h_humidity" ON "home_assistant" BEGIN SELECT mean("value") AS value INTO "hour_year"."humidity" FROM "4_weeks"."humidity" GROUP BY time(1h), entity_id FILL(previous) TZ('Europe/Rome') END CREATE CONTINUOUS QUERY "cq_1h_temperature" ON "home_assistant" BEGIN SELECT mean("value") AS value INTO "hour_year"."temperature" FROM "4_weeks"."temperature" GROUP BY time(1h), entity_id FILL(previous) TZ('Europe/Rome') END

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  CREATE CONTINUOUS QUERY "cq_1h_humidity" ON "home_assistant" BEGIN   SELECT mean("value") AS value   INTO "hour_year"."humidity"   FROM "4_weeks"."humidity"   GROUP BY time(1h), entity_id   FILL(previous)   TZ('Europe/Rome') END   CREATE CONTINUOUS QUERY "cq_1h_temperature" ON "home_assistant" BEGIN   SELECT mean("value") AS value   INTO "hour_year"."temperature"   FROM "4_weeks"."temperature"   GROUP BY time(1h), entity_id   FILL(previous)   TZ('Europe/Rome') END

• CP sulla misurazioni “temperature” che calcola media, massimo e minimo giornaliero salvando il risultato nella RP “day_infinite“, con field diversificati per i tre valori.
  
  CREATE CONTINUOUS QUERY "cq_1d_temperature" ON "home_assistant" BEGIN SELECT min("value") AS value_min, mean("value") AS value, max("value") as value_max INTO "day_infinite"."temperature" FROM "4_weeks"."temperature" GROUP BY time(1d), entity_id TZ('Europe/Rome') END

  1 2 3 4 5 6 7 8

  CREATE CONTINUOUS QUERY "cq_1d_temperature" ON "home_assistant" BEGIN   SELECT min("value") AS value_min, mean("value") AS value, max("value") as value_max   INTO "day_infinite"."temperature"   FROM "4_weeks"."temperature"   GROUP BY time(1d), entity_id   TZ('Europe/Rome') END

• CP che effettua l’integrale della “misurazione” potenza recuperata dai dati grezzi e salva il risultato nella RP “hour_infinite“, il valore viene salvato nel field “value_energy” che avrà come unita di misura il Wh (wattora).
  
  CREATE CONTINUOUS QUERY "cq_1h_energy" ON "home_assistant" BEGIN SELECT integral("value") / 3600 AS value_energy INTO "hour_year"."energy" FROM "4_weeks"."power" GROUP BY time(1h), entity_id TZ('Europe/Rome') END

  1 2 3 4 5 6 7 8

  CREATE CONTINUOUS QUERY "cq_1h_energy" ON "home_assistant" BEGIN   SELECT integral("value") / 3600 AS value_energy   INTO "hour_year"."energy"   FROM "4_weeks"."power"   GROUP BY time(1h), entity_id   TZ('Europe/Rome') END

Come linea generale sarebbero da evitare più RP all’interno di un singolo database a meno che non si abbia una giustificazione particolare per farlo, il motivo è che se sono presenti più RP all’interno di un singolo database, le query dovranno fare riferimento esplicitamente alle RP (con la dicutura db.policy..measurement ad esempio home_asisstant.2_weeks.power) quando si opera sui dati. Questo renderà le tue query meno robuste a causa dei riferimenti espliciti ad una retention policy.

L’approccio migliore sarebbe quello di definire un  DB separato in modo specifico per tutti i dati a lungo termine che si desidera conservare. In questo modo sarà facile modificare le RP in un secondo momento.Questo dovrebbe essere  l’approccio da seguire nel caso di installazioni “enterprise”, con un DB per i dati grezzi con durata minima ed uno per i dati storici di lunga durata.

Per i dati HA l’approccio proposto è quello del singolo DB e tre retention policy, vedremo nel tempo se proporre una strategia più sofisticata.

Conclusioni

Una volta effettuate le operazioni descritte nell’articolo per tutte le “misurazioni” che ci interessa conservare, il passo successivo è impostare come descritto nel nostro articolo (qui il link) l’accesso ad InfluxdB da Grafana, e creare i grafici/ cruscotti (“dashboard”) che più ci interessano, come nell’esempio sottostante creato per i consumi elettrici:

Ricordo sempre che gli articoli devono essere fonte di sviluppo e riflessione per poter creare le proprie configurazioni e personalizzazioni: quello che va bene per me nella mia infrastruttura non è detto che sia repicabile integralmente per voi nella vostra.

Se avete qualcosa da suggerire ci vediamo nei gruppi Telegram e Facebook.

Alcuni link utili:

• InfluxDB: https://docs.influxdata.com/influxdb/v1.8/
• InfluxDB RP best practices: https://www.influxdata.com/blog/simplifying-influxdb-retention-policy-best-practices/
• InfluxDB e Grafana: https://www.influxdata.com/blog/how-to-use-grafana-with-influxdb-to-monitor-time-series-data/

Sostienici, dona un caffè al nostro sito