Smart Home: Uraren eta elektrizitatearen kontsumoaren grafikoak Home Assistant-en

Argindarraren eta uraren ordainketa jasotzen dudan bakoitzean, galdetzen diot nire buruari: benetan asko kontsumitzen al du nire familiak? Tira, bai, komunean zoru berogailua eta galdara bat daude, baina ez dute denbora guztian suhiltzaile gisa lan egiten. Ura ere aurrezten dugula ematen du (komunean zipriztinak egitea ere gustatzen zaigun arren). Duela urte batzuk jadanik konektatutako ur kontagailuak и elektrizitatea etxe adimendun batera, baina hemen gelditu ziren gauzak. Eskuak orain bakarrik heldu dira kontsumoaren azterketara, eta horixe da, hain zuzen ere, artikulu hau.

Duela gutxi Home Assistant-era aldatu naiz nire etxeko sistema adimendun gisa. Arrazoietako bat datu kopuru handiaren bilketa antolatzeko gaitasuna izan zen, hainbat grafiko mota eroso eraikitzeko aukerarekin.

Artikulu honetan deskribatzen den informazioa ez da berria, saltsa ezberdinen azpian dauden gauza horiek guztiak Interneten deskribatu dira dagoeneko. Baina artikulu bakoitzak, oro har, ikuspegi edo alderdi bakarra deskribatzen du. Planteamendu horiek guztiak alderatu eta neuk aukeratu behar nuen egokiena. Artikuluak oraindik ez du datu-bilketari buruzko informazio zehatza ematen, baina nola egin nuenaren laburpen moduko bat da. Beraz, ongi etorriak dira kritika eraikitzaileak eta hobetzeko iradokizunak.

Arazoaren formulazioa

Beraz, gaurko ariketaren helburua uraren eta elektrizitatearen kontsumoaren grafiko ederrak lortzea da:

• Orduka 2 egunez
• Egunero 2 astez
• (aukerakoa) astero eta hilero

Honetan zailtasun batzuk daude:

• Diagramako osagai estandarrak nahiko eskasak izan ohi dira. Onenean, lerro grafiko bat puntuka eraiki dezakezu.

  Ondo bilatzen baduzu, diagrama estandarraren gaitasunak zabaltzen dituzten hirugarrenen osagaiak aurki ditzakezu. Etxeko laguntzailearentzat, printzipioz, osagai ona eta ederra mini-txartel grafikoa, baina zertxobait mugatua ere bada:

  • Zaila da barra-diagramaren parametroak tarte handietan ezartzea (barraren zabalera orduko zatietan ezartzen da, hau da, ordubete baino luzeagoak diren tarteak zenbaki zatikietan ezarriko dira)
  • Ezin duzu entitate desberdinak gehitu grafiko batean (adibidez, tenperatura eta hezetasuna, edo barra grafiko bat lerro batekin konbinatu).
• Etxeko laguntzaileak lehenespenez SQLite datu-base primitiboena erabiltzen ez ezik (eta nik, eskuzainak, ez nuen MySQL edo Postgres-en instalazioa menperatzen), datuak ez dira modurik hoberenean gordetzen. Beraz, adibidez, parametro baten parametro digital txikiena ere bakoitzaren aldaketa bakoitzarekin, kilobyte bateko tamaina inguruko json handi bat idazten da datu-basean

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

  Sentsore dezente dauzkat (tenperatura sentsoreak gela guztietan, ur eta elektrizitate kontagailuak), eta batzuek datu dezente sortzen dute ere. Esate baterako, SDM220 elektrizitate kontagailuak soilik dozena bat balio sortzen ditu 10-15 segundoro, eta horrelako 8 neurgailu instalatu nahiko nituzke. Eta beste sentsoreetan oinarrituta kalkulatzen diren parametro mordoa ere badago. Hori. balio horiek guztiek datu-basea egunero 100-200 MB erraz puzten dute. Astebetean, sistema ia ez da bueltaka egingo, eta hilabete batean flash drive-a hilko da (mugurdi PI-n etxeko laguntzailearen instalazio tipiko baten kasuan), eta ezin da urte osorako datuak biltegiratzea.

• Zortea baduzu, zure kontagailuak berak konta dezake kontsumoa. Edozein momentutan kontagailuarekin harremanetan jar zaitezke eta metatutako kontsumo-balioa zein ordutan dagoen galdetu. Oro har, interfaze digitala duten elektrizitate kontagailu guztiek (RS232/RS485/Modbus/Zigbee) aukera eskaintzen dute.

  Okerrago, gailuak berehalako parametroren bat neur dezake (adibidez, berehalako potentzia edo korrontea) edo, besterik gabe, X watt-ordu edo litro bakoitzeko pultsuak sortzen baditu. Gero, nola eta zerrekin integratu eta balioa non metatu pentsatu behar duzu. Edozein arrazoirengatik hurrengo txostena galtzeko arriskua dago, eta sistema osoaren zehaztasunak zalantzak sortzen ditu. Hori guztia etxeko laguntzailea bezalako etxeko sistema adimendun bati utz diezaiokezu, noski, baina inork ez du datu-baseko sarrera kopuruari buruzko puntua bertan behera utzi eta segundoan behin baino gehiagotan inkesta-sentsoreek ez dute funtzionatuko (muga bat). etxeko laguntzaile arkitektura).

Planteamendua 1

Lehenik eta behin, ikus dezagun zer etxeko laguntzailea eskaintzen den kutxatik kanpo. Epe batean kontsumoa neurtzea oso eskatutako funtzionaltasuna da. Jakina, aspaldi inplementatu zen osagai espezializatu gisa - utility_meter.

Osagaiaren funtsa da uneko_balio_pilatua_aldagaia barruan abiarazten duela eta epe jakin baten ondoren (ordu/aste/hilabete) berrezarri duela. Osagaiak berak sarrerako aldagaia kontrolatzen du (sentsore motaren baten balioa), balioaren aldaketak harpidetzen ditu - amaitutako emaitza besterik ez duzu lortzen. Gauza hau konfigurazio fitxategiko lerro gutxitan deskribatzen da

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

Hemen sensor.water_meter_cold neurgailuaren egungo balioa da lortzen dudan litrotan zuzenean plantxatik arabera mqtt. Diseinuak 2 sentsore berri sortzen ditu water_cold_hour_um eta water_cold_day_um, zeinak orduko eta eguneroko irakurketak pilatzen dituztenak, aldi baten ondoren zerora berrezarriz. Hona hemen egun erdiko orduko bateriaren grafikoa.

Lovelace-UI-ren orduko eta eguneko grafikoaren kodea honelakoa da:

      - 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

Izan ere, algoritmo honetan planteamendu honen arazoa dago. Esan bezala, sarrerako balio bakoitzeko (hurrengo litro bakoitzeko kontagailuaren uneko irakurketa), erregistro baten 1 kb sortzen da datu-basean. Erabilgarritasun-neurgailu bakoitzak balio berri bat ere sortzen du, oinarriari gehitzen zaiona ere. Orduko/eguneroko/asteroko/hileroko irakurketak bildu nahi baditut, bai, hainbat ur igogailuren kasuan, eta kontagailu elektrikoen paketea ere gehitu, datu asko izango dira. Beno, zehatzago esanda, ez dago datu asko, baina etxeko laguntzaileak datu-basean beharrezkoa ez den informazio mordoa idazten duenez, datu-basearen tamaina jauzika haziko da. Are gehiago, beldur naiz asteko eta hileko diagramen oinarriaren tamaina kalkulatzeari.

Gainera, erabilgarritasun-neurgailuak berak ez du arazoa konpontzen. Erabilgarritasun-neurgailuaren grafikoa orduro 0-ra berrezartzen den funtzio monotoniko bat da. Kontsumo egutegia erabilerraza ere behar dugu, aldian zenbat litro jan ziren. Historia grafikoaren osagai estandarrak ez du hori egiten, baina kanpoko mini-txartel grafikoaren osagaiak lagun zaitzake.

Hau da lovelace-UI txartelaren kodea:

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

Sentsorearen izena, grafiko mota, kolorea bezalako ezarpen estandarrez gain (ez zait gustatu laranja estandarra), garrantzitsua da hemen 3 ezarpenak kontuan hartzea:

• group_by:hour - diagrama orduaren hasieran lerrokatuta dauden zutabeekin sortuko da
• points_per_hour: 1 - orduko barra bat
• Eta garrantzitsuena, aggregate_func: max ordu bakoitzeko gehienezko balioa hartzea da. Parametro hori da zerra-hortzen diagrama barra bihurtzen duena.

Ez jarri arreta ezkerreko zutabeen ilarari - hau da osagaiaren portaera estandarra daturik ez badago. Baina ez zegoen daturik - datu bilketa aktibatu nuen erabilgarritasun-neurgailua erabiliz duela ordu pare bat artikulu honen mesedetan (nire egungo ikuspegia apur bat beherago deskribatuko dut).

Irudi honetan, batzuetan datuen bistaratzeak ere funtzionatzen duela eta barrek balio zuzenak islatzen dituztela erakutsi nahi nuen. Baina hori ez da guztia. Arrazoiren batengatik, 11:12etatik 19:62etara aldirako nabarmendutako zutabeak XNUMX litro bistaratzen ditu, nahiz eta hortz grafikoan sentsore beretik XNUMX litroko kontsumoa apur bat gorago ikusten dugun aldi berean. Edo zomorro bat edo eskuak okertuta daude. Baina oraindik ez dut ulertzen zergatik hautsi ziren eskuineko datuak: hango kontsumoa normala zen, hortz grafikotik ere ikusten dena.

Orokorrean, ez nuen lortu ikuspegi honen sinesgarritasuna - grafikoak ia beti erakusten du nolabaiteko heresia.

Eguneko sentsorearen antzeko kodea.

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

Kontuan izan group_by parametroa tarte gisa ezarrita dagoela eta points_per_hour parametroak dena arautzen duela. Eta hau osagai honen beste arazo bat da - points_per_hour-ek ondo funtzionatzen du ordu bateko edo gutxiagoko grafikoetan, baina nazkagarri tarte handiagoetan. Beraz, egun batean zutabe bat lortzeko, 1/24=0.04166666 balioa sartu behar nuen. Ez naiz asteko eta hileko grafikoez ari.

Planteamendua 2

Etxeko laguntzailea asmatzen ari nintzela, bideo hau topatu nuen:

Lagunak kontsumo datuak biltzen ditu Xiaomi entxufe mota ezberdinetatik. Bere zeregina apur bat sinpleagoa da: bistaratu gaur, atzo eta hilabeteko kontsumoaren balioa. Ez da grafikorik behar.

Utz ditzagun albo batera utzitako potentzia-balioen eskuzko integrazioari buruzko argudioak - Dagoeneko idatzi nuen ikuspegi honen "zehaztasuna" buruz. Ez dago argi zergatik ez zituen erabili metatutako kontsumo-balioak, dagoeneko saltoki berak jasotzen dituenak. Nire ustez, burdin zatiaren barnean integratzeak hobeto funtzionatuko du.

Bideotik, aldi baterako kontsumoa eskuz zenbatzeko ideia hartuko dugu. Gizon batentzat, gaurko eta atzoko balioak bakarrik hartzen dira kontuan, baina harago joango gara eta grafiko bat marrazten saiatuko gara. Nire kasuan proposatutako metodoaren funtsa honakoa da.

Balio_aldagai bat sortuko dugu orduaren_hasieran, eta bertan uneko kontagailuaren irakurketak idatziko ditugu.
Ordu amaierako (edo hurrengoaren hasieran) tenporizadorearen arabera, uneko irakurketaren eta ordu hasieran gordetakoaren arteko aldea kalkulatzen dugu. Diferentzia hori uneko orduko kontsumoa izango da - balioa sentsorean gordeko dugu, eta etorkizunean balio horretan oinarritutako grafiko bat eraikiko dugu.
Era berean, value_at_beginning_of_hour aldagaia "berrezarri" behar duzu kontagailuaren uneko balioa bertan idatziz.

Hau guztia ondo egin daiteke... etxeko laguntzailearen beraren bitartez.

Aurreko planteamenduan baino kode apur bat gehiago idatzi beharko duzu. Has gaitezen "aldagai" hauekin. Kutxatik kanpo, ez dugu entitate "aldakorra", baina mqtt broker baten zerbitzuak erabil ditzakezu. Balioak hara bidaliko ditugu retain=true banderarekin - honek artekariaren barneko balioa gordeko du, eta edozein unetan atera daiteke, etxeko laguntzailea berrabiarazi arren. Orduko eta eguneko kontagailuak aldi berean egin nituen.

- 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

Magia guztia automatizazioan gertatzen da, orduro eta gauero, hurrenez hurren.

- 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

Bi automatizazio bi gauza egiten dituzte:

• Kalkulatu tarte bakoitzeko balioa hasierako eta amaierako balioaren arteko diferentzia gisa
• Eguneratu oinarrizko balioa hurrengo tarterako

Kasu honetan grafikoen eraikuntza ohiko historia grafikoaren bidez ebazten da:

      - 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

Honela dirudi:

Printzipioz, hau da dagoeneko behar duzuna. Metodo honen abantaila da datuak tarte bakoitzean behin sortzen direla. Horiek. guztira, eguneko 24 sarrera ordu-diagramarako.

Zoritxarrez, horrek oraindik ez du konpontzen hazten ari den oinarriaren arazo orokorra. Hileroko kontsumo grafiko bat nahi badut, gutxienez urtebetez gorde beharko ditut datuak. Etxeko laguntzaileak datu-base osorako biltegiratze-iraupen ezarpen bakarra eskaintzen duenez, horrek esan nahi du sistemako datu GUZTIAK urtebetez gorde beharko direla. Adibidez, urtebetean 200 metro kubiko ur kontsumitzen ditut, hau da, 200000 sarrera datu-basean. Eta beste sentsore batzuk kontuan hartzen badituzu, orduan zifra, oro har, ez-duzina bihurtzen da.

Planteamendua 3

Zorionez, pertsona adimendunek arazo hau konpondu dute dagoeneko InfluxDB datu-basea idatziz. Datu-base hau denboran oinarritutako datuak gordetzeko bereziki optimizatuta dago eta sentsore ezberdinen balioak gordetzeko aproposa da. Sistemak SQL antzeko kontsulta-lengoaia ere eskaintzen du, datu-basetik balioak ateratzeko eta, ondoren, modu ezberdinetan gehitzeko. Azkenik, datu desberdinak denbora ezberdinetarako gorde daitezke. Esaterako, sarri aldatzen diren irakurketak, hala nola tenperatura edo hezetasuna, pare bat astez bakarrik gorde daitezke, eta uraren kontsumoaren eguneroko irakurketak urte osoan gorde daitezke.

InfluxDBz gain, pertsona adimendunek Grafana ere asmatu zuten, InfluxDBko datuetatik grafikoak marrazteko sistema. Grafanak grafiko mota desberdinak marraz ditzake, xehetasunez pertsonaliza ditzake eta, batez ere, grafiko hauek lovelace-UI etxeko laguntzailean "konektatu" daitezke.

inspiratu zaitez Hemen и Hemen. Artikuluek xehetasunez deskribatzen dute InfluxDB eta Grafana etxeko laguntzailearekin instalatzeko eta konektatzeko prozesua. Nire arazo zehatza konpontzen zentratuko naiz.

Beraz, lehenik eta behin, has gaitezen kontagailuaren balioa gehitzen influxDB-n. Etxeko laguntzailearen konfigurazioaren zati bat (adibide honetan, hotzarekin ez ezik, ur beroarekin ere ondo pasako dut):

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

Desgaitu dezagun datu berdinak etxeko laguntzailearen barneko datu-basean gordetzea, berriro ez puzteko:

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

Goazen orain InfluxDB kontsolara eta konfigura dezagun gure datu-basea. Bereziki, datu jakin batzuk zenbat denboran gordeko diren konfiguratu behar duzu. Hau deitzen denak arautzen du. atxikipen-politika - datu-base nagusiaren barneko datu-baseen antzekoa da, barne datu-base bakoitzak bere ezarpenak dituelarik. Lehenespenez, datu guztiak autogen izeneko atxikipen politikara gehitzen dira, datu hauek astebetez gordeko dira. Orduko datuak hilabetez gordetzea nahiko nuke, asteko datuak urtebetez eta hileko datuak inoiz ezabatzea. Atxikipen politika egokiak sortuko ditugu

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

Orain, hain zuzen ere, trikimailu nagusia datuen agregazioa da etengabeko kontsulta erabiliz. Hau automatikoki kontsulta bat zehaztutako tarteetan abiarazten duen mekanismoa da, kontsulta honen datuak batzen dituena eta emaitza balio berri bati gehitzen diona. Ikus dezagun adibide bat (zutabe batean idazten dut irakurgarritasuna lortzeko, baina errealitatean komando hau lerro batean sartu behar nuen)

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

Komando hau:

• cq_water_cold_hourly izeneko etengabeko kontsulta bat sortzen du etxeko laguntzailearen datu-basean
• Kontsulta orduro egingo da (denbora (1h))
• Kontsultak neurketa-a homeassistant.autogen.l (litro) datu guztiak aterako ditu, ur hotzaren eta beroaren irakurketak barne.
• Datu agregatuak entity_id-en arabera taldekatuko dira, eta horrek ur hotzaren eta beroaren balio bereiziak sortuko ditu.
• Litroen kontadorea ordu bakoitzeko sekuentzia monotoniko handitzen denez, gehienezko balioa hartu beharko duzu, beraz, batuketa max(balioa) funtzioak egingo du.
• Balio berria homeassistant.month.water_meter_hour helbidean idatziko da, non hilabetea atxikipen-politikaren izena den hilabeteko atxikipen-epearekin. Gainera, ur hotzari eta beroari buruzko datuak erregistro bereizietan sakabanatuko dira dagokion entity_id-arekin eta balio-eremuko balioarekin

Gauez edo etxean inor ez dagoenean, ez dago ur-kontsumorik, eta horren arabera, homeassistant.autogen.l-en ere ez dago erregistro berririk. Kontsulta arruntetan balioak falta ez daitezen, bete (aurrekoa) erabil dezakezu. Honek InfluxDB iragan orduko balioa erabiltzera behartuko du.

Zoritxarrez, etengabeko kontsultak berezitasun bat du: betetzeko (aurreko) trikimailuak ez du funtzionatzen eta erregistroak ez dira sortzen. Gainera, hau arazo gaindiezin bat da, zeina urtebete baino gehiago eztabaidatu da. Aurrerago arazo honi aurre egingo diogu, eta bete (aurrekoa) etengabeko kontsultan egon behar dugu - ez du oztopatzen.

Ikus dezagun zer gertatu den (noski, ordu pare bat itxaron behar duzu):

> 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

Kontuan izan datu-baseko balioak UTC-n gordetzen direla, beraz, zerrenda hau 3 ordutan desberdina da - InfluxDB irteerako 7:10etako balioak goiko zerrendetako 2:5etako balioekin bat datoz. Kontuan izan, gainera, goizeko XNUMXetatik XNUMXetara ez dagoela erregistrorik; hau da etengabeko kontsultaren ezaugarria.

Ikus dezakezun bezala, balio agregatua ere monotonikoki hazten den sekuentzia bat da, sarrerak baino ez dira maizago - orduan behin. Baina hau ez da arazo bat - grafikorako datu zuzenak aterako dituen beste kontsulta bat idatz dezakegu.

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)

Deszifratuko dut:

• homeassistant.month.water_meter_hour datu-basetik, entity_id='water_meter_cold'-ren datuak aterako ditugu azken eguneko (ordua >= now() -24h).
• Esan bezala, baliteke sarrera batzuk falta izatea homeassistant.month.water_meter_hour sekuentzian. Datu hauek birsortuko ditugu kontsulta GROUP BY denborarekin (1h) exekutatuz. Oraingoan, bete (aurrekoa) behar bezala funtzionatuko du, falta diren datuak sortuz (funtzioak aurreko balioa hartuko du)
• Kontsulta honetan garrantzitsuena diferentzia funtzioa da, ordu-marken arteko aldea kalkulatuko duena. Berez, ez du funtzionatzen eta agregazio-funtzioa behar du. Izan bedi hau aurretik erabilitako max()-a.

Exekuzioaren emaitza honelakoa da

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

2:5etatik 0:XNUMXetara (UTC) ez zegoen kontsumorik. Dena den, kontsultak kontsumo-balio bera itzuliko du betetzeari esker (aurrekoa), eta diferentzia-funtzioak balio hori kenduko du eta irteeran XNUMX lortuko du, benetan beharrezkoa dena.

Egin beharreko gauza bakarra grafiko bat eraikitzea da. Horretarako, ireki Grafana, ireki lehendik dauden (edo sortu berri) panel bat, sortu panel berri bat. Diagramaren ezarpenak honako hauek izango dira.

Ur hotzaren eta beroaren datuak grafiko berean bistaratuko ditut. Eskaera goian deskribatu dudan berdina da.

Bistaratzeko parametroak honela ezartzen dira. Niretzat lerroekin (lerroekin) grafiko bat izango da, mailaka (eskailera) doana. Pila parametroa jarraian azalduko da. Behean bistaratzeko aukera pare bat gehiago daude, baina ez dira hain interesgarriak.

Lortutako grafikoa etxeko laguntzaileari gehitzeko, hau egin behar duzu:

• irten diagrama editatzeko modutik. Arrazoiren batengatik, diagrama partekatzeko ezarpen zuzenak paneleko orritik soilik eskaintzen dira
• Egin klik diagramaren izenaren ondoan dagoen triangeluan, hautatu partekatu menuan
• Irekitzen den leihoan, joan kapsulatzeko fitxara
• Desmarkatu uneko ordu-tartea - URL bidez ezarriko dugu denbora-tartea
• Aukeratu nahi den gaia. Nire kasuan argia da
• Kopiatu ondoriozko URLa lovelace-UI ezarpenen txartelean

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

Kontuan izan denbora tartea (azken 2 egunak) hemen ezartzen dela, eta ez aginte-panelaren ezarpenetan.

Diagrama honen itxura du. Azken 2 egunetan ez dut ur beroa erabili, beraz, ur hotzaren grafiko bat bakarrik marraztu da.

Ez dut nik neuk erabaki zein taula gustatzen zaidan gehien, urrats-lerro bat edo benetako barrak. Hori dela eta, eguneroko kontsumo-egutegi baten adibidea besterik ez dut jarriko, oraingoan bakarrik tabernetan. Kontsultak goian deskribatutako modu berean eraikitzen dira. Bistaratzeko aukerak hauek dira:

Taula honek itxura hau du:

Beraz, Pila parametroari buruz. Grafiko honetan, ur hotz barra bat marraztuta dago barra bero baten gainean. Altuera osoa denboraldiko ur hotzaren eta beroaren guztizko kontsumoari dagokio.

Erakusten diren grafiko guztiak dinamikoak dira. Sagua leku interesgarriaren gainean mugitu dezakezu eta xehetasunak eta balioa ikus ditzakezu puntu jakin batean.

Zoritxarrez, ez zen ukenduan euli pare bat gabe. Barra-diagrama batean (urrats-lerroak dituen grafikoan ez bezala), barraren erdia ez dago egunaren erdian, 00:00etan baizik. Horiek. barraren ezkerreko erdia aurreko egunekoaren ordez marrazten da. Beraz, larunbateko eta igandeko grafikoak zona urdinxkaren ezkerrera apur bat marraztuta daude. Nola irabazi asmatu nuen arte.

Beste arazo bat hileroko tarteekin behar bezala lan egiteko ezintasuna da. Kontua da ordu/egun/asteko iraupena finkoa dela, baina hilabetearen iraupena desberdina da bakoitzean. InfluxDB tarte berdinekin bakarrik funtziona dezake. Orain arte, nire garuna nahikoa izan da 30 eguneko tarte finkoa ezartzeko. Bai, taulak apur bat flotatuko du urtean zehar eta barrak ez dira zehazki hilabeteekin bat etorriko. Baina gauza hau pantaila-neurgailu gisa interesgarria denez, ondo nago honekin.

Gutxienez bi irtenbide ikusten ditut:

• Hileroko zerrendetan puntuatzeko eta astekoetara mugatzeko. Urte batean asteko 52 tabernak nahiko ona dirudi
• Demagun hileroko kontsumoa bera 2. metodo gisa, eta erabili grafana grafiko ederretarako soilik. Nahiko irtenbide zehatza da. Azken urteko grafikoak ere gainjar ditzakezu alderatzeko - grafanak hori egin dezake.

Ondorioa

Ez dakit zergatik, baina horrelako grafikoak maite ditut. Bizitza pil-pilean dagoela eta dena aldatzen ari dela erakusten dute. Atzo asko, gaur gutxi, bihar beste zerbait izango da. Etxeekin kontsumoaren gaia lantzea geratzen da. Baina egungo goseak izanda ere, fakturako zifra handi eta ulertezina besterik ez da jada kontsumoaren irudi ulergarri samarra bihurtzen.

Programatzaile gisa ia 20 urteko ibilbidea izan arren, ia ez nintzen datu-baseekin gurutzatzen. Hori dela eta, kanpoko datu-base bat instalatzea hain itxuragabea eta ulergaitza zirudien. Dena aldatu da goiko artikulua - Erreminta egoki bat izorratzea klik pare batean egiten dela ondorioztatu zen, eta tresna espezializatu batekin, marrazteko zeregina apur bat errazten da.

Izenburuan, elektrizitate kontsumoa aipatu dut. Zoritxarrez, momentuz ezin dut grafikorik eman. SDM120 neurgailu bat hilda dago, eta bestea akatsa dago Modbus bidez sartzen denean. Hala ere, horrek ez dio inola ere eragiten artikulu honen gaiari - grafikoak uraren moduan eraikiko dira.

Artikulu honetan, nik neuk probatu ditudan planteamendu horiek eman ditut. Segur aski, badirela ezagutzen ez ditudan datuen bilketa eta bistaratzea antolatzeko beste modu batzuk. Konta iezadazu iruzkinetan, asko interesatuko zait. Pozik hartuko dut kritika eraikitzaileak eta ideia berriak. Espero dut goiko materialak ere norbait laguntzea.

Iturria: www.habr.com