Sa herĂ« qĂ« marr faturĂ«n e energjisĂ« elektrike dhe ujit, habitem â a konsumon vĂ«rtet familja ime kaq shumĂ«? Po, nĂ« banjĂ« kemi dysheme me ngrohje dhe bojler, por ato nuk punojnĂ« pa ndĂ«rprerje. Edhe ujin duket se e kursejmĂ« (edhe pse na pĂ«lqen edhe tĂ« relaksohemi nĂ« vaskĂ«). Disa vite mĂ« parĂ« unĂ« tashmĂ« dhe me shtĂ«pinĂ« e mençur, por aty mbeti gjithçka. Te analiza e konsumit u ktheva vetĂ«m tani, dhe pikĂ«risht pĂ«r kĂ«tĂ« flet ky artikull.
Së fundmi kalova te Home Assistant si platformë për shtëpinë e mençur. Një nga arsyet ishte pikërisht mundësia për të organizuar mbledhjen e një sasie të madhe të dhënash dhe për të ndërtuar lehtësisht grafikë të llojeve të ndryshme.
Informacioni i përshkruar në këtë artikull nuk është i ri; të gjitha këto zgjidhje janë trajtuar tashmë në internet, në forma të ndryshme. Por çdo artikull, si rregull, përshkruan vetëm një qasje ose një aspekt. Krahasimin e këtyre qasjeve dhe zgjedhjen e asaj më të përshtatshme m'u desh ta bëja vetë. Ky artikull gjithsesi nuk jep një pasqyrë shteruese për mbledhjen e të dhënave, por shërben si një lloj përmbledhjeje se si e kam realizuar unë. Prandaj, kritikat konstruktive dhe sugjerimet për përmirësim janë të mirëpritura.
Formulimi i detyrës
Pra, qëllimi i ushtrimit të sotëm është të marrim grafikë të bukur të konsumit të ujit dhe energjisë elektrike:
- Për çdo orë, për 2 ditë
- Për çdo ditë, për 2 javë
- (opsionale) për çdo javë dhe për çdo muaj
Këtu na presin disa vështirësi:
- Komponentët standardë të grafikëve, si rregull, janë mjaft të dobët. Në rastin më të mirë, mund të ndërtohet një grafik linear sipas pikave.
Nëse kërkoni mirë, mund të gjeni komponentë të palëve të treta që zgjerojnë mundësitë e grafikut standard. Për Home Assistant, në parim, një komponent i mirë dhe estetik është , por edhe ai ka disa kufizime:
- ĂshtĂ« e vĂ«shtirĂ« tĂ« pĂ«rcaktohen parametrat e grafikut me shtylla pĂ«r intervale tĂ« gjata kohore (gjerĂ«sia e shtyllĂ«s pĂ«rcaktohet nĂ« fraksione tĂ« orĂ«s, ndaj intervalet mĂ« tĂ« gjata se njĂ« orĂ« duhet tĂ« jepen me numra dhjetorĂ«)
- Nuk mund të shtohen në të njëjtin grafik entitete të ndryshme (për shembull temperatura dhe lagështia, ose të kombinohet një grafik me shtylla me një vijë)
- Jo vetëm që Home Assistant si parazgjedhje përdor bazën më të thjeshtë të të dhënave, SQLite (dhe unë, për paaftësinë time, nuk arrita të instaloj MySQL ose Postgres), por edhe të dhënat ruhen jo në mënyrën më optimale. Për shembull, sa herë që ndryshon secili parametër numerik, qoftë edhe më i vogli, në bazë shkruhet një JSON i madh me madhësi rreth 1 kilobajt.
{"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ë temperature në çdo dhomë, matës uji dhe energjie elektrike), dhe disa prej tyre gjenerojnë edhe shumë të dhëna. Për shembull, vetëm matësi i energjisë elektrike SDM220 prodhon rreth një duzinë vlerash çdo 10-15 sekonda, dhe unë do të doja të instaloja rreth 8 matës të tillë. Përveç kësaj, ka edhe një sërë parametrash që llogariten mbi bazën e sensorëve të tjerë. Kështu, të gjitha këto vlera mund ta fryjnë lehtësisht bazën e të dhënave me 100-200 MB në ditë. Pas një jave sistemi mezi do të punojë, ndërsa pas një muaji do të dështojë memoria flash (në rastin e instalimit tipik të Home Assistant në Raspberry Pi), e për ruajtjen e të dhënave për një vit të tërë as që mund të bëhet fjalë.
- NĂ«se keni fat, matĂ«si juaj di vetĂ« tĂ« llogarisĂ« konsumin. NĂ« çdo moment mund tâi drejtoheni matĂ«sit dhe tĂ« kĂ«rkoni vlerĂ«n e akumuluar tĂ« konsumit deri nĂ« atĂ« çast. Si rregull, tĂ« gjithĂ« matĂ«sit e energjisĂ« elektrike qĂ« kanĂ« ndĂ«rfaqe dixhitale (RS232/RS485/Modbus/Zigbee) e ofrojnĂ« kĂ«tĂ« mundĂ«si.
ĂshtĂ« edhe mĂ« keq nĂ«se pajisja mund tĂ« masĂ« vetĂ«m njĂ« parametĂ«r tĂ« çastit (pĂ«r shembull fuqinĂ« ose rrymĂ«n e çastit), ose thjesht tĂ« gjenerojĂ« impulse çdo X vat-orĂ« apo litra. AtĂ«herĂ« duhet menduar si dhe me çfarĂ« tĂ« integrohet kjo dhe ku tĂ« grumbullohet vlera. Ekziston rreziku tĂ« humbet raporti i radhĂ«s pĂ«r ndonjĂ« arsye, dhe edhe saktĂ«sia e sistemit nĂ« tĂ«rĂ«si ngre pikĂ«pyetje. Sigurisht, tĂ« gjitha kĂ«to mund tâi besohen njĂ« sistemi smart home si Home Assistant, por askush nuk e ka anuluar çështjen e numrit tĂ« regjistrimeve nĂ« bazĂ«n e tĂ« dhĂ«nave, dhe sondazhi i sensorĂ«ve mĂ« shpesh se njĂ« herĂ« nĂ« sekondĂ« nuk do tĂ« jetĂ« i mundur (kufizim i arkitekturĂ«s sĂ« Home Assistant).
Qasja 1
SĂ« pari, le tĂ« shohim çfarĂ« ofron Home Assistant si funksionalitet standard. Matja e konsumit pĂ«r njĂ« periudhĂ« Ă«shtĂ« njĂ« veçori shumĂ« e kĂ«rkuar. Natyrisht, kjo Ă«shtĂ« zbatuar prej kohĂ«sh nĂ« formĂ«n e njĂ« komponenti tĂ« specializuar â utility_meter.
Thelbi i komponentit Ă«shtĂ« se ai krijon brenda njĂ« variabĂ«l current_accumulated_value dhe e rivendos atĂ« pas pĂ«rfundimit tĂ« periudhĂ«s sĂ« caktuar (orĂ«/javĂ«/muaj). Komponenti vetĂ« monitoron variablĂ«n hyrĂ«se (vlerĂ«n e njĂ« sensori), vetĂ« abonohet ndaj ndryshimeve tĂ« vlerĂ«s â ju thjesht merrni rezultatin gati. Kjo gjĂ« pĂ«rshkruhet vetĂ«m me 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 matësit në litra, të cilën e marr përmes mqtt. Kjo strukturë krijon 2 sensorë të rinj water_cold_hour_um dhe water_cold_day_um, të cilët grumbullojnë leximet orare dhe ditore, duke i zeruar ato pas përfundimit të periudhës. Ja grafiku i akumulatorit orar për gjysmë dite.
Kodi i grafikëve orarë dhe ditorë për lovelace-UI duket kështu:
- type: history-graph
title: 'Konsumi orar i ujit duke përdorur vars'
hours_to_show: 48
entities:
- sensor.water_hour
- type: history-graph
title: 'Konsumi ditor i ujit duke përdorur vars'
hours_to_show: 360
entities:
- sensor.water_day
NĂ« fakt, pikĂ«risht te ky algoritĂ«m qĂ«ndron problemi i kĂ«saj qasjeje. Siç e pĂ«rmenda mĂ« herĂ«t, pĂ«r çdo vlerĂ« hyrĂ«se (leximi aktual i matĂ«sit pĂ«r çdo litĂ«r pasues) krijohet nga 1 KB regjistrim nĂ« bazĂ«n e tĂ« dhĂ«nave. Ădo utility meter gjeneron gjithashtu njĂ« vlerĂ« tĂ« re, e cila po ashtu ruhet nĂ« bazĂ«. NĂ«se dua tĂ« mbledh lexime orare/ditore/javore/mujore, pĂ«r disa kolona uji, dhe tâu shtoj edhe njĂ« grup matĂ«sish tĂ« energjisĂ« elektrike, kjo do tĂ« krijojĂ« shumĂ« tĂ« dhĂ«na. Ose mĂ« saktĂ«, vetĂ« tĂ« dhĂ«nat nuk janĂ« edhe aq shumĂ«, por meqĂ« Home Assistant shkruan nĂ« bazĂ« shumĂ« informacion tĂ« panevojshĂ«m, madhĂ«sia e bazĂ«s do tĂ« rritet me shpejtĂ«si marramendĂ«se. Madje hezitoj tĂ« pĂ«rllogaris sa e madhe do tĂ« bĂ«hej baza pĂ«r grafikĂ« javore dhe mujore.
Përveç kësaj, utility meter në vetvete nuk e zgjidh detyrën e vendosur. Grafiku i vlerave që jep utility meter është një funksion monoton në rritje, që rikthehet në 0 çdo orë. Ndërsa ne kemi nevojë për një grafik konsumi të qartë për përdoruesin: sa litra janë konsumuar gjatë një periudhe të caktuar. Komponenti standard history-graph nuk e ofron këtë, por mund të na ndihmojë komponenti i jashtëm mini-graph-card.
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: "Konsumi orar i ujit i agreguar nga utility meter"
points_per_hour: 1
show:
graph: bar
type: 'custom:mini-graph-card'Përveç parametrave standardë si emri i sensorit, lloji i grafikut dhe ngjyra (portokallia standarde nuk më pëlqeu), këtu vlen të theksohen 3 cilësime:
- group_by:hour â grafiku do tĂ« gjenerohet me rreshtimin e shtyllave sipas fillimit tĂ« orĂ«s
- points_per_hour: 1 â njĂ« shtyllĂ« pĂ«r çdo orĂ«
- Dhe mĂ« e rĂ«ndĂ«sishmja, aggregate_func: max â merret vlera maksimale brenda çdo ore. PikĂ«risht ky parametĂ«r e shndĂ«rron grafikun nĂ« formĂ« dhĂ«mbĂ«sh sharre nĂ« shtylla
Mos u kushtoni vĂ«mendje rreshtit tĂ« shtyllave nĂ« tĂ« majtĂ« â kjo Ă«shtĂ« sjellje standarde e komponentit kur nuk ka tĂ« dhĂ«na. Dhe tĂ« dhĂ«na vĂ«rtet nuk kishte â mbledhjen e tĂ« dhĂ«nave pĂ«r utility meter e aktivizova vetĂ«m para pak orĂ«sh, posaçërisht pĂ«r kĂ«tĂ« artikull (qasjen time aktuale do ta shpjegoj pak mĂ« poshtĂ«).
NĂ« kĂ«tĂ« figurĂ« doja tĂ« tregoja se ndonjĂ«herĂ« paraqitja e tĂ« dhĂ«nave madje funksionon, dhe shtyllat vĂ«rtet pasqyrojnĂ« vlerat e sakta. VetĂ«m se jo tĂ« gjitha. Shtylla e theksuar pĂ«r intervalin nga 11 deri nĂ« 12 paradite, pĂ«r ndonjĂ« arsye, tregon 19 litra, ndĂ«rsa nĂ« grafikun me dhĂ«mbĂ« pak mĂ« sipĂ«r, pĂ«r tĂ« njĂ«jtĂ«n periudhĂ« dhe nga i njĂ«jti sensor, shohim konsum prej 62 litrash. Ose Ă«shtĂ« bug, ose Ă«shtĂ« bĂ«rĂ« keq. NdĂ«rsa pse janĂ« prishur tĂ« dhĂ«nat nĂ« tĂ« djathtĂ«, kĂ«tĂ« ende nuk e kam kuptuar â konsumi aty ishte normal, gjĂ« qĂ« shihet gjithashtu nga grafiku me dhĂ«mbĂ«.
Me pak fjalĂ«, nuk arrita tâi jap besueshmĂ«ri kĂ«tij qasjeje â grafiku pothuajse gjithmonĂ« shfaq ndonjĂ« marrĂ«zi.
Kod analog 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 utility meter"
points_per_hour: 0.0416666666
show:
graph: bar
type: 'custom:mini-graph-card'
Vini re se parametri group_by Ă«shtĂ« vendosur nĂ« vlerĂ«n interval, dhe parametrin kryesor kĂ«tu e pĂ«rcakton points_per_hour. KĂ«tu qĂ«ndron edhe njĂ« problem tjetĂ«r i kĂ«tij komponenti â points_per_hour funksionon mirĂ« pĂ«r grafikĂ« me kohĂ«zgjatje njĂ« orĂ« ose mĂ« pak, por shumĂ« keq pĂ«r intervale mĂ« tĂ« gjata. KĂ«shtu, qĂ« tĂ« merrja njĂ« shtyllĂ« pĂ«r njĂ« ditĂ«, mĂ« Ă«shtĂ« dashur tĂ« vendos vlerĂ«n 1/24=0.04166666. PĂ«r tĂ« mos folur fare pĂ«r grafikĂ«t javorĂ« dhe mujorĂ«.
Qasja 2
Teksa sapo po njihesha me Home Assistant, hasa në këtë video:
Autori mbledh tĂ« dhĂ«na tĂ« konsumit nga disa lloje prizash Xiaomi. Detyra e tij Ă«shtĂ« pak mĂ« e thjeshtĂ« â thjesht tĂ« shfaqĂ« vlerĂ«n e konsumit pĂ«r sot, dje dhe pĂ«r muajin. Nuk nevojiten fare grafikĂ«.
Le tâi lĂ«mĂ« mĂ«njanĂ« arsyetimet pĂ«r integrimin manual tĂ« vlerave tĂ« menjĂ«hershme tĂ« fuqisĂ« â pĂ«r âsaktĂ«sinĂ«â e kĂ«saj qasjeje kam shkruar tashmĂ« mĂ« sipĂ«r. Nuk Ă«shtĂ« e qartĂ« pse ai nuk pĂ«rdori vlerat e akumuluara tĂ« konsumit, tĂ« cilat mblidhen tashmĂ« nga e njĂ«jta prizĂ«. Sipas mendimit tim, integrimi brenda pajisjes do tĂ« funksionojĂ« mĂ« mirĂ«.
Nga videoja do të marrim idenë e llogaritjes manuale të konsumit për një periudhë. Tek ai llogariten vetëm vlerat për sot dhe për 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 Đ·ĐœĐ°ŃĐ”ĐœĐžĐ”_ĐČ_ĐœĐ°ŃалД_ŃĐ°ŃĐ°, ku do tĂ« regjistrojmĂ« leximet aktuale tĂ« matĂ«sit
Sipas njĂ« kohĂ«matĂ«si nĂ« fund tĂ« orĂ«s (ose nĂ« fillim tĂ« orĂ«s tjetĂ«r), do tĂ« llogarisim diferencĂ«n midis leximit aktual dhe atij tĂ« ruajtur nĂ« fillim tĂ« orĂ«s. Kjo diferencĂ« do tĂ« jetĂ« konsumi pĂ«r orĂ«n aktuale â do ta ruajmĂ« vlerĂ«n nĂ« sensor dhe mĂ« pas do ta pĂ«rdorim pĂ«r tĂ« ndĂ«rtuar grafikun.
Gjithashtu duhet tĂ« âzerohetâ variabla Đ·ĐœĐ°ŃĐ”ĐœĐžĐ”_ĐČ_ĐœĐ°ŃалД_ŃĐ°ŃĐ° duke shkruar aty vlerĂ«n aktuale tĂ« matĂ«sit.
E gjithë kjo mund të bëhet me vetë mjetet e Home Assistant.
Do tĂ« duhet tĂ« shkruhet disi mĂ« shumĂ« kod sesa nĂ« qasjen e mĂ«parshme. SĂ« pari, le tĂ« krijojmĂ« kĂ«to âvariablaâ. Si standard, nuk kemi njĂ« entitet âvariabĂ«lâ, por mund tĂ« pĂ«rdorim MQTT broker. Do tĂ« dĂ«rgojmĂ« aty vlerat me flamurin retain=true â kjo do ta ruajĂ« vlerĂ«n brenda broker-it dhe mund tĂ« merret prej andej nĂ« çdo moment, edhe pas rinisjes sĂ« Home Assistant. UnĂ« krijova 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ë magjia ndodh në automatizim, i cili niset 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: trueTë dy automatizimet 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 pasues
Ndërtimi i grafikëve në këtë rast zgjidhet me history-graph të zakonshëm:
- type: history-graph
title: 'Konsumi orar i ujit duke përdorur vars'
hours_to_show: 48
entities:
- sensor.water_hour
- type: history-graph
title: 'Konsumi ditor i ujit duke përdorur vars'
hours_to_show: 360
entities:
- sensor.water_dayDuket kështu:
Në thelb, kjo është tashmë ajo që duhet. Përparësia e kësaj metode është se të dhënat gjenerohen vetëm një herë për çdo interval. Pra, gjithsej 24 regjistrime në ditë për grafikun orar.
FatkeqĂ«sisht, kjo gjithsesi nuk e zgjidh problemin e pĂ«rgjithshĂ«m tĂ« rritjes sĂ« bazĂ«s. NĂ«se dua njĂ« grafik tĂ« konsumit mujor, do tĂ« mĂ« duhet tâi ruaj tĂ« dhĂ«nat tĂ« paktĂ«n pĂ«r njĂ« vit. Dhe meqĂ« Home Assistant ofron vetĂ«m njĂ« cilĂ«sim tĂ« vetĂ«m pĂ«r kohĂ«zgjatjen e ruajtjes pĂ«r tĂ« gjithĂ« bazĂ«n, 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, brenda njĂ« viti konsumoj 200 metra kub ujĂ«, qĂ« do tĂ« thotĂ« 200000 regjistrime nĂ« bazĂ«. E nĂ«se marrim parasysh edhe sensorĂ«t e tjerĂ«, atĂ«herĂ« shifra bĂ«het fare e pajustifikueshme.
Qasja 3
Për fat të mirë, njerëzit e zgjuar e kanë zgjidhur tashmë këtë problem duke krijuar 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 nga sensorë të ndryshëm. Sistemi ofron gjithashtu një gjuhë pyetësish të ngjashme me SQL, e cila lejon të nxirren vlerat nga baza dhe më pas të agregohen në mënyra të ndryshme. Së fundi, lloje të ndryshme të dhënash mund të ruhen për periudha të ndryshme. Për shembull, matjet që ndryshojnë shpesh, si temperatura ose lagështia, mund të ruhen vetëm për disa javë, ndërsa matjet 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 vizualizimin e grafikĂ«ve nga tĂ« dhĂ«nat e InfluxDB. Grafana mund tĂ« krijojĂ« 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Ă« Home Assistant.
Frymëzim dhe Në artikuj përshkruhet në detaje procesi i instalimit dhe lidhjes së InfluxDB dhe Grafana me Home Assistant. Unë do të përqendrohem te zgjidhja e detyrës sime konkrete.
Pra, si hap të parë, le të fillojmë të ruajmë vlerën e matësit në InfluxDB. Pjesë e konfigurimit të Home Assistant (në këtë shembull do të merrem jo vetëm me ujin e ftohtë, por edhe me atë të ngrohtë):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldLe të çaktivizojmë ruajtjen e këtyre të njëjtave të dhëna në bazën e brendshme të Home Assistant, që të mos e zmadhojmë pa nevojë:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldTani le tĂ« kalojmĂ« nĂ« konzolĂ«n e InfluxDB dhe tĂ« konfigurojmĂ« bazĂ«n tonĂ«. Konkretisht, duhet tĂ« pĂ«rcaktojmĂ« sa kohĂ« do tĂ« ruhen lloje tĂ« caktuara tĂ« dhĂ«nash. Kjo rregullohet nga e ashtuquajtura retention policy â diçka e ngjashme me baza tĂ« dhĂ«nash brenda bazĂ«s kryesore, ku secila bazĂ« e brendshme ka parametrat e vet. Si parazgjedhje, tĂ« gjitha tĂ« dhĂ«nat ruhen nĂ« retention policy me emrin autogen, dhe kĂ«to tĂ« dhĂ«na mbahen pĂ«r njĂ« javĂ«. UnĂ« do tĂ« doja qĂ« tĂ« dhĂ«nat orare tĂ« ruheshin pĂ«r njĂ« muaj, ato javore pĂ«r njĂ« vit, ndĂ«rsa ato mujore tĂ« mos fshiheshin kurrĂ«. Le tĂ« krijojmĂ« retention policy pĂ«rkatĂ«se
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 vjen truku kryesor â agregimi i tĂ« dhĂ«nave me ndihmĂ«n e continuous query. Ky Ă«shtĂ« njĂ« mekanizĂ«m qĂ« ekzekuton automatikisht njĂ« kĂ«rkesĂ« nĂ« intervale tĂ« caktuara kohore, i agregjon tĂ« dhĂ«nat sipas kĂ«saj kĂ«rkese dhe rezultatin e ruan si njĂ« vlerĂ« tĂ« re. Ta shohim me njĂ« shembull (po e shkruaj me rreshta pĂ«r lexueshmĂ«ri, por nĂ« praktikĂ« mĂ« Ă«shtĂ« dashur ta fus kĂ«tĂ« komandĂ« nĂ« njĂ« rresht tĂ« vetĂ«m)
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)
ENDKjo komandë:
- Krijon një continuous query me emrin cq_water_cold_hourly në bazën homeassistant
- Kërkesa do të ekzekutohet çdo orë (time(1h))
- Kërkesa do të marrë të gjitha të dhënat nga measurement homeassistant.autogen.l (litra), përfshirë leximet e ujit të ftohtë dhe të ngrohtë
- Të dhënat e agreguara do të grupohen sipas entity_id, gjë që do të krijojë vlera të ndara për ujin e ftohtë dhe të ngrohtë
- Meqenëse matësi i litrave është një sekuencë me rritje monotone, brenda çdo ore duhet marrë vlera maksimale, prandaj agregimi do të kryhet me funksionin max(value)
- Vlera e re do të shkruhet në homeassistant.month.water_meter_hour, ku month është emri i retention policy me afat ruajtjeje një muaj. Të dhënat për ujin e ftohtë dhe të ngrohtë do të ruhen në regjistrime të veçanta me entity_id përkatës dhe vlerën në fushën value
Natën ose kur nuk ka njeri në shtëpi, nuk ka konsum uji dhe, për rrjedhojë, nuk ka as regjistrime të reja në homeassistant.autogen.l. Që të mos ketë boshllëqe në vlera gjatë kërkesave të zakonshme, mund të përdoret fill(previous). Kjo e detyron InfluxDB të përdorë vlerën e orës së mëparshme.
FatkeqĂ«sisht, continuous query ka njĂ« veçori: truku fill(previous) nuk funksionon dhe regjistrimet thjesht nuk krijohen. Madje kjo Ă«shtĂ« njĂ« problematikĂ« qĂ« duket e pazgjidhshme dhe qĂ« . Me kĂ«tĂ« problem do tĂ« merremi mĂ« vonĂ«, ndĂ«rsa fill(previous) le tĂ« mbetet nĂ« continuous query â nuk pengon.
Le të kontrollojmë çfarë kemi marrë si rezultat (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, prandaj nĂ« kĂ«tĂ« listĂ« ato ndryshojnĂ« me 3 orĂ« â vlerat pĂ«r orĂ«n 7 tĂ« mĂ«ngjesit nĂ« daljen e InfluxDB pĂ«rputhen me vlerat pĂ«r orĂ«n 10 tĂ« mĂ«ngjesit nĂ« grafiqet mĂ« sipĂ«r. Gjithashtu, vini re se midis orĂ«s 2 dhe 5 tĂ« mĂ«ngjesit thjesht nuk ka regjistrime â kjo Ă«shtĂ« pikĂ«risht ajo veçori e continuous query.
Siç mund ta shihni, edhe vlera e agreguar Ă«shtĂ« njĂ« sekuencĂ« monotone nĂ« rritje, vetĂ«m se regjistrimet shfaqen mĂ« rrallĂ« â njĂ« herĂ« nĂ« orĂ«. Por kjo nuk Ă«shtĂ« problem â mund tĂ« shkruajmĂ« edhe njĂ« query 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)Po e shpjegoj:
- Nga baza homeassistant.month.water_meter_hour do tĂ« marrim tĂ« dhĂ«nat pĂ«r entity_id=âwater_meter_coldâ pĂ«r 24 orĂ«t e fundit (time >= now() -24h).
- Siç e pĂ«rmenda mĂ« sipĂ«r, nĂ« sekuencĂ«n homeassistant.month.water_meter_hour mund tĂ« mungojnĂ« disa regjistrime. KĂ«to tĂ« dhĂ«na do tâi gjenerojmĂ« sĂ«rish duke ekzekutuar query me GROUP BY time(1h). KĂ«tĂ« herĂ« fill(previous) do tĂ« funksionojĂ« siç duhet, duke gjeneruar tĂ« dhĂ«nat qĂ« mungojnĂ« (funksioni do tĂ« marrĂ« vlerĂ«n e mĂ«parshme)
- Pjesa më e rëndësishme në këtë query është funksioni difference, i cili llogarit diferencën midis pikave orare. Në vetvete ai nuk funksionon dhe kërkon një funksion agregues. Le të jetë max(), i 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 ka pasur konsum. Megjithatë, kërkesa do të kthejë të njëjtën vlerë konsumi falë fill(previous), ndërsa funksioni difference do ta zbresë këtë vlerë nga vetja dhe në dalje do të marrim 0, që është pikërisht ajo që na duhet.
Mbetet vetĂ«m hapi i fundit â tĂ« ndĂ«rtojmĂ« grafikun. PĂ«r kĂ«tĂ« hapim Grafana, hapim njĂ« dashboard ekzistues (ose krijojmĂ« njĂ« tĂ« ri) dhe shtojmĂ« njĂ« panel tĂ« ri. CilĂ«simet e grafikut do tĂ« jenĂ« si mĂ« poshtĂ«.
Unë do të shfaq të dhënat për ujin e ftohtë dhe të ngrohtë në të njëjtin grafik. Kërkesa është saktësisht e njëjtë siç e përshkrova më sipër.
Parametrat e shfaqjes vendosen kështu. Në rastin tim do të jetë një grafik me vija (lines), i paraqitur me hapa (stairs). Parametrin Stack do ta shpjegoj pak më poshtë. Ka edhe disa parametra të tjerë të shfaqjes, por nuk janë aq interesantë.
Për të shtuar grafikun e krijuar në home assistant, duhet:
- të dilni nga modaliteti i redaktimit të grafikut. Për ndonjë arsye, cilësimet e sakta për ndarjen e grafikëve ofrohen vetëm nga faqja e dashboard-it
- Të klikoni mbi trekëndëshin pranë emrit të grafikut dhe në menu të zgjidhni share
- Në dritaren që hapet, kaloni te skeda embed
- Hiqni shenjĂ«n te current time range â diapazoni kohor do tĂ« pĂ«rcaktohet pĂ«rmes URL-sĂ«
- Zgjidhni temën e nevojshme. Në rastin tim është light
- Kopjoni URL-në e krijuar 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"
Vini re se diapazoni kohor (2 ditët e fundit) përcaktohet pikërisht këtu, jo te cilësimet e dashboard-it.
Grafiku duket kështu. Ujë të ngrohtë nuk kam përdorur gjatë 2 ditëve të fundit, prandaj shfaqet vetëm grafiku i ujit të ftohtë.
Unë ende nuk kam vendosur se cili grafik më pëlqen më shumë: ai me vijë në formë shkallësh apo shtyllat reale. Prandaj po jap thjesht një shembull të grafikut ditor të konsumit, por këtë herë me shtylla. Kërkesat ndërtohen në të njëjtën mënyrë si më sipër. Parametrat e shfaqjes janë këta:
Ky grafik duket kështu:
Sa për parametrin Stack. Në këtë grafik, shtylla e ujit të ftohtë vizatohet mbi shtyllën e ujit të ngrohtë. Lartësia totale përputhet me konsumin e përgjithshëm të ujit të ftohtë dhe të ngrohtë për periudhën.
Të gjithë grafikët e paraqitur janë dinamikë. Mund ta vendosni miun mbi pikën që ju intereson për të parë detajet dhe vlerën në atë pikë të caktuar.
Fatkeqësisht, nuk shpëtuam pa disa mangësi. Te grafiku me shtylla (ndryshe nga grafiku me vija-shkallë), qendra e shtyllës nuk bie në mes të ditës, por në 00:00. Pra, gjysma e majtë e shtyllës vizatohet në vendin e ditës së mëparshme. Për këtë arsye, grafiqet për të shtunën dhe të dielën dalin pak më majtas se zona me nuancë blu. Deri tani nuk kam gjetur ende si ta zgjidh këtë.
NjĂ« problem tjetĂ«r Ă«shtĂ« pamundĂ«sia pĂ«r tĂ« punuar saktĂ« me intervalet mujore. ĂĂ«shtja Ă«shtĂ« se gjatĂ«sia e orĂ«s/ditĂ«s/javĂ«s Ă«shtĂ« fikse, ndĂ«rsa gjatĂ«sia e muajit ndryshon çdo herĂ«. InfluxDB di tĂ« punojĂ« vetĂ«m me intervale tĂ« njĂ«jta. Deri tani zgjidhja ime ka qenĂ« tĂ« vendos njĂ« interval fiks prej 30 ditĂ«sh. Po, gjatĂ« vitit grafiku do tĂ« zhvendoset pak dhe shtyllat nuk do tâu korrespondojnĂ« plotĂ«sisht muajve. Por, meqĂ« kjo gjĂ« mĂ« duhet thjesht si njĂ« tregues vizual, kjo pĂ«r mua Ă«shtĂ« nĂ« rregull.
Shoh të paktën dy zgjidhje:
- Të heq dorë nga grafiqet mujore dhe të kufizohem te ato javore. 52 shtylla javore në vit duken mjaft mirë
- VetĂ« konsumin mujor ta llogaris me metodĂ«n nr. 2, ndĂ«rsa Grafana ta pĂ«rdor vetĂ«m pĂ«r grafikĂ« tĂ« bukur. KĂ«shtu do tĂ« dalĂ« njĂ« zgjidhje mjaft e saktĂ«. Madje mund tĂ« mbivendosen edhe grafiqet e vitit tĂ« kaluar pĂ«r krahasim â Grafana e mbĂ«shtet edhe kĂ«tĂ«.
PĂ«rfundim
Nuk e di pse, por më pëlqejnë shumë këto lloj grafikësh. Ato tregojnë se jeta është në lëvizje dhe gjithçka ndryshon. Dje kishte shumë, sot ka pak, nesër do të jetë ndryshe. Tani mbetet të punohet me familjarët për temën e konsumit. Por edhe me këtë nivel aktual shpenzimi, shifra e madhe dhe e pakuptueshme në faturë tashmë po kthehet në një pamje mjaft të qartë të konsumit.
PavarĂ«sisht njĂ« karriere pothuajse 20-vjeçare si programues, me bazat e tĂ« dhĂ«nave pothuajse nuk jam pĂ«rballur fare. Prandaj, instalimi i njĂ« baze tĂ« dhĂ«nash tĂ« jashtme mĂ« dukej si diçka tepĂ«r e ndĂ«rlikuar dhe e paqartĂ«. Gjithçka e ndryshoi â doli se lidhja e mjetit tĂ« duhur bĂ«het me vetĂ«m disa klikime, dhe me njĂ« mjet tĂ« specializuar detyra e ndĂ«rtimit tĂ« grafikĂ«ve bĂ«het disi mĂ« e thjeshtĂ«.
NĂ« titull pĂ«rmenda konsumin e energjisĂ« elektrike. FatkeqĂ«sisht, pĂ«r momentin nuk mund tĂ« paraqes asnjĂ« grafik. NjĂ«ri matĂ«s SDM120 mĂ« Ă«shtĂ« prishur, ndĂ«rsa tjetri ka probleme kur aksesohet pĂ«rmes Modbus. MegjithatĂ«, kjo nuk ndikon aspak nĂ« temĂ«n e kĂ«tij artikulli â grafiqet do tĂ« ndĂ«rtohen nĂ« tĂ« njĂ«jtĂ«n mĂ«nyrĂ« si pĂ«r ujin.
NĂ« kĂ«tĂ« artikull kam pĂ«rshkruar qasjet qĂ« i kam provuar vetĂ«. Me siguri ka edhe mĂ«nyra tĂ« tjera pĂ«r organizimin e mbledhjes dhe vizualizimit tĂ« tĂ« dhĂ«nave, pĂ«r tĂ« cilat unĂ« nuk di. MĂ« tregoni pĂ«r to nĂ« komente, do tĂ« ishte shumĂ« interesante pĂ«r mua. Do tĂ« jem i lumtur tĂ« marr kritika konstruktive dhe ide tĂ« reja. Shpresoj qĂ« materiali i paraqitur tâi ndihmojĂ« edhe dikujt tjetĂ«r.
Burimi: habr.com
