Cada vez que recibo un pago de luz y agua, me pregunto: ¿mi familia realmente consume tanto? Bueno, sí, hay un suelo radiante y una caldera en el baño, pero no trabajan como bomberos todo el tiempo. También parece que ahorramos agua (aunque también nos gusta chapotear en el baño). Hace unos años ya и a una casa inteligente, pero aquí es donde las cosas se atascaron. Las manos han llegado al análisis del consumo recién ahora, que, de hecho, es de lo que trata este artículo.
Recientemente cambié a Home Assistant como mi sistema de hogar inteligente. Una de las razones fue simplemente la capacidad de organizar la recopilación de una gran cantidad de datos con la posibilidad de construir convenientemente varios tipos de gráficos.
La información descrita en este artículo no es nueva, todas estas cosas bajo diferentes salsas ya han sido descritas en Internet. Pero cada artículo, por regla general, describe solo un enfoque o aspecto. Tuve que comparar todos estos enfoques y elegir yo mismo el más adecuado. El artículo todavía no proporciona información exhaustiva sobre la recopilación de datos, pero es una especie de resumen de cómo lo hice. Por lo que son bienvenidas las críticas constructivas y las sugerencias de mejora.
Formulación del problema
Entonces, el objetivo del ejercicio de hoy es obtener hermosos gráficos de consumo de agua y electricidad:
- Cada hora durante 2 días
- Diariamente durante 2 semanas
- (opcional) semanal y mensual
Hay algunas dificultades en esto:
- Los componentes estándar del gráfico tienden a ser bastante pobres. En el mejor de los casos, puede construir un gráfico de líneas por puntos.
Si busca bien, puede encontrar componentes de terceros que amplían las capacidades del gráfico estándar. Para el asistente del hogar, en principio, un componente bueno y hermoso. , pero también es algo limitado:
- Es difícil establecer los parámetros del gráfico de barras en intervalos grandes (el ancho de la barra se establece en fracciones de una hora, lo que significa que los intervalos de más de una hora se establecerán en números fraccionarios)
- No puede agregar diferentes entidades a un gráfico (por ejemplo, temperatura y humedad, o combinar un gráfico de barras con una línea)
- El asistente doméstico no solo usa la base de datos SQLite más primitiva de forma predeterminada (y yo, el manitas, no dominaba la instalación de MySQL o Postgres), sino que los datos no se almacenan de la manera más óptima. Entonces, por ejemplo, con cada cambio de cada parámetro digital, incluso el más pequeño de un parámetro, se escribe en la base de datos un json enorme de aproximadamente un kilobyte de tamaño.
{"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}}}Tengo bastantes sensores (sensores de temperatura en cada habitación, medidores de agua y electricidad), y algunos también generan bastantes datos. Por ejemplo, solo el medidor de electricidad SDM220 genera alrededor de una docena de valores cada 10-15 segundos, y me gustaría instalar esos medidores 8. Y también hay un montón de parámetros que se calculan en función de otros sensores. Eso. todos estos valores pueden inflar fácilmente la base de datos en 100-200 MB diarios. En una semana, el sistema apenas dará vueltas y vueltas, y en un mes la unidad flash morirá (en el caso de una instalación típica de Home Assistant en Raspberry PI), y no se puede hablar de almacenar datos durante todo un año. .
- Si tiene suerte, su propio medidor puede contar el consumo. Puede ponerse en contacto con el medidor en cualquier momento y preguntar a qué hora es el valor de consumo acumulado. Como regla general, todos los medidores de electricidad que tienen una interfaz digital (RS232/RS485/Modbus/Zigbee) brindan esa oportunidad.
Peor aún, si el dispositivo puede simplemente medir algún parámetro instantáneo (por ejemplo, potencia o corriente instantánea), o simplemente generar pulsos cada X vatios-hora o litros. Luego hay que pensar cómo y con qué integrarlo y dónde acumular valor. Existe el riesgo de perderse el próximo informe por cualquier motivo, y la precisión del sistema en su conjunto genera dudas. Por supuesto, puede confiar todo esto a un sistema doméstico inteligente como el asistente doméstico, pero nadie ha cancelado el punto sobre la cantidad de entradas en la base de datos, y sondear los sensores más de una vez por segundo no funcionará (una limitación de la asistente de arquitectura del hogar).
Enfoque 1
Primero, veamos qué asistente doméstico viene incluido. Medir el consumo durante un período es una funcionalidad muy solicitada. Por supuesto, se implementó hace mucho tiempo como un componente especializado: utility_meter.
La esencia del componente es que inicia la variable current_accumulated_value dentro y la restablece después de un período específico (hora/semana/mes). El componente en sí monitorea la variable entrante (el valor de algún tipo de sensor), se suscribe a los cambios en el valor en sí mismo; solo obtiene el resultado final. Esto se describe en unas pocas líneas en el archivo 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 es el valor actual del medidor en litros que obtengo por mqtt. El diseño crea 2 nuevos sensores water_cold_hour_um y water_cold_day_um, que acumulan lecturas horarias y diarias, restableciéndolas a cero después de un período. Aquí hay un gráfico de la batería por hora durante medio día.
El código de gráfico diario y por hora para lovelace-UI se ve así:
- 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 realidad, en este algoritmo radica el problema de este enfoque. Como ya mencioné, por cada valor entrante (la lectura actual del medidor para cada litro siguiente), se genera 1kb de registro en la base de datos. Cada medidor de servicios públicos también genera un nuevo valor, que también se agrega a la base. Si quiero recopilar lecturas por hora/diarias/semanales/mensuales, sí, para varios elevadores de agua, e incluso agregar un paquete de medidores eléctricos, esto será una gran cantidad de datos. Bueno, más precisamente, no hay muchos datos, pero dado que el asistente personal escribe un montón de información innecesaria en la base de datos, el tamaño de la base de datos crecerá a pasos agigantados. Incluso tengo miedo de estimar el tamaño de la base para gráficos semanales y mensuales.
Además, el medidor de servicios públicos en sí mismo no resuelve el problema. El diagrama del medidor de servicios públicos es una función que aumenta monótonamente y se restablece a 0 cada hora. También necesitamos un programa de consumo fácil de usar, cuántos litros se consumieron durante el período. El componente de gráfico de historial estándar no hace esto, pero el componente de tarjeta de minigráfico externo puede ayudarnos.
Este es el código de la tarjeta 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'Además de las configuraciones estándar como el nombre del sensor, el tipo de gráfico, el color (no me gustó el naranja estándar), es importante tener en cuenta 3 configuraciones aquí:
- group_by:hora: el gráfico se generará con columnas alineadas al comienzo de la hora
- points_per_hour: 1 - una barra por hora
- Y lo más importante, added_func: max es tomar el valor máximo dentro de cada hora. Es este parámetro el que convierte el gráfico de diente de sierra en barras.
No preste atención a la fila de columnas de la izquierda: este es el comportamiento estándar del componente si no hay datos. Pero no había datos: solo encendí la recopilación de datos usando el medidor de servicios públicos hace un par de horas solo por el bien de este artículo (describiré mi enfoque actual un poco más abajo).
En esta imagen, quería mostrar que a veces la visualización de datos incluso funciona y las barras realmente reflejan los valores correctos. Pero eso no es todo. Por alguna razón, la columna resaltada para el período de 11 am a 12 am muestra 19 litros, aunque en el gráfico con dientes un poco más alto para el mismo período del mismo sensor vemos un consumo de 62 litros. O un insecto o las manos están torcidas. Pero todavía no entiendo por qué se rompieron los datos de la derecha: el consumo allí fue normal, lo que también se puede ver en el gráfico con dientes.
En general, no pude lograr la plausibilidad de este enfoque: el gráfico casi siempre muestra algún tipo de herejía.
Código similar para el sensor 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'
Tenga en cuenta que el parámetro group_by está configurado en intervalo, y el parámetro points_per_hour lo gobierna todo. Y este es otro problema con este componente: points_per_hour funciona bien en gráficos de una hora o menos, pero es desagradable en intervalos más grandes. Entonces, para obtener una columna en un día, tuve que ingresar el valor 1/24 = 0.04166666. No estoy hablando de gráficos semanales y mensuales.
Enfoque 2
Mientras seguía descifrando al asistente doméstico, me encontré con este video:
El camarada recopila datos de consumo de varios tipos de enchufes Xiaomi. Su tarea es un poco más simple: simplemente muestre el valor del consumo de hoy, ayer y del mes. No se requieren gráficos.
Dejemos de lado los argumentos sobre la integración manual de valores de potencia instantáneos: ya escribí sobre la "precisión" de este enfoque anteriormente. No está claro por qué no utilizó los valores de consumo acumulados, que ya son recogidos por el mismo punto de venta. En mi opinión, la integración dentro de la pieza de hierro funcionará mejor.
Del video, tomaremos la idea de contar manualmente el consumo durante un período. Para un hombre, solo se consideran los valores de hoy y ayer, pero iremos más allá e intentaremos dibujar un gráfico. La esencia del método propuesto en mi caso es la siguiente.
Crearemos una variable valor_al_comienzo_de_hora, en la que escribiremos las lecturas actuales del contador
Según el temporizador al final de la hora (o al principio de la siguiente), calculamos la diferencia entre la lectura actual y la almacenada al principio de la hora. Esta diferencia será el consumo de la hora actual: guardaremos el valor en el sensor y, en el futuro, crearemos un gráfico basado en este valor.
También necesita "restablecer" la variable value_at_beginning_of_hour escribiendo el valor actual del contador allí.
Todo esto se puede hacer bien... por medio del propio asistente del hogar.
Tendrá que escribir un poco más de código que en el enfoque anterior. Comencemos con estas "variables". Fuera de la caja, no tenemos la entidad "variable", pero puede utilizar los servicios de un corredor mqtt. Enviaremos valores allí con el indicador de retención = verdadero: esto guardará el valor dentro del corredor y se puede extraer en cualquier momento, incluso cuando se reinicia el asistente de inicio. Hice contadores horarios y diarios a la 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: lToda la magia sucede en la automatización, que funciona cada hora y cada noche, 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: trueAmbas automatizaciones hacen 2 cosas:
- Calcule el valor por intervalo como la diferencia entre el valor inicial y final
- Actualizar el valor base para el siguiente intervalo
La construcción de gráficos en este caso se resuelve mediante el gráfico histórico 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_daySe ve así:
En principio, esto ya es lo que necesitas. La ventaja de este método es que los datos se generan una vez por intervalo. Aquellos. un total de 24 entradas por día para el gráfico horario.
Desafortunadamente, esto todavía no resuelve el problema general de una base creciente. Si quiero un gráfico de consumo mensual, tendré que almacenar datos durante al menos un año. Y dado que Home Assistant proporciona solo una configuración de duración de almacenamiento para toda la base de datos, esto significa que TODOS los datos en el sistema deberán almacenarse durante todo un año. Por ejemplo, en un año consumo 200 metros cúbicos de agua, lo que significa 200000 entradas en la base de datos. Y si tiene en cuenta otros sensores, la figura se vuelve generalmente indecente.
Enfoque 3
Afortunadamente, las personas inteligentes ya han resuelto este problema al escribir la base de datos InfluxDB. Esta base de datos está especialmente optimizada para almacenar datos basados en el tiempo y es ideal para almacenar los valores de diferentes sensores. El sistema también proporciona un lenguaje de consulta similar a SQL que le permite extraer valores de la base de datos y luego agregarlos de varias maneras. Finalmente, se pueden almacenar diferentes datos para diferentes tiempos. Por ejemplo, las lecturas que cambian con frecuencia, como la temperatura o la humedad, se pueden almacenar solo durante un par de semanas, mientras que las lecturas diarias de consumo de agua se pueden almacenar durante todo un año.
Además de InfluxDB, las personas inteligentes también inventaron Grafana, un sistema para dibujar gráficos a partir de datos de InfluxDB. Grafana puede dibujar diferentes tipos de gráficos, personalizarlos en detalle y, lo que es más importante, estos gráficos se pueden "conectar" al asistente doméstico lovelace-UI.
estar inspirado и . Los artículos describen en detalle el proceso de instalación y conexión de InfluxDB y Grafana a Home Assistant. Me centraré en resolver mi problema específico.
Entonces, antes que nada, comencemos a agregar el valor del contador en influxDB. Una parte de la configuración del asistente doméstico (en este ejemplo, me divertiré no solo con agua fría, sino también con agua caliente):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldDesactivemos guardar los mismos datos en la base de datos interna del asistente doméstico para no inflarlos una vez más:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldVayamos ahora a la consola de InfluxDB y configuremos nuestra base de datos. En particular, debe configurar cuánto tiempo se almacenarán ciertos datos. Esto está regulado por el llamado. política de retención: esto es similar a las bases de datos dentro de la base de datos principal, y cada base de datos interna tiene su propia configuración. De forma predeterminada, todos los datos se agregan a la política de retención llamada autogen, estos datos se almacenarán durante una semana. Me gustaría que los datos horarios se almacenen durante un mes, los datos semanales durante un año y los datos mensuales nunca se eliminen. Crearemos políticas de retención apropiadas
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 1Ahora, de hecho, el truco principal es la agregación de datos mediante consultas continuas. Este es un mecanismo que lanza automáticamente una consulta a intervalos específicos, agrega los datos para esta consulta y agrega el resultado a un nuevo valor. Veamos un ejemplo (escribo en una columna para facilitar la lectura, pero en realidad tuve que ingresar este comando en una línea)
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)
ENDEste comando:
- Crea una consulta continua llamada cq_water_cold_hourly en la base de datos de homeassistant
- La consulta se ejecutará cada hora (time(1h))
- La consulta extraerá todos los datos de medición'a homeassistant.autogen.l (litros), incluidas las lecturas de agua fría y caliente
- Los datos agregados se agruparán por entidad_id, lo que creará valores separados para agua fría y caliente.
- Dado que el contador de litros es una secuencia que aumenta monótonamente dentro de cada hora, deberá tomar el valor máximo, por lo que la agregación se llevará a cabo mediante la función max(value)
- El nuevo valor se escribirá en homeassistant.month.water_meter_hour, donde mes es el nombre de la política de retención con un período de retención de un mes. Además, los datos sobre agua fría y caliente se dispersarán en registros separados con el correspondiente entidad_id y el valor en el campo de valor
Por la noche o cuando no hay nadie en casa, no hay consumo de agua, por lo que tampoco hay nuevos registros en homeassistant.autogen.l. Para evitar que falten valores en las consultas normales, puede utilizar el relleno (anterior). Esto forzará a InfluxDB a usar el valor de la última hora.
Desafortunadamente, la consulta continua tiene una peculiaridad: el truco de llenar (anterior) no funciona y los registros simplemente no se crean. Además, este es algún tipo de problema insuperable, que . Nos ocuparemos de este problema más adelante, y dejaremos que el relleno (anterior) en la consulta continua esté allí; no interfiere.
Veamos qué sucedió (por supuesto, debe 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
Tenga en cuenta que los valores en la base de datos se almacenan en UTC, por lo que esta lista difiere en 3 horas: los valores de las 7 a. m. en la salida de InfluxDB coinciden con los valores de las 10 a. m. en los gráficos anteriores. También tenga en cuenta que entre las 2 y las 5 de la mañana simplemente no hay registros; esta es la característica misma de la consulta continua.
Como puede ver, el valor agregado también es una secuencia que aumenta monótonamente, solo que las entradas son menos frecuentes, una vez por hora. Pero esto no es un problema: podemos escribir otra consulta que extraiga los datos correctos para el 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)Descifraré:
- De la base de datos homeassistant.month.water_meter_hour, extraeremos datos para entity_id='water_meter_cold' del último día (hora >= ahora() -24 h).
- Como mencioné, es posible que falten algunas entradas en la secuencia homeassistant.month.water_meter_hour. Regeneraremos estos datos ejecutando la consulta con GROUP BY time(1h). Esta vez, fill(anterior) funcionará correctamente, generando los datos faltantes (la función tomará el valor anterior)
- Lo más importante en esta consulta es la función de diferencia, que calculará la diferencia entre las marcas de hora. Por sí mismo, no funciona y requiere una función de agregación. Sea este el max() usado antes.
El resultado de la ejecución se ve así
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 72De 2 am a 5 am (UTC) no hubo consumo. No obstante, la consulta devolverá el mismo valor de consumo gracias a fill(anterior), y la función de diferencia restará este valor de sí misma y obtendrá 0 en la salida, que es lo que realmente se requiere.
Lo único que queda por hacer es construir un gráfico. Para hacer esto, abra Grafana, abra algún tablero existente (o cree uno nuevo), cree un nuevo panel. La configuración del gráfico será la siguiente.
Mostraré datos de agua fría y caliente en el mismo gráfico. La solicitud es exactamente la misma que describí anteriormente.
Los parámetros de visualización se configuran de la siguiente manera. Para mí será un gráfico con líneas (líneas), que va en pasos (escaleras). El parámetro Stack se explicará a continuación. Hay un par de opciones de visualización más a continuación, pero no son tan interesantes.
Para agregar el gráfico resultante a Home Assistant, debe:
- salir del modo de edición de gráficos. Por alguna razón, la configuración correcta para compartir gráficos se ofrece solo desde la página del panel
- Haga clic en el triángulo junto al nombre del gráfico, seleccione compartir en el menú
- En la ventana que se abre, ve a la pestaña de inserción
- Desmarque el rango de tiempo actual: estableceremos el rango de tiempo a través de la URL
- Seleccione el tema requerido. en mi caso es ligero
- Copie la URL resultante en la tarjeta de configuración 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"
Tenga en cuenta que el rango de tiempo (últimos 2 días) se establece aquí, y no en la configuración del panel.
El gráfico se ve así. No he usado agua caliente en los últimos 2 días, por lo que solo se dibuja una gráfica de agua fría.
No he decidido por mí mismo qué gráfico me gusta más, una línea escalonada o barras reales. Por lo tanto, simplemente daré un ejemplo de un horario de consumo diario, solo que esta vez en bares. Las consultas se construyen de la misma manera que se describe anteriormente. Las opciones de visualización son:
Este gráfico se ve así:
Entonces, sobre el parámetro Stack. En este gráfico, se dibuja una barra de agua fría encima de una barra caliente. La altura total corresponde al consumo total de agua fría y caliente del período.
Todos los gráficos mostrados son dinámicos. Puede mover el mouse sobre el punto de interés y ver los detalles y el valor en un punto en particular.
Desafortunadamente, no fue sin un par de moscas en el ungüento. En un gráfico de barras (a diferencia del gráfico con líneas escalonadas), la mitad de la barra no está a la mitad del día, sino a las 00:00. Aquellos. la mitad izquierda de la barra se dibuja en lugar del día anterior. Entonces, los gráficos para el sábado y el domingo se dibujan un poco a la izquierda de la zona azulada. Hasta que descubrí cómo ganarlo.
Otro problema es la imposibilidad de trabajar correctamente con intervalos mensuales. El hecho es que la duración de la hora/día/semana es fija, pero la duración del mes es diferente cada vez. InfluxDB solo puede trabajar con intervalos iguales. Hasta ahora, mi cerebro ha sido suficiente para establecer un intervalo fijo de 30 días. Sí, el gráfico flotará un poco durante el año y las barras no se corresponderán exactamente con los meses. Pero dado que esto es interesante para mí solo como un medidor de pantalla, estoy de acuerdo con esto.
Veo al menos dos soluciones:
- Para anotar en gráficos mensuales y limitarse a los semanales. 52 barras semanales en un año se ven bastante bien
- Considere el consumo mensual en sí como método No. 2, y use la grafana solo para gráficos hermosos. Es una solución bastante precisa. Incluso puede superponer gráficos del año pasado para comparar: grafana puede hacerlo.
Conclusión
No sé por qué, pero me encantan este tipo de gráficos. Muestran que la vida está en pleno apogeo y que todo está cambiando. Ayer había mucho, hoy hay poco, mañana habrá algo más. Queda por trabajar con los hogares en el tema del consumo. Pero incluso con los apetitos actuales, solo una cifra grande e incomprensible en la factura ya se está convirtiendo en una imagen de consumo bastante comprensible.
A pesar de mi carrera de casi 20 años como programador, prácticamente no me cruzaba con bases de datos. Por lo tanto, instalar una base de datos externa parecía algo tan abstruso e incomprensible. Todo ha cambiado - Resultó que atornillar una herramienta adecuada se realiza con un par de clics, y con una herramienta especializada, la tarea de trazar se vuelve un poco más fácil.
En el título, mencioné el consumo de electricidad. Desafortunadamente, por el momento no puedo proporcionar ningún gráfico. Un medidor SDM120 está muerto y el otro tiene errores cuando se accede a través de Modbus. Sin embargo, esto no afecta el tema de este artículo de ninguna manera: los gráficos se construirán de la misma manera que para el agua.
En este artículo, he dado los enfoques que he probado yo mismo. Seguramente hay otras formas de organizar la recopilación y visualización de datos que desconozco. Cuéntamelo en los comentarios, me interesará mucho. Estaré encantado de recibir críticas constructivas y nuevas ideas. Espero que el material anterior también ayude a alguien.
Fuente: habr.com