Smart Home: Mencatat Konsumsi Air dan Listrik di Home Assistant

Setiap kali saya menerima pembayaran untuk listrik dan air, saya bertanya-tanya - apakah keluarga saya benar-benar mengkonsumsi begitu banyak? Ya, ada lantai berpemanas dan ketel di kamar mandi, tetapi mereka tidak selalu bekerja sebagai petugas pemadam kebakaran. Kami juga sepertinya hemat air (walaupun kami juga suka cipratan air di kamar mandi). Beberapa tahun yang lalu saya sudah meter air yang terhubung и listrik ke rumah pintar, tapi di sinilah segalanya macet. Tangan baru sampai pada analisis konsumsi, yang sebenarnya adalah tentang artikel ini.

Saya baru-baru ini beralih ke Home Assistant sebagai sistem rumah pintar saya. Salah satu alasannya hanyalah kemampuan untuk mengatur pengumpulan data dalam jumlah besar dengan kemungkinan konstruksi yang nyaman dari berbagai jenis grafik.

Informasi yang dijelaskan dalam artikel ini bukanlah hal baru, semua hal ini dengan saus yang berbeda telah dijelaskan di Internet. Tetapi setiap artikel, sebagai suatu peraturan, hanya menjelaskan satu pendekatan atau aspek. Saya harus membandingkan semua pendekatan ini dan memilih sendiri yang paling cocok. Artikel tersebut masih belum memberikan informasi lengkap tentang pengumpulan data, melainkan semacam ringkasan bagaimana saya melakukannya. Oleh karena itu, kritik dan saran yang membangun untuk perbaikan sangat diharapkan.

Pernyataan masalah

Jadi, tujuan latihan hari ini adalah untuk mendapatkan grafik konsumsi air dan listrik yang indah:

• Setiap jam selama 2 hari
• Setiap hari selama 2 minggu
• (opsional) mingguan dan bulanan

Ada beberapa kesulitan dalam hal ini:

• Komponen bagan standar cenderung sangat buruk. Paling-paling, Anda dapat membuat grafik garis berdasarkan poin.

  Jika Anda mencari dengan baik, Anda dapat menemukan komponen pihak ketiga yang memperluas kemampuan bagan standar. Untuk asisten rumah tangga, pada prinsipnya komponen yang bagus dan cantik kartu grafis mini, tetapi juga agak terbatas:

  • Sulit untuk mengatur parameter grafik batang pada interval yang besar (lebar batang diatur dalam pecahan satu jam, yang berarti bahwa interval yang lebih lama dari satu jam akan diatur dalam angka pecahan)
  • Anda tidak dapat menambahkan entitas yang berbeda ke satu grafik (misalnya, suhu dan kelembapan, atau menggabungkan grafik batang dengan garis)
• Asisten rumah tidak hanya menggunakan database SQLite paling primitif secara default (dan saya, tukang, tidak menguasai penginstalan MySQL atau Postgres), data tidak disimpan dengan cara yang paling optimal. Jadi, misalnya, dengan setiap perubahan dari setiap parameter digital terkecil dari suatu parameter, sebuah json besar berukuran sekitar satu kilobyte ditulis ke 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}}}

  Saya punya cukup banyak sensor (sensor suhu di setiap ruangan, meteran air dan listrik), dan beberapa juga menghasilkan data yang cukup banyak. Misalnya, hanya meteran listrik SDM220 yang menghasilkan sekitar selusin nilai setiap 10-15 detik, dan saya ingin memasang 8 meter seperti itu, dan ada juga sejumlah besar parameter yang dihitung berdasarkan sensor lain. Itu. semua nilai ini dapat dengan mudah mengembang basis data sebesar 100-200 MB setiap hari. Dalam seminggu, sistem hampir tidak akan terlempar dan berputar, dan dalam sebulan flash drive akan mati (dalam kasus instalasi tipikal asisten rumah pada raspberry PI), dan tidak ada pembicaraan tentang menyimpan data selama setahun penuh .

• Jika Anda beruntung, meteran Anda sendiri dapat menghitung konsumsi. Anda dapat menghubungi meteran kapan saja dan menanyakan jam berapa nilai konsumsi yang terakumulasi. Sebagai aturan, semua meteran listrik yang memiliki antarmuka digital (RS232/RS485/Modbus/Zigbee) memberikan kesempatan seperti itu.

  Lebih buruk lagi, jika perangkat hanya dapat mengukur beberapa parameter sesaat (misalnya, daya atau arus sesaat), atau hanya menghasilkan pulsa setiap X watt-jam atau liter. Maka Anda perlu memikirkan bagaimana dan dengan apa mengintegrasikannya dan di mana mengumpulkan nilai. Ada risiko kehilangan laporan berikutnya karena alasan apa pun, dan keakuratan sistem secara keseluruhan menimbulkan pertanyaan. Anda dapat, tentu saja, mempercayakan semua ini ke sistem rumah pintar seperti asisten rumah, tetapi tidak ada yang membatalkan poin tentang jumlah entri dalam database, dan sensor polling lebih dari sekali per detik tidak akan berfungsi (batasan dari arsitektur asisten rumah).

Pendekatan 1

Pertama, mari kita lihat asisten rumah apa yang disediakan di luar kotak. Mengukur konsumsi selama suatu periode adalah fungsi yang sangat diminta. Tentu saja, ini sudah lama diterapkan sebagai komponen khusus - utility_meter.

Inti dari komponen adalah memulai variabel current_accumulated_value di dalam dan meresetnya setelah jangka waktu tertentu (jam/minggu/bulan). Komponen itu sendiri memantau variabel yang masuk (nilai dari beberapa jenis sensor), berlangganan perubahan nilai itu sendiri - Anda baru saja mendapatkan hasil akhir. Hal ini dijelaskan hanya dalam beberapa baris di 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

Di sini sensor.water_meter_cold adalah nilai meteran saat ini dalam liter yang saya dapatkan langsung dari setrika oleh mqtt. Desainnya membuat 2 sensor baru water_cold_hour_um dan water_cold_day_um, yang mengakumulasi pembacaan per jam dan harian, menyetelnya kembali ke nol setelah satu periode. Berikut adalah grafik baterai per jam selama setengah hari.

Kode grafik per jam dan harian untuk lovelace-UI terlihat 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 dari pendekatan ini. Seperti yang sudah saya sebutkan, untuk setiap nilai yang masuk (pembacaan meteran saat ini untuk setiap liter berikutnya), 1kb record dibuat di database. Setiap meter utilitas juga menghasilkan nilai baru, yang juga ditambahkan ke pangkalan. Jika saya ingin mengumpulkan pembacaan per jam/harian/mingguan/bulanan, ya, untuk beberapa anak tangga air, dan bahkan menambahkan satu pak meteran listrik, ini akan menjadi banyak data. Lebih tepatnya, tidak banyak data, tetapi karena asisten rumah menulis banyak informasi yang tidak perlu ke database, ukuran database akan bertambah pesat. Saya bahkan takut memperkirakan ukuran basis untuk grafik mingguan dan bulanan.

Selain itu, meteran listrik itu sendiri tidak menyelesaikan masalah. Plot pengukur utilitas adalah fungsi yang meningkat secara monoton yang disetel ulang ke 0 setiap jam. Kami juga membutuhkan jadwal konsumsi yang ramah pengguna, berapa liter yang dimakan selama periode tersebut. Komponen grafik riwayat standar tidak melakukan ini, tetapi komponen kartu grafik mini eksternal dapat membantu kami.

Ini adalah kode kartu 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 pengaturan standar seperti nama sensor, jenis grafik, warna (saya tidak suka oranye standar), penting untuk mencatat 3 pengaturan di sini:

• group_by:hour - bagan akan dibuat dengan kolom yang disejajarkan dengan awal jam
• poin_per_jam: 1 - satu batang per jam
• Dan yang paling penting, agregat_func: max mengambil nilai maksimum dalam setiap jam. Parameter inilah yang mengubah diagram gigi gergaji menjadi batangan.

Jangan perhatikan deretan kolom di sebelah kiri - ini adalah perilaku standar komponen jika tidak ada data. Tetapi tidak ada data - saya hanya mengaktifkan pengumpulan data menggunakan meteran listrik beberapa jam yang lalu hanya untuk kepentingan artikel ini (saya akan menjelaskan pendekatan saya saat ini sedikit lebih rendah).

Dalam gambar ini, saya ingin menunjukkan bahwa terkadang tampilan data bahkan berfungsi, dan bilah benar-benar mencerminkan nilai yang benar. Tapi itu belum semuanya. Untuk beberapa alasan, kolom yang disorot untuk periode dari 11 pagi hingga 12 pagi menampilkan 19 liter, meskipun pada grafik bergigi sedikit lebih tinggi untuk periode yang sama dari sensor yang sama kami melihat konsumsi 62 liter. Entah serangga atau tangan yang bengkok. Tapi saya masih tidak mengerti mengapa data di sebelah kanan terputus - konsumsi di sana normal, yang juga terlihat dari grafik bergigi.

Secara umum, saya gagal mencapai masuk akal dari pendekatan ini - grafik hampir selalu menunjukkan semacam ajaran sesat.

Kode serupa untuk sensor 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'

Harap perhatikan bahwa parameter group_by disetel ke interval, dan parameter points_per_hour mengatur segalanya. Dan ini adalah masalah lain dengan komponen ini - points_per_hour bekerja dengan baik pada grafik satu jam atau kurang, tetapi menjijikkan pada interval yang lebih besar. Jadi untuk mendapatkan satu kolom dalam satu hari, saya harus memasukkan nilai 1/24=0.04166666. Saya tidak berbicara tentang grafik mingguan dan bulanan.

Pendekatan 2

Saat masih mencari tahu asisten rumah, saya menemukan video ini:

Kawan mengumpulkan data konsumsi dari beberapa jenis soket Xiaomi. Tugasnya sedikit lebih sederhana - cukup tampilkan nilai konsumsi hari ini, kemarin dan sebulan. Tidak diperlukan bagan.

Mari kita kesampingkan argumen tentang integrasi manual nilai daya sesaat - saya sudah menulis tentang "akurasi" pendekatan ini di atas. Tidak jelas mengapa dia tidak menggunakan akumulasi nilai konsumsi yang sudah dikumpulkan oleh outlet yang sama. Menurut saya, integrasi di dalam potongan besi akan bekerja lebih baik.

Dari video tersebut, kita akan mengambil ide menghitung konsumsi secara manual untuk suatu periode. Untuk seorang pria, hanya nilai hari ini dan kemarin yang dipertimbangkan, tetapi kita akan melangkah lebih jauh dan mencoba menggambar grafik. Inti dari metode yang diusulkan dalam kasus saya adalah sebagai berikut.

Kami akan membuat variabel value_at_the_beginning_of_hour, di mana kami akan menulis pembacaan penghitung saat ini
Menurut pengatur waktu di akhir jam (atau di awal jam berikutnya), kami menghitung perbedaan antara pembacaan saat ini dan yang disimpan di awal jam. Perbedaan ini akan menjadi konsumsi untuk jam saat ini - kami akan menyimpan nilainya ke sensor, dan di masa mendatang kami akan membuat grafik berdasarkan nilai ini.
Anda juga perlu "mengatur ulang" variabel value_at_beginning_of_hour dengan menulis nilai counter saat ini di sana.

Semua ini dapat dilakukan dengan baik ... melalui asisten rumah itu sendiri.

Anda harus menulis kode lebih sedikit daripada pendekatan sebelumnya. Mari kita mulai dengan "variabel" ini. Di luar kotak, kami tidak memiliki entitas "variabel", tetapi Anda dapat menggunakan layanan broker mqtt. Kami akan mengirim nilai ke sana dengan flag retain=true - ini akan menyimpan nilai di dalam broker, dan dapat ditarik keluar kapan saja, bahkan saat asisten rumah di-boot ulang. Saya membuat penghitung 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: l

Semua keajaiban terjadi dalam otomatisasi, yang masing-masing berjalan setiap jam dan setiap malam.

- 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

Kedua otomatisasi melakukan 2 hal:

• Hitung nilai per interval sebagai selisih antara nilai awal dan akhir
• Perbarui nilai dasar untuk interval berikutnya

Konstruksi grafik dalam hal ini diselesaikan dengan grafik 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_day

Terlihat seperti ini:

Pada prinsipnya, inilah yang Anda butuhkan. Keuntungan dari metode ini adalah data dihasilkan satu kali per interval. Itu. total 24 entri per hari untuk grafik per jam.

Sayangnya, ini masih belum menyelesaikan masalah umum dari basis yang berkembang. Jika saya ingin grafik konsumsi bulanan, saya harus menyimpan data setidaknya selama satu tahun. Dan karena asisten rumah hanya menyediakan satu pengaturan durasi penyimpanan untuk seluruh database, ini berarti SEMUA data dalam sistem harus disimpan selama satu tahun penuh. Misalnya, dalam setahun saya mengonsumsi 200 meter kubik air, berarti 200000 entri di database. Dan jika Anda memperhitungkan sensor lain, maka angka tersebut secara umum menjadi tidak senonoh.

Pendekatan 3

Untungnya, orang pintar telah menyelesaikan masalah ini dengan menulis database InfluxDB. Basis data ini secara khusus dioptimalkan untuk menyimpan data berbasis waktu dan ideal untuk menyimpan nilai berbagai sensor. Sistem ini juga menyediakan bahasa kueri seperti SQL yang memungkinkan Anda mengekstrak nilai dari database dan kemudian menggabungkannya dengan berbagai cara. Terakhir, data yang berbeda dapat disimpan untuk waktu yang berbeda. Misalnya, pembacaan yang sering berubah seperti suhu atau kelembapan dapat disimpan hanya untuk beberapa minggu, sedangkan pembacaan konsumsi air harian dapat disimpan selama satu tahun penuh.

Selain InfluxDB, orang pintar juga menemukan Grafana, sebuah sistem untuk menggambar grafik dari data dari InfluxDB. Grafana dapat menggambar berbagai jenis bagan, menyesuaikannya secara mendetail, dan yang terpenting, bagan ini dapat "dipasang" ke asisten rumah lovelace-UI.

terinspirasi di sini и di sini. Artikel menjelaskan secara rinci proses menginstal dan menghubungkan InfluxDB dan Grafana ke asisten rumah. Saya akan fokus pada pemecahan masalah spesifik saya.

Jadi, pertama-tama, mari kita mulai menambahkan nilai penghitung di influxDB. Sepotong konfigurasi asisten rumah (dalam contoh ini, saya akan bersenang-senang tidak hanya dengan dingin, 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_cold

Mari matikan menyimpan data yang sama ke database internal asisten rumah agar tidak mengembang sekali lagi:

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

Sekarang mari kita pergi ke konsol InfluxDB dan menyiapkan database kita. Secara khusus, Anda perlu mengonfigurasi berapa lama data tertentu akan disimpan. Ini diatur oleh apa yang disebut. kebijakan penyimpanan - ini mirip dengan database di dalam database utama, dengan setiap database internal memiliki pengaturannya sendiri. Secara default, semua data ditambahkan ke kebijakan penyimpanan yang disebut autogen, data ini akan disimpan selama seminggu. Saya ingin data per jam disimpan selama sebulan, data mingguan selama satu tahun, dan data bulanan tidak pernah dihapus sama sekali. Kami akan membuat kebijakan retensi 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 1

Sebenarnya, trik utamanya adalah agregasi data menggunakan kueri berkelanjutan. Ini adalah mekanisme yang secara otomatis meluncurkan kueri pada interval tertentu, mengumpulkan data untuk kueri ini, dan menambahkan hasilnya ke nilai baru. Mari kita lihat sebuah contoh (saya menulis di kolom agar mudah dibaca, tetapi pada kenyataannya saya harus memasukkan perintah ini dalam 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) 
END

Perintah ini:

• Membuat kueri berkelanjutan bernama cq_water_cold_hourly di database asisten rumah
• Kueri akan dieksekusi setiap jam (time(1h))
• Kueri akan menarik semua data dari measurement'a homeassistant.autogen.l (liter), termasuk pembacaan air dingin dan panas
• Data gabungan akan dikelompokkan berdasarkan entitas_id, yang akan membuat nilai terpisah untuk air dingin dan panas.
• Karena penghitung liter adalah urutan yang meningkat secara monoton dalam setiap jam, Anda perlu mengambil nilai maksimum, sehingga agregasi akan dilakukan oleh fungsi max(value)
• Nilai baru akan ditulis ke homeassistant.month.water_meter_hour dimana month adalah nama kebijakan retensi dengan periode retensi satu bulan. Selain itu, data tentang air dingin dan panas akan tersebar menjadi catatan terpisah dengan entitas_id yang sesuai dan nilai di bidang nilai

Pada malam hari atau saat tidak ada orang di rumah, tidak ada konsumsi air, dan karenanya tidak ada rekor baru di homeassistant.autogen.l juga. Untuk menghindari nilai yang hilang dalam kueri normal, Anda dapat menggunakan isian (sebelumnya). Ini akan memaksa InfluxDB untuk menggunakan nilai jam terakhir.

Sayangnya, kueri berkelanjutan memiliki kekhasan: trik isian (sebelumnya) tidak berfungsi dan catatan tidak dibuat. Selain itu, ini adalah semacam masalah yang tidak dapat diatasi, yaitu telah dibahas selama lebih dari satu tahun. Kami akan menangani masalah ini nanti, dan biarkan isi (sebelumnya) dalam kueri berkelanjutan ada di sana - tidak mengganggu.

Mari kita periksa apa yang terjadi (tentu saja, 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

Perhatikan bahwa nilai dalam database disimpan dalam UTC, jadi daftar ini berbeda 3 jam - nilai jam 7 pagi di keluaran InfluxDB cocok dengan nilai jam 10 pagi di bagan di atas. Perhatikan juga bahwa antara jam 2 dan 5 pagi tidak ada catatan sama sekali - ini adalah fitur kueri berkelanjutan.

Seperti yang Anda lihat, nilai agregat juga merupakan urutan yang meningkat secara monoton, hanya entri yang lebih jarang - satu jam sekali. Tapi ini bukan masalah - kita bisa menulis kueri lain yang akan mengekstrak data yang benar untuk bagan.

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:

• Dari database homeassistant.month.water_meter_hour, kami akan menarik data untuk entitas_id='water_meter_cold' untuk hari terakhir (time >= now() -24h).
• Seperti yang saya sebutkan, beberapa entri mungkin hilang dari urutan homeassistant.month.water_meter_hour. Kami akan membuat ulang data ini dengan menjalankan kueri dengan GROUP BY time(1h). Kali ini, isi(sebelumnya) akan berfungsi dengan baik, menghasilkan data yang hilang (fungsi akan mengambil nilai sebelumnya)
• Hal terpenting dalam kueri ini adalah fungsi perbedaan, yang akan menghitung perbedaan antara tanda jam. Dengan sendirinya, itu tidak berfungsi dan membutuhkan fungsi agregasi. Biarkan ini menjadi max() yang digunakan sebelumnya.

Hasil eksekusinya 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 72

Dari jam 2 pagi sampai jam 5 pagi (UTC) tidak ada konsumsi. Namun demikian, kueri akan mengembalikan nilai konsumsi yang sama berkat isi(sebelumnya), dan fungsi perbedaan akan mengurangi nilai ini dari dirinya sendiri dan mendapatkan 0 pada keluaran, yang sebenarnya diperlukan.

Satu-satunya hal yang tersisa untuk dilakukan adalah membuat grafik. Untuk melakukan ini, buka Grafana, buka beberapa dasbor yang ada (atau buat yang baru), buat panel baru. Pengaturan grafik adalah sebagai berikut.

Saya akan menampilkan data air dingin dan panas pada grafik yang sama. Permintaannya persis sama dengan yang saya jelaskan di atas.

Parameter tampilan diatur sebagai berikut. Bagi saya itu akan menjadi grafik dengan garis (garis), yang berjalan secara bertahap (tangga). Parameter Stack akan dijelaskan di bawah ini. Ada beberapa opsi tampilan lagi di bawah, tetapi tidak begitu menarik.

Untuk menambahkan grafik yang dihasilkan ke asisten rumah, Anda perlu:

• keluar dari mode pengeditan grafik. Untuk beberapa alasan, pengaturan berbagi grafik yang benar hanya ditawarkan dari halaman dasbor
• Klik segitiga di sebelah nama bagan, pilih bagikan dari menu
• Di jendela yang terbuka, buka tab sematan
• Hapus centang rentang waktu saat ini - kami akan mengatur rentang waktu melalui URL
• Pilih topik yang diperlukan. Dalam kasus saya ini ringan
• Salin URL yang dihasilkan ke kartu pengaturan 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"

Harap perhatikan bahwa rentang waktu (2 hari terakhir) diatur di sini, dan bukan di pengaturan dasbor.

Grafiknya terlihat seperti ini. Saya tidak menggunakan air panas dalam 2 hari terakhir, jadi hanya grafik air dingin yang digambar.

Saya belum memutuskan sendiri bagan mana yang paling saya sukai, garis langkah, atau batang nyata. Oleh karena itu, saya hanya akan memberikan contoh jadwal konsumsi harian, kali ini hanya di bar. Kueri dibuat dengan cara yang sama seperti yang dijelaskan di atas. Opsi tampilan adalah:

Bagan ini terlihat seperti ini:

Jadi, tentang parameter Stack. Dalam grafik ini, batang air dingin digambar di atas batang air panas. Tinggi total sesuai dengan total konsumsi air dingin dan panas untuk periode tersebut.

Semua grafik yang ditampilkan bersifat dinamis. Anda dapat menggerakkan mouse ke tempat menarik dan melihat detail dan nilai pada titik tertentu.

Sayangnya, itu bukannya tanpa beberapa lalat di salep. Pada diagram batang (berbeda dengan grafik dengan garis langkah), bagian tengah batang tidak berada di tengah hari, melainkan pada pukul 00:00. Itu. separuh kiri bilah digambar menggantikan hari sebelumnya. Jadi grafik untuk hari Sabtu dan Minggu digambar sedikit ke kiri dari zona kebiruan. Sampai saya menemukan cara untuk memenangkannya.

Masalah lainnya adalah ketidakmampuan untuk bekerja dengan benar dengan interval bulanan. Faktanya adalah panjang jam / hari / minggu tetap, tetapi panjang bulan berbeda setiap saat. InfluxDB hanya dapat bekerja dengan interval yang sama. Sejauh ini, otak saya sudah cukup untuk menetapkan interval tetap 30 hari. Ya, bagan akan mengambang sedikit sepanjang tahun dan batang tidak akan sama persis dengan bulan. Tapi karena hal ini menarik bagi saya hanya sebagai pengukur tampilan, saya setuju dengan ini.

Saya melihat setidaknya dua solusi:

• Untuk mencetak skor pada grafik bulanan dan batasi diri Anda pada grafik mingguan. 52 bar mingguan dalam setahun terlihat cukup bagus
• Pertimbangkan konsumsi bulanan itu sendiri sebagai metode No. 2, dan gunakan grafana hanya untuk grafik yang indah. Ini solusi yang cukup akurat. Anda bahkan dapat melapisi bagan selama setahun terakhir untuk perbandingan - grafana dapat melakukannya.

Kesimpulan

Saya tidak tahu mengapa, tapi saya suka grafik semacam ini. Mereka menunjukkan bahwa hidup berjalan lancar dan segalanya berubah. Kemarin banyak, hari ini sedikit, besok ada lagi. Tetap bekerja dengan rumah tangga tentang topik konsumsi. Tetapi bahkan dengan selera saat ini, angka tagihan yang besar dan tidak dapat dipahami sudah berubah menjadi gambaran konsumsi yang cukup dapat dimengerti.

Meskipun karir saya hampir 20 tahun sebagai programmer, saya praktis tidak bersinggungan dengan database. Oleh karena itu, menginstal database eksternal tampak seperti sesuatu yang sangat rumit dan tidak dapat dipahami. Semuanya telah berubah artikel di atas - ternyata mengacaukan alat yang cocok dilakukan dalam beberapa klik, dan dengan alat khusus, tugas merencanakan menjadi sedikit lebih mudah.

Di judul, saya menyebutkan konsumsi listrik. Sayangnya, saat ini saya tidak dapat memberikan grafik apa pun. Satu meter SDM120 mati, dan satu lagi buggy saat diakses melalui Modbus. Namun, ini sama sekali tidak memengaruhi topik artikel ini - grafik akan dibuat dengan cara yang sama seperti untuk air.

Dalam artikel ini, saya telah memberikan pendekatan yang telah saya coba sendiri. Tentunya ada beberapa cara lain untuk mengatur pengumpulan dan visualisasi data yang belum saya ketahui. Ceritakan tentang itu di komentar, saya akan sangat tertarik. Saya akan senang untuk kritik konstruktif dan ide-ide baru. Saya harap materi di atas juga akan membantu seseorang.

Sumber: www.habr.com