Inteligenta Hejmo: Bildo de Akvo kaj Elektro-Konsumo en Hejma Asistanto

Ĉiufoje, kiam mi ricevas pagon por elektro kaj akvo, mi demandas min - ĉu mia familio vere konsumas tiom multe? Nu, jes, estas hejtita planko kaj kaldrono en la banĉambro, sed ili ne funkcias kiel fajrobrigadistoj la tutan tempon. Ni ankaŭ ŝajnas ŝpari akvon (kvankam ni ankaŭ ŝatas plaŭdi en la banĉambro). Antaŭ kelkaj jaroj mi jam konektitaj akvomezuriloj и elektro al inteligenta hejmo, sed ĉi tie la aferoj blokiĝis. La manoj atingis la analizon de konsumo nur nun, pri kio, fakte, temas ĉi tiu artikolo.

Mi lastatempe ŝanĝis al Hejma Asistanto kiel mia inteligenta hejma sistemo. Unu el la kialoj estis nur la kapablo organizi la kolekton de granda kvanto da datumoj kun la ebleco de oportuna konstruado de diversaj specoj de grafikaĵoj.

La informoj priskribitaj en ĉi tiu artikolo ne estas nova, ĉiuj ĉi aferoj sub malsamaj saŭcoj jam estis priskribitaj en la Interreto. Sed ĉiu artikolo, kiel regulo, priskribas nur unu aliron aŭ aspekton. Mi devis kompari ĉiujn ĉi tiujn alirojn kaj elekti la plej taŭgan mem. La artikolo ankoraŭ ne provizas ĝisfundajn informojn pri datumkolektado, sed estas speco de resumo pri kiel mi faris ĝin. Do konstruiva kritiko kaj sugestoj por plibonigo estas bonvenaj.

Formulado de la problemo

Do, la celo de la hodiaŭa ekzerco estas akiri belajn grafikaĵojn de akvo kaj elektrokonsumo:

• Ĉiuhore dum 2 tagoj
• Ĉiutage dum 2 semajnoj
• (laŭvola) ĉiusemajne kaj monata

Estas iuj malfacilaĵoj en ĉi tio:

• La normaj diagramkomponentoj tendencas esti sufiĉe malbonaj. En la plej bona kazo, vi povas konstrui liniografeon laŭ punktoj.

  Se vi serĉas bone, vi povas trovi triajn komponantojn, kiuj etendas la kapablojn de la norma diagramo. Por hejma asistanto, principe, bona kaj bela komponanto mini grafika karto, sed ĝi ankaŭ estas iom limigita:

  • Estas malfacile agordi la parametrojn de la stangodiagramo je grandaj intervaloj (la larĝo de la stango estas agordita en frakcioj de horo, kio signifas, ke intervaloj pli longaj ol horo estos agordita en frakciaj nombroj)
  • Vi ne povas aldoni malsamajn entojn al unu grafikaĵo (ekzemple temperaturo kaj humideco, aŭ kombini strekgrafikon kun linio)
• Ne nur la hejma asistanto uzas la plej primitivan datumbazon SQLite defaŭlte (kaj mi, la manlaboristo, ne regis la instaladon de MySQL aŭ Postgres), la datumoj ne estas konservitaj en la plej optimuma maniero. Do, ekzemple, kun ĉiu ŝanĝo de ĉiu eĉ la plej malgranda cifereca parametro de parametro, grandega json ĉirkaŭ kilobajto estas skribita al la datumbazo

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

  Mi havas sufiĉe da sensiloj (temperatursensiloj en ĉiu ĉambro, akvo- kaj elektromezuriloj), kaj kelkaj ankaŭ generas sufiĉe multajn datumojn. Ekzemple, nur la elektromezurilo SDM220 generas ĉirkaŭ dekduon da valoroj ĉiujn 10-15 sekundojn, kaj mi ŝatus instali tiajn mezurilojn 8. Kaj ankaŭ ekzistas tuta aro da parametroj, kiuj estas kalkulitaj surbaze de aliaj sensiloj. Tio. ĉiuj ĉi tiuj valoroj povas facile ŝveligi la datumbazon je 100-200 MB ĉiutage. Post unu semajno, la sistemo apenaŭ ĵetos kaj turniĝos, kaj post unu monato la poŝmemoro mortos (en la kazo de tipa instalado de hejma asistanto sur frambo PI), kaj oni ne povas paroli pri konservado de datumoj dum tuta jaro. .

• Se vi estas bonŝanca, via mezurilo mem povas kalkuli konsumon. Vi povas kontakti la mezurilon iam ajn kaj demandi kioma horo estas la akumulita konsumvaloro. Kiel regulo, ĉiuj elektromezuriloj, kiuj havas ciferecan interfacon (RS232/RS485/Modbus/Zigbee) provizas tian ŝancon.

  Pli malbone, se la aparato povas simple mezuri iun tujan parametron (ekzemple, tujan potencon aŭ kurenton), aŭ simple generi pulsojn ĉiujn X vathorojn aŭ litrojn. Tiam vi devas pensi pri kiel kaj per kio integri ĝin kaj kie amasigi valoron. Estas risko maltrafi la sekvan raporton ial ajn, kaj la precizeco de la sistemo entute levas demandojn. Vi povas, kompreneble, konfidi ĉion ĉi al inteligenta hejma sistemo kiel hejma asistanto, sed neniu nuligis la punkton pri la nombro da eniroj en la datumbazo, kaj balotaj sensiloj pli ol unufoje sekundo ne funkcios (limigo de la hejma asistanto arkitekturo).

Aliro 1

Unue, ni vidu, kia hejma asistanto estas provizita el la skatolo. Mezuri konsumon dum periodo estas tre petita funkcio. Kompreneble, ĝi estis efektivigita antaŭ longa tempo kiel speciala komponanto - utility_meter.

La esenco de la komponanto estas, ke ĝi komencas la variablon current_accumulated_value interne kaj rekomencigas ĝin post difinita periodo (horo/semajno/monato). La komponanto mem kontrolas la envenantan variablon (la valoron de ia sensilo), abonas ŝanĝojn en la valoro mem - vi nur ricevas la pretan rezulton. Ĉi tiu afero estas priskribita en nur kelkaj linioj en la agorda dosiero

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

Ĉi tie sensor.water_meter_cold estas la aktuala valoro de la metro en litroj, kiun mi ricevas rekte el la fero de mqtt. La dezajno kreas 2 novajn sensilojn water_cold_hour_um kaj water_cold_day_um, kiuj amasigas horajn kaj ĉiutagajn legaĵojn, restarigante ilin al nulo post periodo. Jen grafiko de la hora baterio dum duona tago.

La hora kaj ĉiutaga diagramkodo por lovelace-UI aspektas jene:

      - 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

Efektive, en ĉi tiu algoritmo kuŝas la problemo de ĉi tiu aliro. Kiel mi jam menciis, por ĉiu envenanta valoro (la aktuala mezurila legado por ĉiu sekva litro), 1kb de rekordo estas generita en la datumbazo. Ĉiu utilmezurilo ankaŭ generas novan valoron, kiu ankaŭ estas aldonita al la bazo. Se mi volas kolekti horajn/ĉiutagajn/semajnajn/monatajn legaĵojn, jes, por pluraj akvomontriloj, kaj eĉ aldoni pakon da elektraj mezuriloj, tio estos multaj datumoj. Nu, pli precize, ne estas multe da datumoj, sed ĉar la hejma asistanto skribas amason da nenecesaj informoj al la datumbazo, la grandeco de la datumbazo kreskos laŭpaŝe. Mi eĉ timas taksi la grandecon de la bazo por semajnaj kaj monataj leteroj.

Krome, la utilmezurilo mem ne solvas la problemon. La utilmezurila intrigo estas monotone kreskanta funkcio kiu restarigas al 0 ĉiun horon. Ni ankaŭ bezonas uzant-amikan konsumhoraron, kiom da litroj estis manĝitaj dum la periodo. La norma historio-grafika komponanto ne faras tion, sed la ekstera mini-grafika komponanto povas helpi nin.

Jen la kartkodo por 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'

Krom la normaj agordoj kiel la sensilnomo, grafika tipo, koloro (mi ne ŝatis la norman oranĝon), gravas noti 3 agordojn ĉi tie:

• group_by:hour - la diagramo estos generita kun kolumnoj vicigitaj al la komenco de la horo
• points_per_hour: 1 - unu takto por horo
• Kaj plej grave, aggregate_func: max estas preni la maksimuman valoron ene de ĉiu horo. Estas ĉi tiu parametro, kiu transformas la segildentan diagramon en stangojn.

Ne atentu la vicon de kolumnoj maldekstre - ĉi tio estas la norma konduto de la komponanto se ne ekzistas datumoj. Sed ne estis datumoj - mi nur ŝaltis datumkolektadon per la utilmezurilo antaŭ kelkaj horoj nur pro ĉi tiu artikolo (mi priskribos mian nunan aliron iom pli malalte).

En ĉi tiu bildo, mi volis montri, ke foje la datummontrado eĉ funkcias, kaj la stangoj vere reflektas la ĝustajn valorojn. Sed tio ne estas ĉio. Ial, la emfazita kolumno por la periodo de 11 a.m. ĝis 12 a.m. montras 19 litrojn, kvankam sur la denta grafikaĵo iom pli alta por la sama periodo de la sama sensilo ni vidas konsumon de 62 litroj. Aŭ cimo aŭ manoj estas kurbaj. Sed mi ankoraŭ ne komprenas, kial la datumoj dekstre rompiĝis - la konsumo tie estis normala, kio ankaŭ estas videbla el la denta grafikaĵo.

Ĝenerale, mi ne sukcesis atingi la verŝajnecon de ĉi tiu aliro - la grafikaĵo preskaŭ ĉiam montras ian herezon.

Simila kodo por la taga sensilo.

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

Bonvolu noti, ke la parametro group_by estas agordita al intervalo, kaj la parametro points_per_hour regas ĉion. Kaj ĉi tio estas alia problemo kun ĉi tiu komponanto - points_per_hour funkcias bone sur leteroj de horo aŭ malpli, sed abomene sur pli grandaj intervaloj. Do por ricevi unu kolumnon en unu tago, mi devis enigi la valoron 1/24=0.04166666. Mi ne parolas pri semajnaj kaj monataj leteroj.

Aliro 2

Dum ankoraŭ eltrovante la hejman asistanton, mi trovis ĉi tiun filmeton:

La kamarado kolektas konsumajn datumojn de pluraj specoj de Xiaomi-ingoj. Lia tasko estas iom pli simpla - nur montru la valoron de konsumo por hodiaŭ, hieraŭ kaj por la monato. Neniuj diagramoj bezonataj.

Ni lasu flanken la argumentojn pri la mana integriĝo de tujaj potencaj valoroj - mi jam skribis supre pri la "precizeco" de ĉi tiu aliro. Ne estas klare, kial li ne uzis la amasigitajn konsumvalorojn, kiuj jam estas kolektitaj de la sama ellasejo. Laŭ mi, integriĝo ene de la ferpeco funkcios pli bone.

De la video, ni prenos la ideon permane kalkuli konsumon dum periodo. Por viro, nur la valoroj por hodiaŭ kaj por hieraŭ estas konsiderataj, sed ni iros plu kaj provos desegni grafeon. La esenco de la proponita metodo en mia kazo estas jena.

Ni kreos varian valoron_je_la_komenco_de_horo, en kiu ni skribos la aktualajn nombrilojn.
Laŭ la temporigilo je la fino de la horo (aŭ komence de la sekva), ni kalkulas la diferencon inter la nuna legado kaj tiu konservita je la komenco de la horo. Ĉi tiu diferenco estos la konsumo por la nuna horo - ni konservos la valoron al la sensilo, kaj estonte ni konstruos grafeon bazitan sur ĉi tiu valoro.
Vi ankaŭ devas "restarigi" la variablon value_at_beginning_of_hour skribante la nunan valoron de la nombrilo tie.

Ĉio ĉi povas esti farita per bone ... per la hejma asistanto mem.

Vi devos skribi iom pli da kodo ol en la antaŭa aliro. Ni komencu per ĉi tiuj "variabloj". El la skatolo, ni ne havas la "varian" enton, sed vi povas uzi la servojn de mqtt-broker. Ni sendos tien valorojn kun la retain=vera flago - ĉi tio savos la valoron ene de la makleristo, kaj ĝi povas esti eltirita en ajna momento, eĉ kiam la hejma asistanto estas rekomencita. Mi faris horon kaj ĉiutagajn nombrilojn samtempe.

- 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

La tuta magio okazas en la aŭtomatigo, kiu funkcias ĉiun horon kaj ĉiunokte respektive.

- 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

Ambaŭ aŭtomatigoj faras 2 aferojn:

• Kalkulu la valoron per intervalo kiel la diferenco inter la komenca kaj fina valoro
• Ĝisdatigu la bazan valoron por la sekva intervalo

La konstruado de grafeoj en ĉi tiu kazo estas solvita per la kutima historia-grafo:

      - 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

Ĝi aspektas jene:

En principo, ĉi tio jam estas kion vi bezonas. La avantaĝo de ĉi tiu metodo estas ke la datumoj estas generitaj unufoje per intervalo. Tiuj. entute 24 enskriboj tage por la hora diagramo.

Bedaŭrinde, ĉi tio ankoraŭ ne solvas la ĝeneralan problemon de kreskanta bazo. Se mi volas monatan konsuman grafikon, mi devos konservi datumojn dum almenaŭ jaro. Kaj ĉar hejma asistanto provizas nur unu konservan daŭron por la tuta datumbazo, tio signifas, ke ĈIUJ datumoj en la sistemo devos esti konservitaj dum tuta jaro. Ekzemple, en jaro mi konsumas 200 kubmetrojn da akvo, kio signifas 200000 XNUMX enskribojn en la datumbazo. Kaj se vi konsideras aliajn sensilojn, tiam la figuro fariĝas ĝenerale maldeca.

Aliro 3

Feliĉe, inteligentaj homoj jam solvis ĉi tiun problemon skribante la datumbazon InfluxDB. Ĉi tiu datumbazo estas speciale optimumigita por stoki tempbazitajn datumojn kaj estas ideala por stoki valorojn de malsamaj sensiloj. La sistemo ankaŭ provizas SQL-similan demandlingvon, kiu ebligas al vi ĉerpi valorojn el la datumbazo kaj poste aldoni ilin diversmaniere. Fine, malsamaj datumoj povas esti konservitaj por malsamaj tempoj. Ekzemple, ofte ŝanĝiĝantaj legaĵoj kiel temperaturo aŭ humideco povas esti stokitaj dum nur kelkaj semajnoj, dum ĉiutagaj legaĵoj de akvokonsumo povas esti stokitaj dum tuta jaro.

Krom InfluxDB, inteligentaj homoj ankaŭ inventis Grafana, sistemon por desegni grafikaĵojn el datumoj de InfluxDB. Grafana povas desegni malsamajn specojn de leteroj, personecigi ilin detale, kaj, plej grave, ĉi tiuj leteroj povas esti "ŝtopitaj" al la hejma asistanto lovelace-UI.

esti inspirita tie и tie. La artikoloj priskribas detale la procezon de instalado kaj konekto de InfluxDB kaj Grafana al hejma asistanto. Mi koncentriĝos pri solvado de mia specifa problemo.

Do, unue, ni komencu aldoni la nombrilon en influxDB. Peco de la hejmhelpa agordo (en ĉi tiu ekzemplo, mi amuziĝos ne nur kun malvarma, sed ankaŭ kun varma akvo):

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

Ni malŝaltu konservadon de la samaj datumoj al la interna datumbazo de hejma asistanto por ne ŝveligi ĝin denove:

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

Ni nun iru al la InfluxDB-konzolo kaj agordu nian datumbazon. Aparte, vi devas agordi kiom longe certaj datumoj estos konservitaj. Ĉi tio estas reguligita de la tn. retenpolitiko - tio similas al datumbazoj ene de la ĉefa datumbazo, kie ĉiu interna datumbazo havas siajn proprajn agordojn. Defaŭlte, ĉiuj datumoj estas aldonitaj al la retenpolitiko nomata aŭtogen, ĉi tiuj datumoj estos konservitaj dum semajno. Mi ŝatus ke horaj datumoj estu konservitaj dum monato, semajnaj datumoj dum jaro, kaj monataj datumoj tute neniam esti forigitaj. Ni kreos taŭgajn retenajn politikojn

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

Nun, fakte, la ĉefa lertaĵo estas agregado de datumoj uzante kontinuan demandon. Ĉi tio estas mekanismo, kiu aŭtomate lanĉas demandon je difinitaj intervaloj, agregas la datumojn por ĉi tiu demando kaj aldonas la rezulton al nova valoro. Ni rigardu ekzemplon (mi skribas en kolumno por legebleco, sed fakte mi devis enigi ĉi tiun komandon sur unu linio)

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

Ĉi tiu komando:

• Kreas kontinuan demandon nomitan cq_water_cold_hourly en la hejmhelpa datumbazo
• La demando estos efektivigita ĉiun horon (tempo (1h))
• La demando eltiros ĉiujn datumojn de mezurado de homeassistant.autogen.l (litroj), inkluzive de legaĵoj de malvarma kaj varma akvo
• Agregataj datumoj estos grupigitaj per entity_id, kiu kreos apartajn valorojn por malvarma kaj varma akvo.
• Ĉar la nombrilo de litroj estas monotone kreskanta sekvenco ene de ĉiu horo, vi devos preni la maksimuman valoron, do la agregado estos farita per la max(valora) funkcio.
• La nova valoro estos skribita al homeassistant.month.water_meter_hour kie monato estas la nomo de la retenpolitiko kun retenperiodo de unu monato. Plie, datumoj pri malvarma kaj varma akvo estos disigitaj en apartajn registrojn kun la responda entity_id kaj la valoro en la valorkampo

Nokte aŭ kiam neniu estas hejme, ne estas akvokonsumo, kaj sekve ankaŭ ne estas novaj rekordoj en homeassistant.autogen.l. Por eviti mankantajn valorojn en normalaj demandoj, vi povas uzi plenigi (antaŭan). Ĉi tio devigos InfluxDB uzi la pasintan horon.

Bedaŭrinde, kontinua konsulto havas apartaĵon: la plenigaĵo (antaŭa) ne funkcias kaj registroj simple ne estas kreitaj. Cetere, ĉi tio estas ia nesuperebla problemo, kiu diskutata dum pli ol unu jaro. Ni traktos ĉi tiun problemon poste, kaj lasos plenigi(antaŭan) en kontinua demando esti tie - ĝi ne malhelpas.

Ni kontrolu kio okazis (kompreneble, vi devas atendi kelkajn horojn):

> 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

Notu, ke la valoroj en la datumbazo estas stokitaj en UTC, do ĉi tiu listo diferencas je 3 horoj - la valoroj de la 7-a horo en la eligo de InfluxDB kongruas kun la valoroj de la 10-a en la supraj leteroj. Rimarku ankaŭ, ke inter la 2-a kaj la 5-a matene estas simple neniuj registroj - ĉi tio estas la trajto de daŭra konsultado.

Kiel vi povas vidi, la kunigita valoro ankaŭ estas monotone kreskanta sekvenco, nur la enskriboj estas malpli oftaj - unufoje hore. Sed ĉi tio ne estas problemo - ni povas skribi alian demandon, kiu ĉerpos la ĝustajn datumojn por la diagramo.

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)

Mi deĉifris:

• El la datumbazo homeassistant.month.water_meter_hour, ni eltiros datumojn por entity_id='water_meter_cold' por la lasta tago (tempo >= nun() -24h).
• Kiel mi menciis, iuj enskriboj eble mankas en la sinsekvo homeassistant.month.water_meter_hour. Ni regeneros ĉi tiujn datumojn rulante la demandon kun GROUP BY tempo (1h). Ĉi-foje, plenigi(antaŭa) funkcios ĝuste, generante la mankantajn datumojn (la funkcio prenos la antaŭan valoron)
• La plej grava afero en ĉi tiu demando estas la diferenco-funkcio, kiu kalkulos la diferencon inter la hormarkoj. Per si mem, ĝi ne funkcias kaj postulas agregan funkcion. Estu ĉi tio la max() uzata antaŭe.

La ekzekutrezulto aspektas tiel

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 la 2-a ĝis la 5-a (UTC) ne estis konsumado. Tamen, la demando resendos la saman konsumvaloron danke al plenigi(antaŭa), kaj la diferencfunkcio subtrahos ĉi tiun valoron de si mem kaj ricevos 0 ĉe la eligo, kio estas efektive postulata.

La nura afero por fari estas konstrui grafeon. Por fari tion, malfermu Grafana, malfermu iun ekzistantan (aŭ kreu novan) panelon, kreu novan panelon. La diagramaj agordoj estos kiel sekvas.

Mi montros datumojn pri malvarma kaj varma akvo sur la sama grafikaĵo. La peto estas ĝuste la sama kiel mi priskribis supre.

Vidigaj parametroj estas fiksitaj jene. Por mi estos grafeo kun linioj (linioj), kiu iras en ŝtupoj (ŝtuparo). La Stako-parametro estos klarigita sube. Estas kelkaj pliaj montraj opcioj sube, sed ili ne estas tiom interesaj.

Por aldoni la rezultan grafikon al hejma asistanto, vi devas:

• eliru la grafikan redaktan reĝimon. Ial, la ĝustaj agordoj de kunhavigo de diagramoj estas ofertitaj nur de la panela paĝo
• Alklaku la triangulon apud la nomo de la diagramo, elektu kunhavigi el la menuo
• En la fenestro kiu malfermiĝas, iru al la enigita langeto
• Malmarku nunan temporanĝon - ni agordos la temporanĝon per URL
• Elektu la bezonatan temon. En mia kazo ĝi estas malpeza
• Kopiu la rezultan URL al la agorda karto 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"

Bonvolu noti, ke la tempointervalo (lastaj 2 tagoj) estas agordita ĉi tie, kaj ne en la panela agordo.

La diagramo aspektas tiel. Mi ne uzis varman akvon en la lastaj 2 tagoj, do nur grafiko de malvarma akvo estas desegnita.

Mi ne decidis por mi, kiun diagramon mi plej ŝatas, paŝolinion aŭ verajn stangojn. Tial mi simple donos ekzemplon de ĉiutaga konsumhoraro, nur ĉi-foje en trinkejoj. Demandoj estas konstruitaj en la sama maniero kiel priskribite supre. La montraj opcioj estas:

Ĉi tiu diagramo aspektas jene:

Do pri la parametro Stack. En ĉi tiu grafikaĵo, malvarmakva trinkejo estas desegnita supre de varma trinkejo. La tuta alteco respondas al la tuta konsumo de malvarma kaj varma akvo por la periodo.

Ĉiuj grafikaĵoj montritaj estas dinamikaj. Vi povas movi la muson super la interespunkton kaj vidi la detalojn kaj valoron ĉe aparta punkto.

Bedaŭrinde, ĝi ne estis sen paro da muŝo en la ungvento. Sur strekodiagramo (male al la grafeo kun paŝolinioj), la mezo de la stango ne estas en la mezo de la tago, sed je 00:00. Tiuj. la maldekstra duono de la stango estas desegnita anstataŭ la antaŭa tago. Do la leteroj por sabato kaj dimanĉo estas desegnitaj iomete maldekstre de la blua zono. Ĝis mi eltrovis kiel gajni ĝin.

Alia problemo estas la malkapablo labori ĝuste kun monataj intervaloj. La fakto estas, ke la longeco de la horo / tago / semajno estas fiksita, sed la daŭro de la monato estas malsama ĉiufoje. InfluxDB povas funkcii nur kun egalaj intervaloj. Ĝis nun, mia cerbo sufiĉis por fiksi fiksan intervalon de 30 tagoj. Jes, la diagramo flosos iomete dum la jaro kaj la stangoj ne ĝuste respondas al la monatoj. Sed ĉar ĉi tiu afero estas interesa por mi nur kiel ekrana mezurilo, mi estas en ordo kun ĉi tio.

Mi vidas almenaŭ du solvojn:

• Por poenti sur monataj leteroj kaj limigi vin al semajnaj. 52 semajnaj trinkejoj en jaro aspektas sufiĉe bone
• Konsideru la monatan konsumon mem kiel metodon n-ro 2, kaj uzu la grafana nur por belaj grafikaĵoj. Ĝi estas sufiĉe preciza solvo. Vi povas eĉ supermeti leterojn por la pasinta jaro por komparo - grafana povas fari tion.

konkludo

Mi ne scias kial, sed mi amas ĉi tiajn leterojn. Ili montras, ke la vivo estas en plena svingo kaj ĉio ŝanĝiĝas. Hieraŭ estis multe, hodiaŭ estas malmulte, morgaŭ estos io alia. Restas labori kun hejmoj pri la temo de konsumo. Sed eĉ kun nunaj apetitoj, nur granda kaj nekomprenebla cifero en la fakturo jam fariĝas sufiĉe komprenebla bildo de konsumo.

Malgraŭ mia preskaŭ 20-jara kariero kiel programisto, mi praktike ne intersekciĝis kun datumbazoj. Tial instali eksteran datumbazon ŝajnis io tiel abstrusa kaj nekomprenebla. Ĉio ŝanĝiĝis la supra artikolo - montriĝis, ke ŝraŭbi taŭgan ilon estas farita per kelkaj klakoj, kaj per speciala ilo, la tasko de intrigo fariĝas iom pli facila.

En la titolo, mi menciis elektrokonsumon. Bedaŭrinde, nuntempe mi ne povas provizi ajnan grafikaĵon. Unu SDM120-mezurilo estas morta, kaj la alia estas buga kiam alirite per Modbus. Tamen ĉi tio neniel influas la temon de ĉi tiu artikolo - la grafikaĵoj estos konstruitaj same kiel por akvo.

En ĉi tiu artikolo, mi donis tiujn alirojn, kiujn mi mem provis. Verŝajne ekzistas iuj aliaj manieroj organizi la kolekton kaj bildigon de datumoj pri kiuj mi ne konas. Rakontu pri ĝi en la komentoj, mi tre interesiĝos. Mi ĝojos al konstrua kritiko kaj novaj ideoj. Mi esperas, ke la supra materialo ankaŭ helpos iun.

fonto: www.habr.com