Get best of the week

Smart Home: Membangun Grafik Air dan Listrik di Home Assistant


Setiap kali saya menerima tagihan untuk listrik dan air, saya bertanya-tanya - apakah keluarga saya benar-benar mengkonsumsi begitu banyak? Ya, kamar mandi memiliki lantai berpemanas dan ketel, tetapi mereka tidak terus menyala. Kami juga tampaknya menghemat air (meskipun kami juga suka cipratan di kamar mandi). Beberapa tahun yang lalu, saya sudah menghubungkan meter air dan listrik ke rumah pintar, tapi ini macet. Tangan sampai pada analisis konsumsi hanya sekarang, tentang yang, pada kenyataannya, artikel ini tentang.

Saya baru saja beralih ke Home Assistant sebagai sistem rumah pintar. Salah satu alasannya adalah hanya kesempatan untuk mengatur pengumpulan sejumlah besar data dengan kemungkinan membangun 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 menggambarkan satu pendekatan atau aspek. Saya harus membandingkan semua pendekatan ini dan memilih sendiri yang paling cocok. Artikel itu masih tidak memberikan informasi yang komprehensif tentang pengumpulan data, tetapi ini adalah semacam sinopsis tentang bagaimana saya melakukannya. Jadi kritik konstruktif dan saran untuk perbaikan dipersilahkan.

Perumusan 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

Di sinilah beberapa kesulitan menunggu kita:

  • , , . .

    , , . home assistant, , mini-graph-card, :

    • ( , )
    • ( , )
  • , home assistant SQLite ( , , MySQL Postgres), . , , json

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

    ( , ), . SDM220 10-15 , 8. , . .. 100-200 . , ( home assistant raspberry PI), .
  • , . . (RS232/RS485/Modbus/Zigbee) .

    ( ), X - . . , . , , home assistant, , ( home assistant).

1


Pertama, mari kita lihat apa yang asisten rumah disediakan di luar kotak. Mengukur konsumsi selama periode adalah fungsi yang sangat dituntut. Tentu saja, itu direalisasikan sejak lama dalam bentuk komponen khusus - utility_meter.

Inti dari komponen adalah bahwa di dalamnya dimulai variabel current_accumulated_value, dan ulang setelah periode tertentu (jam / minggu / bulan). Komponen itu sendiri memonitor variabel yang masuk (nilai semacam sensor), berlangganan perubahan nilai itu sendiri - Anda baru saja mendapatkan hasil yang selesai. 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 saat ini dari penghitung dalam liter, yang saya dapatkan langsung dari potongan besi oleh mqtt. Desain menciptakan 2 sensor baru water_cold_hour_um dan water_cold_day_um, yang mengakumulasikan pembacaan setiap jam dan harian, mengatur ulang mereka setelah suatu periode. Berikut bagan baterai setengah jam.

gambar

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, masalah dari pendekatan ini terletak pada algoritma ini. Seperti yang saya sebutkan, untuk setiap nilai input (pembacaan meter saat ini untuk setiap liter berikutnya), catatan 1kb dihasilkan dalam database. Setiap meteran utilitas juga menghasilkan nilai baru, yang juga menambahkan hingga ke basis data. Jika saya ingin mengumpulkan bacaan per jam / harian / mingguan / bulanan, dan untuk beberapa penambah air, dan bahkan menambahkan banyak meter listrik - ini akan banyak data. Yah, lebih tepatnya, tidak ada banyak data, tetapi karena asisten rumah menulis ke database banyak informasi yang tidak perlu, ukuran database akan tumbuh dengan pesat. Saya takut bahkan untuk memperkirakan ukuran basis untuk grafik mingguan dan bulanan.

Selain itu, meteran utilitas saja tidak menyelesaikan tugas. Grafik nilai yang diberikan meteran utilitas adalah fungsi yang meningkat secara monoton yang diatur ulang ke 0 setiap jam. Kami membutuhkan grafik konsumsi yang ramah pengguna, berapa liter yang dimakan selama periode tersebut. Komponen grafik sejarah standar tidak tahu bagaimana 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 dicatat pengaturan 3:

  • group_by: jam - bagan akan dihasilkan dengan kolom disejajarkan di awal jam
  • points_per_hour: 1 - satu bar untuk setiap jam
  • , aggregate_func: max — .



Jangan memperhatikan sejumlah kolom di sebelah kiri - ini adalah perilaku standar komponen jika tidak ada data. Dan tidak ada data - saya hanya menyalakan pengumpulan data meteran utilitas hanya beberapa jam yang lalu hanya demi artikel ini (saya akan membahas pendekatan saya saat ini nanti).

Dalam gambar ini, saya ingin menunjukkan bahwa kadang-kadang tampilan data berfungsi, dan bilah benar-benar mencerminkan nilai yang benar. Tapi itu belum semuanya. Kolom yang dipilih untuk interval 11 hingga 12 di pagi hari untuk beberapa alasan menampilkan 19 liter, meskipun pada bagan bergigi sedikit lebih tinggi untuk periode yang sama kita melihat konsumsi 62 liter dari sensor yang sama. Baik bug atau tangan bengkok. Tetapi saya tidak mengerti mengapa data di sebelah kanan terputus - konsumsi di sana normal, yang juga terlihat pada jadwal yang sulit.

Secara umum, saya tidak dapat mencapai kredibilitas dari pendekatan ini - grafik hampir selalu menunjukkan semacam bid'ah.

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

Perhatikan bahwa parameter group_by diatur ke interval, dan parameter points_per_hour mengatur semuanya. Dan ini adalah masalah lain dari komponen ini - points_per_hour bekerja dengan baik pada grafik dalam satu jam atau kurang, tetapi menjijikkan pada interval 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


Hanya mencari tahu asisten rumah, saya menemukan video ini di sini:


Seorang teman mengumpulkan data konsumsi dari beberapa jenis outlet Xiaomi. Tugasnya sedikit lebih mudah - hanya menampilkan nilai konsumsi untuk hari ini, kemarin dan bulan ini. Tidak diperlukan jadwal.

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

Dari video, kami mengambil gagasan untuk menghitung konsumsi secara manual untuk periode tersebut. Petani hanya menghitung nilai untuk hari ini dan kemarin, tapi kami akan melangkah lebih jauh dan mencoba menggambar grafik. Inti dari metode yang diusulkan dalam kasus saya adalah sebagai berikut.

  • ___,
  • ( ) . — , .
  • “” ___ .

Semua ini dapat dilakukan melalui ... asisten rumah sendiri.

Anda harus menulis beberapa kode lebih banyak dari pada pendekatan sebelumnya. Untuk memulai, mari kita mulai dari “variabel” ini. Di luar kotak, kami tidak memiliki entitas "variabel", tetapi Anda dapat menggunakan layanan broker mqtt. Kami akan mengirimkan nilai dengan flag retain = true di sana - ini akan menyimpan nilai di dalam broker, dan Anda dapat menariknya kapan saja, bahkan ketika asisten rumah reboot. Saya langsung membuat counter jam dan hari.

- 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 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: true

Kedua otomasi melakukan 2 tindakan:

  • Nilai untuk interval dihitung sebagai perbedaan antara nilai awal dan akhir
  • Perbarui nilai dasar untuk interval berikutnya

Grafik dalam kasus ini dipecahkan oleh grafik sejarah yang 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

Ini terlihat seperti ini:



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

Sayangnya, ini masih tidak menyelesaikan masalah umum dari basis yang berkembang. Jika saya ingin jadwal konsumsi bulanan, saya harus menyimpan data selama setidaknya satu tahun. Dan karena asisten rumah hanya menyediakan satu pengaturan untuk durasi penyimpanan untuk seluruh database, ini berarti bahwa SEMUA data dalam sistem harus disimpan selama satu tahun penuh. Sebagai contoh, selama setahun saya mengonsumsi 200 meter kubik air, yang berarti 200.000 catatan dalam database. Dan jika Anda memperhitungkan sensor lain, angkanya menjadi tidak senonoh sama sekali.

Pendekatan 3


Untungnya, orang pintar sudah menyelesaikan masalah ini dengan menulis basis data InfluxDB. Basis data ini dioptimalkan secara khusus untuk menyimpan data berbasis waktu dan ideal untuk menyimpan nilai sensor yang berbeda. Sistem ini juga menyediakan bahasa query seperti SQL yang memungkinkan Anda memilih nilai dari database, dan kemudian menggabungkannya dengan berbagai cara. Akhirnya, data yang berbeda dapat disimpan pada waktu yang berbeda. Misalnya, bacaan yang sering berubah seperti suhu atau kelembaban dapat disimpan hanya untuk beberapa minggu, sementara bacaan harian konsumsi air dapat disimpan selama setahun penuh.

Selain InfluxDB, orang pintar juga menemukan Grafana, sistem pembuatan bagan berdasarkan data dari InfluxDB. Grafana dapat menggambar berbagai jenis grafik, menyesuaikannya secara rinci, dan, yang paling penting, grafik ini dapat "macet" pada asisten rumah UI-lovelace.

Dapatkan inspirasi di sini dan di sini . Artikel-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

Matikan penyimpanan data yang sama ke database internal asisten rumah agar tidak mengembang lagi:

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

Kami sekarang pergi ke konsol InfluxDB dan mengatur basis data kami. Secara khusus, Anda perlu mengkonfigurasi berapa lama data ini atau itu akan disimpan. Ini diatur oleh yang disebut kebijakan penyimpanan - ini mirip dengan basis data di dalam basis data utama, dengan setiap basis data internal memiliki pengaturannya sendiri. Secara default, semua data disimpan dalam kebijakan retensi yang disebut autogen, data ini akan disimpan selama seminggu. Saya ingin data per jam disimpan selama sebulan, mingguan selama setahun, dan bulanan tidak boleh dihapus sama sekali. Buat kebijakan penyimpanan yang tepat

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

Sekarang, sebenarnya, trik utamanya adalah pengumpulan data menggunakan kueri berkelanjutan. Ini adalah mekanisme yang secara otomatis memulai kueri pada interval yang ditentukan, mengumpulkan data untuk kueri ini, dan menambahkan hasilnya ke nilai baru. Mari kita lihat contoh (saya menulis di kolom agar mudah dibaca, tetapi sebenarnya 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 homeassistant
  • Permintaan akan dieksekusi setiap jam (waktu (1 jam))
  • Permintaan akan mengambil semua data dari pengukuran 'homeassistant.autogen.l (liter), termasuk pembacaan air dingin dan panas
  • Data teragregasi akan dikelompokkan berdasarkan entity_id, yang akan membuat nilai terpisah untuk air dingin dan panas.
  • , max(value)
  • homeassistant.month.water_meter_hour, month retention policy . entity_id value

Di malam hari atau ketika tidak ada orang di rumah tidak ada konsumsi air, dan karenanya tidak ada entri baru di homeassistant.autogen.l juga. Untuk menghindari nilai yang hilang dalam kueri reguler, 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 rekaman tidak dibuat. Selain itu, ini adalah beberapa masalah yang tidak dapat diatasi yang telah dibahas selama lebih dari setahun . Kami akan menangani masalah ini nanti, dan biarkan isi (sebelumnya) dalam kueri terus-menerus - itu 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

Harap dicatat bahwa nilai-nilai dalam database disimpan dalam UTC, oleh karena itu dalam daftar ini mereka berbeda dengan 3 jam - nilai-nilai untuk jam 7 pagi dalam output InfluxDB sesuai dengan nilai-nilai untuk jam 10 pagi dalam grafik di atas. Perhatikan juga bahwa antara 2 dan 5 pagi sama sekali tidak ada catatan - ini adalah fitur yang sama dari permintaan berkelanjutan.

Seperti yang Anda lihat, nilai agregat juga merupakan urutan yang meningkat secara monoton, hanya catatan yang lebih jarang - satu kali per jam. Tapi ini bukan masalah - kita bisa menulis kueri lain yang akan menghasilkan 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 mendekripsi:

  • Dari database homeassistant.month.water_meter_hour, kami mengekstrak data untuk entity_id = 'water_meter_cold' untuk hari terakhir (waktu> = sekarang () -24jam).
  • Seperti yang saya sebutkan dalam urutan homeassistant.month.water_meter_hour beberapa entri mungkin hilang. Kami akan membuat ulang data ini dengan menjalankan kueri dengan GROUP BY time (1h). Pengisian waktu ini (sebelumnya) akan bekerja sesuai kebutuhan, menghasilkan data yang hilang (fungsi akan mengambil nilai sebelumnya)
  • Hal terpenting dalam permintaan ini adalah fungsi perbedaan, yang akan menghitung perbedaan antara tanda jam. Dengan sendirinya, itu tidak berfungsi dan membutuhkan fungsi agregat. Biarkan itu menjadi max () yang digunakan sebelumnya.

Hasil eksekusi terlihat 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 2 hingga 5 pagi (UTC) tidak ada konsumsi. Namun demikian, kueri akan mengembalikan nilai konsumsi yang sama karena untuk mengisi (sebelumnya), dan fungsi perbedaan akan mengurangi nilai ini dari dirinya sendiri dan kita akan mendapatkan 0 pada output, yang sebenarnya diperlukan.

Satu-satunya yang tersisa adalah membuat jadwal. Untuk melakukan ini, buka Grafana, buka beberapa dasbor yang ada (atau buat baru), buat panel baru. Pengaturan bagan akan seperti ini.



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

Parameter tampilan diatur sebagai berikut. Saya akan memiliki grafik dengan garis, yang berjalan dengan tangga. Saya akan menjelaskan parameter Stack tepat di bawah. Ada beberapa opsi tampilan di bawah ini, tetapi tidak begitu menarik.



Untuk menambahkan jadwal yang diterima ke asisten rumah yang Anda butuhkan:

  • . -
  • , share
  • embed
  • current time range — URL
  • . light
  • URL 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) ditetapkan di sini, dan bukan di pengaturan dasbor.

Grafiknya terlihat seperti ini. Saya belum pernah menggunakan air panas dalam 2 hari terakhir, jadi hanya grafik air dingin yang diambil.



Saya tidak memutuskan sendiri jadwal mana yang paling saya sukai, garis step, atau bar nyata. Karena itu, saya hanya akan memberikan contoh grafik konsumsi harian, hanya kali ini dalam kolom. Permintaan dibangun dengan cara yang sama seperti yang dijelaskan di atas. Parameter tampilan adalah sebagai berikut:



Grafik ini terlihat seperti ini:



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

Semua grafik yang ditampilkan adalah dinamis. Anda dapat mengarahkan mouse ke tempat tujuan dan melihat detail dan nilai pada titik tertentu.

Sayangnya, beberapa sendok tar tidak bisa melakukannya. Pada grafik batang (berbeda dengan grafik dengan garis langkah), bagian tengah batang tidak di tengah hari, tetapi pada pukul 00:00. Itu setengah kiri kolom digambar di tempat hari sebelumnya. Jadi grafik untuk hari Sabtu dan Minggu ditarik sedikit ke kiri daripada zona kebiruan. Sampai saya menemukan cara untuk memenangkannya.

Masalah lain adalah ketidakmampuan untuk bekerja dengan benar pada interval bulanan. Faktanya adalah bahwa panjang jam / hari / minggu adalah tetap, tetapi panjang bulan berbeda setiap kali. InfluxDB hanya dapat bekerja secara berkala. Sejauh ini, otak saya sudah cukup untuk menetapkan interval tetap 30 hari. Ya, grafik akan melayang sedikit sepanjang tahun dan kolom tidak akan persis sesuai dengan bulan. Tapi karena hal ini menarik bagi saya hanya sebagai perangkat layar, maka saya setuju dengan itu.

Saya melihat setidaknya dua solusi:

  • Skor pada jadwal bulanan dan batasi hingga mingguan. 52 bar mingguan untuk tahun ini terlihat cukup bagus
  • №2, . . — .



Saya tidak tahu mengapa, tetapi saya lamban pada jenis grafik seperti itu. Mereka menunjukkan bahwa hidup dalam ayunan penuh dan semuanya berubah. Kemarin banyak, hari ini tidak cukup, besok akan menjadi sesuatu yang lain. Masih bekerja dengan rumah tangga pada topik konsumsi. Tetapi bahkan dengan selera saat ini, hanya angka besar dan tidak bisa dipahami dalam pembayaran sudah berubah menjadi gambaran konsumsi yang cukup jelas.

Meskipun hampir 20 tahun berkarier sebagai programmer, saya praktis tidak bersinggungan dengan database. Oleh karena itu, pemasangan basis data eksternal tampak sangat musykil dan tidak dapat dipahami. Semuanya diubah oleh artikel tersebut - ternyata meniduri alat yang cocok dilakukan dalam beberapa klik, dan dengan alat khusus tugas grafik menjadi sedikit lebih mudah.

Dalam tajuk utama, saya menyebutkan konsumsi listrik. Sayangnya, saat ini saya tidak dapat memberikan grafik tunggal. Satu penghitung SDM120 sudah mati, dan yang lainnya buggy saat mengakses melalui Modbus. Namun, ini tidak mempengaruhi topik artikel ini - grafik akan dibuat dengan cara yang sama seperti untuk air.

Dalam artikel ini, saya mengutip pendekatan yang saya coba sendiri. Tentunya ada beberapa cara lain untuk mengatur pengumpulan dan visualisasi data yang tidak saya ketahui. Ceritakan pada saya di komentar, itu akan sangat menarik bagi saya. Saya akan senang untuk membangun kritik dan ide-ide baru. Saya berharap materi yang disajikan juga akan membantu seseorang.

More articles:


All Articles