ProHoster > Blog > administratë > Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant
Sa herë që marr një pagesë për energjinë elektrike dhe ujin, habitem - a konsumon vërtet familja ime kaq shumë? Epo, po, banjo ka një dysheme të nxehtë dhe një kazan, por ato nuk djegin zjarre gjatë gjithë kohës. Ne gjithashtu duket se po kursejmë ujin (edhe pse na pëlqen të spërkatemi në banjë). Disa vite më parë unë tashmë ujëmatës të lidhur и elektricitet në një shtëpi të zgjuar, por këtu ngecën gjërat. Ne vetëm tani kemi arritur të analizojmë konsumin, për të cilin në të vërtetë ka të bëjë me këtë artikull.

Kohët e fundit kam kaluar te Home Assistant si sistemi im inteligjent i shtëpisë. Një nga arsyet ishte pikërisht mundësia për të organizuar mbledhjen e një sasie të madhe të dhënash me aftësinë për të ndërtuar me lehtësi lloje të ndryshme grafikësh.

Informacioni i përshkruar në këtë artikull nuk është i ri; të gjitha këto gjëra nën salca të ndryshme janë përshkruar tashmë në internet. Por çdo artikull zakonisht përshkruan vetëm një qasje ose aspekt. Më duhej të krahasoja të gjitha këto qasje dhe të zgjidhja vetë më të përshtatshmen. Artikulli ende nuk ofron informacion të plotë mbi mbledhjen e të dhënave, por është një lloj përmbledhje se si e bëra atë. Pra, kritikat konstruktive dhe sugjerimet për përmirësim janë të mirëseardhura.

Formulimi i problemit

Pra, qëllimi i ushtrimit të sotëm është të marrim grafikët e bukur të konsumit të ujit dhe energjisë elektrike:

  • Për orë për 2 ditë
  • Çdo ditë për 2 javë
  • (opsionale) javore dhe mujore

Ka disa vështirësi me këtë:

  • Komponentët standardë të grafikut janë zakonisht mjaft të varfër. Në rastin më të mirë, mund të ndërtoni një grafik vijash pikë për pikë.

    Nëse shikoni mjaftueshëm, mund të gjeni komponentë të palëve të treta që zgjerojnë aftësitë e grafikut standard. Për një asistent në shtëpi, në parim, ky është një komponent i mirë dhe i bukur kartë mini-grafike, por është gjithashtu disi i kufizuar:

    • Është e vështirë të vendosësh parametrat e një grafiku me shirita në intervale të mëdha (gjerësia e shiritit vendoset në fraksione të një ore, që do të thotë se intervalet më të gjata se një orë do të vendosen në numra të pjesshëm)
    • Ju nuk mund të shtoni entitete të ndryshme në një grafik (për shembull, temperaturën dhe lagështinë, ose të kombinoni një grafik me shtylla me një vijë)
  • Jo vetëm që asistenti në shtëpi përdor si parazgjedhje bazën e të dhënave më primitive SQLite (dhe unë, një duarartë, nuk mund ta përballoja instalimin e MySQL ose Postgres), por të dhënat nuk ruhen në mënyrën më optimale. Kështu, për shembull, sa herë që ndryshoni edhe parametrin më të vogël dixhital të një parametri, një json i madh rreth një kilobajt në madhësi shkruhet në bazën e të dhënave. 
    {"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}}}

    Unë kam mjaft sensorë (sensorë të temperaturës në çdo dhomë, matës të ujit dhe energjisë elektrike), dhe disa gjithashtu gjenerojnë mjaft të dhëna. Për shembull, vetëm njehsori i energjisë elektrike SDM220 gjeneron rreth një duzinë vlerash çdo 10-15 sekonda, dhe unë do të doja të instaloja rreth 8 matës të tillë. Ekziston edhe një grup i tërë parametrash që llogariten në bazë të sensorëve të tjerë. Se. të gjitha këto vlera mund të fryjnë lehtësisht bazën e të dhënave me 100-200 MB në ditë. Brenda një jave sistemi mezi do të lëvizë, dhe brenda një muaji flash drive do të vdesë (në rastin e një instalimi tipik të asistentit në shtëpi në një Raspberry PI), dhe ruajtja e të dhënave për një vit të tërë nuk bëhet fjalë.

  • Nëse jeni me fat, njehsori juaj mund të llogarisë vetë konsumin. Mund t'i drejtoheni matësit në çdo kohë dhe të pyesni se sa është vlera e konsumit të akumuluar. Si rregull, të gjithë matësit e energjisë elektrike që kanë një ndërfaqe dixhitale (RS232/RS485/Modbus/Zigbee) e ofrojnë këtë mundësi.

    Është më keq nëse pajisja mund të matë thjesht disa parametra të menjëhershëm (për shembull, fuqinë ose rrymën e menjëhershme), ose thjesht të gjenerojë pulse çdo X vat-orë ose litra. Atëherë duhet të mendoni se si dhe me çfarë ta integroni atë dhe ku të grumbulloni vlerë. Ekziston rreziku për të humbur raportin e radhës për çfarëdo arsye dhe saktësia e sistemit në tërësi ngre pikëpyetje. Ju, sigurisht, mund t'i besoni të gjitha këto një sistemi të zgjuar shtëpie si asistenti në shtëpi, por askush nuk e ka anuluar pikën për numrin e regjistrimeve në bazën e të dhënave dhe nuk do të jetë e mundur të anketohen sensorët më shumë se një herë në sekondë (një kufizimi i arkitekturës së asistentit të shtëpisë).

Qasja 1

Së pari, le të shohim se çfarë ofron ndihmësi në shtëpi jashtë kutisë. Matja e konsumit gjatë një periudhe është një funksion shumë i kërkuar. Sigurisht, ai u zbatua shumë kohë më parë në formën e një komponenti të specializuar - utility_meter.

Thelbi i komponentit është se ai krijon nga brenda një variabël aktual_akumuluar_vlerë dhe e rivendos atë pas një periudhe të caktuar (orë/javë/muaj). Vetë komponenti monitoron variablin e hyrjes (vlera e disa sensorëve), pajtohet me ndryshimet në vlerë - thjesht merrni rezultatin e përfunduar. Kjo gjë përshkruhet në vetëm disa rreshta në skedarin e konfigurimit

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

Këtu sensor.water_meter_cold është vlera aktuale e njehsorit në litra që marr direkt nga copa e hekurit nga mqtt. Dizajni krijon 2 sensorë të rinj water_cold_hour_um dhe water_cold_day_um, të cilët grumbullojnë lexime për orë dhe ditore, duke i rivendosur ato në zero pasi të ketë skaduar periudha. Këtu është një grafik i baterisë për orë për gjysmë dite.

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Kodi për grafikët për orë dhe ditore për lovelace-UI duket si ky:

      - 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

Në fakt, problemi me këtë qasje qëndron në këtë algoritëm. Siç e përmenda tashmë, për secilën vlerë hyrëse (leximi aktual i njehsorit për çdo litër tjetër) 1 kb regjistrime gjenerohen në bazën e të dhënave. Çdo matës i shërbimeve gjeneron gjithashtu një vlerë të re, e cila gjithashtu i shtohet bazës. Nëse dua të mbledh lexime për orë / ditore / javore / mujore, dhe për disa ngritës të ujit, dhe të shtoj një paketë matësash elektrikë, do të jenë shumë të dhëna. Epo, më saktë, nuk ka shumë të dhëna, por meqenëse ndihmësi i shtëpisë shkruan një mori informacionesh të panevojshme në bazën e të dhënave, madhësia e bazës së të dhënave do të rritet me hapa të mëdhenj. Kam frikë të vlerësoj edhe madhësinë e bazës për grafikët javore dhe mujore.

Për më tepër, njehsori i shërbimeve në vetvete nuk e zgjidh problemin. Grafiku i vlerave të prodhuara nga njehsori i shërbimeve është një funksion në rritje monotonike që rivendoset në 0 çdo orë. Ne kemi nevojë për një grafik konsumi që është i kuptueshëm për përdoruesin, që tregon se sa litra janë konsumuar gjatë periudhës. Komponenti standard historik-graf nuk mund ta bëjë këtë, por komponenti i jashtëm i mini-kartës grafike mund të na ndihmojë.

Ky është kodi i kartës për 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'

Përveç cilësimeve standarde si emri i sensorit, lloji i grafikut, ngjyra (nuk më pëlqeu portokallia standarde), është e rëndësishme të vini re 3 cilësime:

  • group_by:hour — grafiku do të krijohet me shirita të rreshtuar në fillim të orës
  • pikë_për_orë: 1 - një shirit për çdo orë
  • Dhe më e rëndësishmja, aggregate_func: max - merrni vlerën maksimale brenda çdo ore. Është ky parametër që e kthen grafikun e dhëmbit të sharrës në shufra

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Mos i kushtoni vëmendje rreshtit të kolonave në të majtë - kjo është sjellja standarde e komponentit nëse nuk ka të dhëna. Por nuk kishte të dhëna - unë aktivizova mbledhjen e të dhënave të njehsorëve të shërbimeve vetëm disa orë më parë vetëm për hir të këtij artikulli (do të përshkruaj qasjen time aktuale më poshtë).

Në këtë foto doja të tregoja se ndonjëherë shfaqja e të dhënave madje funksionon dhe shiritat në të vërtetë pasqyrojnë vlerat e sakta. Por kjo nuk është e gjitha. Për disa arsye, kolona e zgjedhur për periudhën nga ora 11 deri në 12 të mëngjesit tregon 19 litra, megjithëse në grafikun e dhëmbëve pak më lart për të njëjtën periudhë nga i njëjti sensor shohim konsum prej 62 litrash. Ose ka një defekt ose duart janë të shtrembër. Por ende nuk e kuptoj pse u ndërprenë të dhënat në të djathtë - konsumi atje ishte normal, gjë që është e dukshme edhe nga grafiku i dhëmbëzuar.

Në përgjithësi, nuk isha në gjendje të arrija besueshmërinë e kësaj qasjeje - grafiku pothuajse gjithmonë tregon një lloj herezie.

Kodi i ngjashëm për sensorin e ditës. 

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

Ju lutemi vini re se parametri group_by është vendosur në interval dhe parametri point_per_hour rregullon gjithçka. Dhe këtu qëndron një problem tjetër me këtë komponent - points_per_hour funksionon mirë në grafikët e një ore ose më pak, por ai thith në intervale më të mëdha. Pra, për të marrë një kolonë në një ditë, më duhej të fusja vlerën 1/24=0.04166666. Nuk po flas as për grafikët javor dhe mujor.

Qasja 2

Ndërsa ende e kuptoja asistentin në shtëpi, hasa në këtë video:


Një mik mbledh të dhëna konsumi nga disa lloje prizash Xiaomi. Detyra e tij është pak më e thjeshtë - thjesht shfaq vlerën e konsumit për sot, dje dhe për muajin. Nuk kërkohen orare.

Le të lëmë mënjanë diskutimet në lidhje me integrimin manual të vlerave të menjëhershme të fuqisë - kam shkruar tashmë më lart për "saktësinë" e kësaj qasjeje. Nuk është e qartë pse ai nuk ka përdorur vlerat e akumuluara të konsumit, të cilat tashmë janë mbledhur nga e njëjta pikë. Sipas mendimit tim, integrimi brenda harduerit do të funksionojë më mirë.

Nga video do të marrim idenë e numërimit manual të konsumit për një periudhë. Djali numëron vetëm vlerat për sot dhe dje, por ne do të shkojmë më tej dhe do të përpiqemi të vizatojmë një grafik. Thelbi i metodës së propozuar në rastin tim është si më poshtë.

Le të krijojmë një variabël value_at_the_beginning_of_hour, në të cilën do të regjistrojmë leximet aktuale të njehsorit
Duke përdorur kohëmatësin, në fund të orës (ose në fillim të orës tjetër) ne llogarisim ndryshimin midis leximit aktual dhe atij të ruajtur në fillim të orës. Ky ndryshim do të jetë konsumi për orën aktuale - ne do ta ruajmë vlerën në sensor, dhe në të ardhmen do të ndërtojmë një grafik bazuar në këtë vlerë.
Ju gjithashtu duhet të "rivendosni" variablin value_at_beginning_of_hour duke shkruar atje vlerën aktuale të numëruesit.

E gjithë kjo mund të bëhet përmes vetë asistentit të shtëpisë.

Ju do të duhet të shkruani pak më shumë kod sesa në qasjen e mëparshme. Së pari, le të krijojmë të njëjtat "variabla". Nga kutia nuk kemi entitetin “variabël”, por mund të përdorim shërbimet e brokerit mqtt. Ne do të dërgojmë vlera atje me flamurin retain=true - kjo do të ruajë vlerën brenda ndërmjetësit dhe mund të tërhiqet nga atje në çdo kohë, edhe kur asistenti i shtëpisë është rindezur. Kam bërë sportelet për orë dhe ditore menjëherë.

- 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

E gjithë magjia ndodh në automatizimin, i cili funksionon përkatësisht çdo orë dhe çdo natë.

- 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

Të dy automatizmat kryejnë 2 veprime:

  • Llogaritni vlerën për një interval si diferencë midis vlerave të fillimit dhe të fundit
  • Përditësoni vlerën bazë për intervalin tjetër

Ndërtimi i grafikëve në këtë rast zgjidhet nga grafiku i zakonshëm i historisë:

      - 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

Duket kështu:

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Në parim, kjo është tashmë ajo që nevojitet. Avantazhi i kësaj metode është se të dhënat gjenerohen një herë në interval. ato. vetëm 24 regjistrime në ditë për një tabelë për orë.

Fatkeqësisht, kjo ende nuk e zgjidh problemin e përgjithshëm të një baze në rritje. Nëse dua një grafik konsumi mujor, do të më duhet të ruaj të dhënat për të paktën një vit. Dhe duke qenë se asistenti në shtëpi ofron vetëm një cilësim të kohëzgjatjes së ruajtjes për të gjithë bazën e të dhënave, kjo do të thotë se TË GJITHA të dhënat në sistem do të duhet të ruhen për një vit të tërë. Për shembull, në një vit unë konsumoj 200 metra kub ujë, që do të thotë se kjo do të thotë 200000 hyrje në bazën e të dhënave. Dhe nëse merrni parasysh sensorë të tjerë, atëherë shifra bëhet përgjithësisht e pahijshme.

Qasja 3

Për fat të mirë, njerëzit e zgjuar tashmë e kanë zgjidhur këtë problem duke shkruar bazën e të dhënave InfluxDB. Kjo bazë të dhënash është e optimizuar posaçërisht për ruajtjen e të dhënave të bazuara në kohë dhe është ideale për ruajtjen e vlerave të sensorëve të ndryshëm. Sistemi gjithashtu ofron një gjuhë pyetjesh të ngjashme me SQL që ju lejon të nxirrni vlera nga baza e të dhënave dhe më pas t'i grumbulloni ato në mënyra të ndryshme. Së fundi, të dhëna të ndryshme mund të ruhen për kohë të ndryshme. Për shembull, ndryshimi i shpeshtë i leximeve si temperatura ose lagështia mund të ruhen për vetëm disa javë, ndërsa leximet ditore të konsumit të ujit mund të ruhen për një vit të tërë.

Përveç InfluxDB, njerëzit e zgjuar shpikën edhe Grafana, një sistem për vizatimin e grafikëve bazuar në të dhënat nga InfluxDB. Grafana mund të vizatojë lloje të ndryshme grafikësh, t'i personalizojë ato në detaje dhe, më e rëndësishmja, këta grafikë mund të "futen" në asistentin e shtëpisë lovelace-UI.

Frymëzohuni këtu и këtu. Artikujt përshkruajnë në detaje procesin e instalimit dhe lidhjes së InfluxDB dhe Grafana me asistentin në shtëpi. Do të fokusohem në zgjidhjen e problemit tim specifik.

Pra, para së gjithash, le të fillojmë të shtojmë vlerën e numëruesit në influxDB. Një pjesë e konfigurimit të asistentit të shtëpisë (në këtë shembull do të argëtohem jo vetëm me ujë të ftohtë, por edhe me ujë të nxehtë):

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

Le të çaktivizojmë ruajtjen e të njëjtave të dhëna në bazën e të dhënave të brendshme të ndihmësit në shtëpi, në mënyrë që të mos e fryjmë përsëri:

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

Le të shkojmë tani në tastierën InfluxDB dhe të konfigurojmë bazën tonë të të dhënave. Në veçanti, duhet të konfiguroni se sa kohë do të ruhen të dhëna të caktuara. Kjo rregullohet nga të ashtuquajturat. Politika e mbajtjes - kjo është e ngjashme me bazat e të dhënave brenda një bazë të dhënash kryesore, me çdo bazë të dhënash të brendshme që ka cilësimet e veta. Si parazgjedhje, të gjitha të dhënat ruhen në një politikë ruajtjeje të quajtur autogen; këto të dhëna do të ruhen për një javë. Do të doja që të dhënat për orë të ruhen për një muaj, të dhënat javore të mbahen për një vit dhe të dhënat mujore të mos fshihen kurrë. Le të krijojmë politikën e duhur të mbajtjes

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

Tani, në fakt, truku kryesor është grumbullimi i të dhënave duke përdorur pyetje të vazhdueshme. Ky është një mekanizëm që drejton automatikisht një pyetje në intervale të caktuara, grumbullon të dhënat për këtë pyetje dhe shton rezultatin në një vlerë të re. Le të shohim një shembull (Unë shkruaj në një kolonë për lexueshmëri, por në realitet më duhej ta fusja këtë komandë në një rresht)

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

Kjo komandë:

  • Krijon një pyetje të vazhdueshme të quajtur cq_water_cold_hourly në bazën e të dhënave homeassistant
  • Kërkesa do të ekzekutohet çdo orë (koha (1 orë))
  • Kërkesa do të fshijë të gjitha të dhënat nga matja homeassistant.autogen.l (litra), duke përfshirë leximet e ujit të ftohtë dhe të nxehtë
  • Të dhënat e grumbulluara do të grupohen sipas entity_id, i cili do të na japë vlera të veçanta për ujin e ftohtë dhe të nxehtë
  • Meqenëse numëruesi i litrave është një sekuencë në rritje monotonike brenda çdo ore, do të jetë e nevojshme të merret vlera maksimale, kështu që grumbullimi do të kryhet nga funksioni max(vlera)
  • Vlera e re do të shkruhet në homeassistant.month.water_meter_hour, ku muaji është emri i politikës së ruajtjes me një periudhë ruajtjeje prej një muaji. Për më tepër, të dhënat për ujin e ftohtë dhe të nxehtë do të shpërndahen në regjistrime të veçanta me entity_id dhe vlerën përkatëse në fushën e vlerës

Natën ose kur askush nuk është në shtëpi, nuk ka konsum të ujit dhe për këtë arsye nuk ka hyrje të reja në homeassistant.autogen.l. Për të shmangur mungesën e vlerave në pyetjet e rregullta, mund të përdorni fill(previous). Kjo do të detyrojë InfluxDB të përdorë vlerën e orës së fundit.

Fatkeqësisht, pyetja e vazhdueshme ka një veçori: truku i mbushjes (e mëparshme) nuk funksionon dhe regjistrimet thjesht nuk krijohen. Për më tepër, ky është një lloj problemi i pakapërcyeshëm që diskutohet prej disa vitesh. Ne do të merremi me këtë problem më vonë, por le të jetë fill(previous) në pyetjen e vazhdueshme - nuk ndërhyn.

Le të kontrollojmë se çfarë ndodhi (natyrisht, duhet të prisni disa orë):

> 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

Vini re se vlerat në bazën e të dhënave ruhen në UTC, kështu që kjo listë ndryshon me 3 orë - vlerat e 7 të mëngjesit në daljen InfluxDB korrespondojnë me vlerat e 10 të mëngjesit në grafikët e mësipërm. Vini re gjithashtu se midis orës 2 dhe 5 të mëngjesit thjesht nuk ka regjistrime - kjo është e njëjta veçori e pyetjes së vazhdueshme.

Siç mund ta shihni, vlera e grumbulluar është gjithashtu një sekuencë në rritje monotonike, vetëm hyrjet ndodhin më rrallë - një herë në orë. Por ky nuk është problem - ne mund të shkruajmë një pyetje tjetër që do të marrë të dhënat e sakta për grafikun.

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)

Unë do të deshifroj:

  • Nga baza e të dhënave homeassistant.month.water_meter_hour ne do të nxjerrim të dhëna për entity_id='water_meter_cold' për ditën e fundit (koha >= tani() -24 orë).
  • Siç e përmenda tashmë, disa hyrje mund të mungojnë në sekuencën homeassistant.month.water_meter_hour. Ne do t'i rigjenerojmë këto të dhëna duke ekzekutuar një pyetje me GROUP BY time(1h). Kjo kohë mbushje (e mëparshme) do të funksionojë siç pritej, duke gjeneruar të dhënat që mungojnë (funksioni do të marrë vlerën e mëparshme)
  • Gjëja më e rëndësishme në këtë kërkesë është funksioni i diferencës, i cili do të llogarisë diferencën midis shenjave të orës. Nuk funksionon më vete dhe kërkon një funksion grumbullimi. Le të jetë kjo max() e përdorur më parë.

Rezultati i ekzekutimit duket si ky

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

Nga ora 2 deri në 5 të mëngjesit (UTC) nuk kishte konsum. Sidoqoftë, pyetja do të kthejë të njëjtën vlerë konsumi falë mbushjes (e mëparshme), dhe funksioni i diferencës do ta zbresë këtë vlerë nga vetja dhe dalja do të jetë 0, që është pikërisht ajo që kërkohet.

Gjithçka që mbetet është të ndërtohet një grafik. Për ta bërë këtë, hapni Grafana, hapni një panel ekzistues (ose krijoni një panel të ri) dhe krijoni një panel të ri. Cilësimet e grafikut do të jenë të tilla.

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Do të shfaq të dhënat e ujit të ftohtë dhe të nxehtë në të njëjtin grafik. Kërkesa është saktësisht e njëjtë me atë që përshkrova më lart.

Parametrat e ekranit vendosen si më poshtë. Për mua do të jetë një grafik me vija, që shkon me hapa (shkallë). Më poshtë do të shpjegoj parametrin Stack. Ka disa opsione të tjera të ekranit më poshtë, por ato nuk janë aq interesante.

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Për të shtuar grafikun që rezulton te asistenti i shtëpisë, duhet të:

  • dilni nga modaliteti i redaktimit të grafikut. Për disa arsye, cilësimet e sakta të ndarjes së grafikut ofrohen vetëm nga faqja e panelit të kontrollit
  • Klikoni në trekëndëshin pranë emrit të grafikut dhe zgjidhni share nga menyja
  • Në dritaren që hapet, shkoni te skeda e ngulitjes
  • Hiq zgjedhjen e intervalit aktual kohor - ne do ta vendosim intervalin kohor nëpërmjet URL-së
  • Zgjidhni temën e kërkuar. Në rastin tim është dritë
  • Kopjo URL-në që rezulton në kartën e cilësimeve të 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"

Ju lutemi vini re se diapazoni i kohës (2 ditët e fundit) është vendosur këtu dhe jo në cilësimet e panelit të kontrollit.

Grafiku duket si ky. Nuk kam përdorur ujë të nxehtë në 2 ditët e fundit, kështu që vizatohet vetëm grafiku i ujit të ftohtë.

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Ende nuk e kam vendosur vetë se cili grafik më pëlqen më shumë, një hap i linjës apo shirita të vërtetë. Prandaj, thjesht do të jap një shembull të grafikut të konsumit ditor, vetëm këtë herë në shirita. Pyetjet janë ndërtuar në mënyrë të ngjashme me ato të përshkruara më sipër. Opsionet e shfaqjes janë:

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Ky grafik duket si ky:

Shtëpi inteligjente: Ne ndërtojmë grafikët e konsumit të ujit dhe energjisë elektrike në Home Assistant

Pra, në lidhje me parametrin Stack. Në këtë grafik, një kolonë me ujë të ftohtë vizatohet mbi një kolonë me ujë të nxehtë. Lartësia totale korrespondon me konsumin total të ujit të ftohtë dhe të nxehtë për periudhën.

Të gjithë grafikët e paraqitur janë dinamikë. Mund ta vendosni miun mbi pikën e interesit dhe të shihni detajet dhe vlerën në një pikë të caktuar.

Fatkeqësisht, kishte disa miza në vaj. Në një grafik me shtylla (ndryshe nga një grafik me vija hapash), mesi i shiritit nuk është në mes të ditës, por në orën 00:00. ato. gjysma e majtë e kolonës vizatohet në vend të ditës së mëparshme. Pra, grafikët për të shtunën dhe të dielën vizatohen pak në të majtë të zonës kaltërosh. Derisa kuptova se si ta mposhtja.

Një problem tjetër është pamundësia për të punuar siç duhet në intervale mujore. Fakti është se gjatësia e orës/ditës/javës është fikse, por gjatësia e muajit është e ndryshme çdo herë. InfluxDB mund të funksionojë vetëm në intervale të barabarta. Deri tani truri im ka mjaftuar për të vendosur një interval fiks prej 30 ditësh. Po, grafiku do të notojë pak gjatë gjithë vitit dhe shufrat nuk do të korrespondojnë saktësisht me muajt. Por duke qenë se unë jam i interesuar për këtë gjë thjesht si një matës ekrani, jam në rregull me të.

Unë shoh të paktën dy zgjidhje:

  • Hiqni dorë nga tabelat mujore dhe kufizohuni në ato javore. 52 bare javore për vitin duken mjaft mirë
  • Konsideroni vetë konsumin mujor si metodën nr. 2 dhe përdorni grafana vetëm për grafikë të bukur. Do të jetë një zgjidhje mjaft e saktë. Ju madje mund të mbivendosni grafikët për vitin e kaluar për krahasim - edhe grafana mund ta bëjë këtë.

Përfundim

Nuk e di pse, por jam i fiksuar pas këtyre lloj grafikësh. Ata tregojnë se jeta është në ecje të plotë dhe gjithçka po ndryshon. Dje ka pasur shumë, sot ka pak, nesër do të jetë diçka tjetër. Mbetet vetëm të punohet me anëtarët e familjes në temën e konsumit. Por edhe me orekset aktuale, vetëm një shifër e madhe dhe e pakuptueshme në fletëpagesë po kthehet tashmë në një tablo mjaft të kuptueshme të konsumit.

Pavarësisht karrierës sime pothuajse 20-vjeçare si programues, praktikisht nuk kisha asnjë kontakt me bazat e të dhënave. Prandaj, instalimi i një baze të dhënash të jashtme dukej si diçka kaq abstruse dhe e pakuptueshme. Ndryshoi gjithçka artikulli i mësipërm — doli që bashkëngjitja e një mjeti të përshtatshëm bëhet me disa klikime dhe me një mjet të specializuar, detyra e hartimit të grafikëve bëhet pak më e lehtë.

Në titull përmenda konsumin e energjisë elektrike. Fatkeqësisht, për momentin nuk mund të jap asnjë grafik. Një metër SDM120 vdiq për mua, dhe tjetri është i shkëlqyeshëm kur aksesohet përmes Modbus. Sidoqoftë, kjo nuk ndikon në asnjë mënyrë në temën e këtij artikulli - grafikët do të ndërtohen në të njëjtën mënyrë si për ujin.

Në këtë artikull kam paraqitur qasjet që kam provuar vetë. Sigurisht që ka disa mënyra të tjera për të organizuar mbledhjen dhe vizualizimin e të dhënave për të cilat unë nuk i di. Më tregoni për këtë në komente, do të jem shumë i interesuar. Do të jem i lumtur për kritikat konstruktive dhe idetë e reja. Shpresoj se materiali i paraqitur gjithashtu do të ndihmojë dikë.

Burimi: www.habr.com

Shto një koment