Setiap kali saya menerima bayaran untuk elektrik dan air, saya tertanya-tanya - adakah keluarga saya benar-benar menggunakan begitu banyak? Ya, ada lantai yang dipanaskan dan dandang di dalam bilik mandi, tetapi mereka tidak berfungsi sebagai bomba sepanjang masa. Kami juga nampaknya menjimatkan air (walaupun kami juga suka memercik dalam bilik air). Beberapa tahun yang lalu saya sudah ΠΈ ke rumah pintar, tetapi di sinilah keadaan tersekat. Tangan telah mencapai analisis penggunaan hanya sekarang, yang, sebenarnya, adalah tentang artikel ini.
Saya baru-baru ini bertukar kepada Home Assistant sebagai sistem rumah pintar saya. Salah satu sebabnya ialah hanya keupayaan untuk mengatur pengumpulan sejumlah besar data dengan kemungkinan pembinaan mudah pelbagai jenis graf.
Maklumat yang diterangkan dalam artikel ini bukanlah perkara baru, semua perkara ini di bawah sos yang berbeza telah pun diterangkan di Internet. Tetapi setiap artikel, sebagai peraturan, menerangkan hanya satu pendekatan atau aspek. Saya terpaksa membandingkan semua pendekatan ini dan memilih sendiri yang paling sesuai. Artikel itu masih tidak memberikan maklumat lengkap tentang pengumpulan data, tetapi adalah sejenis ringkasan tentang cara saya melakukannya. Jadi kritikan dan cadangan yang membina dialu-alukan.
Pernyataan masalah
Jadi, matlamat latihan hari ini adalah untuk mendapatkan graf penggunaan air dan elektrik yang cantik:
- Setiap jam selama 2 hari
- Setiap hari selama 2 minggu
- (pilihan) mingguan dan bulanan
Terdapat beberapa kesukaran dalam hal ini:
- Komponen carta standard cenderung agak lemah. Paling baik, anda boleh membina graf garis mengikut mata.
Jika anda mencari dengan baik, anda boleh menemui komponen pihak ketiga yang memanjangkan keupayaan carta standard. Untuk pembantu rumah, pada dasarnya, komponen yang baik dan cantik , tetapi ia juga agak terhad:
- Sukar untuk menetapkan parameter carta bar pada selang masa yang besar (lebar bar ditetapkan dalam pecahan sejam, yang bermaksud bahawa selang lebih daripada satu jam akan ditetapkan dalam nombor pecahan)
- Anda tidak boleh menambah entiti yang berbeza pada satu graf (contohnya, suhu dan kelembapan, atau menggabungkan graf bar dengan garisan)
- Bukan sahaja pembantu rumah menggunakan pangkalan data SQLite paling primitif secara lalai (dan saya, tukang, tidak menguasai pemasangan MySQL atau Postgres), data tidak disimpan dengan cara yang paling optimum. Jadi, sebagai contoh, dengan setiap perubahan bagi setiap parameter digital walaupun terkecil parameter, json besar kira-kira satu kilobait dalam saiz ditulis ke pangkalan data
{"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}}}Saya mempunyai beberapa penderia (penderia suhu di setiap bilik, meter air dan elektrik), dan beberapa juga menjana data yang agak banyak. Sebagai contoh, hanya meter elektrik SDM220 menjana kira-kira sedozen nilai setiap 10-15 saat, dan saya ingin memasang 8 meter sedemikian. Dan terdapat juga sejumlah besar parameter yang dikira berdasarkan sensor lain. Itu. semua nilai ini boleh dengan mudah mengembang pangkalan data sebanyak 100-200 MB setiap hari. Dalam seminggu, sistem hampir tidak akan berpusing, dan dalam sebulan pemacu denyar akan mati (dalam kes pemasangan pembantu rumah pada raspberry PI biasa), dan tidak boleh bercakap tentang menyimpan data sepanjang tahun. .
- Jika anda bernasib baik, meter anda sendiri boleh mengira penggunaan. Anda boleh menghubungi meter pada bila-bila masa dan bertanya pada pukul berapa nilai penggunaan terkumpul. Sebagai peraturan, semua meter elektrik yang mempunyai antara muka digital (RS232/RS485/Modbus/Zigbee) memberikan peluang sedemikian.
Lebih buruk lagi, jika peranti hanya boleh mengukur beberapa parameter serta-merta (contohnya, kuasa atau arus serta-merta), atau hanya menjana denyutan setiap X watt-jam atau liter. Kemudian anda perlu memikirkan bagaimana dan dengan apa untuk mengintegrasikannya dan di mana untuk mengumpul nilai. Terdapat risiko kehilangan laporan seterusnya atas sebarang sebab, dan ketepatan sistem secara keseluruhan menimbulkan persoalan. Anda boleh, tentu saja, mempercayakan semua ini kepada sistem rumah pintar seperti pembantu rumah, tetapi tiada siapa yang membatalkan perkara tentang bilangan entri dalam pangkalan data, dan penderia pengundian lebih daripada sekali sesaat tidak akan berfungsi (had seni bina pembantu rumah).
Pendekatan 1
Mula-mula, mari lihat pembantu rumah yang disediakan di luar kotak. Mengukur penggunaan dalam satu tempoh adalah fungsi yang sangat diminta. Sudah tentu, ia telah lama dilaksanakan sebagai komponen khusus - utiliti_meter.
Intipati komponen ialah ia memulakan pembolehubah nilai_terkumpul semasa di dalam dan menetapkannya semula selepas tempoh tertentu (jam/minggu/bulan). Komponen itu sendiri memantau pembolehubah masuk (nilai beberapa jenis sensor), melanggan perubahan dalam nilai itu sendiri - anda hanya mendapat hasil yang telah siap. Perkara ini diterangkan hanya dalam beberapa baris dalam fail 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
Di sini sensor.water_meter_cold ialah nilai semasa meter dalam liter yang saya dapat oleh mqtt. Reka bentuk mencipta 2 sensor baharu water_cold_hour_um dan water_cold_day_um, yang terkumpul bacaan setiap jam dan harian, menetapkannya semula kepada sifar selepas satu tempoh. Berikut ialah graf bateri setiap jam untuk setengah hari.
Kod carta setiap jam dan harian untuk lovelace-UI kelihatan seperti ini:
- 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
Sebenarnya, dalam algoritma ini terletak masalah pendekatan ini. Seperti yang telah saya nyatakan, untuk setiap nilai masuk (bacaan meter semasa untuk setiap liter seterusnya), 1kb rekod dijana dalam pangkalan data. Setiap meter utiliti juga menjana nilai baharu, yang turut ditambah pada pangkalan. Jika saya ingin mengumpul bacaan setiap jam/harian/mingguan/bulanan, ya, untuk beberapa penaik air, dan juga menambah satu pek meter elektrik, ini akan menjadi banyak data. Lebih tepat lagi, tidak ada banyak data, tetapi sejak pembantu rumah menulis sekumpulan maklumat yang tidak diperlukan ke pangkalan data, saiz pangkalan data akan berkembang dengan pesat. Saya juga takut untuk menganggarkan saiz asas untuk carta mingguan dan bulanan.
Di samping itu, meter utiliti itu sendiri tidak menyelesaikan masalah. Plot meter utiliti ialah fungsi yang meningkat secara monoton yang ditetapkan semula kepada 0 setiap jam. Kami juga memerlukan jadual penggunaan yang mesra pengguna, berapa liter yang dimakan dalam tempoh tersebut. Komponen graf sejarah standard tidak melakukan ini, tetapi komponen kad graf mini luaran boleh membantu kami.
Ini ialah kod kad untuk 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'Selain tetapan standard seperti nama penderia, jenis graf, warna (saya tidak suka oren standard), adalah penting untuk ambil perhatian 3 tetapan di sini:
- group_by:hour - carta akan dijana dengan lajur yang sejajar dengan permulaan jam
- mata_sejam: 1 - satu bar sejam
- Dan yang paling penting, aggregate_func: max ialah mengambil nilai maksimum dalam setiap jam. Parameter inilah yang menjadikan carta gigi gergaji menjadi bar.
Jangan perhatikan baris lajur di sebelah kiri - ini adalah kelakuan standard komponen jika tiada data. Tetapi tiada data - saya hanya menghidupkan pengumpulan data menggunakan meter utiliti beberapa jam yang lalu hanya demi artikel ini (saya akan menerangkan pendekatan semasa saya sedikit lebih rendah).
Dalam gambar ini, saya ingin menunjukkan bahawa kadangkala paparan data juga berfungsi, dan bar benar-benar mencerminkan nilai yang betul. Tetapi bukan itu sahaja. Atas sebab tertentu, lajur yang diserlahkan untuk tempoh dari 11 pagi hingga 12 pagi memaparkan 19 liter, walaupun pada graf bergigi sedikit lebih tinggi untuk tempoh yang sama dari sensor yang sama kita melihat penggunaan 62 liter. Sama ada pepijat atau tangan bengkok. Tetapi saya masih tidak faham mengapa data di sebelah kanan terputus - penggunaan di sana adalah normal, yang juga boleh dilihat daripada graf bergigi.
Secara umum, saya gagal mencapai kebolehpercayaan pendekatan ini - graf hampir selalu menunjukkan sejenis bidaah.
Kod serupa untuk penderia siang hari.
- 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'
Sila ambil perhatian bahawa parameter group_by ditetapkan kepada selang waktu dan parameter points_per_hour mengawal segala-galanya. Dan ini adalah satu lagi masalah dengan komponen ini - points_per_hour berfungsi dengan baik pada carta sejam atau kurang, tetapi menjijikkan pada selang yang lebih besar. Jadi untuk mendapatkan satu lajur dalam satu hari, saya perlu memasukkan nilai 1/24=0.04166666. Saya tidak bercakap tentang carta mingguan dan bulanan.
Pendekatan 2
Semasa masih memikirkan pembantu rumah, saya terjumpa video ini:
Rakan seperjuangan mengumpul data penggunaan daripada beberapa jenis soket Xiaomi. Tugasnya lebih mudah sedikit - hanya memaparkan nilai penggunaan untuk hari ini, semalam dan untuk bulan tersebut. Tiada carta diperlukan.
Mari kita mengetepikan hujah mengenai penyepaduan manual nilai kuasa serta-merta - Saya telah menulis tentang "ketepatan" pendekatan ini di atas. Tidak jelas mengapa dia tidak menggunakan nilai penggunaan terkumpul, yang telah dikumpulkan oleh kedai yang sama. Pada pendapat saya, penyepaduan di dalam kepingan besi akan berfungsi dengan lebih baik.
Daripada video, kami akan mengambil idea mengira penggunaan secara manual untuk satu tempoh. Bagi seorang lelaki, hanya nilai untuk hari ini dan untuk semalam dipertimbangkan, tetapi kami akan pergi lebih jauh dan cuba melukis graf. Intipati kaedah yang dicadangkan dalam kes saya adalah seperti berikut.
Kami akan mencipta nilai pembolehubah_pada_permulaan_jam, di mana kami akan menulis bacaan kaunter semasa
Mengikut pemasa pada penghujung jam (atau pada permulaan jam berikutnya), kami mengira perbezaan antara bacaan semasa dan yang disimpan pada awal jam. Perbezaan ini akan menjadi penggunaan untuk jam semasa - kami akan menyimpan nilai pada sensor, dan pada masa hadapan kami akan membina graf berdasarkan nilai ini.
Anda juga perlu "set semula" nilai pembolehubah_pada_permulaan_jam dengan menulis nilai semasa kaunter di sana.
Semua ini boleh dilakukan dengan baik ... melalui pembantu rumah itu sendiri.
Anda perlu menulis lebih sedikit kod daripada pendekatan sebelumnya. Mari kita mulakan dengan "pembolehubah" ini. Di luar kotak, kami tidak mempunyai entiti "pembolehubah", tetapi anda boleh menggunakan perkhidmatan broker mqtt. Kami akan menghantar nilai ke sana dengan retain=true flag - ini akan menjimatkan nilai di dalam broker, dan ia boleh ditarik keluar pada bila-bila masa, walaupun semasa pembantu rumah dibut semula. Saya membuat kaunter setiap jam dan harian sekaligus.
- 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: lSemua keajaiban berlaku dalam automasi, yang berjalan setiap jam dan setiap malam, masing-masing.
- 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: trueKedua-dua automasi melakukan 2 perkara:
- Kira nilai setiap selang sebagai perbezaan antara nilai mula dan akhir
- Kemas kini nilai asas untuk selang seterusnya
Pembinaan graf dalam kes ini diselesaikan dengan graf sejarah 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_dayIa kelihatan seperti ini:
Pada dasarnya, ini sudah menjadi apa yang anda perlukan. Kelebihan kaedah ini ialah data dijana sekali setiap selang. Itu. sejumlah 24 penyertaan setiap hari untuk carta setiap jam.
Malangnya, ini masih tidak menyelesaikan masalah umum pangkalan yang semakin meningkat. Jika saya mahukan graf penggunaan bulanan, saya perlu menyimpan data sekurang-kurangnya setahun. Dan kerana pembantu rumah hanya menyediakan satu tetapan tempoh storan untuk keseluruhan pangkalan data, ini bermakna SEMUA data dalam sistem perlu disimpan selama setahun penuh. Sebagai contoh, dalam setahun saya menggunakan 200 meter padu air, bermakna 200000 entri dalam pangkalan data. Dan jika anda mengambil kira sensor lain, maka angka itu menjadi tidak senonoh.
Pendekatan 3
Nasib baik, orang pintar telah menyelesaikan masalah ini dengan menulis pangkalan data InfluxDB. Pangkalan data ini dioptimumkan khas untuk menyimpan data berasaskan masa dan sesuai untuk menyimpan nilai penderia yang berbeza. Sistem ini juga menyediakan bahasa pertanyaan seperti SQL yang membolehkan anda mengekstrak nilai daripada pangkalan data dan kemudian mengagregatkannya dalam pelbagai cara. Akhirnya, data yang berbeza boleh disimpan untuk masa yang berbeza. Contohnya, bacaan yang kerap berubah seperti suhu atau kelembapan boleh disimpan selama beberapa minggu sahaja, manakala bacaan harian penggunaan air boleh disimpan sepanjang tahun.
Selain InfluxDB, orang pintar juga mencipta Grafana, sebuah sistem untuk melukis graf daripada data daripada InfluxDB. Grafana boleh melukis pelbagai jenis carta, menyesuaikannya secara terperinci dan, yang paling penting, carta ini boleh "dipalamkan" ke dalam pembantu rumah lovelace-UI.
mendapat inspirasi ΠΈ . Artikel tersebut menerangkan secara terperinci proses memasang dan menyambungkan InfluxDB dan Grafana kepada pembantu rumah. Saya akan fokus untuk menyelesaikan masalah khusus saya.
Jadi, pertama sekali, mari kita mula menambah nilai kaunter dalam influxDB. Sekeping konfigurasi pembantu rumah (dalam contoh ini, saya akan berseronok bukan sahaja dengan sejuk, tetapi juga dengan air panas):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldMari matikan menyimpan data yang sama ke pangkalan data dalaman pembantu rumah supaya tidak mengembangnya sekali lagi:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldSekarang mari pergi ke konsol InfluxDB dan sediakan pangkalan data kami. Khususnya, anda perlu mengkonfigurasi berapa lama data tertentu akan disimpan. Ini dikawal oleh apa yang dipanggil. dasar pengekalan - ini serupa dengan pangkalan data di dalam pangkalan data utama, dengan setiap pangkalan data dalaman mempunyai tetapan sendiri. Secara lalai, semua data ditambahkan pada dasar pengekalan yang dipanggil autogen, data ini akan disimpan selama seminggu. Saya ingin data setiap jam disimpan selama sebulan, data mingguan selama setahun dan data bulanan tidak pernah dipadamkan sama sekali. Kami akan membuat dasar pengekalan yang sesuai
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 1Sekarang, sebenarnya, helah utama ialah pengagregatan data menggunakan pertanyaan berterusan. Ini ialah mekanisme yang melancarkan pertanyaan secara automatik pada selang waktu tertentu, mengagregatkan data untuk pertanyaan ini dan menambahkan hasil pada nilai baharu. Mari lihat contoh (saya menulis dalam lajur untuk kebolehbacaan, tetapi sebenarnya saya terpaksa memasukkan arahan ini pada satu 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)
ENDPerintah ini:
- Mencipta pertanyaan berterusan bernama cq_water_cold_hourly dalam pangkalan data pembantu rumah
- Pertanyaan akan dilaksanakan setiap jam (masa(1j))
- Pertanyaan akan mengeluarkan semua data daripada measurement'a homeassistant.autogen.l (liter), termasuk bacaan air sejuk dan panas
- Data agregat akan dikumpulkan mengikut entity_id, yang akan mencipta nilai berasingan untuk air sejuk dan panas.
- Memandangkan pembilang liter ialah urutan yang meningkat secara monoton dalam setiap jam, anda perlu mengambil nilai maksimum, jadi pengagregatan akan dijalankan oleh fungsi maks(nilai)
- Nilai baharu akan ditulis kepada homeassistant.month.water_meter_hour di mana bulan ialah nama polisi pengekalan dengan tempoh pengekalan selama sebulan. Selain itu, data mengenai air sejuk dan panas akan ditaburkan ke dalam rekod berasingan dengan entity_id yang sepadan dan nilai dalam medan nilai
Pada waktu malam atau ketika tiada sesiapa di rumah, tiada penggunaan air, dan oleh itu tiada rekod baharu dalam homeassistant.autogen.l sama ada. Untuk mengelakkan nilai hilang dalam pertanyaan biasa, anda boleh menggunakan isian(sebelumnya). Ini akan memaksa InfluxDB menggunakan nilai jam yang lalu.
Malangnya, pertanyaan berterusan mempunyai keistimewaan: helah isi(sebelumnya) tidak berfungsi dan rekod tidak dibuat. Lebih-lebih lagi, ini adalah sejenis masalah yang tidak dapat diatasi, yang . Kami akan menangani masalah ini kemudian, dan biarkan ia diisi(sebelumnya) dalam pertanyaan berterusan - ia tidak mengganggu.
Mari semak apa yang berlaku (sudah tentu, anda perlu menunggu beberapa 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
Ambil perhatian bahawa nilai dalam pangkalan data disimpan dalam UTC, jadi senarai ini berbeza sebanyak 3 jam - nilai 7 pagi dalam output InfluxDB sepadan dengan nilai 10 pagi dalam carta di atas. Juga ambil perhatian bahawa antara 2 dan 5 pagi tiada rekod - ini adalah ciri pertanyaan berterusan.
Seperti yang anda lihat, nilai agregat juga merupakan jujukan yang meningkat secara monoton, hanya entri yang kurang kerap - sekali sejam. Tetapi ini bukan masalah - kita boleh menulis pertanyaan lain yang akan mengekstrak data yang betul untuk carta.
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)Saya akan menguraikan:
- Daripada pangkalan data homeassistant.month.water_meter_hour, kami akan menarik data untuk entity_id='water_meter_cold' untuk hari terakhir (masa >= sekarang() -24j).
- Seperti yang saya nyatakan, beberapa entri mungkin tiada daripada urutan homeassistant.month.water_meter_hour. Kami akan menjana semula data ini dengan menjalankan pertanyaan dengan GROUP BY time(1j). Kali ini, isi (sebelumnya) akan berfungsi dengan betul, menghasilkan data yang hilang (fungsi akan mengambil nilai sebelumnya)
- Perkara yang paling penting dalam pertanyaan ini ialah fungsi perbezaan, yang akan mengira perbezaan antara tanda jam. Dengan sendirinya, ia tidak berfungsi dan memerlukan fungsi pengagregatan. Biarkan ini menjadi max() yang digunakan sebelum ini.
Keputusan pelaksanaan kelihatan seperti ini
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 72Dari 2 pagi hingga 5 pagi (UTC) tiada penggunaan. Namun begitu, pertanyaan akan mengembalikan nilai penggunaan yang sama terima kasih kepada isi(sebelumnya), dan fungsi perbezaan akan menolak nilai ini daripada dirinya sendiri dan mendapat 0 pada output, yang sebenarnya diperlukan.
Satu-satunya perkara yang perlu dilakukan ialah membina graf. Untuk melakukan ini, buka Grafana, buka beberapa papan pemuka sedia ada (atau buat baharu), buat panel baharu. Tetapan carta adalah seperti berikut.
Saya akan memaparkan data air sejuk dan panas pada graf yang sama. Permintaan adalah sama seperti yang saya nyatakan di atas.
Parameter paparan ditetapkan seperti berikut. Bagi saya ia akan menjadi graf dengan garisan (garisan), yang berjalan dalam langkah (tangga). Parameter Stack akan diterangkan di bawah. Terdapat beberapa lagi pilihan paparan di bawah, tetapi ia tidak begitu menarik.
Untuk menambah graf yang terhasil pada pembantu rumah, anda perlu:
- keluar daripada mod penyuntingan carta. Atas sebab tertentu, tetapan perkongsian carta yang betul ditawarkan hanya dari halaman papan pemuka
- Klik pada segi tiga di sebelah nama carta, pilih kongsi daripada menu
- Dalam tetingkap yang terbuka, pergi ke tab benam
- Nyahtanda julat masa semasa - kami akan menetapkan julat masa melalui URL
- Pilih topik yang diperlukan. Dalam kes saya ia adalah ringan
- Salin URL yang terhasil ke kad tetapan 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"
Sila ambil perhatian bahawa julat masa (2 hari lepas) ditetapkan di sini dan bukan dalam tetapan papan pemuka.
Carta kelihatan seperti ini. Saya tidak menggunakan air panas sejak 2 hari yang lalu, jadi hanya graf air sejuk yang dilukis.
Saya belum memutuskan sendiri carta yang paling saya suka, garis langkah atau bar sebenar. Oleh itu, saya hanya akan memberikan contoh jadual penggunaan harian, hanya kali ini dalam bar. Pertanyaan dibina dengan cara yang sama seperti yang diterangkan di atas. Pilihan paparan ialah:
Carta ini kelihatan seperti ini:
Jadi, mengenai parameter Stack. Dalam graf ini, bar air sejuk dilukis di atas bar panas. Jumlah ketinggian sepadan dengan jumlah penggunaan air sejuk dan panas untuk tempoh tersebut.
Semua graf yang ditunjukkan adalah dinamik. Anda boleh menggerakkan tetikus ke atas tempat menarik dan melihat butiran dan nilai pada titik tertentu.
Malangnya, ia bukan tanpa beberapa lalat dalam salap. Pada carta bar (tidak seperti graf dengan garis langkah), bahagian tengah bar tidak berada di tengah hari, tetapi pada 00:00. Itu. separuh kiri palang dilukis menggantikan hari sebelumnya. Jadi carta untuk Sabtu dan Ahad dilukis sedikit ke kiri zon kebiruan. Sehingga saya tahu bagaimana untuk memenanginya.
Masalah lain ialah ketidakupayaan untuk bekerja dengan betul dengan selang bulanan. Hakikatnya ialah tempoh jam / hari / minggu adalah tetap, tetapi tempoh bulan berbeza setiap masa. InfluxDB hanya boleh berfungsi dengan selang yang sama. Setakat ini, otak saya sudah cukup untuk menetapkan selang tetap 30 hari. Ya, carta akan terapung sedikit sepanjang tahun dan bar tidak akan sepadan dengan bulan. Tetapi oleh kerana perkara ini menarik bagi saya hanya sebagai meter paparan, saya ok dengan ini.
Saya melihat sekurang-kurangnya dua penyelesaian:
- Untuk mendapat markah pada carta bulanan dan hadkan diri anda kepada carta mingguan. 52 bar mingguan dalam setahun kelihatan cukup bagus
- Pertimbangkan penggunaan bulanan itu sendiri sebagai kaedah No. 2, dan gunakan grafana hanya untuk graf yang cantik. Ia satu penyelesaian yang cukup tepat. Anda juga boleh menindih carta untuk tahun lalu sebagai perbandingan - grafana boleh melakukannya.
Kesimpulan
Saya tidak tahu mengapa, tetapi saya suka carta jenis ini. Mereka menunjukkan bahawa kehidupan sedang berjalan lancar dan segala-galanya berubah. Semalam ada banyak, hari ini ada sedikit, esok ada yang lain. Ia kekal untuk bekerjasama dengan isi rumah mengenai topik penggunaan. Tetapi walaupun dengan selera semasa, hanya angka yang besar dan tidak dapat difahami dalam rang undang-undang sudah bertukar menjadi gambaran penggunaan yang agak mudah difahami.
Walaupun kerjaya saya hampir 20 tahun sebagai pengaturcara, saya boleh dikatakan tidak bersilang dengan pangkalan data. Oleh itu, memasang pangkalan data luaran kelihatan seperti sesuatu yang sangat kabur dan tidak dapat difahami. Segalanya telah berubah - ternyata mengacaukan alat yang sesuai dilakukan dalam beberapa klik, dan dengan alat khusus, tugas merancang menjadi lebih mudah.
Dalam tajuk, saya ada menyebut penggunaan elektrik. Malangnya, pada masa ini saya tidak dapat memberikan sebarang graf. Satu meter SDM120 mati, dan satu lagi buggy apabila diakses melalui Modbus. Walau bagaimanapun, ini tidak menjejaskan topik artikel ini dalam apa jua cara - graf akan dibina dengan cara yang sama seperti untuk air.
Dalam artikel ini, saya telah memberikan pendekatan yang telah saya cuba sendiri. Pasti ada beberapa cara lain untuk mengatur pengumpulan dan visualisasi data yang saya tidak tahu. Beritahu saya mengenainya dalam ulasan, saya akan sangat berminat. Saya akan gembira untuk kritikan membina dan idea-idea baru. Saya harap bahan di atas juga akan membantu seseorang.
Sumber: www.habr.com