Smart Home: Gráfica do consumo de auga e electricidade en Home Assistant

Cada vez que recibo un pago por electricidade e auga, pregúntome: a miña familia realmente consume moito? Ben, si, hai un chan calefaccionado e unha caldeira no baño, pero non traballan como bombeiros todo o tempo. Tamén parece que aforramos auga (aínda que tamén nos gusta salpicar no baño). Hai uns anos xa contadores de auga conectados и electricidade a unha casa intelixente, pero aquí é onde as cousas quedaron atascadas. As mans chegaron só agora á análise do consumo, do que, de feito, trata este artigo.

Recentemente cambiei ao Home Assistant como o meu sistema doméstico intelixente. Unha das razóns foi só a capacidade de organizar a recollida dunha gran cantidade de datos coa posibilidade de construír convenientemente varios tipos de gráficos.

A información descrita neste artigo non é nova, todas estas cousas en diferentes salsas xa foron descritas en Internet. Pero cada artigo, por regra xeral, describe só un enfoque ou aspecto. Tiven que comparar todos estes enfoques e escoller eu mesmo o máis axeitado. O artigo aínda non ofrece información exhaustiva sobre a recollida de datos, pero é unha especie de resumo de como o fixen. Así que se aceptan críticas construtivas e suxestións de mellora.

Declaración de problemas

Entón, o obxectivo do exercicio de hoxe é obter fermosas gráficas do consumo de auga e electricidade:

• Cada hora durante 2 días
• Diariamente durante 2 semanas
• (opcional) semanal e mensual

Hai algunhas dificultades nisto:

• Os compoñentes estándar do gráfico tenden a ser bastante pobres. Ao mellor, podes construír un gráfico de liñas por puntos.

  Se buscas ben, podes atopar compoñentes de terceiros que amplían as capacidades do gráfico estándar. Para o asistente doméstico, en principio, un bo e fermoso compoñente mini tarxeta gráfica, pero tamén é algo limitado:

  • É difícil establecer os parámetros do gráfico de barras a grandes intervalos (o ancho da barra establécese en fraccións de hora, o que significa que os intervalos superiores a unha hora estableceranse en números fraccionarios)
  • Non pode engadir diferentes entidades a un gráfico (por exemplo, temperatura e humidade, nin combinar un gráfico de barras cunha liña)
• Non só o asistente doméstico utiliza a base de datos SQLite máis primitiva por defecto (e eu, o manitas, non dominaba a instalación de MySQL ou Postgres), os datos non se almacenan da forma máis óptima. Así, por exemplo, con cada cambio de cada un, incluso o máis pequeno parámetro dixital dun parámetro, escríbese na base de datos un enorme json de aproximadamente 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}}}

  Teño bastantes sensores (sensores de temperatura en cada habitación, contadores de auga e electricidade), e algúns tamén xeran bastantes datos. Por exemplo, só o contador de electricidade SDM220 xera preto dunha ducia de valores cada 10-15 segundos, e gustaríame instalar estes medidores 8. E tamén hai un montón de parámetros que se calculan en función doutros sensores. Iso. todos estes valores poden inflar facilmente a base de datos entre 100 e 200 MB diarios. Nunha semana, o sistema apenas dará voltas e nun mes a unidade flash morrerá (no caso dunha instalación típica de asistente doméstico en Raspberry PI), e non cabe cuestión de almacenar datos durante todo un ano.

• Se tes sorte, o teu propio contador pode contar o consumo. Podes contactar co contador en calquera momento e preguntar a que hora é o valor do consumo acumulado. Como regra xeral, todos os contadores de electricidade que teñen unha interface dixital (RS232/RS485/Modbus/Zigbee) ofrecen esta oportunidade.

  Peor aínda, se o dispositivo pode simplemente medir algún parámetro instantáneo (por exemplo, potencia ou corrente instantánea) ou simplemente xerar pulsos cada X vatios-hora ou litros. Despois hai que pensar como e con que integralo e onde acumular valor. Existe o risco de perder o seguinte informe por calquera motivo, e a precisión do sistema no seu conxunto suscita dúbidas. Por suposto, podes confiar todo isto a un sistema doméstico intelixente como o asistente doméstico, pero ninguén cancelou o punto sobre o número de entradas na base de datos e os sensores de sondeo máis dunha vez por segundo non funcionarán (unha limitación do auxiliar de arquitectura).

Aproximación 1

En primeiro lugar, vexamos que asistente doméstico se proporciona fóra da caixa. Medir o consumo nun período é unha funcionalidade moi solicitada. Por suposto, implementouse hai moito tempo como un compoñente especializado: utility_meter.

A esencia do compoñente é que inicia a variable current_accumulated_value dentro e restablecea despois dun período especificado (hora/semana/mes). O propio compoñente supervisa a variable entrante (o valor dalgún tipo de sensor), subscríbese aos cambios no propio valor: só obtén o resultado final. Esta cousa descríbese en poucas liñas no ficheiro de configuración

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

Aquí sensor.water_meter_cold é o valor actual do medidor en litros que recibo directamente do ferro por mqtt. O deseño crea dous novos sensores water_cold_hour_um e water_cold_day_um, que acumulan lecturas horarias e diarias, restablecéndoas a cero despois dun período. Aquí tes un gráfico da batería horaria durante medio día.

O código do gráfico horario e diario para lovelace-UI ten o seguinte aspecto:

      - 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

En realidade, neste algoritmo reside o problema deste enfoque. Como xa mencionei, para cada valor entrante (a lectura actual do contador para cada litro seguinte), xérase 1 kb dun rexistro na base de datos. Cada contador de utilidade tamén xera un novo valor, que tamén se engade á base. Se quero recoller lecturas horarias/diarias/semanais/mensuais, iso si, para varias subidas de auga, e mesmo engadir un paquete de contadores eléctricos, estes serán moitos datos. Ben, máis precisamente, non hai moitos datos, pero como o asistente doméstico escribe unha morea de información innecesaria na base de datos, o tamaño da base de datos crecerá a pasos agigantados. Mesmo teño medo de estimar o tamaño da base para os gráficos semanais e mensuais.

Ademais, o propio contador de servizos públicos non resolve o problema. O gráfico do contador de servizos públicos é unha función crecente monótona que se reinicia a 0 cada hora. Tamén necesitamos un horario de consumo amigable, cantos litros se consumiron durante o período. O compoñente estándar de gráficos históricos non fai isto, pero o compoñente de mini-tarxeta gráfica externa pode axudarnos.

Este é o código da tarxeta para 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'

Ademais das configuracións estándar como o nome do sensor, o tipo de gráfico, a cor (non me gustou a laranxa estándar), é importante ter en conta 3 opcións aquí:

• group_by:hour: o gráfico xerarase con columnas aliñadas ao comezo da hora
• points_per_hour: 1 - unha barra por hora
• E o máis importante, aggregate_func: max é tomar o valor máximo dentro de cada hora. É este parámetro o que converte o gráfico de dentes de serra en barras.

Non prestes atención á fila de columnas da esquerda: este é o comportamento estándar do compoñente se non hai datos. Pero non había datos: só activei a recollida de datos usando o contador de servizos públicos hai un par de horas só por este artigo (describirei o meu enfoque actual un pouco máis baixo).

Nesta imaxe, quería mostrar que ás veces a visualización de datos incluso funciona e que as barras realmente reflicten os valores correctos. Pero iso non é todo. Por algún motivo, a columna destacada para o período de 11 a 12 mostra 19 litros, aínda que na gráfica dentada un pouco máis alta para o mesmo período do mesmo sensor vemos un consumo de 62 litros. Ou un bicho, ou as mans están tortas. Pero aínda non entendo por que se romperon os datos da dereita: o consumo alí era normal, o que tamén se pode ver na gráfica dentada.

En xeral, non conseguín alcanzar a verosimilitud deste enfoque: o gráfico case sempre mostra algún tipo de herexía.

Código similar para o sensor de día.

      - 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'

Teña en conta que o parámetro group_by está definido como interval, e o parámetro points_per_hour rexe todo. E este é outro problema con este compoñente: points_per_hour funciona ben en gráficos dunha hora ou menos, pero de forma noxenta en intervalos máis grandes. Entón, para obter unha columna nun día, tiven que introducir o valor 1/24=0.04166666. Non falo de gráficos semanais e mensuais.

Aproximación 2

Mentres aínda descubría o asistente doméstico, atopei este vídeo:

O compañeiro recolle datos de consumo de varios tipos de tomas Xiaomi. A súa tarefa é un pouco máis sinxela: basta con mostrar o valor do consumo para hoxe, onte e para o mes. Non se precisan gráficos.

Deixemos de lado os argumentos sobre a integración manual dos valores de potencia instantáneas - xa escribín sobre a "precisión" deste enfoque anterior. Non está claro por que non utilizou os valores de consumo acumulado, que xa recolle o mesmo punto de venda. Na miña opinión, a integración dentro da peza de ferro funcionará mellor.

Do vídeo, tomaremos a idea de contar manualmente o consumo durante un período. Para un home, só se consideran os valores de hoxe e de onte, pero iremos máis aló e tentaremos debuxar un gráfico. A esencia do método proposto no meu caso é a seguinte.

Crearemos unha variable value_at_the_beginning_of_hour, na que escribiremos as lecturas actuais do contador
Segundo o temporizador ao final da hora (ou ao comezo da seguinte), calculamos a diferenza entre a lectura actual e a almacenada ao comezo da hora. Esta diferenza será o consumo para a hora actual: gardaremos o valor no sensor e, no futuro, elaboraremos un gráfico baseado neste valor.
Tamén cómpre "reiniciar" a variable value_at_beginning_of_hour escribindo alí o valor actual do contador.

Todo isto pódese facer ben... mediante o propio asistente doméstico.

Terá que escribir un pouco máis de código que no enfoque anterior. Comecemos con estas "variables". Fóra da caixa, non temos a entidade "variable", pero podes usar os servizos dun corredor mqtt. Enviaremos valores alí coa bandeira retain=true; isto gardará o valor dentro do corredor e pódese retirar en calquera momento, mesmo cando se reinicie o asistente doméstico. Fixen contadores diarios e horarios á vez.

- 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

Toda a maxia ocorre na automatización, que funciona cada hora e cada noite, respectivamente.

- 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

Ambas automatizacións fan dúas cousas:

• Calcula o valor por intervalo como a diferenza entre o valor inicial e final
• Actualiza o valor base para o seguinte intervalo

A construción de gráficos neste caso resólvese coa historia-gráfica habitual:

      - 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

Parece así:

En principio, isto xa é o que necesitas. A vantaxe deste método é que os datos se xeran unha vez por intervalo. Eses. un total de 24 entradas por día para o gráfico horario.

Desafortunadamente, isto aínda non resolve o problema xeral dunha base en crecemento. Se quero unha gráfica de consumo mensual, terei que almacenar datos durante polo menos un ano. E como o asistente doméstico ofrece só unha configuración de duración de almacenamento para toda a base de datos, isto significa que TODOS os datos do sistema terán que almacenarse durante un ano enteiro. Por exemplo, nun ano consome 200 metros cúbicos de auga, o que significa 200000 entradas na base de datos. E se tes en conta outros sensores, entón a cifra vólvese en xeral indecente.

Aproximación 3

Afortunadamente, as persoas intelixentes xa resolveron este problema escribindo a base de datos InfluxDB. Esta base de datos está especialmente optimizada para almacenar datos baseados no tempo e é ideal para almacenar valores de diferentes sensores. O sistema tamén ofrece unha linguaxe de consulta similar a SQL que lle permite extraer valores da base de datos e, a continuación, agregalos de varias maneiras. Finalmente, pódense almacenar diferentes datos para diferentes momentos. Por exemplo, as lecturas que cambian con frecuencia, como a temperatura ou a humidade, pódense almacenar só un par de semanas, mentres que as lecturas diarias do consumo de auga pódense almacenar durante un ano enteiro.

Ademais de InfluxDB, as persoas intelixentes tamén inventaron Grafana, un sistema para debuxar gráficos a partir de datos de InfluxDB. Grafana pode debuxar diferentes tipos de gráficos, personalizalos en detalle e, o máis importante, estes gráficos pódense "conectar" ao asistente doméstico de lovelace-UI.

estar inspirado aquí и aquí. Os artigos describen en detalle o proceso de instalación e conexión de InfluxDB e Grafana ao asistente doméstico. Centrareime en resolver o meu problema específico.

Entón, primeiro de todo, imos comezar a engadir o valor do contador en influxDB. Unha parte da configuración do asistente doméstico (neste exemplo, divertirei non só con auga fría, senón tamén con auga quente):

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

Desactivemos o gardado dos mesmos datos na base de datos interna do asistente doméstico, para non inflalo unha vez máis:

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

Imos agora á consola InfluxDB e configuremos a nosa base de datos. En particular, cómpre configurar canto tempo se almacenarán determinados datos. Isto está regulado polo chamado. política de retención: é semellante ás bases de datos dentro da base de datos principal, con cada base de datos interna tendo a súa propia configuración. De forma predeterminada, todos os datos engádense á política de retención chamada autogen, estes datos almacenaranse durante unha semana. Gustaríame que os datos horarios se almacenen durante un mes, os datos semanais durante un ano e que nunca se eliminen os datos mensuais. Crearemos políticas de retención adecuadas

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

Agora, de feito, o truco principal é a agregación de datos mediante consulta continua. Este é un mecanismo que lanza automaticamente unha consulta a intervalos especificados, agrega os datos desta consulta e engade o resultado a un valor novo. Vexamos un exemplo (escribo nunha columna para ser lexible, pero en realidade tiven que introducir este comando nunha soa liña)

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

Este comando:

• Crea unha consulta continua chamada cq_water_cold_hourly na base de datos do asistente doméstico
• A consulta executarase cada hora (tempo (1h))
• A consulta sacará todos os datos de medición'a homeassistant.autogen.l (litros), incluídas lecturas de auga fría e quente
• Os datos agregados agruparanse por entity_id, o que creará valores separados para a auga fría e quente.
• Dado que o contador de litros é unha secuencia crecente monótonamente dentro de cada hora, terás que tomar o valor máximo, polo que a agregación realizarase mediante a función max(valor)
• O novo valor escribirase en homeassistant.month.water_meter_hour onde mes é o nome da política de retención cun período de retención dun mes. Ademais, os datos sobre auga fría e quente espallaranse en rexistros separados co entity_id correspondente e o valor no campo de valor

De noite ou cando non hai ninguén na casa, non hai consumo de auga e, en consecuencia, tampouco hai novos rexistros en homeassistant.autogen.l. Para evitar que falten valores nas consultas normais, pode usar o recheo (anterior). Isto obrigará a InfluxDB a usar o valor da última hora.

Desafortunadamente, a consulta continua ten unha peculiaridade: o truco de recheo (anterior) non funciona e simplemente non se crean rexistros. Ademais, este é algún tipo de problema insalvable, que discutido durante máis dun ano. Trataremos este problema máis adiante e deixamos que o enchido (anterior) en consulta continua estea alí, non interfire.

Vexamos o que pasou (por suposto, hai que esperar un par de horas):

> 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

Teña en conta que os valores da base de datos almacénanse en UTC, polo que esta lista difire en 3 horas: os valores das 7 da mañá na saída de InfluxDB coinciden cos valores das 10 da mañá dos gráficos anteriores. Teña en conta tamén que entre as 2 e as 5 da mañá simplemente non hai rexistros: esta é a característica da consulta continua.

Como podes ver, o valor agregado tamén é unha secuencia crecente monótonamente, só as entradas son menos frecuentes: unha vez por hora. Pero isto non é un problema: podemos escribir outra consulta que extraiga os datos correctos para o gráfico.

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)

Vou descifrar:

• Da base de datos homeassistant.month.water_meter_hour, extraeremos os datos de entity_id='water_meter_cold' para o último día (time >= now() -24h).
• Como mencionei, é posible que falten algunhas entradas na secuencia homeassistant.month.water_meter_hour. Rexeneraremos estes datos executando a consulta co tempo GROUP BY (1h). Esta vez, fill(anterior) funcionará correctamente, xerando os datos que faltan (a función tomará o valor anterior)
• O máis importante nesta consulta é a función de diferenza, que calculará a diferenza entre as marcas horarias. Por si só, non funciona e require unha función de agregación. Deixa que este sexa o max() usado antes.

O resultado da execución ten este aspecto

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

De 2 a 5 da mañá (UTC) non houbo consumo. Non obstante, a consulta devolverá o mesmo valor de consumo grazas a fill(previous), e a función de diferenza restará este valor de si mesma e obterá 0 na saída, o que realmente é necesario.

O único que queda por facer é construír un gráfico. Para iso, abra Grafana, abra algún panel de control existente (ou cree un novo), cree un novo panel. A configuración do gráfico será a seguinte.

Mostrarei datos de auga fría e quente no mesmo gráfico. A solicitude é exactamente a mesma que describín anteriormente.

Os parámetros de visualización establécense do seguinte xeito. Para min será un gráfico con liñas (liñas), que vai en chanzos (escaleiras). O parámetro Stack explicarase a continuación. Hai un par de opcións de visualización máis a continuación, pero non son tan interesantes.

Para engadir o gráfico resultante ao asistente de casa, cómpre:

• saír do modo de edición de gráficos. Por algún motivo, a configuración correcta para compartir gráficos só se ofrece desde a páxina do panel
• Fai clic no triángulo xunto ao nome do gráfico, selecciona Compartir no menú
• Na xanela que se abre, vai á pestana de inserción
• Desmarque o intervalo de tempo actual: establecerémolo mediante o URL
• Seleccione o tema necesario. No meu caso é lixeiro
• Copia o URL resultante na tarxeta de configuración de lovelace-UI

      - 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"

Teña en conta que o intervalo de tempo (últimos 2 días) establécese aquí e non na configuración do panel.

O gráfico ten este aspecto. Non usei auga quente nos últimos 2 días, polo que só se debuxa un gráfico de auga fría.

Non decidín por min mesmo que gráfico me gusta máis, unha liña de pasos ou barras reais. Polo tanto, simplemente poñerei un exemplo de horario de consumo diario, só que esta vez nos bares. As consultas realízanse do mesmo xeito que se describe anteriormente. As opcións de visualización son:

Este gráfico ten o seguinte aspecto:

Entón, sobre o parámetro Stack. Neste gráfico, debúxase unha barra de auga fría enriba dunha barra quente. A altura total corresponde ao consumo total de auga fría e quente durante o período.

Todos os gráficos mostrados son dinámicos. Podes mover o rato sobre o punto de interese e ver os detalles e o valor nun punto concreto.

Por desgraza, non foi sen un par de mosca na pomada. Nun gráfico de barras (a diferenza do gráfico con liñas de pasos), o medio da barra non está no medio do día, senón ás 00:00. Eses. a metade esquerda da barra está debuxada no lugar do día anterior. Así que os gráficos para o sábado e o domingo están debuxados un pouco á esquerda da zona azulada. Ata que descubrín como gañalo.

Outro problema é a imposibilidade de traballar correctamente con intervalos mensuais. O feito é que a duración da hora / día / semana é fixa, pero a duración do mes é diferente cada vez. InfluxDB só pode funcionar con intervalos iguais. Ata agora, o meu cerebro foi suficiente para establecer un intervalo fixo de 30 días. Si, o gráfico flotará un pouco durante o ano e as barras non se corresponderán exactamente cos meses. Pero como isto é interesante para min só como medidor de pantalla, estou de acordo con isto.

Vexo polo menos dúas solucións:

• Para puntuar nos gráficos mensuais e limitarse aos semanais. 52 barras semanais nun ano ven bastante ben
• Considere o propio consumo mensual como o método número 2 e use a grafana só para gráficos fermosos. É unha solución bastante precisa. Incluso podes superpoñer gráficos do ano pasado para comparalos; grafana pode facelo.

Conclusión

Non sei por que, pero encántanme este tipo de gráficos. Mostran que a vida está en pleno apoxeo e que todo está cambiando. Onte houbo moito, hoxe pouco, mañá haberá outra cousa. Queda por traballar cos fogares o tema do consumo. Pero aínda cos apetitos actuais, só unha grande e incomprensible cifra da factura xa se está a converter nunha imaxe bastante comprensible do consumo.

A pesar da miña carreira de case 20 anos como programador, practicamente non me cruzaba coas bases de datos. Polo tanto, instalar unha base de datos externa parecía algo tan abstruso e incomprensible. Todo cambiou o artigo anterior - Resultou que parafusar unha ferramenta adecuada faise nun par de clics e cunha ferramenta especializada, a tarefa de trazar faise un pouco máis fácil.

No título, mencionei o consumo eléctrico. Por desgraza, polo momento non podo proporcionar ningún gráfico. Un medidor SDM120 está morto e o outro ten erros cando se accede a través de Modbus. Non obstante, isto non afecta de ningún xeito ao tema deste artigo: os gráficos construiranse do mesmo xeito que para a auga.

Neste artigo, dei aqueles enfoques que eu mesmo probei. Seguramente hai outras formas de organizar a recollida e visualización de datos que non coñezo. Cóntame nos comentarios, estarei moi interesado. Estarei encantado de recibir críticas construtivas e novas ideas. Espero que o material anterior tamén axude a alguén.

Fonte: www.habr.com