Ădo herĂ« qĂ« merr faturĂ«n pĂ«r elektricitetin dhe ujĂ«, çuditem - vallĂ«, familja ime konsumon kaq shumĂ«? Po, nĂ« banjĂ« kemi ngrohje tĂ« dyshemesĂ« dhe njĂ« bojler, por ato nuk punojnĂ« nonstop. Edhe pĂ«r ujĂ« duket se e kursejmĂ« (pavarĂ«sisht se na pĂ«lqen tĂ« bĂ«jmĂ« njĂ« banjĂ«). Para disa vitesh, kam dhe nĂ« shtĂ«pinĂ« time inteligjente, por puna ndaloi atje. Analiza e konsumit arriti vetĂ«m tani, pĂ«r tĂ« cilĂ«n, nĂ« fakt, Ă«shtĂ« kjo artikull.
Së fundmi kam kaluar në Home Assistant si sistemin tim të shtëpisë inteligjente. Një nga arsyet ishte pikërisht mundësia për të organizuar mbledhjen e një sasie të madhe të të dhënave me mundësinë e ndërtimit të grafikeve të ndryshme.
Informacioni i përshkruar në këtë artikull nuk është i ri, të gjitha këto gjëra në forma të ndryshme janë përshkruar tashmë në internet. Por çdo artikull, në përgjithësi, përshkruan vetëm një qasje ose aspekt. Krahasimi i të gjitha këtyre qasjeve dhe zgjedhja e më të përshtatshmes është detyra ime. Artikulli gjithsesi nuk ofron informacion të plotë mbi mbledhjen e të dhënave, por është një lloj përmbledhjeje të asaj që kam bërë. Pra, kritika konstruktive dhe propozime për përmirësim janë të mirëpritura.
Vendosja e detyrës
Prandaj, qëllimi i ushtrimit të sotëm është të merret grafika e bukur e konsumit të ujit dhe energjisë elektrike:
- Për çdo orë gjatë 2 ditëve
- Për çdo ditë gjatë 2 javëve
- (opsionale) për çdo javë dhe për çdo muaj
Në këtë na presin disa vështirësi:
- Komponentët standardë të grafikëve, në përgjithësi, janë mjaft të varfër. Në rastin më të mirë, mund të ndërtohet një grafik linear mbi pika.
Nëse kërkoni mirë, mund të gjeni komponentë të jashtëm që zgjasin mundësitë e grafikëve standardë. Për home assistant, në thelb, është një komponent i mirë dhe i bukur , por edhe ai është disi i kufizuar:
- ĂshtĂ« e vĂ«shtirĂ« tĂ« vendosĂ«sh parametrat e grafikĂ«ve me kolona nĂ« intervale tĂ« mĂ«dha (gjerĂ«sia e kolonave vendoset nĂ« pjesĂ« orĂ«sh, qĂ« do tĂ« thotĂ« se intervalet mĂ« tĂ« gjata se njĂ« orĂ« do tĂ« vendosen si numra decimalĂ«)
- Nuk mund të shtosh entitete të ndryshme në një grafik (p.sh. temperaturën dhe lagështinë, ose të kombinosh grafikun me kolona me një vijë)
- Jo vetëm që Home Assistant për default përdor bazën e të dhënave më primitive SQLite (dhe unë, i pafuqishëm, nuk arrita të instaloja MySQL ose Postgres), por edhe të dhënat ruhen në një mënyrë që nuk është optimale. Për shembull, me çdo ndryshim të çdo parametri edhe më të vogël në numra, në bazë shkruhet një JSON i madh me një madhësi prej rreth kilobajtësh.
{"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}}}Kam kam shumë sensorë (sensorë temperaturës në çdo dhomë, matës uji dhe elektriciteti), dhe disa madje gjenerojnë shumë të dhëna. Për shembull, vetëm matësi i elektricitetit SDM220 gjeneron rreth një duzinë vlerash çdo 10-15 sekonda, dhe unë do të doja të instaloj rreth 8 prej këtyre matësve. Gjithashtu ka një grup të madh parametrash që llogariten në bazë të sensorëve të tjerë. Të gjitha këto vlera lehtësisht mund ta fryjnë bazën e të dhënave me 100-200 MB çdo ditë. Pas një jave, sistemi do të ketë vështirësi të funksionojë, dhe pas një muaji, plaka USB do të dështojë (në rastin e instalimit tipik të home assistant në raspberry PI), dhe nuk bëhet fjalë për ruajtjen e të dhënave për një vit të tërë.
- Nëse keni fat, matësi juaj mund të llogarisë vetë konsumimin. Në çdo moment mund të drejtoheni te matësi dhe të pyesni se cila është vlera akumuluese e konsumit. Në përgjithësi, të gjithë matësit e energjisë elektrike që kanë një ndërfaqe digjitale (RS232/RS485/Modbus/Zigbee) ofrojnë një mundësi të tillë.
ĂshtĂ« mĂ« keq nĂ«se pajisja mund thjesht tĂ« masĂ« njĂ« parametĂ«r tĂ« menjĂ«hershĂ«m (p.sh., fuqinĂ« ose rrymĂ«n e menjĂ«hershme), ose thjesht tĂ« gjenerojĂ« impulset çdo X vat-orĂ« ose litra. AtĂ«herĂ« duhet tĂ« mendojmĂ« se si dhe me çfarĂ« ta integrojmĂ« dhe ku ta ruajmĂ« vlerĂ«n. Ka rrezik tĂ« humbasim raportin e radhĂ«s pĂ«r ndonjĂ« arsye, madje dhe saktesia e sistemit nĂ« tĂ«rĂ«si ngre pyetje. Sigurisht, mund ta ngarkojmĂ« tĂ«rĂ« kĂ«tĂ« sistemit tĂ« shtĂ«pisĂ« inteligjente si home assistant, por pika mbi numrin e regjistrimeve nĂ« bazĂ« nuk Ă«shtĂ« anuluar, dhe as nuk do tĂ« arrijmĂ« tĂ« anketojmĂ« sensorĂ«t mĂ« shpesh se njĂ« herĂ« nĂ« sekondĂ« (kufizimi i arkitekturĂ«s sĂ« home assistant).
Qasja 1
SĂ« pari, le tĂ« shohim se çfarĂ« ofron home assistant direkt. Matja e konsumit pĂ«r njĂ« periudhĂ« â Ă«shtĂ« njĂ« funksionalitet shumĂ« i kĂ«rkuar. Sigurisht, kjo Ă«shtĂ« realizuar prej kohĂ«sh nĂ« formĂ«n e njĂ« komponente tĂ« specializuar â utility_meter.
The essence of the component is that it internally initializes a variable called current_accumulated_value, and resets it after a specified period (hour/week/month). The component independently monitors the input variable (value from some sensor), subscribes to changes in the value itself â you simply receive the final result. This is described in just a few lines in the configuration file.
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Here, sensor.water_meter_cold is the current value of the meter in liters, which I receive. via mqtt. The structure creates two new sensors water_cold_hour_um and water_cold_day_um, which accumulate hourly and daily readings, resetting them at the end of the period. Hereâs the hourly accumulator graph for half a day.
The code for the hourly and daily graphs for the lovelace-UI looks like this:
- 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Ă« kĂ«tĂ« algoritĂ«m qĂ«ndron problemi i kĂ«tij qasje. Siç e pĂ«rmenda, pĂ«r çdo vlerĂ« hyrĂ«se (leximi aktual i matĂ«sit pĂ«r çdo litĂ«r tĂ« ardhshĂ«m) gjenerohet 1 kB regjistrimi nĂ« bazĂ«. Ădo matĂ«s gjithashtu gjeneron njĂ« vlerĂ« tĂ« re qĂ« gjithashtu regjistrohet nĂ« bazĂ«. NĂ«se dua tĂ« mbledh lexime orĂ«she / ditorĂ« / javore / mujore, po pĂ«r disa matĂ«s pĂ«r ujin, dhe gjithashtu tĂ« shtoj njĂ« paketĂ« matĂ«sish tĂ« energjisĂ« elektrike - do tĂ« jetĂ« shumĂ« tĂ« dhĂ«na. NĂ« tĂ« vĂ«rtetĂ«, tĂ« dhĂ«nat nuk janĂ« shumĂ«, por pasi home assistant shkruan nĂ« bazĂ« shumĂ« informacion tĂ« panevojshĂ«m, madhĂ«sia e bazĂ«s do tĂ« rritet si maja e drogĂ«s. Frikohem tĂ« bĂ«j llogaritjet pĂ«r madhĂ«sinĂ« e bazĂ«s pĂ«r grafikĂ«t javore dhe mujore.
Përveç kësaj, utility meter vetë nuk zgjidh problemin e caktuar. Grafiku i vlerave që jep utility meter është një funksion monotonik në rritje, i cili reset gabimin në 0 çdo orë. Na nevojitet një grafik i qartë për përdoruesin se sa litra janë konsumuar gjatë një periudhe. Komponenti standard history-graph nuk e bën këtë, por një komponent i jashtëm mini-graph-card 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: "Konsumimi orar i ujit i agreguar nga matësi i utilitetit"
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 (portokalli standard nuk më pëlqeu), është e rëndësishme të theksohen 3 cilësime:
- group_by:hour â grafiku do tĂ« gjenerohet me rreshtimin e kolonave nĂ« fillim tĂ« orĂ«s
- points_per_hour: 1 â njĂ« kolone pĂ«r çdo orĂ«
- Dhe mĂ« e rĂ«ndĂ«sishmja, aggregate_func: max â tĂ« merret vlera maksimale brenda çdo ore. Ky parametĂ«r e kthen grafikun zigzag nĂ« kolona.
Mos u shqetĂ«soni pĂ«r disa kolona nĂ« tĂ« majtĂ« â kjo Ă«shtĂ« sjellja standarde e komponentit nĂ«se nuk ka tĂ« dhĂ«na. Dhe nuk kishte tĂ« dhĂ«na â aktivizova mbledhjen e tĂ« dhĂ«nave pĂ«r matĂ«sin e utilitetit vetĂ«m pĂ«r kĂ«tĂ« artikull (qasja ime aktuale do ta diskutoj pak mĂ« poshtĂ«).
NĂ« kĂ«tĂ« imazh doja tĂ« tregoja se ndonjĂ«herĂ« shfaqja e tĂ« dhĂ«nave funksionon, dhe kolonat vĂ«rtet reflektojnĂ« vlera tĂ« sakta. Por jo tĂ« gjitha. Kolona e veçantĂ« pĂ«r intervalin nga 11 deri nĂ« 12 tĂ« mĂ«ngjesit pĂ«r çfarĂ«do arsye tregon 19 litra, ndĂ«rsa nĂ« grafikun me dhĂ«mbĂ« pak mĂ« lart pĂ«r kĂ«tĂ« periudhĂ« nga i njĂ«jti sensor shohim konsumimin prej 62 litrave. Ose Ă«shtĂ« njĂ« gabim, ose ka diçka tĂ« keqe me konfigurimin. Sa i pĂ«rket pse tĂ« dhĂ«nat nĂ« anĂ«n e djathtĂ« mungojnĂ«, nuk e kam kuptuar ende â konsumimi atje ishte normal, gjĂ« qĂ« Ă«shtĂ« e dukshme edhe nga grafiku me dhĂ«mbĂ«.
NĂ« pĂ«rgjithĂ«si, nuk arrita tĂ« arrij besueshmĂ«rinĂ« e kĂ«tij qasje â grafiku pothuajse gjithmonĂ« tregon ndonjĂ« gjĂ« tĂ« çuditshme.
Kodi i ngjashëm për sensorin ditor.
- aggregate_func: max
entities:
- color: var(--primary-color)
entity: sensor.water_cold_day_um
group_by: interval
hours_to_show: 360
name: "Konsumi ditor i ujit i agreguar nga një matës utilitar"
points_per_hour: 0.0416666666
show:
graph: bar
type: 'custom:mini-graph-card'
VĂ«reni se qĂ« parameteri group_by Ă«shtĂ« vendosur nĂ« vlerĂ«n interval, dhe rregullon tĂ« gjithĂ« parametrin points_per_hour. Kjo Ă«shtĂ« njĂ« tjetĂ«r problem i kĂ«tij komponenti â points_per_hour funksionon mirĂ« nĂ« grafikĂ«t pĂ«r njĂ« orĂ« ose mĂ« pak, por keq pĂ«r periudha mĂ« tĂ« gjata. PĂ«r tĂ« marrĂ« njĂ« kolonĂ« pĂ«r njĂ« ditĂ«, duhej tĂ« shkruaja vlerĂ«n 1/24=0.04166666. Nuk po flas pĂ«r grafikĂ«t javore dhe mujore.
Qasja 2
Duke u njohur me home assistant, kam hasur këtë video:
Shoku mbledh tĂ« dhĂ«nat e konsumit nga disa lloje prizash Xiaomi. Detyra e tij Ă«shtĂ« pak mĂ« e thjeshtĂ« â thjesht tĂ« tregojĂ« vlerĂ«n e konsumit pĂ«r sot, dje dhe pĂ«r muajin. Nuk kĂ«rkohen grafikĂ«.
Do ta lĂ«mĂ« mĂ«njanĂ« diskutimin mbi integimin manual tĂ« vlerave momentale tĂ« fuqisĂ« â mbi 'saktĂ«sinĂ«' e kĂ«tij qasjeje kam shkruar mĂ« sipĂ«r. Nuk Ă«shtĂ« e qartĂ« pse ai nuk pĂ«rdori vlerat akumuluese tĂ« konsumit, tĂ« cilat tashmĂ« mblidhen nga e njĂ«jta prizĂ«. NĂ« opinonin tim, integimi brenda pajisjes do tĂ« punojĂ« mĂ« mirĂ«.
Nga video do të marrim idenë e numërimit manual të konsumit për një periudhë. Fakti që llogariten vetëm vlerat për sot dhe dje është një fillim, 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 përfshin këtë.
Do të krijojmë një variabël vlera_në_fillim_të_orës, në të cilin do të regjistrojmë leximet aktuale të matësit.
NĂ« fund tĂ« orĂ«s (ose nĂ« fillim tĂ« ardhshme), do tĂ« llogarisim diferencĂ«n midis leximit aktual dhe atij tĂ« regjistruar nĂ« fillim tĂ« orĂ«s. Kjo diferencĂ« do tĂ« jetĂ« konsumimi pĂ«r orĂ«n aktuale â do ta ruajmĂ« kĂ«tĂ« vlerĂ« nĂ« sensor dhe nĂ« tĂ« ardhmen do tĂ« ndĂ«rtojmĂ« grafikun pĂ«r kĂ«tĂ« vlerĂ«.
Gjithashtu, nevojitet që të "zerojmë" variablin vlera_në_fillim_të_orës duke regjistruar aty vlerën aktuale të matësit.
E gjithë kjo mund të bëhet përmes mjeteve të vetë home assistant.
Do t'nahet mĂ« shumĂ« kod se nĂ« qasjen e mĂ«parshme. Fillimisht do tĂ« krijojmĂ« kĂ«to âvariablaâ. Nga kutia nuk kemi njĂ« entitet âvariabĂ«lâ, por mund tĂ« shfrytĂ«zojmĂ« shĂ«rbimet e brokerit mqtt. Do tĂ« dĂ«rgojmĂ« atje vlera me flagun retain=true â kjo do ta ruajĂ« vlerĂ«n brenda brokerit, dhe mund ta nxjerrim nĂ« çdo moment, edhe pas rinisjes sĂ« home assistant. Kam bĂ«rĂ« menjĂ«herĂ« numĂ«ruesit orarĂ« dhe ditorĂ«.
- 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: lE gjithë magia ndodh në automatizimin, i cili aktivizohet çdo orë dhe çdo natë përkatësisht.
- 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: trueTë dy automatikat kryejnë 2 veprime:
- Llogarisin vlerën për intervalin si diferencë midis vlerës fillestare dhe asaj përfundimtare
- Përditësojnë vlerën bazë për intervalin tjetër
Ndërtimi i grafikëve në këtë rast zgjidhet me një history-graph të zakonshëm:
- 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_dayDuket kështu:
Në princip, kjo është ajo që nevojitet. Avantazhi i këtij metode është se të dhënat gjenerohen një herë për intervalin. Pra, gjithsej 24 regjistrime për ditë për grafikun orar.
Fatkeqësisht, kjo nuk zgjidh problemin e përgjithshëm të rritjes së bazës. Nëse dua një grafik të konsumit mujor, do të duhet të ruaj të dhënat për të paktën një vit. Dhe pasi që home assistant ofron vetëm një cilësim të kohëzgjatjes së ruajtjes për të gjithë bazën, kjo do të thotë që të DHENAT e GJITHA në sistem do të duhet të ruhen për një vit. Për shembull, për një vit konsumoj 200 metra kub ujë, kjo do të thotë 200000 regjistrime në bazë. E nëse marrim parasysh edhe sensorët e tjerë, numri bëhet vërtet i papëlqyeshëm.
Qasja 3
Fatmirësisht, njerëzit e mençur kanë zgjidhur këtë problem duke shkruar bazën e të dhënave InfluxDB. Kjo bazë është 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ë kërkimesh të ngjashme me SQL, e cila lejon nxjerrjen e vlerave nga baza dhe më pas agregimin e tyre në mënyra të ndryshme. Së fundi, të dhënat e ndryshme mund të ruhen për kohë të ndryshme. Për shembull, leximet që ndihen shpesh si temperatura apo lagështira 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ërë.
PĂ«rveç InfluxDB, njerĂ«z tĂ« mençur gjithashtu shpikĂ«n Grafana â njĂ« sistem pĂ«r vizatimin e grafikĂ«ve nga tĂ« dhĂ«nat e 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Ă« âintegrohenâ nĂ« lovelace-UI tĂ« asistentit tĂ« shtĂ«pisĂ«.
Të frymëzohesh dhe . Artikujt përshkruajnë në detaje procesin e instalimit dhe lidhjes së InfluxDB dhe Grafana me asistentin e shtëpisë. Unë do të përqendrohem në zgjidhjen e detyrës sime specifike.
Pra, gjëja e parë është të fillojmë me ruajtjen e vlerës së 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ë ngrohtë):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldDo të çaktivizojmë ruajtjen e këtyre të dhënave në bazën e të dhënave të brendshme të asistentit të shtëpisë, për të mos e fryrë atë pa nevojë:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldTani tani kalojmĂ« nĂ« konsolĂ«n InfluxDB dhe konfigurojmĂ« bazĂ«n tonĂ«. NĂ« veçanti, duhet tĂ« pĂ«rcaktojmĂ« sa kohĂ« do tĂ« ruhen tĂ« dhĂ«nat e ndryshme. Kjo rregullohet nga politika e ruajtjes e njohur si retention policy â kjo Ă«shtĂ« si bazat e tĂ« dhĂ«nave brenda njĂ« baze tĂ« dhĂ«nash kryesore, ku çdo bazĂ« e brendshme ka parametrat e saj tĂ« konfiguruar. NĂ« mĂ«nyrĂ« tĂ« paracaktuar, tĂ« gjitha tĂ« dhĂ«nat vendosen nĂ« retention policy me emrin autogen, kĂ«to tĂ« dhĂ«na do tĂ« ruhen pĂ«r njĂ« javĂ«. Do tĂ« doja qĂ« tĂ« dhĂ«nat pĂ«r orĂ«t tĂ« ruhen pĂ«r njĂ« muaj, ato javore pĂ«r njĂ« vit dhe ato mujore tĂ« mos fshihen kurrĂ«. TĂ« krijojmĂ« politikat pĂ«rkatĂ«se tĂ« ruajtjes.
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 1Tani, truku kryesor â agregimi i tĂ« dhĂ«nave pĂ«rmes kĂ«rkesĂ«s continue. Ky Ă«shtĂ« njĂ« mekanizĂ«m qĂ« aktivizon automatikisht njĂ« kĂ«rkesĂ« nĂ« intervale tĂ« caktuara, agregon tĂ« dhĂ«nat sipas kĂ«saj kĂ«rkese, dhe rezultati ruhet si njĂ« vlerĂ« e re. Le tĂ« shohim me njĂ« shembull (po e shkruaj nĂ« kolonĂ« pĂ«r lehtĂ«si leximi, por nĂ« tĂ« vĂ«rtetĂ« do tĂ« duhet ta futja kĂ«tĂ« komandĂ« nĂ« njĂ« rresht)
KRIJO KĂRKESĂN E CONTINUAR cq_water_hourly NĂ homeassistant
BEGIN
ZGJIDH max(value) SI vlera
NĂ homeassistant.month.water_meter_hour
NGA homeassistant.autogen.l
GRUPO Nà kohë(1h), entity_id mbush(para)
ENDKjo komandë:
- Krijon një kërkesë të vazhdueshme me emrin cq_water_cold_hourly në databazën homeassistant
- Kërkesa do të ekzekutohet çdo orë (kohë(1h))
- Kërkesa do të nxjerrë 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 agreguara do të grupohen sipas entity_id, që do të krijojë vlera të veçanta për ujin e ftohtë dhe të nxehtë
- Duke qenë se matësi i litrit është një sekuencë që rritet monotone brenda çdo ore, do të merret vlera maksimale, prandaj agregimi do të kryhet nga funksioni max(value)
- Vlera e re do të shkruhet në homeassistant.month.water_meter_hour, ku month është emri i politikës së mbajtjes me një afat ruajtjeje prej një muaji. Të dhënat për ujin e ftohtë dhe të nxehtë do të shpërndahen në regjistrime të veçanta me entity_id përkatës dhe vlera në fushën value
Në natë ose kur nuk ka askënd në shtëpi, konsumi i ujit nuk është, dhe për pasojë nuk ka regjistrime të reja në homeassistant.autogen.l. Për të shmangur boshllëqe në vlerat e kërkesave të zakonshme mund të përdorni fill(previous). Kjo do ta detyrojë InfluxDB të përdorë vlerën e orës së kaluar.
FatkeqĂ«sisht, ka njĂ« veçori pĂ«r pyetjen e vazhdueshme: truku fill(previous) nuk funksionon dhe regjistrimet thjesht nuk krijohen. Kjo Ă«shtĂ« njĂ« problem qĂ« duket se Ă«shtĂ« i pakalueshĂ«m, Me kĂ«tĂ« problem do tĂ« merremi mĂ« vonĂ«, ndĂ«rsa fill(previous) nĂ« pyetjen e vazhdueshme le tĂ« qendrojĂ« â nuk dĂ«mton.
Le të shohim se çfarë kemi arritur (sigurisht, duhet të presim 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
Ju kujdes, se vlerat nĂ« bazĂ« ruajten nĂ« UTC, prandaj nĂ« kĂ«tĂ« listĂ« ndryshojnĂ« me 3 orĂ« â vlerat pĂ«r nĂ«ntĂ« mĂ«ngjesi nĂ« daljen InfluxDB pĂ«rputhen me vlerat pĂ«r dymbĂ«dhjetĂ« nĂ« grafikĂ«t mĂ« sipĂ«r. Gjithashtu, ju lutemi vini re se nga ora dy deri nĂ« pesĂ« mĂ«ngjesi thjesht nuk ka shenja â kjo Ă«shtĂ« veçoria e kĂ«rkesĂ«s continue.
Siç e shihni, vlera e grumbulluar gjithashtu Ă«shtĂ« njĂ« sekuencĂ« monotone nĂ« rritje, vetĂ«m se shĂ«nimet ndryshojnĂ« mĂ« rrallĂ« â çdo orĂ«. Por kjo nuk Ă«shtĂ« problem â ne mund tĂ« shkruajmĂ« njĂ« kĂ«rkesĂ« tjetĂ«r qĂ« do tĂ« nxjerrĂ« 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)Le të shpjegoj:
- Nga baza homeassistant.month.water_meter_hour do tĂ« nxjerrim tĂ« dhĂ«na pĂ«r entity_id=âwater_meter_coldâ pĂ«r 24 orĂ«t e fundit (time >= now() -24h).
- Siç e përmenda më parë, në sekvencën homeassistant.month.water_meter_hour mund të mungojnë disa shënime. Ne do t'i gjenerojmë këto të dhëna përsëri, duke ekzekutuar një kërkesë me GROUP BY time(1h). Këtë herë fill(previous) do të funksionojë siç duhet, duke gjeneruar të dhënat mungesë (funksioni do të marrë vlerën e mëparshme).
- E rëndësishme në këtë kërkesë është funksioni difference, i cili do të llogarisë ndryshimin midis shënimeve të orës. Ai vetë nuk funksionon dhe kërkon një funksion agregues. Le të jetë max() që është përdorur më parë.
Rezultati i ekzekutimit duket kështu
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 72Nga ora 2 deri në 5 të mëngjesit (UTC) nuk pati konsum. Megjithatë, kërkesa do të kthejë të njëjtin vlerë të konsumit falë fill(previous), ndërsa funksioni difference do ta heqë këtë vlerë nga vetvetja dhe në dalje do të kemi 0, që është në fakt ajo që ne kërkojmë.
Tani mbetet vetëm të ndërtosh grafikun. Për këtë, do të hapim Grafana, do të hapim një tabela ekzistuese (ose do të krijojmë një të re), do të krijojmë një panel të ri. Cilësimet e grafikëve do të jenë të tilla.
Unë do të tregoj të dhënat për ujë të ftohtë dhe të ngrohtë në një grafik. Kërkesa është pikërisht ajo që e përshkrova më sipër.
Parametrat e shfaqjes caktohen kështu. Në rastin tim do të kem një grafik me linja (lines), i cili do të jetë me hapa (stairs). Parametri Stack do ta shpjegoj pak më poshtë. Ka disa parametra të tjerë shfaqjeje më poshtë, por ato nuk janë aq interesante.
Për të shtuar grafikun e marrë në home assistant duhet:
- të dalësh nga moda e redaktimit të grafikëve. për një arsye të panjohur, caktimet e sakta të ndarjes së grafikëve ofrohen vetëm nga faqja e panelit.
- Të klikosh në trekëndëshin pranë emrit të grafikët, në menu të zgjedhësh share.
- Në dritaren e hapur të kalosh në tab-in embed.
- TĂ« hiqni shenjĂ«n aktuale tĂ« gamĂ«s sĂ« kohĂ«s â gamĂ«n e kohĂ«s do ta caktojmĂ« pĂ«rmes URL-sĂ«.
- Të zgjedhësh temën e nevojshme. Në rastin tim kjo është light.
- Të kopjosh URL-në e atëhershme në kartelën e cilësimeve 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"
Vini re se gamë e kohës (dy ditët e fundit) caktohet pikërisht këtu, e jo në cilësimet e panelit.
Grafiku duket kështu. Unë nuk kam përdorur ujë të nxehtë për dy ditët e fundit, prandaj çizmet vetëm grafikun e ujit të ftohtë.
Nuk e kam vendosur ende se cilin grafik e preferoj më shumë, atë me vijë të shkallëzuar ose me shtylla reale. Prandaj, thjesht do të sjell një shembull grafik të përditshëm të konsumit, këtë herë me shtylla. Kërkesat ndërtohen njësoj siç përshkruheshin më sipër. Parametrat e shfaqjes janë të tillë:
Ky grafik duket kështu:
Ky është parametri Stack. Në këtë grafik, shtylla e ujit të ftohtë vizatohet mbi shtyllën e ujit të ngrohtë. Në total, lartësia përfaqëson konsum total të ujit të ftohtë dhe të ngrohtë për periudhën.
Të gjithë grafiket e paraqitur janë dinamikë. Mund të kaloni me miun mbi pikën e interesit dhe të shihni detajet dhe vlerën në pikën specifike.
Fatkeqësisht, pa disa pika të hidhura nuk do të ndodhte. Në grafikun me shtylla (ndryshe nga ai me vijë të shkallëzuar), mesi i shtyllës nuk qëndron në mes të ditës, por në orën 00:00. Pra, gjysma e majtë e shtyllës është vizatuar në vendin e ditës së kaluar. Pra, grafiket për të shtunën dhe të dielën janë vizatuar pak majtas nga zona bluese. Deri tani nuk kam gjetur një mënyrë si ta zgjidh këtë problem.
NjĂ« problem tjetĂ«r Ă«shtĂ« pamundĂ«sia pĂ«r tĂ« punuar siç duhet me intervalet mujore. ĂĂ«shtja Ă«shtĂ« se gjatĂ«si e orĂ«s/ditĂ«s/java Ă«shtĂ« fiks, ndĂ«rsa gjatĂ«si e muajit Ă«shtĂ« çdo herĂ« e ndryshme. InfluxDB Ă«shtĂ« nĂ« gjendje tĂ« punojĂ« vetĂ«m me intervale tĂ« njĂ«jta. Aktualisht kam arritur tĂ« caktoj njĂ« interval tĂ« fikst 30 ditĂ«sh. Po, grafiku gjatĂ« vitit do tĂ« ketĂ« disa shpĂ«rqendrime dhe kolonat nuk do tĂ« pĂ«rputhen saktĂ«sisht me muajt. Por, pasi qĂ« kjo Ă«shtĂ« interesante pĂ«r mua si njĂ« matĂ«s, do ta pranoj kĂ«tĂ«.
Shikoj të paktën dy zgjidhje:
- Të nënvleftësoj grafiku mujore dhe të kufizohem me ato javore. 52 kolona javore në vit duken mjaft mirë.
- TĂ« llogaris konsumimin mujor si metodĂ« e dytĂ« dhe tĂ« pĂ«rdor grafana vetĂ«m pĂ«r grafika tĂ« bukura. Do tĂ« rezultojĂ« njĂ« zgjidhje mjaft e saktĂ«. Mund tĂ« mbivendos grafikat nga viti i kaluar pĂ«r krahasim â grafana e bĂ«n kĂ«tĂ« gjithashtu.
PĂ«rfundimi
Nuk e di pse, por më pëlqen shumë ky lloj grafiku. Ato tregojnë se jeta është dinamike dhe gjithçka po ndryshon. Dje kishte shumë, sot ka pak, nesër do të jetë ndryshe. Mbetet të punoj me anëtarët e familjes mbi temën e konsumit. Por përderisa kërkesat aktuale janë kështu, thjesht një numër i madh dhe i paqartë në faturë tashmë shndërrohet në një pamje mjaft të qartë të konsumit.
PavarĂ«sisht njĂ« karriere gati 20-vjeçare si programues, kam pasur pak pĂ«rvojĂ« me bazat e tĂ« dhĂ«nave. Prandaj, instalimi i njĂ« baze tĂ« dhĂ«nash tĂ« jashtme mĂ« dukej si diçka shumĂ« komplekse dhe e paqartĂ«. Gjithçka ndryshoi â duke u treguar se lidhja e njĂ« instrumenti tĂ« pĂ«rshtatshĂ«m bĂ«het me disa klikime, dhe me njĂ« instrument tĂ« specializuar, detyra e ndĂ«rtimit tĂ« grafikĂ«ve bĂ«het pak mĂ« e lehtĂ«.
NĂ« titullin kam pĂ«rmendur konsumimin e energjisĂ« elektrike. FatkeqĂ«sisht, nĂ« kĂ«tĂ« moment nuk mund tĂ« sjell asnjĂ« grafik. NjĂ« matĂ«s SDM120 mĂ« ka ndalur, ndĂ«rsa tjetri ka probleme kur i qaset nĂ«pĂ«rmjet Modbus. MegjithatĂ«, kjo nuk ndikon aspak 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 sjellë qasjet që kam provuar vetë. Sigurisht, ka edhe metoda të tjera për organizimin e mbledhjes dhe vizualizimit të të dhënave, për të cilat nuk kam dijeni. Më tregoni për to në komentet, do të më interesonte shumë. Do të isha i lumtur për kritikat konstruktive dhe idetë e reja. Shpresoj se materiali i shpjeguar do t'i ndihmojë gjithashtu dikujt.
Burimi: habr.com
