Smart Home: tracciare il consumo di acqua ed elettricità in Home Assistant

Ogni volta che ricevo un pagamento per l'elettricità e l'acqua, mi chiedo: la mia famiglia consuma davvero così tanto? Ebbene sì, c'è un pavimento riscaldato e una caldaia in bagno, ma non lavorano sempre come vigili del fuoco. Ci sembra anche di risparmiare acqua (anche se ci piace anche sguazzare in bagno). Alcuni anni fa ho già contatori d'acqua collegati и elettricità a una casa intelligente, ma è qui che le cose si sono bloccate. Le mani sono arrivate solo ora all'analisi dei consumi, che, in effetti, è l'argomento di questo articolo.

Di recente sono passato a Home Assistant come sistema per la casa intelligente. Uno dei motivi era proprio la possibilità di organizzare la raccolta di una grande mole di dati con la possibilità di costruire comodamente vari tipi di grafici.

Le informazioni descritte in questo articolo non sono nuove, tutte queste cose sotto diverse salse sono già state descritte su Internet. Ma ogni articolo, di regola, descrive solo un approccio o un aspetto. Ho dovuto confrontare tutti questi approcci e scegliere io stesso quello più adatto. L'articolo non fornisce ancora informazioni esaustive sulla raccolta dei dati, ma è una sorta di riassunto di come l'ho fatto. Quindi critiche costruttive e suggerimenti per il miglioramento sono i benvenuti.

Formulazione del problema

Quindi, l'obiettivo dell'esercizio di oggi è ottenere bellissimi grafici del consumo di acqua ed elettricità:

• Ogni ora per 2 giorni
• Quotidianamente per 2 settimane
• (facoltativo) settimanale e mensile

Ci sono alcune difficoltà in questo:

• I componenti grafici standard tendono ad essere piuttosto scadenti. Nella migliore delle ipotesi, puoi costruire un grafico a linee per punti.

  Se cerchi bene, puoi trovare componenti di terze parti che estendono le capacità del grafico standard. Per l'assistente domestico, in linea di principio, un componente buono e bello mini scheda grafica, ma è anche piuttosto limitato:

  • È difficile impostare i parametri del grafico a barre a grandi intervalli (la larghezza della barra è impostata in frazioni di un'ora, il che significa che gli intervalli più lunghi di un'ora saranno impostati in numeri frazionari)
  • Non è possibile aggiungere entità diverse a un grafico (ad esempio, temperatura e umidità o combinare un grafico a barre con una linea)
• Non solo l'assistente domestico utilizza per impostazione predefinita il database SQLite più primitivo (e io, il tuttofare, non padroneggiavo l'installazione di MySQL o Postgres), ma i dati non vengono archiviati nel modo più ottimale. Quindi, ad esempio, ad ogni modifica anche del più piccolo parametro digitale di un parametro, nel database viene scritto un enorme json di circa un kilobyte

  {"entity_id": "sensor.water_cold_hourly", "old_state": {"entity_id": "sensor.water_cold_hourly", "state": "3", "attributes": {"source": "sensor.water_meter_cold", "status": "collecting", "last_period": "29", "last_reset": "2020-02-23T21:00:00.022246+02:00", "meter_period": "hourly", "unit_of_measurement": "l", "friendly_name": "water_cold_hourly", "icon": "mdi:counter"}, "last_changed": "2020-02-23T19:05:06.897604+00:00", "last_updated": "2020-02-23T19:05:06.897604+00:00", "context": {"id": "aafc8ca305ba4e49ad4c97f0eddd8893", "parent_id": null, "user_id": null}}, "new_state": {"entity_id": "sensor.water_cold_hourly", "state": "4", "attributes": {"source": "sensor.water_meter_cold", "status": "collecting", "last_period": "29", "last_reset": "2020-02-23T21:00:00.022246+02:00", "meter_period": "hourly", "unit_of_measurement": "l", "friendly_name": "water_cold_hourly", "icon": "mdi:counter"}, "last_changed": "2020-02-23T19:11:11.251545+00:00", "last_updated": "2020-02-23T19:11:11.251545+00:00", "context": {"id": "0de64b8af6f14bb9a419dcf3b200ef56", "parent_id": null, "user_id": null}}}

  Ho parecchi sensori (sensori di temperatura in ogni stanza, contatori dell'acqua e dell'elettricità) e alcuni generano anche molti dati. Ad esempio, solo il contatore elettrico SDM220 genera circa una dozzina di valori ogni 10-15 secondi e vorrei installare tali contatori 8. E c'è anche tutta una serie di parametri che vengono calcolati sulla base di altri sensori. Quello. tutti questi valori possono facilmente gonfiare il database di 100-200 MB al giorno. In una settimana, il sistema si girerà a malapena e in un mese l'unità flash morirà (nel caso di una tipica installazione di un assistente domestico su Raspberry PI) e non si può parlare di archiviazione dei dati per un anno intero.

• Se sei fortunato, il tuo contatore stesso può contare il consumo. Puoi contattare il contatore in qualsiasi momento e chiedere a che ora è il valore del consumo accumulato. Di norma, tutti i contatori elettrici dotati di interfaccia digitale (RS232/RS485/Modbus/Zigbee) offrono tale possibilità.

  Peggio ancora, se il dispositivo può semplicemente misurare alcuni parametri istantanei (ad esempio, potenza o corrente istantanea) o semplicemente generare impulsi ogni X wattora o litri. Poi bisogna pensare a come e con cosa integrarlo e dove accumulare valore. C'è il rischio di perdere il rapporto successivo per qualsiasi motivo e l'accuratezza del sistema nel suo insieme solleva interrogativi. Ovviamente puoi affidare tutto questo a un sistema di casa intelligente come l'assistente domestico, ma nessuno ha cancellato il punto sul numero di voci nel database e il polling dei sensori più di una volta al secondo non funzionerà (una limitazione dell'architettura dell'assistente domestico).

Approccio 1

Per prima cosa, vediamo quale assistente domestico viene fornito fuori dagli schemi. La misurazione del consumo in un periodo è una funzionalità molto richiesta. Naturalmente, è stato implementato molto tempo fa come componente specializzato: utility_meter.

L'essenza del componente è che avvia la variabile current_accumulated_value all'interno e la reimposta dopo un periodo specificato (ora/settimana/mese). Il componente stesso monitora la variabile in ingresso (il valore di un qualche tipo di sensore), si iscrive ai cambiamenti nel valore stesso: ottieni solo il risultato finale. Questa cosa è descritta in poche righe nel file di configurazione

utility_meter:
  water_cold_hour_um:
    source: sensor.water_meter_cold
    cycle: hourly
  water_cold_day_um:
    source: sensor.water_meter_cold
    cycle: daily

Qui sensor.water_meter_cold è il valore corrente del contatore in litri che ottengo direttamente dal ferro di mqtt. Il progetto crea 2 nuovi sensori water_cold_hour_um e water_cold_day_um, che accumulano letture orarie e giornaliere, azzerandole dopo un periodo. Ecco un grafico della batteria oraria per mezza giornata.

Il codice del grafico orario e giornaliero per lovelace-UI è simile al seguente:

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

In realtà, in questo algoritmo risiede il problema di questo approccio. Come ho già accennato, per ogni valore in entrata (l'attuale lettura del contatore per ogni litro successivo), nel database viene generato 1kb di un record. Ogni contatore dell'utenza genera anche un nuovo valore, che viene anche aggiunto alla base. Se voglio raccogliere letture orarie/giornaliere/settimanali/mensili, sì, per diverse colonne montanti dell'acqua, e anche aggiungere un pacchetto di contatori elettrici, saranno molti dati. Ebbene, più precisamente, non ci sono molti dati, ma poiché l'assistente domestico scrive un mucchio di informazioni non necessarie nel database, le dimensioni del database aumenteranno a passi da gigante. Ho persino paura di stimare la dimensione della base per i grafici settimanali e mensili.

Inoltre, il contatore stesso non risolve il problema. Il grafico del contatore di utilità è una funzione crescente in modo monotono che si azzera a 0 ogni ora. Abbiamo anche bisogno di un programma di consumo intuitivo, quanti litri sono stati consumati durante il periodo. Il componente grafico cronologico standard non lo fa, ma il componente esterno mini-scheda grafica può aiutarci.

Questo è il codice della carta per lovelace-UI:

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_hour_um
        group_by: hour
        hours_to_show: 48
        name: "Hourly water consumption aggregated by utility meter"
        points_per_hour: 1
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Oltre alle impostazioni standard come il nome del sensore, il tipo di grafico, il colore (non mi piaceva l'arancione standard), è importante notare 3 impostazioni qui:

• group_by:hour - il grafico verrà generato con colonne allineate all'inizio dell'ora
• points_per_hour: 1 - una barra all'ora
• E, cosa più importante, aggregate_func: max è prendere il valore massimo entro ogni ora. È questo parametro che trasforma il grafico a dente di sega in barre.

Non prestare attenzione alla riga di colonne a sinistra: questo è il comportamento standard del componente se non ci sono dati. Ma non c'erano dati: ho attivato la raccolta dei dati utilizzando il misuratore di utilità solo un paio d'ore fa solo per il bene di questo articolo (descriverò il mio approccio attuale un po 'più in basso).

In questa immagine, volevo mostrare che a volte la visualizzazione dei dati funziona anche e le barre riflettono davvero i valori corretti. Ma non è tutto. Per qualche motivo, la colonna evidenziata per il periodo dalle 11:12 alle 19:62 mostra XNUMX litri, anche se sul grafico a trentadue denti leggermente più alto per lo stesso periodo dallo stesso sensore vediamo un consumo di XNUMX litri. O un insetto o le mani sono storte. Ma ancora non capisco perché i dati a destra si siano interrotti: il consumo era normale, il che è visibile anche dal grafico a trentadue denti.

In generale, non sono riuscito a raggiungere la plausibilità di questo approccio: il grafico mostra quasi sempre una sorta di eresia.

Codice simile per il sensore diurno.

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_day_um
        group_by: interval
        hours_to_show: 360
        name: "Daily water consumption aggregated by utility meter"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

Tieni presente che il parametro group_by è impostato su intervallo e il parametro points_per_hour regola tutto. E questo è un altro problema con questo componente: points_per_hour funziona bene su grafici di un'ora o meno, ma disgustosamente su intervalli più ampi. Quindi, per ottenere una colonna in un giorno, ho dovuto inserire il valore 1/24=0.04166666. Non sto parlando di grafici settimanali e mensili.

Approccio 2

Mentre stavo ancora cercando di capire l'assistente domestico, mi sono imbattuto in questo video:

Il compagno raccoglie i dati di consumo da diversi tipi di prese Xiaomi. Il suo compito è un po' più semplice: basta visualizzare il valore del consumo per oggi, ieri e per il mese. Nessun grafico richiesto.

Lasciamo da parte gli argomenti sull'integrazione manuale dei valori di potenza istantanei - ho già scritto sulla "precisione" di questo approccio sopra. Non è chiaro perché non abbia utilizzato i valori di consumo accumulati, che sono già raccolti dallo stesso punto vendita. Secondo me l'integrazione all'interno del pezzo di ferro funzionerà meglio.

Dal video prenderemo l'idea di contare manualmente i consumi per un periodo. Per un uomo vengono considerati solo i valori di oggi e di ieri, ma andremo oltre e proveremo a tracciare un grafico. L'essenza del metodo proposto nel mio caso è la seguente.

Creeremo una variabile value_at_the_beginning_of_hour, in cui scriveremo le letture correnti del contatore
In base al timer alla fine dell'ora (o all'inizio della successiva), calcoliamo la differenza tra la lettura corrente e quella memorizzata all'inizio dell'ora. Questa differenza sarà il consumo per l'ora corrente: salveremo il valore sul sensore e in futuro costruiremo un grafico basato su questo valore.
È inoltre necessario "resettare" la variabile value_at_beginning_of_hour scrivendo lì il valore corrente del contatore.

Tutto questo può essere fatto bene ... tramite lo stesso assistente domestico.

Dovrai scrivere un po' più di codice rispetto all'approccio precedente. Cominciamo con queste "variabili". Fuori dagli schemi, non abbiamo l'entità "variabile", ma puoi utilizzare i servizi di un broker mqtt. Invieremo i valori lì con il flag retain=true: questo salverà il valore all'interno del broker e potrà essere estratto in qualsiasi momento, anche quando l'assistente domestico viene riavviato. Ho creato contatori orari e giornalieri contemporaneamente.

- platform: mqtt
  state_topic: "test/water/hour"
  name: water_hour
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/hour_begin"
  name: water_hour_begin
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day"
  name: water_day
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day_begin"
  name: water_day_begin
  unit_of_measurement: l

Tutta la magia avviene nell'automazione, che funziona rispettivamente ogni ora e ogni notte.

- id: water_new_hour
  alias: water_new_hour
  initial_state: true
  trigger:
    - platform: time_pattern
      minutes: 0
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/hour"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_hour_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/hour_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

- id: water_new_day
  alias: water_new_day
  initial_state: true
  trigger:
    - platform: time
      at: "00:00:00"
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/day"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_day_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/day_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

Entrambe le automazioni fanno 2 cose:

• Calcolare il valore per intervallo come differenza tra il valore iniziale e quello finale
• Aggiorna il valore di base per l'intervallo successivo

La costruzione dei grafici in questo caso è risolta dal solito grafico storico:

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

Sembra questo:

In linea di principio, questo è già ciò di cui hai bisogno. Il vantaggio di questo metodo è che i dati vengono generati una volta per intervallo. Quelli. un totale di 24 voci al giorno per il grafico orario.

Sfortunatamente, questo non risolve ancora il problema generale di una base in crescita. Se voglio un grafico del consumo mensile, devo archiviare i dati per almeno un anno. E poiché l'assistente domestico fornisce solo un'impostazione della durata dell'archiviazione per l'intero database, ciò significa che TUTTI i dati nel sistema dovranno essere archiviati per un anno intero. Ad esempio, in un anno consumo 200 metri cubi di acqua, il che significa 200000 voci nel database. E se prendi in considerazione altri sensori, la cifra diventa generalmente indecente.

Approccio 3

Fortunatamente, persone intelligenti hanno già risolto questo problema scrivendo il database InfluxDB. Questo database è appositamente ottimizzato per la memorizzazione di dati basati sul tempo ed è ideale per memorizzare i valori di diversi sensori. Il sistema mette a disposizione anche un linguaggio di interrogazione simile a SQL che permette di estrarre valori dal database per poi aggregarli in vari modi. Infine, dati diversi possono essere memorizzati per tempi diversi. Ad esempio, le letture che cambiano frequentemente come la temperatura o l'umidità possono essere memorizzate solo per un paio di settimane, mentre le letture giornaliere del consumo idrico possono essere memorizzate per un anno intero.

Oltre a InfluxDB, persone intelligenti hanno anche inventato Grafana, un sistema per disegnare grafici dai dati di InfluxDB. Grafana può disegnare diversi tipi di grafici, personalizzarli in dettaglio e, cosa più importante, questi grafici possono essere "inseriti" nell'assistente domestico lovelace-UI.

essere inspirati qui и qui. Gli articoli descrivono in dettaglio il processo di installazione e connessione di InfluxDB e Grafana all'assistente domestico. Mi concentrerò sulla risoluzione del mio problema specifico.

Quindi, prima di tutto, iniziamo ad aggiungere il valore del contatore in influxDB. Un pezzo della configurazione dell'assistente domestico (in questo esempio mi divertirò non solo con il freddo, ma anche con l'acqua calda):

influxdb:
  host: localhost
  max_retries: 3
  default_measurement: state
  database: homeassistant
  include:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

Disattiviamo il salvataggio degli stessi dati nel database interno di home assistant, per non gonfiarlo ancora una volta:

recorder:
  purge_keep_days: 10
  purge_interval: 1
  exclude:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

Andiamo ora alla console di InfluxDB e impostiamo il nostro database. In particolare, è necessario configurare per quanto tempo verranno archiviati determinati dati. Questo è regolato dal cosiddetto. criterio di conservazione: è simile ai database all'interno del database principale, con ogni database interno con le proprie impostazioni. Per impostazione predefinita, tutti i dati vengono aggiunti al criterio di conservazione chiamato autogen, questi dati verranno archiviati per una settimana. Vorrei che i dati orari venissero archiviati per un mese, i dati settimanali per un anno e i dati mensili non venissero mai cancellati. Creeremo politiche di conservazione appropriate

CREATE RETENTION POLICY "month" ON "homeassistant" DURATION 30d REPLICATION 1
CREATE RETENTION POLICY "year" ON "homeassistant" DURATION 52w REPLICATION 1
CREATE RETENTION POLICY "infinite" ON "homeassistant" DURATION INF REPLICATION 1

Ora, infatti, il trucco principale è l'aggregazione dei dati utilizzando la query continua. Si tratta di un meccanismo che avvia automaticamente una query a intervalli specificati, aggrega i dati per questa query e aggiunge il risultato a un nuovo valore. Diamo un'occhiata a un esempio (scrivo in una colonna per leggibilità, ma in realtà ho dovuto inserire questo comando su una riga)

CREATE CONTINUOUS QUERY cq_water_hourly ON homeassistant 
BEGIN 
  SELECT max(value) AS value 
  INTO homeassistant.month.water_meter_hour 
  FROM homeassistant.autogen.l 
  GROUP BY time(1h), entity_id fill(previous) 
END

Questo comando:

• Crea una query continua denominata cq_water_cold_hourly nel database homeassistant
• La query verrà eseguita ogni ora (time(1h))
• La query estrarrà tutti i dati dalla misurazione'a homeassistant.autogen.l (litri), comprese le letture di acqua fredda e calda
• I dati aggregati verranno raggruppati per entity_id, che creerà valori separati per l'acqua fredda e calda.
• Poiché il contatore di litri è una sequenza crescente in modo monotono all'interno di ogni ora, sarà necessario assumere il valore massimo, quindi l'aggregazione verrà effettuata dalla funzione max(valore)
• Il nuovo valore verrà scritto in homeassistant.month.water_meter_hour dove month è il nome del criterio di conservazione con un periodo di conservazione di un mese. Inoltre, i dati sull'acqua fredda e calda saranno sparsi in record separati con l'entità_id corrispondente e il valore nel campo valore

Di notte o quando non c'è nessuno in casa, non c'è consumo di acqua, e di conseguenza non ci sono nuovi record neanche in homeassistant.autogen.l. Per evitare valori mancanti nelle query normali, puoi utilizzare fill(previous). Ciò costringerà InfluxDB a utilizzare il valore dell'ultima ora.

Sfortunatamente, la query continua ha una particolarità: il trucco fill(previous) non funziona e i record semplicemente non vengono creati. Inoltre, questa è una sorta di problema insormontabile, che se ne discute da più di un anno. Ci occuperemo di questo problema in seguito e lasceremo che fill(precedente) in una query continua sia lì - non interferisce.

Controlliamo cosa è successo (ovviamente, devi aspettare un paio d'ore):

> select * from homeassistant.month.water_meter_hour group by entity_id
...
name: water_meter_hour
tags: entity_id=water_meter_cold
time                 value
----                 -----
...
2020-03-08T01:00:00Z 370511
2020-03-08T02:00:00Z 370513
2020-03-08T05:00:00Z 370527
2020-03-08T06:00:00Z 370605
2020-03-08T07:00:00Z 370635
2020-03-08T08:00:00Z 370699
2020-03-08T09:00:00Z 370761
2020-03-08T10:00:00Z 370767
2020-03-08T11:00:00Z 370810
2020-03-08T12:00:00Z 370818
2020-03-08T13:00:00Z 370827
2020-03-08T14:00:00Z 370849
2020-03-08T15:00:00Z 370921

Si noti che i valori nel database sono memorizzati in UTC, quindi questo elenco differisce di 3 ore: i valori delle 7:10 nell'output di InfluxDB corrispondono ai valori delle 2:5 nei grafici sopra. Si noti inoltre che tra le XNUMX e le XNUMX del mattino semplicemente non ci sono record: questa è la caratteristica stessa della query continua.

Come puoi vedere, anche il valore aggregato è una sequenza crescente in modo monotono, solo che le voci sono meno frequenti, una volta all'ora. Ma questo non è un problema: possiamo scrivere un'altra query che estrarrà i dati corretti per il grafico.

SELECT difference(max(value)) 
FROM homeassistant.month.water_meter_hour 
WHERE entity_id='water_meter_cold' and time >= now() -24h 
GROUP BY time(1h), entity_id 
fill(previous)

Decifrerò:

• Dal database homeassistant.month.water_meter_hour, estrarremo i dati per entity_id='water_meter_cold' per l'ultimo giorno (time >= now() -24h).
• Come ho già detto, alcune voci potrebbero mancare nella sequenza homeassistant.month.water_meter_hour. Rigenereremo questi dati eseguendo la query con GROUP BY time(1h). Questa volta, fill(previous) funzionerà correttamente, generando i dati mancanti (la funzione prenderà il valore precedente)
• La cosa più importante in questa query è la funzione differenza, che calcolerà la differenza tra i segni delle ore. Di per sé, non funziona e richiede una funzione di aggregazione. Lascia che questo sia il max() usato prima.

Il risultato dell'esecuzione è simile a questo

name: water_meter_hour
tags: entity_id=water_meter_cold
time                 difference
----                 ----------
...
2020-03-08T02:00:00Z 2
2020-03-08T03:00:00Z 0
2020-03-08T04:00:00Z 0
2020-03-08T05:00:00Z 14
2020-03-08T06:00:00Z 78
2020-03-08T07:00:00Z 30
2020-03-08T08:00:00Z 64
2020-03-08T09:00:00Z 62
2020-03-08T10:00:00Z 6
2020-03-08T11:00:00Z 43
2020-03-08T12:00:00Z 8
2020-03-08T13:00:00Z 9
2020-03-08T14:00:00Z 22
2020-03-08T15:00:00Z 72

Dalle 2:5 alle 0:XNUMX (UTC) non c'era consumo. Tuttavia, la query restituirà lo stesso valore di consumo grazie a fill(previous) e la funzione difference sottrarrà questo valore da se stessa e otterrà XNUMX in output, che è effettivamente richiesto.

L'unica cosa che resta da fare è costruire un grafico. Per fare ciò, apri Grafana, apri una dashboard esistente (o creane una nuova), crea un nuovo pannello. Le impostazioni del grafico saranno le seguenti.

Visualizzerò i dati dell'acqua fredda e calda sullo stesso grafico. La richiesta è esattamente la stessa che ho descritto sopra.

I parametri di visualizzazione sono impostati come segue. Per me sarà un grafico con linee (linee), che va a gradini (scale). Il parametro Stack verrà spiegato di seguito. Di seguito ci sono un paio di opzioni di visualizzazione in più, ma non sono così interessanti.

Per aggiungere il grafico risultante all'assistente domestico, devi:

• uscire dalla modalità di modifica del grafico. Per qualche motivo, le impostazioni di condivisione del grafico corrette vengono offerte solo dalla pagina del dashboard
• Fai clic sul triangolo accanto al nome del grafico, seleziona condividi dal menu
• Nella finestra che si apre, vai alla scheda di incorporamento
• Deseleziona l'intervallo di tempo corrente: imposteremo l'intervallo di tempo tramite URL
• Seleziona l'argomento richiesto. Nel mio caso è leggero
• Copia l'URL risultante nella scheda delle impostazioni dell'interfaccia utente di lovelace

      - type: iframe
        id: graf_water_hourly
        url: "http://192.168.10.200:3000/d-solo/rZARemQWk/water?orgId=1&panelId=2&from=now-2d&to=now&theme=light"

Tieni presente che l'intervallo di tempo (ultimi 2 giorni) è impostato qui e non nelle impostazioni della dashboard.

Il grafico ha questo aspetto. Non ho usato acqua calda negli ultimi 2 giorni, quindi viene disegnato solo un grafico di acqua fredda.

Non ho deciso da solo quale grafico mi piace di più, una linea di passi o barre reali. Pertanto, fornirò semplicemente un esempio di un programma di consumo giornaliero, solo questa volta nei bar. Le query sono costruite nello stesso modo descritto sopra. Le opzioni di visualizzazione sono:

Questo grafico ha questo aspetto:

Quindi, riguardo al parametro Stack. In questo grafico, una barra dell'acqua fredda è disegnata sopra una barra calda. L'altezza totale corrisponde al consumo totale di acqua fredda e calda per il periodo.

Tutti i grafici mostrati sono dinamici. Puoi spostare il mouse sopra il punto di interesse e vedere i dettagli e il valore in un punto particolare.

Sfortunatamente, non è stato senza un paio di neo. Su un grafico a barre (a differenza del grafico con linee di passaggio), il centro della barra non è a metà giornata, ma alle 00:00. Quelli. la metà sinistra della barra viene disegnata al posto del giorno precedente. Quindi i grafici per sabato e domenica sono disegnati un po' a sinistra della zona bluastra. Finché non ho capito come vincerlo.

Un altro problema è l'incapacità di lavorare correttamente con intervalli mensili. Il fatto è che la lunghezza dell'ora/giorno/settimana è fissa, ma la durata del mese è diversa ogni volta. InfluxDB può funzionare solo con intervalli uguali. Finora, il mio cervello è stato sufficiente per impostare un intervallo fisso di 30 giorni. Sì, il grafico fluttuerà un po' durante l'anno e le barre non corrisponderanno esattamente ai mesi. Ma poiché questa cosa è interessante per me solo come misuratore di visualizzazione, sono d'accordo con questo.

Vedo almeno due soluzioni:

• Per segnare nei grafici mensili e limitarti a quelli settimanali. 52 barre settimanali in un anno sembrano abbastanza buone
• Considera il consumo mensile stesso come metodo n. 2 e usa la grafana solo per bei grafici. È una soluzione piuttosto accurata. Puoi persino sovrapporre i grafici dell'anno passato per il confronto: grafana può farlo.

conclusione

Non so perché, ma adoro questo tipo di classifiche. Mostrano che la vita è in pieno svolgimento e tutto sta cambiando. Ieri c'era molto, oggi c'è poco, domani ci sarà qualcos'altro. Resta da lavorare con le famiglie sul tema del consumo. Ma anche con gli attuali appetiti, solo una cifra grande e incomprensibile in bolletta si sta già trasformando in un quadro abbastanza comprensibile del consumo.

Nonostante la mia carriera di programmatore di quasi 20 anni, praticamente non mi sono intersecato con i database. Pertanto, l'installazione di un database esterno sembrava qualcosa di così astruso e incomprensibile. Tutto è cambiato l'articolo di cui sopra - si è scoperto che l'avvitamento di uno strumento adatto viene eseguito in un paio di clic e con uno strumento specializzato il compito di tracciare diventa un po 'più semplice.

Nel titolo ho citato il consumo di elettricità. Purtroppo al momento non posso fornire alcun grafico. Un misuratore SDM120 è guasto e l'altro è difettoso quando si accede tramite Modbus. Tuttavia, ciò non influisce in alcun modo sull'argomento di questo articolo: i grafici saranno costruiti allo stesso modo dell'acqua.

In questo articolo, ho fornito quegli approcci che ho provato io stesso. Sicuramente ci sono altri modi per organizzare la raccolta e la visualizzazione dei dati che non conosco. Raccontamelo nei commenti, sarò molto interessato. Sarò lieto di critiche costruttive e nuove idee. Spero che anche il materiale di cui sopra possa aiutare qualcuno.

Fonte: habr.com