Hər dəfə işıq və su pulu alanda düşünürəm ki, mənim ailəm həqiqətənmi çox istehlak edir? Bəli, hamamda qızdırılan döşəmə və qazan var, lakin onlar həmişə yanğınsöndürən kimi işləmirlər. Biz də deyəsən suya qənaət edirik (baxmayaraq ki, biz hamamda sıçramağı da sevirik). Bir neçə il əvvəl mən artıq и ağıllı bir evə, amma işlərin ilişib qaldığı yer budur. Əllər istehlakın təhlilinə yalnız indi çatdı, əslində bu məqalənin mövzusu budur.
Bu yaxınlarda mən ağıllı ev sistemim kimi Ev köməkçisinə keçdim. Səbəblərdən biri sadəcə müxtəlif növ qrafiklərin rahat qurulması imkanı ilə böyük miqdarda məlumatların toplanmasının təşkili idi.
Bu məqalədə təsvir olunan məlumatlar yeni deyil, müxtəlif souslar altında olan bütün bunlar İnternetdə artıq təsvir edilmişdir. Ancaq hər bir məqalə, bir qayda olaraq, yalnız bir yanaşma və ya aspekti təsvir edir. Mən bütün bu yanaşmaları müqayisə edib ən uyğununu özüm seçməli oldum. Məqalə hələ də məlumatların toplanması ilə bağlı hərtərəfli məlumat vermir, lakin bunu necə etdiyimin bir növ xülasəsidir. Beləliklə, konstruktiv tənqid və təkmilləşdirmə təklifləri qəbul edilir.
Problem problemi
Beləliklə, bugünkü məşqin məqsədi su və elektrik istehlakının gözəl qrafiklərini əldə etməkdir:
- 2 gün saatda bir
- Gündəlik 2 həftə
- (isteğe bağlı) həftəlik və aylıq
Bu işdə bəzi çətinliklər var:
- Standart diaqram komponentləri olduqca zəif olur. Ən yaxşı halda, nöqtələr üzrə xətt qrafiki qura bilərsiniz.
Yaxşı axtarış etsəniz, standart diaqramın imkanlarını genişləndirən üçüncü tərəf komponentlərini tapa bilərsiniz. Ev köməkçisi üçün, prinsipcə, yaxşı və gözəl bir komponentdir , lakin bu da bir qədər məhduddur:
- Ştrix diaqramının parametrlərini böyük intervallarla təyin etmək çətindir (barın eni bir saatın fraksiyaları ilə müəyyən edilir, bu o deməkdir ki, bir saatdan uzun intervallar kəsr ədədlərlə təyin olunacaq)
- Siz bir qrafikə müxtəlif obyektlər əlavə edə bilməzsiniz (məsələn, temperatur və rütubət və ya bar qrafikini xəttlə birləşdirin)
- Ev köməkçisi nəinki standart olaraq ən primitiv SQLite verilənlər bazasından istifadə edir (və mən usta, MySQL və ya Postgres-in quraşdırılmasını mənimsəməmişəm), məlumatlar ən optimal şəkildə saxlanmır. Beləliklə, məsələn, hər bir parametrin hətta ən kiçik rəqəmsal parametrinin hər dəyişməsi ilə verilənlər bazasına təxminən bir kilobayt ölçüsündə nəhəng bir json yazılır.
{"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}}}Mənim kifayət qədər sensorlarım var (hər otaqda temperatur sensorları, su və elektrik sayğacları), bəziləri də kifayət qədər çox məlumat yaradır. Məsələn, yalnız SDM220 elektrik sayğacı hər 10-15 saniyədə təxminən onlarla dəyər yaradır və mən 8 belə sayğac quraşdırmaq istərdim.Və digər sensorlar əsasında hesablanan bir çox parametrlər də var. Bu. bütün bu dəyərlər verilənlər bazasını asanlıqla gündə 100-200 MB şişirdə bilər. Bir həftə ərzində sistem çətinliklə fırlanacaq və dönəcək və bir aydan sonra flash sürücü öləcək (moruq PI-də tipik bir ev köməkçisi quraşdırılması halında) və bütün il ərzində məlumatların saxlanmasından söhbət gedə bilməz.
- Əgər şanslısınızsa, sayğacınız özü istehlakı hesablaya bilər. İstənilən vaxt sayğacla əlaqə saxlayaraq yığılmış istehlak dəyərinin saat neçədə olduğunu soruşa bilərsiniz. Bir qayda olaraq, rəqəmsal interfeysə (RS232/RS485/Modbus/Zigbee) malik olan bütün elektrik sayğacları belə bir fürsət verir.
Daha da pisi, cihaz bəzi ani parametrləri (məsələn, ani güc və ya cərəyan) ölçə bilirsə və ya sadəcə olaraq hər X vatt-saatda və ya litrdə impulslar yarada bilirsə. Sonra onu necə və nə ilə birləşdirəcəyinizi və dəyəri harada toplayacağınızı düşünməlisiniz. Hər hansı səbəbdən növbəti hesabatı qaçırma riski var və bütövlükdə sistemin düzgünlüyü suallar yaradır. Siz, əlbəttə ki, bütün bunları ev köməkçisi kimi ağıllı ev sisteminə həvalə edə bilərsiniz, lakin heç kim verilənlər bazasındakı girişlərin sayı ilə bağlı nöqtəni ləğv etməyib və səsvermə sensorları saniyədə bir dəfədən çox işləməyəcək (məhdudiyyət ev köməkçisi memarlığı).
1-ci yanaşma
Əvvəlcə qutudan hansı ev köməkçisinin verildiyini görək. Müəyyən müddət ərzində istehlakın ölçülməsi çox tələb olunan funksionallıqdır. Əlbəttə ki, o, uzun müddət əvvəl ixtisaslaşmış bir komponent kimi həyata keçirildi - utility_meter.
Komponentin mahiyyəti ondan ibarətdir ki, o, cari_toplanmış_dəyər dəyişənini daxilində işə salır və müəyyən bir müddətdən sonra (saat/həftə/ay) onu sıfırlayır. Komponentin özü daxil olan dəyişəni (bir növ sensorun dəyəri) izləyir, dəyərin özündə dəyişikliklərə abunə olur - sadəcə hazır nəticə əldə edirsiniz. Bu şey konfiqurasiya faylında bir neçə sətirdə təsvir edilmişdir
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Burada sensor.water_meter_cold mənim əldə etdiyim sayğacın litrlə cari qiymətidir mqtt tərəfindən. Dizayn 2 yeni water_cold_hour_um və water_cold_day_um yaradır, onlar saatlıq və gündəlik göstəriciləri toplayır və müəyyən müddətdən sonra onları sıfıra qaytarır. Budur yarım gün üçün saatlıq batareyanın qrafiki.
Lovelace-UI üçün saatlıq və gündəlik diaqram kodu belə görünür:
- 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
Əslində, bu alqoritmdə bu yanaşmanın problemi var. Artıq qeyd etdiyim kimi, verilənlər bazasında hər daxil olan dəyər üçün (hər növbəti litr üçün cari sayğacın oxunuşu) 1kb rekord yaradılır. Hər bir kommunal sayğac həm də bazaya əlavə olunan yeni bir dəyər yaradır. Əgər saatlıq/gündəlik/həftəlik/aylıq oxunuşları toplamaq istəsəm, bəli, bir neçə su qaldırıcısı üçün və hətta bir paket elektrik sayğacı əlavə etmək, bu çox məlumat olacaq. Yaxşı, daha doğrusu, çox məlumat yoxdur, amma ev köməkçisi verilənlər bazasına bir dəstə lazımsız məlumat yazdığından, verilənlər bazasının ölçüsü sıçrayış və həddə çatacaq. Həftəlik və aylıq qrafiklər üçün bazanın ölçüsünü təxmin etməkdən belə qorxuram.
Bundan əlavə, kommunal sayğacın özü problemi həll etmir. Kommunal sayğac sahəsi hər saat 0-a sıfırlanan monoton artan funksiyadır. Bizə həm də istifadəçi dostu istehlak cədvəli lazımdır, müddət ərzində neçə litr yeyildi. Standart tarix qrafiki komponenti bunu etmir, lakin xarici mini-qrafik kart komponenti bizə kömək edə bilər.
Bu lovelace-UI üçün kart kodudur:
- 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'Sensor adı, qrafik növü, rəng (standart narıncı bəyənmədim) kimi standart parametrlərə əlavə olaraq burada 3 parametri qeyd etmək vacibdir:
- group_by:hour - qrafik saatın əvvəlinə uyğunlaşdırılmış sütunlarla yaradılacaq
- saatda_bal: 1 - saatda bir bar
- Və ən əsası, aggregate_func: max hər saat ərzində maksimum dəyəri götürməkdir. Məhz bu parametr mişar dişi cədvəlini çubuqlara çevirir.
Soldakı sütunlar sırasına diqqət yetirməyin - məlumat yoxdursa, bu komponentin standart davranışıdır. Ancaq heç bir məlumat yox idi - mən yalnız bu məqalənin xatirinə bir neçə saat əvvəl kommunal sayğacdan istifadə edərək məlumat toplamağı işə saldım (indiki yanaşmamı bir az daha aşağı təsvir edəcəyəm).
Bu şəkildə göstərmək istədim ki, bəzən məlumat ekranı işləyir və barlar həqiqətən düzgün dəyərləri əks etdirir. Ancaq bu, hamısı deyil. Nədənsə, səhər saat 11-dən səhər 12-ə qədər olan dövr üçün vurğulanan sütun 19 litr göstərir, baxmayaraq ki, dişli qrafikdə eyni sensordan eyni dövr üçün bir qədər yüksəkdir, 62 litr istehlak görürük. Ya səhv, ya da əllər əyridir. Ancaq sağdakı məlumatların niyə pozulduğunu hələ də başa düşə bilmirəm - orada istehlak normal idi, bu da dişli qrafikdən görünür.
Ümumiyyətlə, mən bu yanaşmanın inandırıcılığına nail ola bilmədim - qrafik demək olar ki, həmişə bir növ bidət göstərir.
Gündüz sensoru üçün oxşar kod.
- 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'
Nəzərə alın ki, group_by parametri intervala təyin edilib və point_per_hoat parametri hər şeyi idarə edir. Və bu, bu komponentlə bağlı başqa bir problemdir - point_per_hour bir saat və ya daha az qrafiklərdə yaxşı işləyir, lakin daha böyük intervallarda iyrəncdir. Beləliklə, bir gündə bir sütun əldə etmək üçün 1/24=0.04166666 dəyərini daxil etməli oldum. Mən həftəlik və aylıq qrafiklərdən danışmıram.
2-ci yanaşma
Hələ ev köməkçisini taparkən bu video ilə rastlaşdım:
Yoldaş bir neçə növ Xiaomi rozetkasından istehlak məlumatlarını toplayır. Onun tapşırığı bir az daha sadədir - bu gün, dünən və ay üçün istehlak dəyərini göstərmək kifayətdir. Heç bir qrafik tələb olunmur.
Ani güc dəyərlərinin əl ilə inteqrasiyası ilə bağlı mübahisələri bir kənara qoyaq - yuxarıda bu yanaşmanın "dəqiqliyi" haqqında artıq yazdım. Artıq həmin məntəqə tərəfindən yığılan yığılmış istehlak dəyərlərindən niyə istifadə etmədiyi bəlli deyil. Məncə, dəmir parçasının içinə inteqrasiya daha yaxşı işləyəcək.
Videodan bir müddət ərzində istehlakı əl ilə hesablamaq fikrini alacağıq. Bir kişi üçün yalnız bu gün və dünən üçün dəyərlər nəzərə alınır, lakin biz daha da irəli gedəcəyik və bir qrafik çəkməyə çalışacağıq. Mənim vəziyyətimdə təklif olunan metodun mahiyyəti aşağıdakı kimidir.
Biz saatın_əvvəlində dəyişən dəyər yaradacağıq, orada cari sayğac oxunuşlarını yazacağıq.
Saatın sonunda (və ya növbətinin əvvəlində) taymerə görə, cari oxunuşla saatın əvvəlində saxlanılan arasındakı fərqi hesablayırıq. Bu fərq cari saat üçün sərfiyyat olacaq - biz sensora dəyəri saxlayacağıq və gələcəkdə bu dəyər əsasında bir qrafik quracağıq.
Siz həmçinin sayğacın cari dəyərini ora yazaraq value_at_beginning_of_hour dəyişənini "sıfırlamalısınız".
Bütün bunları yaxşı... ev köməkçisinin özü vasitəsilə etmək olar.
Əvvəlki yanaşmadan bir az daha çox kod yazmalı olacaqsınız. Bu "dəyişənlərdən" başlayaq. Qutudan kənarda, bizdə “dəyişən” qurum yoxdur, lakin siz mqtt brokerinin xidmətlərindən istifadə edə bilərsiniz. Biz ora dəyərləri saxla=true bayrağı ilə göndərəcəyik - bu, brokerin daxilindəki dəyəri saxlayacaq və onu istənilən vaxt, hətta ev köməkçisi yenidən işə salındıqda da çıxarmaq olar. Birdən saatlıq və gündəlik sayğaclar düzəltdim.
- 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: lBütün sehr müvafiq olaraq hər saat və hər gecə işləyən avtomatlaşdırmada baş verir.
- 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: trueHər iki avtomatlaşdırma 2 işi görür:
- Başlanğıc və son dəyər arasındakı fərq kimi interval başına dəyəri hesablayın
- Növbəti interval üçün əsas dəyəri yeniləyin
Bu vəziyyətdə qrafiklərin qurulması adi tarix qrafiki ilə həll olunur:
- 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_dayBelə görünür:
Prinsipcə, bu artıq sizə lazım olan şeydir. Bu metodun üstünlüyü ondan ibarətdir ki, verilənlər intervalda bir dəfə yaradılır. Bunlar. saatlıq diaqram üçün gündə cəmi 24 giriş.
Təəssüf ki, bu, hələ də artan bazanın ümumi problemini həll etmir. Aylıq istehlak qrafiki istəsəm, məlumatları ən azı bir il saxlamalı olacağam. Ev köməkçisi bütün verilənlər bazası üçün yalnız bir saxlama müddəti parametrini təmin etdiyinə görə, bu o deməkdir ki, sistemdəki BÜTÜN məlumatlar bütün il ərzində saxlanmalı olacaq. Məsələn, bir ildə mən 200 kubmetr su sərf edirəm ki, bu da bazaya 200000 min qeyd deməkdir. Digər sensorları nəzərə alsanız, rəqəm ümumiyyətlə ləyaqətsiz olur.
3-ci yanaşma
Xoşbəxtlikdən ağıllı insanlar InfluxDB verilənlər bazasını yazmaqla bu problemi artıq həll ediblər. Bu verilənlər bazası xüsusi olaraq vaxta əsaslanan məlumatların saxlanması üçün optimallaşdırılmışdır və müxtəlif sensorların dəyərlərini saxlamaq üçün idealdır. Sistem həmçinin verilənlər bazasından dəyərlər çıxarmağa və sonra onları müxtəlif yollarla birləşdirməyə imkan verən SQL kimi sorğu dilini təmin edir. Nəhayət, müxtəlif məlumatlar müxtəlif vaxtlar üçün saxlanıla bilər. Məsələn, temperatur və ya rütubət kimi tez-tez dəyişən göstəricilər yalnız bir neçə həftə, su istehlakının gündəlik göstəriciləri isə bütün il ərzində saxlanıla bilər.
InfluxDB-dən əlavə, ağıllı insanlar InfluxDB-dən məlumatlardan qrafiklər çəkmək üçün Grafana sistemini də icad etdilər. Grafana müxtəlif növ diaqramlar çəkə, onları təfərrüatlı şəkildə fərdiləşdirə və ən əsası, bu diaqramları lovelace-UI ev köməkçisinə “qoşmaq” olar.
ilhamlanmaq и . Məqalələr InfluxDB və Grafana-nın ev köməkçisinə quraşdırılması və qoşulması prosesini ətraflı təsvir edir. Mən xüsusi problemimi həll etməyə diqqət edəcəyəm.
Beləliklə, ilk növbədə, influxDB-də sayğac dəyərini əlavə etməyə başlayaq. Ev köməkçisi konfiqurasiyasının bir hissəsi (bu nümunədə mən yalnız soyuqla deyil, həm də isti su ilə əylənəcəyəm):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldBir daha şişirməmək üçün eyni məlumatların ev köməkçisinin daxili verilənlər bazasına saxlanmasını söndürək:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldİndi InfluxDB konsoluna gedək və verilənlər bazamızı quraşdıraq. Xüsusilə, müəyyən məlumatların nə qədər saxlanacağını konfiqurasiya etməlisiniz. Bu sözdə tənzimlənir. saxlama siyasəti - bu, əsas verilənlər bazası daxilində verilənlər bazalarına bənzəyir, hər bir daxili verilənlər bazası öz parametrlərinə malikdir. Varsayılan olaraq, bütün məlumatlar autogen adlı saxlama siyasətinə əlavə olunur, bu məlumatlar bir həftə saxlanılacaq. İstərdim ki, saatlıq məlumat bir ay, həftəlik məlumat bir il saxlansın və aylıq məlumatlar heç vaxt silinməsin. Biz müvafiq saxlama siyasətlərini yaradacağıq
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İndi, əslində, əsas hiylə davamlı sorğudan istifadə edərək məlumatların toplanmasıdır. Bu, müəyyən edilmiş fasilələrlə sorğunu avtomatik işə salan, bu sorğu üçün məlumatları birləşdirən və nəticəni yeni dəyərə əlavə edən mexanizmdir. Bir misala baxaq (oxumaq üçün sütunda yazıram, amma əslində bu əmri bir sətirə daxil etməli oldum)
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)
ENDBu əmr:
- Homeassistant verilənlər bazasında cq_water_cold_hourly adlı davamlı sorğu yaradır
- Sorğu hər saat yerinə yetiriləcək (vaxt (1 saat))
- Sorğu, soyuq və isti suyun oxunuşları da daxil olmaqla, ölçmə'a homeassistant.autogen.l (litr) saytından bütün məlumatları çıxaracaq.
- Ümumi məlumatlar soyuq və isti su üçün ayrıca dəyərlər yaradacaq entity_id ilə qruplaşdırılacaq.
- Litrlərin sayğacı hər saat ərzində monoton artan ardıcıllıq olduğundan, maksimum dəyəri götürməli olacaqsınız, buna görə də toplama max(value) funksiyası ilə həyata keçiriləcək.
- Yeni dəyər homeassistant.month.water_meter_hour ünvanına yazılacaq, burada ay bir aylıq saxlama müddəti ilə saxlama siyasətinin adıdır. Üstəlik, soyuq və isti su ilə bağlı məlumatlar müvafiq entity_id və dəyər sahəsindəki dəyər ilə ayrı qeydlərə səpələnəcək.
Gecə və ya evdə heç kim olmadığı zaman su sərfiyyatı olmur və buna görə homeassistant.autogen.l saytında da yeni qeydlər yoxdur. Normal sorğularda itkin dəyərlərin qarşısını almaq üçün doldurma (əvvəlki) istifadə edə bilərsiniz. Bu, InfluxDB-ni son saat dəyərindən istifadə etməyə məcbur edəcək.
Təəssüf ki, davamlı sorğunun özəlliyi var: doldurma (əvvəlki) hiyləsi işləmir və qeydlər sadəcə yaradılmır. Üstəlik, bu, bir növ həll edilməyən problemdir . Bu problemlə daha sonra məşğul olacağıq və fasiləsiz sorğuda doldurun(əvvəlki) orada qalsın - bu, müdaxilə etmir.
Nə baş verdiyini yoxlayaq (əlbəttə ki, bir neçə saat gözləmək lazımdır):
> 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
Nəzərə alın ki, verilənlər bazasındakı dəyərlər UTC-də saxlanılır, buna görə də bu siyahı 3 saat fərqlənir - InfluxDB çıxışında 7am dəyərləri yuxarıdakı diaqramlarda 10am dəyərlərinə uyğun gəlir. Həm də qeyd edin ki, səhər saat 2-dən 5-ə qədər heç bir qeyd yoxdur - bu, davamlı sorğunun xüsusiyyətidir.
Gördüyünüz kimi, yığılmış dəyər də monoton artan ardıcıllıqdır, yalnız girişlər daha az olur - saatda bir dəfə. Ancaq bu problem deyil - diaqram üçün düzgün məlumatları çıxaracaq başqa bir sorğu yaza bilərik.
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)Mən deşifrə edəcəm:
- homeassistant.month.water_meter_hour verilənlər bazasından biz son gün üçün entity_id='water_meter_cold' üçün məlumatları götürəcəyik (zaman >= indi() -24 saat).
- Qeyd etdiyim kimi, homeassistant.month.water_meter_saat ardıcıllığında bəzi qeydlər olmaya bilər. Biz sorğunu GROUP BY vaxtı (1 saat) ilə işlətməklə bu məlumatları bərpa edəcəyik. Bu dəfə doldurma (əvvəlki) düzgün işləyərək çatışmayan məlumatları yaradacaq (funksiya əvvəlki dəyəri alacaq)
- Bu sorğuda ən vacib şey saat işarələri arasındakı fərqi hesablayacaq fərq funksiyasıdır. Öz-özünə işləmir və toplama funksiyası tələb olunur. Bu, əvvəllər istifadə olunan max() olsun.
İcra nəticəsi belə görünür
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 72Səhər saat 2-dən gecə 5-ə qədər (UTC) istehlak olmayıb. Buna baxmayaraq, sorğu doldurma (əvvəlki) sayəsində eyni istehlak dəyərini qaytaracaq və fərq funksiyası bu dəyəri özündən çıxaracaq və çıxışda 0 alacaq ki, bu da əslində tələb olunur.
Ediləcək tək şey qrafik qurmaqdır. Bunu etmək üçün Grafana-nı açın, bəzi mövcud (və ya yeni) tablosunu açın, yeni panel yaradın. Diaqram parametrləri aşağıdakı kimi olacaq.
Eyni qrafikdə soyuq və isti su məlumatlarını göstərəcəyəm. Müraciət yuxarıda təsvir etdiyim kimidir.
Ekran parametrləri aşağıdakı kimi qurulur. Mənim üçün bu, addımlarla (pilləkənlərlə) gedən xətləri (xətləri) olan bir qrafik olacaq. Stack parametri aşağıda izah ediləcək. Aşağıda daha bir neçə ekran variantı var, lakin onlar o qədər də maraqlı deyil.
Yaranan qrafiki ev köməkçisinə əlavə etmək üçün sizə lazımdır:
- diaqramın redaktə rejimindən çıxın. Nədənsə düzgün diaqram paylaşma parametrləri yalnız idarə paneli səhifəsindən təklif olunur
- Diaqram adının yanındakı üçbucağın üzərinə klikləyin, menyudan paylaşım seçin
- Açılan pəncərədə yerləşdirmə sekmesine keçin
- Cari vaxt aralığını işarədən çıxarın - biz URL vasitəsilə vaxt aralığını təyin edəcəyik
- Lazım olan mövzunu seçin. Mənim vəziyyətimdə yüngüldür
- Yaranan URL-ni lovelace-UI parametrləri kartına kopyalayın
- 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"
Nəzərə alın ki, vaxt diapazonu (son 2 gün) tablosunun parametrlərində deyil, burada təyin olunub.
Diaqram belə görünür. Son 2 gündə isti sudan istifadə etməmişəm, ona görə də yalnız soyuq suyun qrafiki çəkilir.
Hansı qrafiki daha çox bəyəndiyimə qərar verməmişəm, pilləli xətt və ya real çubuqlar. Buna görə də, mən sadəcə gündəlik istehlak cədvəlinə bir nümunə verəcəyəm, yalnız bu dəfə barlarda. Sorğular yuxarıda göstərildiyi kimi qurulur. Ekran seçimləri bunlardır:
Bu diaqram belə görünür:
Beləliklə, Stack parametri haqqında. Bu qrafikdə isti çubuğun üstünə soyuq su çubuğu çəkilmişdir. Ümumi hündürlük dövr üçün soyuq və isti suyun ümumi istehlakına uyğundur.
Göstərilən bütün qrafiklər dinamikdir. Siz siçanı maraq nöqtəsi üzərində hərəkət etdirə və müəyyən bir nöqtədə təfərrüatları və dəyəri görə bilərsiniz.
Təəssüf ki, məlhəmdə bir-iki milçəksiz deyildi. Ştrixli diaqramda (addım xətləri olan qrafikdən fərqli olaraq) zolağın ortası günün ortasında deyil, saat 00:00-dadır. Bunlar. çubuqun sol yarısı əvvəlki günün yerinə çəkilir. Beləliklə, şənbə və bazar günləri üçün qrafiklər mavi zonanın bir az soluna çəkilir. Onu necə qazanacağımı anlayana qədər.
Digər problem aylıq fasilələrlə düzgün işləyə bilməməkdir. Fakt budur ki, saat / gün / həftənin uzunluğu sabitdir, lakin ayın uzunluğu hər dəfə fərqlidir. InfluxDB yalnız bərabər intervallarla işləyə bilər. İndiyə qədər beynim 30 günlük sabit bir interval təyin etmək üçün kifayət etdi. Bəli, qrafik il ərzində bir az üzəcək və barlar aylara tam uyğun gəlməyəcək. Ancaq bu şey mənim üçün bir displey sayğacı kimi maraqlı olduğundan, bununla razıyam.
Ən azı iki həll yolu görürəm:
- Aylıq qrafiklərdə xal toplamaq və özünüzü həftəlik qrafiklərlə məhdudlaşdırmaq. Bir ildə 52 həftəlik bar olduqca yaxşı görünür
- Aylıq istehlakın özünü 2 nömrəli üsul hesab edin və qrafananı yalnız gözəl qrafiklər üçün istifadə edin. Bu olduqca dəqiq bir həlldir. Müqayisə üçün hətta keçən il üçün qrafikləri üst-üstə qoya bilərsiniz - grafana bunu edə bilər.
Nəticə
Bilmirəm niyə, amma bu cür qrafikləri sevirəm. Onlar göstərir ki, həyat tam sürətlə gedir və hər şey dəyişir. Dünən çox idi, bu gün az, sabah başqa bir şey olacaq. İstehlak mövzusunda ev təsərrüfatları ilə işləmək qalır. Ancaq hazırkı iştahla belə, qanun layihəsində sadəcə böyük və anlaşılmaz bir rəqəm artıq istehlakın kifayət qədər başa düşülən mənzərəsinə çevrilir.
Proqramçı kimi demək olar ki, 20 illik karyerama baxmayaraq, verilənlər bazası ilə praktiki olaraq kəsişmədim. Buna görə də, xarici verilənlər bazası quraşdırmaq o qədər abstruktiv və anlaşılmaz bir şey kimi görünürdü. Hər şey dəyişdi - məlum oldu ki, uyğun bir alətin vidalanması bir neçə kliklə həyata keçirilir və xüsusi bir vasitə ilə hiylə qurmaq işi bir az asanlaşır.
Başlıqda elektrik istehlakını qeyd etdim. Təəssüf ki, hazırda heç bir qrafik təqdim edə bilmirəm. Bir SDM120 sayğacı ölüdür, digəri isə Modbus vasitəsilə daxil olanda nasazdır. Ancaq bu, bu məqalənin mövzusuna heç bir şəkildə təsir göstərmir - qrafiklər su ilə eyni şəkildə qurulacaq.
Bu yazıda mən özüm sınadığım o yanaşmaları verdim. Şübhəsiz ki, məlumatların toplanması və vizuallaşdırılmasını təşkil etmək üçün mənim bilmədiyim başqa yollar da var. Bu barədə şərhlərdə mənə deyin, çox maraqlı olacağam. Konstruktiv tənqidə və yeni ideyalara şad olaram. Ümid edirəm ki, yuxarıdakı material da kiməsə kömək edəcəkdir.
Mənbə: www.habr.com