Omah Cerdas: Nggambar Konsumsi Banyu lan Listrik ing Asisten Omah

Saben-saben aku nampa pembayaran listrik lan banyu, aku mikir - apa kulawargaku pancen akeh banget? Inggih, ya, ana lantai sing digawe panas lan ketel ing jedhing, nanging ora bisa digunakake minangka petugas pemadam kebakaran. Kita uga katon ngirit banyu (sanajan kita uga seneng cipratan ing kamar mandi). Sawetara taun kepungkur aku wis meter banyu disambungake и listrik menyang omah sing cerdas, nanging ing kene kedadeyan macet. Tangan wis tekan analisis konsumsi mung saiki, sing, nyatane, apa artikel iki.

Aku bubar ngalih menyang Asisten Ngarep minangka sistem omah sing cerdas. Salah sawijining alasan yaiku mung kemampuan kanggo ngatur koleksi data sing akeh kanthi kamungkinan konstruksi sing trep kanggo macem-macem jinis grafik.

Informasi sing diterangake ing artikel iki ora anyar, kabeh iki ing macem-macem sauces wis diterangake ing Internet. Nanging saben artikel, minangka aturan, mung nggambarake siji pendekatan utawa aspek. Aku kudu mbandhingake kabeh pendekatan kasebut lan milih sing paling cocog dhewe. Artikel kasebut isih ora menehi informasi lengkap babagan pengumpulan data, nanging minangka ringkesan babagan carane aku nindakake. Dadi kritik lan saran sing mbangun kanggo perbaikan.

Formulasi masalah

Dadi, tujuan latihan saiki yaiku entuk grafik konsumsi banyu lan listrik sing apik:

• Saben jam kanggo 2 dina
• Saben dina kanggo 2 minggu
• (opsional) saben minggu lan saben wulan

Ana sawetara kangelan ing iki:

• Komponen bagan standar cenderung kurang apik. Paling apik, sampeyan bisa nggawe grafik garis kanthi poin.

  Yen sampeyan nggoleki kanthi apik, sampeyan bisa nemokake komponen pihak katelu sing ngluwihi kemampuan grafik standar. Kanggo asisten omah, ing prinsip, komponen sing apik lan apik kertu grafik mini, nanging uga rada winates:

  • Iku angel kanggo nyetel paramèter saka grafik bar ing interval gedhe (jembaré bar disetel ing pecahan saka jam, kang tegese interval luwih saka siji jam bakal disetel ing nomer pecahan)
  • Sampeyan ora bisa nambah entitas beda menyang siji grafik (contone, suhu lan asor, utawa gabungke grafik bar karo garis)
• Ora mung asisten omah nggunakake database SQLite paling primitif kanthi standar (lan aku, tukang, ora nguwasani instalasi MySQL utawa Postgres), data kasebut ora disimpen kanthi cara sing paling optimal. Dadi, contone, kanthi saben owah-owahan saben parameter digital sing paling cilik saka parameter, json gedhe babagan ukuran kilobyte ditulis ing database.

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

  Aku duwe cukup sawetara sensor (sensor suhu ing saben kamar, banyu lan listrik meter), lan sawetara uga generate cukup akèh data. Contone, mung meter listrik SDM220 ngasilake kira-kira rolas nilai saben 10-15 detik, lan aku pengin nginstal meter kuwi 8. Lan ana uga akeh paramèter sing diwilang adhedhasar sensor liyane. Iku. kabeh nilai kasebut kanthi gampang bisa nambah database kanthi 100-200 MB saben dina. Ing seminggu, sistem bakal meh ora muter, lan ing sasi flash drive bakal mati (ing kasus instalasi khas asisten omah ing raspberry PI), lan ora ana obrolan babagan nyimpen data sajrone setaun. .

• Yen sampeyan beruntung, meter sampeyan bisa ngetung konsumsi. Sampeyan bisa ngubungi meter ing sembarang wektu lan takon apa wektu akumulasi nilai konsumsi. Minangka aturan, kabeh meter listrik sing duwe antarmuka digital (RS232 / RS485 / Modbus / Zigbee) nyedhiyakake kesempatan kasebut.

  Luwih elek, yen piranti mung bisa ngukur sawetara parameter cepet (contone, daya cepet utawa saiki), utawa mung generate pulsa saben X watt-jam utawa liter. Banjur sampeyan kudu mikir babagan carane lan apa sing kudu digabungake lan ing ngendi kanggo nglumpukake nilai. Ana risiko ilang laporan sabanjure kanthi alesan apa wae, lan akurasi sistem kanthi sakabehe nyebabake pitakonan. Sampeyan bisa, mesthi, ngandelake kabeh iki menyang sistem omah sing cerdas kaya asisten omah, nanging ora ana sing mbatalake titik babagan jumlah entri ing database, lan sensor polling luwih saka sepisan sepisan ora bakal bisa digunakake (watesan saka arsitektur asisten omah).

Pendekatan 1

Pisanan, ayo ndeleng apa asisten omah sing diwenehake metu saka kothak. Ngukur konsumsi sajrone wektu minangka fungsi sing dijaluk banget. Mesthi, wis dileksanakake dangu minangka komponen khusus - utility_meter.

Inti saka komponen kasebut yaiku miwiti variabel current_accumulated_value ing njero lan ngreset sawise wektu sing ditemtokake (jam / minggu / wulan). Komponen kasebut dhewe ngawasi variabel sing mlebu (nilai sawetara sensor), langganan owah-owahan ing nilai kasebut - sampeyan mung entuk asil sing wis rampung. Bab iki diterangake mung sawetara baris ing file konfigurasi

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

Kene sensor.water_meter_cold punika Nilai saiki meter ing liter aku njaluk langsung saka wesi dening mqtt. Desain kasebut nggawe 2 sensor anyar water_cold_hour_um lan water_cold_day_um, sing nglumpukake maca saben jam lan saben dina, ngreset menyang nol sawise sawetara wektu. Iki minangka grafik baterei saben jam kanggo setengah dina.

Kode grafik saben jam lan saben dina kanggo lovelace-UI katon kaya iki:

      - 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

Bener, ing algoritma iki ana masalah pendekatan iki. Kaya sing wis dakcritakake, kanggo saben nilai sing mlebu (maca meter saiki kanggo saben liter sabanjure), 1kb rekaman digawe ing database. Saben meter sarana uga ngasilake nilai anyar, sing uga ditambahake ing pangkalan. Yen aku pengin ngumpulake maca saben jam / saben dina / mingguan / saben wulan, ya, kanggo sawetara water risers, lan malah nambah Pack saka meter elektrik, iki bakal dadi akeh data. Inggih, luwih tepat, ora ana akeh data, nanging wiwit asisten omah nulis akeh informasi sing ora perlu menyang database, ukuran database bakal tuwuh kanthi cepet. Aku malah wedi ngira ukuran dhasar kanggo grafik mingguan lan saben wulan.

Kajaba iku, meter sarana dhewe ora ngrampungake masalah kasebut. Plot meter utilitas minangka fungsi nambah monoton sing direset dadi 0 saben jam. Kita uga butuh jadwal konsumsi sing ramah pangguna, pira liter sing dipangan sajrone wektu kasebut. Komponen sajarah-grafik standar ora nindakake iki, nanging komponen mini-grafik-kertu external bisa bantuan kita.

Iki kode kertu kanggo 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'

Saliyane setelan standar kaya jeneng sensor, jinis grafik, warna (aku ora seneng oranye standar), penting kanggo dicathet 3 setelan ing kene:

• group_by:hour - grafik bakal digawe karo kolom didadekake siji kanggo awal jam
• points_per_hour: 1 - siji bar saben jam
• Lan sing paling penting, aggregate_func: max yaiku njupuk nilai maksimal ing saben jam. Parameter iki sing ngowahi grafik sawtooth dadi bar.

Aja menehi perhatian marang baris kolom ing sisih kiwa - iki minangka prilaku standar komponen yen ora ana data. Nanging ora ana data - aku mung ngaktifake pengumpulan data nggunakake meter sarana sawetara jam kepungkur mung kanggo artikel iki (aku bakal njlèntrèhaké pendekatan saiki sing rada murah).

Ing gambar iki, aku wanted kanggo nuduhake sing kadhangkala tampilan data malah dianggo, lan bar tenan nggambarake nilai bener. Nanging ora mung kuwi. Kanggo sawetara alasan, kolom sing disorot kanggo periode saka 11 am nganti 12 am nampilake 19 liter, sanajan ing grafik toothy rada luwih dhuwur kanggo wektu sing padha saka sensor sing padha kita ndeleng konsumsi 62 liter. Salah siji bug utawa tangan bengkong. Nanging aku isih ora ngerti kenapa data ing sisih tengen pecah - konsumsi ing kono normal, sing uga katon saka grafik gigi.

Umumé, aku gagal kanggo entuk plausibility saka pendekatan iki - graph meh tansah nuduhake sawetara jinis wulangan sesat.

Kode sing padha kanggo sensor awan.

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

Elinga yen parameter group_by disetel kanggo interval, lan parameter points_per_hour aturan kabeh. Lan iki masalah liyane karo komponen iki - points_per_hour dianggo uga ing denah saka jam utawa kurang, nanging njijiki ing interval luwih gedhe. Dadi kanggo entuk siji kolom ing sedina, aku kudu ngetik nilai 1/24=0.04166666. Aku ora ngomong babagan grafik mingguan lan saben wulan.

Pendekatan 2

Nalika isih ngerteni asisten omah, aku nemokake video iki:

Comrade ngumpulake data konsumsi saka sawetara jinis soket Xiaomi. Tugase rada prasaja - mung nampilake nilai konsumsi kanggo dina iki, wingi lan kanggo sasi. Ora ana grafik sing dibutuhake.

Ayo ninggalake bantahan babagan integrasi manual nilai daya cepet - Aku wis nulis babagan "akurasi" pendekatan iki ing ndhuwur. Ora jelas kenapa dheweke ora nggunakake nilai konsumsi akumulasi, sing wis diklumpukake dening outlet sing padha. Miturut pendapatku, integrasi ing potongan wesi bakal luwih apik.

Saka video kasebut, kita bakal njupuk ide ngetung konsumsi kanthi manual sajrone sawetara wektu. Kanggo wong, mung nilai kanggo dina iki lan kanggo wingi sing dianggep, nanging kita bakal luwih maju lan nyoba nggambar grafik. Inti saka metode sing diusulake ing kasusku kaya ing ngisor iki.

Kita bakal nggawe variabel value_at_the_beginning_of_hour, ing ngendi kita bakal nulis maca counter saiki
Miturut wektu ing pungkasan jam (utawa ing wiwitan sabanjure), kita ngetung prabédan antarane maca saiki lan sing disimpen ing wiwitan jam. Bentenane iki bakal dadi konsumsi kanggo jam saiki - kita bakal nyimpen nilai kasebut menyang sensor, lan ing mangsa ngarep kita bakal nggawe grafik adhedhasar nilai kasebut.
Sampeyan uga kudu "ngreset" variabel value_at_beginning_of_hour kanthi nulis nilai saiki counter ana.

Kabeh iki bisa ditindakake kanthi apik ... liwat asisten omah dhewe.

Sampeyan kudu nulis kode luwih sithik tinimbang ing pendekatan sadurunge. Ayo dadi miwiti karo "variabel" iki. Metu saka kothak, kita ora duwe entitas "variabel", nanging sampeyan bisa nggunakake layanan saka broker mqtt. Kita bakal ngirim nilai ing kana kanthi gendéra retain=true - iki bakal ngirit regane ing broker kasebut, lan bisa ditarik metu kapan wae, sanajan asisten omah diwiwiti maneh. Aku nggawe counter saben jam lan saben dina bebarengan.

- 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

Kabeh sihir kedadeyan ing otomatisasi, sing mlaku saben jam lan saben wengi.

- 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

Loro-lorone otomatis nindakake 2 perkara:

• Etung nilai saben interval minangka prabédan antarane nilai wiwitan lan pungkasan
• Nganyari nilai dhasar kanggo interval sabanjure

Konstruksi grafik ing kasus iki ditanggulangi kanthi grafik riwayat biasa:

      - 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

Katon kaya mangkene:

Ing asas, iki wis apa sampeyan kudu. Kauntungan saka metode iki yaiku data digawe sapisan saben interval. Sing. total 24 entri saben dina kanggo grafik saben jam.

Sayange, iki isih ora ngrampungake masalah umum saka basis sing akeh. Yen aku pengin grafik konsumsi saben wulan, aku kudu nyimpen data paling sethithik setaun. Lan amarga asisten omah mung nyedhiyakake setelan durasi panyimpenan kanggo kabeh database, iki tegese ALL data ing sistem kudu disimpen sajrone setaun. Contone, ing setahun aku nggunakake 200 meter kubik banyu, tegese 200000 entri ing database. Lan yen sampeyan njupuk menyang akun sensor liyane, banjur tokoh dadi umum ora sopan.

Pendekatan 3

Untunge, wong pinter wis ngrampungake masalah iki kanthi nulis database InfluxDB. Database iki dioptimalake khusus kanggo nyimpen data adhedhasar wektu lan cocog kanggo nyimpen nilai sensor sing beda. Sistem kasebut uga nyedhiyakake basa pitakon kaya SQL sing ngidini sampeyan ngekstrak nilai saka database lan banjur nglumpukake kanthi macem-macem cara. Pungkasan, data sing beda bisa disimpen ing wektu sing beda. Contone, bacaan sing kerep diganti kayata suhu utawa kelembapan bisa disimpen mung sawetara minggu, dene bacaan saben dina babagan konsumsi banyu bisa disimpen sajrone setaun.

Saliyane InfluxDB, wong pinter uga nemokke Grafana, sistem kanggo nggambar grafik saka data saka InfluxDB. Grafana bisa nggambar macem-macem jinis grafik, ngatur kanthi rinci, lan sing paling penting, grafik kasebut bisa "disambungake" menyang asisten omah lovelace-UI.

dadi inspirasi kene и kene. Artikel kasebut nerangake kanthi rinci babagan proses nginstal lan nyambungake InfluxDB lan Grafana menyang asisten omah. Aku bakal fokus kanggo ngrampungake masalah tartamtu.

Dadi, pisanan, ayo miwiti nambah nilai counter ing influxDB. Sepotong konfigurasi asisten omah (ing conto iki, aku bakal seneng-seneng ora mung karo kadhemen, nanging uga nganggo banyu panas):

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

Ayo mateni nyimpen data sing padha menyang database internal asisten omah supaya ora nggedhekake maneh:

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

Ayo saiki menyang konsol InfluxDB lan atur basis data. Utamane, sampeyan kudu ngatur suwene data tartamtu bakal disimpen. Iki diatur dening sing disebut. kabijakan retensi - iki padha karo database ing basis data utama, kanthi saben database internal duwe setelan dhewe. Kanthi gawan, kabeh data ditambahake menyang kabijakan retensi sing diarani autogen, data iki bakal disimpen sajrone seminggu. Aku pengin data saben jam disimpen sajrone sasi, data mingguan sajrone setahun, lan data saben wulan ora bakal dibusak. Kita bakal nggawe kabijakan penylametan sing cocog

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

Saiki, nyatane, trik utama yaiku agregasi data nggunakake pitakon terus-terusan. Iki minangka mekanisme sing kanthi otomatis mbukak pitakon ing interval tartamtu, nglumpukake data kanggo pitakon iki, lan nambah asil menyang nilai anyar. Ayo goleki conto (aku nulis ing kolom kanggo maca, nanging nyatane aku kudu ngetik perintah iki ing siji baris)

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

Prentah iki:

• Nggawe pitakon terus-terusan jenenge cq_water_cold_hourly ing database homeassistant
• Pitakonan bakal dieksekusi saben jam (wektu(1h))
• Pitakonan bakal narik kabeh data saka measurement'a homeassistant.autogen.l (liter), kalebu maca banyu adhem lan panas.
• Data sing dikumpulake bakal dikelompokake miturut entity_id, sing bakal nggawe nilai sing kapisah kanggo banyu adhem lan panas.
• Wiwit counter liter minangka urutan sing tambah monoton ing saben jam, sampeyan kudu njupuk nilai maksimal, mula panggabungan bakal ditindakake kanthi fungsi maksimal (nilai)
• Nilai anyar bakal ditulis kanggo homeassistant.month.water_meter_hour ngendi sasi iku jeneng saka kabijakan penylametan karo periode retensi siji sasi. Kajaba iku, data babagan banyu adhem lan panas bakal kasebar dadi cathetan sing kapisah kanthi entity_id sing cocog lan nilai ing kolom nilai.

Ing wayah wengi utawa nalika ora ana wong ing omah, ora ana konsumsi banyu, lan ora ana cathetan anyar ing homeassistant.autogen.l. Kanggo ngindhari nilai sing ilang ing pitakon normal, sampeyan bisa nggunakake isi (sadurunge). Iki bakal meksa InfluxDB nggunakake nilai jam kepungkur.

Sayange, pitakon terus-terusan duwe kekhasan: trik isi (sadurunge) ora bisa digunakake lan cathetan ora digawe. Menapa malih, iki sawetara jenis masalah insurmountable, kang wis dibahas luwih saka setahun. Kita bakal ngatasi masalah iki mengko, lan supaya isi (sadurunge) ing pitakonan terus ana - iku ora ngganggu.

Ayo priksa apa sing kedadeyan (mesthi sampeyan kudu ngenteni sawetara jam):

> 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

Elinga yen nilai ing basis data disimpen ing UTC, mula dhaptar iki beda-beda 3 jam - nilai 7am ing output InfluxDB cocog karo nilai 10am ing grafik ing ndhuwur. Uga elinga yen antarane jam 2 lan 5 esuk ora ana cathetan - iki minangka fitur pitakon sing terus-terusan.

Nalika sampeyan bisa ndeleng, nilai aggregated uga urutan monotonically nambah, mung entri kurang asring - sapisan jam. Nanging iki ora dadi masalah - kita bisa nulis pitakon liyane sing bakal ngekstrak data sing bener kanggo grafik.

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)

Aku bakal decipher:

• Saka database homeassistant.month.water_meter_hour, kita bakal narik data kanggo entity_id='water_meter_cold' kanggo dina pungkasan (wektu> = saiki () -24h).
• Kaya sing dakkandhakake, sawetara entri bisa uga ilang saka urutan homeassistant.month.water_meter_hour. Kita bakal ngasilake data iki kanthi mbukak pitakon nganggo GROUP BY time(1h). Wektu iki, isi (sadurunge) bakal bisa digunakake kanthi bener, ngasilake data sing ilang (fungsi kasebut bakal njupuk nilai sadurunge)
• Sing paling penting ing pitakonan iki yaiku fungsi prabédan, sing bakal ngetung prabédan antarane tandha jam. Dhewe, ora bisa digunakake lan mbutuhake fungsi agregasi. Ayo iki dadi maksimal () sing digunakake sadurunge.

Asil eksekusi katon kaya iki

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

Wiwit jam 2 nganti 5 esuk (UTC) ora ana konsumsi. Nanging, pitakon bakal ngasilake nilai konsumsi sing padha amarga diisi (sadurunge), lan fungsi prabédan bakal nyuda nilai kasebut lan entuk 0 ing output, sing pancen dibutuhake.

Siji-sijine sing kudu ditindakake yaiku nggawe grafik. Kanggo nindakake iki, bukak Grafana, bukak sawetara dasbor sing wis ana (utawa gawe anyar), gawe panel anyar. Setelan grafik bakal kaya ing ngisor iki.

Aku bakal nampilake data banyu adhem lan panas ing grafik sing padha. Panyuwunan kasebut persis kaya sing dakkandhakake ing ndhuwur.

Paramèter tampilan disetel kaya ing ngisor iki. Kanggo kula, bakal dadi grafik kanthi garis (garis), sing mlaku kanthi langkah (tangga). Parameter Stack bakal diterangake ing ngisor iki. Ana sawetara opsi tampilan liyane ing ngisor iki, nanging padha ora supaya menarik.

Kanggo nambah grafik sing diasilake menyang asisten omah, sampeyan kudu:

• metu saka mode editing grafik. Kanggo sawetara alasan, setelan nuduhake grafik sing bener mung ditawakake saka kaca dashboard
• Klik ing segitiga ing jejere jeneng grafik, pilih nuduhake saka menu
• Ing jendhela sing mbukak, pindhah menyang tab embed
• Busak centhang rentang wektu saiki - kita bakal nyetel rentang wektu liwat URL
• Pilih topik sing dibutuhake. Ing kasusku iku entheng
• Nyalin URL asil menyang kertu setelan 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"

Elinga yen sawetara wektu (2 dina pungkasan) disetel ing kene, lan ora ing setelan dashboard.

Bagan katon kaya iki. Aku ora nggunakake banyu panas sajrone 2 dina kepungkur, mula mung digambar grafik banyu adhem.

Aku durung mutusake dhewe grafik sing paling disenengi, garis langkah, utawa bar nyata. Mulane, aku mung bakal menehi conto jadwal konsumsi saben dina, mung wektu iki ing bar. Pitakonan dibangun kanthi cara sing padha kaya sing kasebut ing ndhuwur. Pilihan tampilan yaiku:

Bagan iki katon kaya iki:

Dadi, babagan parameter Stack. Ing grafik iki, garis banyu adhem digambar ing ndhuwur bar panas. Dhuwur total cocog karo konsumsi total banyu kadhemen lan panas kanggo periode kasebut.

Kabeh grafik sing ditampilake dinamis. Sampeyan bisa mindhah mouse liwat titik kapentingan lan ndeleng rincian lan nilai ing titik tartamtu.

Sayange, iku ora tanpa saperangan fly ing ointment. Ing bagan bar (ora kaya bagan garis-langkah), tengah bar ora ana ing tengah dina, nanging ing 00:00. Sing. setengah kiwa garis digambar ing panggonan dina sadurunge. Dadi grafik kanggo Setu lan Minggu digambar sethithik ing sisih kiwa zona biru. Nganti aku ngerti carane menang.

Masalah liyane yaiku ora bisa digunakake kanthi bener kanthi interval saben wulan. Kasunyatane, dawane jam / dina / minggu wis tetep, nanging suwene wulan beda-beda saben wektu. InfluxDB mung bisa digunakake kanthi interval sing padha. Nganti saiki, otakku wis cukup kanggo nyetel interval tetep 30 dina. Ya, grafik bakal ngambang sethithik sajrone taun lan bar ora cocog karo sasi. Nanging amarga bab iki menarik kanggo kula mung minangka meter tampilan, Aku ok karo iki.

Aku ndeleng paling ora rong solusi:

• Kanggo ngetung ing denah saben wulan lan mbatesi dhewe ing saben minggu. 52 bar mingguan ing setahun katon apik banget
• Coba konsumsi saben wulan dhewe minangka metode No. 2, lan gunakake grafana mung kanggo grafik sing apik. Iku solusi sing cukup akurat. Sampeyan bisa malah overlay denah kanggo taun kepungkur kanggo mbandhingake - grafana can do that.

kesimpulan

Aku ora ngerti kenapa, nanging aku seneng karo grafik kaya iki. Padha nuduhake yen urip ana ing ayunan lengkap lan kabeh wis ganti. Wingi akeh, dina iki sithik, sesuk ana liyane. Iku tetep kanggo nggarap rumah tangga ing topik konsumsi. Nanging sanajan karo napsu saiki, mung tokoh gedhe lan ora bisa dimangerteni ing tagihan wis dadi gambaran konsumsi sing cukup dingerteni.

Senadyan karirku meh 20 taun minangka programmer, aku meh ora intersect karo database. Mulane, nginstall database eksternal katon kaya abstruse lan ora bisa dingerteni. Kabeh wis owah artikel ing ndhuwur - ternyata screwing alat sing cocog wis rampung ing sawetara klik, lan karo alat khusus, tugas ngrancang dadi sethitik luwih gampang.

Ing judhul, aku nyebutake konsumsi listrik. Sayange, saiki aku ora bisa menehi grafik. Siji meter SDM120 mati, lan liyane buggy nalika diakses liwat Modbus. Nanging, iki ora mengaruhi topik artikel iki kanthi cara apa wae - grafik bakal dibangun kanthi cara sing padha karo banyu.

Ing artikel iki, aku wis menehi pendekatan sing wis dakcoba dhewe. Mesthi ana sawetara cara liya kanggo ngatur koleksi lan visualisasi data sing aku ora ngerti. Ngomong babagan iki ing komentar, aku bakal kasengsem banget. Aku bakal bungah kanggo kritik mbangun lan gagasan anyar. Mugi materi ing ndhuwur uga bakal bantuan wong.

Source: www.habr.com