Cada vegada que rebo un pagament per l'electricitat i l'aigua, em pregunto: la meva família realment consumeix massa? Bé, sí, hi ha un terra radiant i una caldera al bany, però no treballen com a bombers tot el temps. També sembla que estalviem aigua (tot i que també ens agrada esquitxar al bany). Ja fa uns anys и a una casa intel·ligent, però aquí és on les coses es van encallar. Les mans han arribat a l'anàlisi del consum només ara, que, de fet, és del que tracta aquest article.
Recentment he canviat a Home Assistant com a sistema domèstic intel·ligent. Un dels motius va ser només la capacitat d'organitzar la recollida d'una gran quantitat de dades amb la possibilitat de construir còmodament diversos tipus de gràfics.
La informació que es descriu en aquest article no és nova, totes aquestes coses sota diferents salses ja s'han descrit a Internet. Però cada article, per regla general, només descriu un enfocament o aspecte. Vaig haver de comparar tots aquests enfocaments i triar jo mateix el més adequat. L'article encara no ofereix informació exhaustiva sobre la recollida de dades, però és una mena de resum de com ho vaig fer. Per tant, les crítiques constructives i els suggeriments de millora són benvinguts.
Declaració de problemes
Així doncs, l'objectiu de l'exercici d'avui és obtenir bons gràfics del consum d'aigua i electricitat:
- Cada hora durant 2 dies
- Diàriament durant 2 setmanes
- (opcional) setmanal i mensual
Hi ha algunes dificultats en això:
- Els components estàndard del gràfic solen ser força pobres. En el millor dels casos, podeu construir un gràfic de línies per punts.
Si cerqueu bé, podeu trobar components de tercers que ampliïn les capacitats del gràfic estàndard. Per a l'assistent domèstic, en principi, un component bo i bonic , però també és una mica limitat:
- És difícil establir els paràmetres del gràfic de barres a intervals grans (l'amplada de la barra s'estableix en fraccions d'una hora, el que significa que els intervals superiors a una hora s'establiran en nombres fraccionaris)
- No podeu afegir diferents entitats a un gràfic (per exemple, temperatura i humitat, o combinar un gràfic de barres amb una línia)
- L'assistent domèstic no només utilitza la base de dades SQLite més primitiva per defecte (i jo, el manual, no dominava la instal·lació de MySQL o Postgres), les dades no s'emmagatzemen de la manera més òptima. Així, per exemple, amb cada canvi de cada paràmetre digital, fins i tot el més petit d'un paràmetre, s'escriu a la base de dades un json enorme d'aproximadament un kilobyte de mida.
{"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}}}Tinc bastants sensors (sensors de temperatura a cada habitació, comptadors d'aigua i electricitat), i alguns també generen força dades. Per exemple, només el comptador d'electricitat SDM220 genera una dotzena de valors cada 10-15 segons, i m'agradaria instal·lar-ne 8. I també hi ha un munt de paràmetres que es calculen a partir d'altres sensors. Això. tots aquests valors poden inflar fàcilment la base de dades entre 100 i 200 MB diaris. En una setmana, el sistema amb prou feines girarà, i en un mes la unitat flaix morirà (en el cas d'una instal·lació típica de l'assistent domèstic a raspberry PI), i no es pot parlar d'emmagatzemar dades durant un any sencer. .
- Si tens sort, el teu comptador pot comptar el consum. Podeu contactar amb el comptador en qualsevol moment i preguntar a quina hora és el valor de consum acumulat. Com a regla general, tots els comptadors d'electricitat que tenen una interfície digital (RS232/RS485/Modbus/Zigbee) ofereixen aquesta oportunitat.
Pitjor encara, si el dispositiu només pot mesurar algun paràmetre instantani (per exemple, potència instantània o corrent), o simplement generar polsos cada X watts-hora o litres. Aleshores cal pensar com i amb què integrar-lo i on acumular valor. Hi ha el risc de perdre's el següent informe per qualsevol motiu, i l'exactitud del sistema en conjunt planteja preguntes. Per descomptat, podeu confiar tot això a un sistema domèstic intel·ligent com l'assistent domèstic, però ningú ha cancel·lat el punt sobre el nombre d'entrades a la base de dades i els sensors de sondeig més d'una vegada per segon no funcionaran (una limitació de la auxiliar d'arquitectura de la llar).
Enfocament 1
Primer, vegem quin assistent domèstic es proporciona fora de la caixa. Mesurar el consum durant un període és una funcionalitat molt demanada. Per descomptat, es va implementar fa molt de temps com un component especialitzat: utility_meter.
L'essència del component és que inicia la variable current_accumulated_value dins i la restableix després d'un període especificat (hora/setmana/mes). El component en si supervisa la variable entrant (el valor d'algun tipus de sensor), se subscriu als canvis en el valor en si, només obteniu el resultat final. Això es descriu en poques línies al fitxer de configuració
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 és el valor actual del comptador en litres que tinc per mqtt. El disseny crea 2 nous sensors water_cold_hour_um i water_cold_day_um, que acumulen lectures horàries i diàries, restablint-les a zero després d'un període. Aquí teniu un gràfic de la bateria horària durant mig dia.
El codi del gràfic horari i diari de lovelace-UI té aquest aspecte:
- 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
De fet, en aquest algorisme rau el problema d'aquest enfocament. Com ja he esmentat, per a cada valor entrant (la lectura actual del comptador per a cada litre següent), es genera 1 kb d'un registre a la base de dades. Cada comptador de serveis públics també genera un nou valor, que també s'afegeix a la base. Si vull recollir lectures horàries/diàries/setmanals/mensuals, sí, per a diverses pujadores d'aigua, i fins i tot afegir un paquet de comptadors elèctrics, seran moltes dades. Bé, més precisament, no hi ha moltes dades, però com que l'assistent domèstic escriu un munt d'informació innecessària a la base de dades, la mida de la base de dades augmentarà a passos de gegant. Fins i tot tinc por d'estimar la mida de la base per als gràfics setmanals i mensuals.
A més, el comptador d'utilitat en si no resol el problema. La gràfica del comptador d'utilitat és una funció que augmenta monòtonament que es reinicia a 0 cada hora. També necessitem un calendari de consum fàcil d'utilitzar, quants litres s'han consumit durant el període. El component de gràfic d'historial estàndard no ho fa, però el component de mini-targeta gràfica externa ens pot ajudar.
Aquest és el codi de la targeta per a 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'A més de la configuració estàndard com el nom del sensor, el tipus de gràfic, el color (no m'agradava la taronja estàndard), és important tenir en compte 3 paràmetres aquí:
- group_by:hour: el gràfic es generarà amb columnes alineades al principi de l'hora
- points_per_hour: 1 - una barra per hora
- I el més important, aggregate_func: max és prendre el valor màxim dins de cada hora. Aquest paràmetre és el que converteix el gràfic de dents de serra en barres.
No presteu atenció a la fila de columnes de l'esquerra: aquest és el comportament estàndard del component si no hi ha dades. Però no hi havia dades: només vaig activar la recollida de dades amb el comptador de serveis públics fa un parell d'hores només pel bé d'aquest article (descriuré el meu enfocament actual una mica més baix).
En aquesta imatge, volia mostrar que de vegades la visualització de dades fins i tot funciona i que les barres reflecteixen realment els valors correctes. Però això no és tot. Per alguna raó, la columna destacada per al període d'11 a 12 h mostra 19 litres, tot i que al gràfic amb dents una mica més alt durant el mateix període des del mateix sensor veiem un consum de 62 litres. O un error o les mans estan tortes. Però encara no entenc per què es van trencar les dades de la dreta: el consum allà era normal, cosa que també es veu des del gràfic amb dents.
En general, no vaig aconseguir la plausibilitat d'aquest enfocament: el gràfic gairebé sempre mostra algun tipus d'heretgia.
Codi similar per al sensor diürn.
- 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'
Tingueu en compte que el paràmetre group_by s'estableix en interval i el paràmetre points_per_hour ho governa tot. I aquest és un altre problema amb aquest component: points_per_hour funciona bé en gràfics d'una hora o menys, però de manera repugnant en intervals més grans. Per tant, per obtenir una columna en un dia, vaig haver d'introduir el valor 1/24=0.04166666. No parlo de gràfics setmanals i mensuals.
Enfocament 2
Mentre encara esbrinava l'assistent de casa, em vaig trobar amb aquest vídeo:
El company recopila dades de consum de diversos tipus de preses Xiaomi. La seva tasca és una mica més senzilla: només mostra el valor del consum d'avui, d'ahir i del mes. No calen gràfics.
Deixem de banda els arguments sobre la integració manual dels valors de potència instantània: ja vaig escriure sobre la "precisió" d'aquest enfocament anteriorment. No està clar per què no va utilitzar els valors de consum acumulats, que ja recullen el mateix punt de venda. Al meu entendre, la integració dins de la peça de ferro funcionarà millor.
Del vídeo, agafarem la idea de comptar manualment el consum durant un període. Per a un home, només es tenen en compte els valors d'avui i d'ahir, però anirem més enllà i intentarem dibuixar un gràfic. L'essència del mètode proposat en el meu cas és la següent.
Crearem una variable value_at_the_beginning_of_hour, en la qual escriurem les lectures del comptador actuals
Segons el temporitzador al final de l'hora (o al començament de la següent), calculem la diferència entre la lectura actual i la emmagatzemada al principi de l'hora. Aquesta diferència serà el consum de l'hora actual: guardarem el valor al sensor i, en el futur, construirem un gràfic basat en aquest valor.
També heu de "restablir" la variable value_at_beginning_of_hour escrivint-hi el valor actual del comptador.
Tot això es pot fer a través de bé... mitjançant el propi auxiliar de la llar.
Haureu d'escriure una mica més de codi que en l'enfocament anterior. Comencem per aquestes "variables". Fora de la caixa, no tenim l'entitat "variable", però podeu utilitzar els serveis d'un corredor mqtt. Enviarem valors allà amb la bandera retain=true; això desarà el valor dins del corredor i es pot treure en qualsevol moment, fins i tot quan es reinicia l'assistent de casa. Vaig fer comptadors horàries i diaris alhora.
- 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: lTota la màgia passa a l'automatització, que funciona cada hora i cada nit, respectivament.
- 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: trueLes dues automatitzacions fan dues coses:
- Calcula el valor per interval com a diferència entre el valor inicial i final
- Actualitzeu el valor base per al següent interval
La construcció de gràfics en aquest cas es resol amb l'habitual history-graph:
- 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_dayEs veu així:
En principi, això ja és el que necessiteu. L'avantatge d'aquest mètode és que les dades es generen una vegada per interval. Aquells. un total de 24 entrades per dia per al gràfic horari.
Malauradament, això encara no resol el problema general d'una base en creixement. Si vull un gràfic de consum mensual, hauré d'emmagatzemar dades com a mínim durant un any. I com que l'assistent domèstic només proporciona una configuració de durada d'emmagatzematge per a tota la base de dades, això significa que TOTES les dades del sistema s'hauran d'emmagatzemar durant un any sencer. Per exemple, en un any consumeixo 200 metres cúbics d'aigua, és a dir, 200000 entrades a la base de dades. I si teniu en compte altres sensors, la xifra esdevé generalment indecent.
Enfocament 3
Afortunadament, les persones intel·ligents ja han resolt aquest problema escrivint la base de dades InfluxDB. Aquesta base de dades està especialment optimitzada per emmagatzemar dades basades en el temps i és ideal per emmagatzemar valors de diferents sensors. El sistema també proporciona un llenguatge de consulta semblant a SQL que us permet extreure valors de la base de dades i després agregar-los de diverses maneres. Finalment, es poden emmagatzemar dades diferents per a diferents moments. Per exemple, les lectures que canvien amb freqüència, com la temperatura o la humitat, només es poden emmagatzemar durant un parell de setmanes, mentre que les lectures diàries del consum d'aigua es poden emmagatzemar durant un any sencer.
A més d'InfluxDB, les persones intel·ligents també van inventar Grafana, un sistema per dibuixar gràfics a partir de dades d'InfluxDB. Grafana pot dibuixar diferents tipus de gràfics, personalitzar-los en detall i, el més important, aquests gràfics es poden "connectar" a l'assistent domèstic de lovelace-UI.
inspirar-se и . Els articles descriuen detalladament el procés d'instal·lació i connexió d'InfluxDB i Grafana a l'assistent domèstic. Em centraré a resoldre el meu problema específic.
Per tant, primer de tot, comencem a afegir el valor del comptador a influxDB. Una part de la configuració de l'assistent domèstic (en aquest exemple, em divertiré no només amb aigua freda, sinó també amb aigua calenta):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldDesactivem l'emmagatzematge de les mateixes dades a la base de dades interna de l'assistent domèstic per no tornar-la a inflar:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldAnem ara a la consola InfluxDB i configurem la nostra base de dades. En particular, heu de configurar quant de temps s'emmagatzemaran determinades dades. Això està regulat per l'anomenat. política de retenció: és similar a les bases de dades dins de la base de dades principal, amb cada base de dades interna amb la seva pròpia configuració. Per defecte, totes les dades s'afegeixen a la política de retenció anomenada autogen, aquestes dades s'emmagatzemaran durant una setmana. M'agradaria que les dades horàries s'emmagatzemin durant un mes, les dades setmanals durant un any i les dades mensuals no se suprimeixin mai. Crearem polítiques de retenció adequades
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 1Ara, de fet, el truc principal és l'agregació de dades mitjançant la consulta contínua. Aquest és un mecanisme que llança automàticament una consulta a intervals especificats, agrega les dades d'aquesta consulta i afegeix el resultat a un valor nou. Vegem un exemple (escric en una columna per a la llegibilitat, però en realitat vaig haver d'introduir aquesta ordre en una línia)
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)
ENDAquesta comanda:
- Crea una consulta contínua anomenada cq_water_cold_hourly a la base de dades homeassistant
- La consulta s'executarà cada hora (hora (1h))
- La consulta extreu totes les dades de mesurament'a homeassistant.autogen.l (litres), incloses les lectures d'aigua freda i calenta
- Les dades agregades s'agruparan per entity_id, que crearà valors separats per a l'aigua freda i calenta.
- Com que el comptador de litres és una seqüència creixent monòtonament dins de cada hora, haureu de prendre el valor màxim, de manera que l'agregació es durà a terme mitjançant la funció max(valor)
- El valor nou s'escriurà a homeassistant.month.water_meter_hour, on mes és el nom de la política de retenció amb un període de retenció d'un mes. A més, les dades sobre aigua freda i calenta es dispersaran en registres separats amb l'entity_id corresponent i el valor al camp de valor.
De nit o quan no hi ha ningú a casa, no hi ha consum d'aigua i, per tant, tampoc hi ha nous registres a homeassistant.autogen.l. Per evitar que faltin valors a les consultes normals, podeu utilitzar emplenar (anterior). Això obligarà a InfluxDB a utilitzar el valor de l'última hora.
Malauradament, la consulta contínua té una peculiaritat: el truc d'ompliment (anterior) no funciona i simplement no es creen els registres. A més, aquest és una mena de problema insuperable, que . Tractarem aquest problema més endavant, i deixarem que l'ompliment (anterior) en la consulta contínua estigui allà; no interfereix.
Comprovem què ha passat (per descomptat, cal esperar un parell d'hores):
> 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
Tingueu en compte que els valors de la base de dades s'emmagatzemen a UTC, de manera que aquesta llista difereix en 3 hores: els valors de les 7:10 a la sortida d'InfluxDB coincideixen amb els valors de les 2:5 dels gràfics anteriors. Tingueu en compte també que entre les XNUMX i les XNUMX del matí simplement no hi ha registres: aquesta és la característica de la consulta contínua.
Com podeu veure, el valor agregat també és una seqüència creixent monòtonament, només les entrades són menys freqüents: un cop per hora. Però això no és un problema: podem escriure una altra consulta que extreu les dades correctes per al gràfic.
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)Desxifraré:
- Des de la base de dades homeassistant.month.water_meter_hour, extreurem les dades d'entity_id='water_meter_cold' per a l'últim dia (time >= now() -24h).
- Com he esmentat, és possible que faltin algunes entrades a la seqüència homeassistant.month.water_meter_hour. Regenerarem aquestes dades executant la consulta amb el temps GROUP BY (1h). Aquesta vegada, emplenar(anterior) funcionarà correctament, generant les dades que falten (la funció prendrà el valor anterior)
- El més important d'aquesta consulta és la funció de diferència, que calcularà la diferència entre les marques horàries. Per si mateix, no funciona i requereix una funció d'agregació. Sigui aquest el max() utilitzat abans.
El resultat de l'execució sembla aquest
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 les 2 del matí a les 5 del matí (UTC) no hi va haver consum. No obstant això, la consulta retornarà el mateix valor de consum gràcies a fill(anterior), i la funció de diferència restarà aquest valor de si mateixa i obtindrà 0 a la sortida, que realment és necessari.
L'únic que queda per fer és construir un gràfic. Per fer-ho, obriu Grafana, obriu un tauler de control existent (o creeu un nou), creeu un tauler nou. La configuració del gràfic serà la següent.
Mostraré les dades d'aigua freda i calenta al mateix gràfic. La petició és exactament la mateixa que he descrit anteriorment.
Els paràmetres de visualització s'estableixen de la següent manera. Per a mi serà un gràfic amb línies (línies), que va per graons (escales). El paràmetre Stack s'explicarà a continuació. Hi ha un parell d'opcions de visualització més a continuació, però no són tan interessants.
Per afegir el gràfic resultant a Home Assistant, heu de:
- sortir del mode d'edició de gràfics. Per alguna raó, la configuració correcta per compartir gràfics només s'ofereix des de la pàgina del tauler
- Feu clic al triangle al costat del nom del gràfic, seleccioneu compartir al menú
- A la finestra que s'obre, aneu a la pestanya d'inserció
- Desmarqueu l'interval de temps actual: establirem l'interval de temps mitjançant l'URL
- Seleccioneu el tema requerit. En el meu cas és lleuger
- Copieu l'URL resultant a la targeta de configuració 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"
Tingueu en compte que l'interval de temps (darrers 2 dies) s'estableix aquí i no a la configuració del tauler.
El gràfic té aquest aspecte. No he fet servir aigua calenta en els últims 2 dies, així que només es dibuixa un gràfic d'aigua freda.
No he decidit per mi mateix quin gràfic m'agrada més, una línia de pas o barres reals. Per tant, simplement posaré un exemple d'horari de consum diari, només que aquesta vegada en bars. Les consultes es creen de la mateixa manera que es descriu anteriorment. Les opcions de visualització són:
Aquest gràfic té aquest aspecte:
Per tant, sobre el paràmetre Stack. En aquest gràfic, es dibuixa una barra d'aigua freda a sobre d'una barra calenta. L'alçada total correspon al consum total d'aigua freda i calenta del període.
Tots els gràfics mostrats són dinàmics. Podeu moure el ratolí sobre el punt d'interès i veure'n els detalls i el valor en un punt concret.
Malauradament, no va ser sense un parell de mosca a la pomada. En un gràfic de barres (a diferència del gràfic amb línies de pas), el centre de la barra no es troba al mig del dia, sinó a les 00:00. Aquells. la meitat esquerra de la barra es dibuixa en lloc del dia anterior. Així, els gràfics de dissabte i diumenge es dibuixen una mica a l'esquerra de la zona blavosa. Fins que vaig descobrir com guanyar-lo.
Un altre problema és la incapacitat de treballar correctament amb intervals mensuals. El fet és que la durada de l'hora / dia / setmana és fixa, però la durada del mes és diferent cada vegada. InfluxDB només pot funcionar amb intervals iguals. Fins ara, el meu cervell ha estat suficient per establir un interval fix de 30 dies. Sí, el gràfic flotarà una mica durant l'any i les barres no es correspondran exactament amb els mesos. Però com que això és interessant per a mi només com a mesurador de pantalla, estic d'acord amb això.
Jo veig almenys dues solucions:
- Per puntuar en gràfics mensuals i limitar-se a les setmanals. 52 barres setmanals en un any es veuen força bé
- Considereu el consum mensual en si com el mètode núm. 2 i utilitzeu la grafana només per a gràfics bonics. És una solució bastant precisa. Fins i tot podeu superposar gràfics de l'últim any per comparar-los; grafana ho pot fer.
Conclusió
No sé per què, però m'encanten aquest tipus de gràfics. Demostren que la vida està en ple apogeu i que tot està canviant. Ahir hi va haver molt, avui hi ha poc, demà hi haurà una altra cosa. Queda per treballar amb les llars el tema del consum. Però fins i tot amb les ganes actuals, només una xifra gran i incomprensible de la factura ja s'està convertint en una imatge del consum força comprensible.
Malgrat els meus gairebé 20 anys de carrera com a programador, pràcticament no em vaig creuar amb les bases de dades. Per tant, instal·lar una base de dades externa semblava una cosa tan abstrusa i incomprensible. Tot ha canviat - va resultar que cargolar una eina adequada es fa en un parell de clics i, amb una eina especialitzada, la tasca de traçar es fa una mica més fàcil.
En el títol, he esmentat el consum elèctric. Malauradament, de moment no puc proporcionar cap gràfic. Un mesurador SDM120 està mort i l'altre té errors quan s'hi accedeix mitjançant Modbus. Tanmateix, això no afecta de cap manera el tema d'aquest article: els gràfics es construiran de la mateixa manera que per a l'aigua.
En aquest article, he donat aquells enfocaments que he provat jo mateix. Segurament hi ha altres maneres d'organitzar la recollida i visualització de dades que no conec. Explica'm-ho als comentaris, m'interessarà molt. Estaré encantat de rebre crítiques constructives i noves idees. Espero que el material anterior també ajudi a algú.
Font: www.habr.com