ჭკვიანი სახლი: წყლისა და ელექტროენერგიის მოხმარების დიაგრამა სახლის ასისტენტი

ყოველ ჯერზე, როცა ელექტროენერგიის და წყლის საფასურს ვიღებ, მაინტერესებს - მართლა მოიხმარს თუ არა ჩემი ოჯახი ძალიან ბევრს? დიახ, აბაზანაში არის გათბობის იატაკი და ქვაბი, მაგრამ ისინი მუდმივად არ მუშაობენ მეხანძრეებად. ჩვენ, როგორც ჩანს, წყალსაც ვზოგავთ (თუმცა აბაზანაში ჩახშობაც მოგვწონს). რამდენიმე წლის წინ მე უკვე დაკავშირებული წყლის მრიცხველები и ელექტროენერგია ჭკვიან სახლამდე, მაგრამ სწორედ აქ გაჩერდა ყველაფერი. ხელები მოხმარების ანალიზს მხოლოდ ახლა მიაღწიეს, რასაც, ფაქტობრივად, ეს სტატია ეხება.

მე ახლახან გადავედი Home Assistant-ზე, როგორც ჩემი ჭკვიანი სახლის სისტემა. ერთ-ერთი მიზეზი იყო მხოლოდ დიდი რაოდენობით მონაცემების შეგროვების ორგანიზების შესაძლებლობა სხვადასხვა სახის გრაფიკების მოსახერხებელი აგების შესაძლებლობით.

ამ სტატიაში აღწერილი ინფორმაცია ახალი არ არის, ეს ყველაფერი სხვადასხვა სოუსების ქვეშ უკვე აღწერილია ინტერნეტში. მაგრამ თითოეული სტატია, როგორც წესი, აღწერს მხოლოდ ერთ მიდგომას ან ასპექტს. ყველა ეს მიდგომა უნდა შემედარებინა და მე თვითონ ავირჩიე ყველაზე შესაფერისი. სტატია ჯერ კიდევ არ შეიცავს ამომწურავ ინფორმაციას მონაცემთა შეგროვების შესახებ, მაგრამ არის ერთგვარი შეჯამება იმისა, თუ როგორ გავაკეთე ეს. ამიტომ მისასალმებელია კონსტრუქციული კრიტიკა და გაუმჯობესების წინადადებები.

პრობლემის შესახებ განცხადება

ასე რომ, დღევანდელი სავარჯიშოს მიზანია წყლისა და ელექტროენერგიის მოხმარების ლამაზი გრაფიკების მიღება:

• საათობრივად 2 დღის განმავლობაში
• ყოველდღიურად 2 კვირის განმავლობაში
• (სურვილისამებრ) ყოველკვირეულად და ყოველთვიურად

ამაში გარკვეული სირთულეებია:

• სტანდარტული დიაგრამის კომპონენტები, როგორც წესი, საკმაოდ ცუდია. საუკეთესო შემთხვევაში, შეგიძლიათ ააგოთ ხაზოვანი გრაფიკი წერტილების მიხედვით.

  თუ კარგად მოძებნით, შეგიძლიათ იპოვოთ მესამე მხარის კომპონენტები, რომლებიც აფართოებენ სტანდარტული სქემის შესაძლებლობებს. სახლის ასისტენტისთვის, პრინციპში, კარგი და ლამაზი კომპონენტია მინი გრაფიკული ბარათი, მაგრამ ის ასევე გარკვეულწილად შეზღუდულია:

  • ძნელია სვეტების დიაგრამის პარამეტრების დაყენება დიდი ინტერვალებით (ზოლის სიგანე დაყენებულია საათის წილადებში, რაც ნიშნავს, რომ საათზე მეტი ინტერვალები დაყენდება წილადი რიცხვებით)
  • თქვენ არ შეგიძლიათ დაამატოთ სხვადასხვა ერთეულები ერთ გრაფიკზე (მაგალითად, ტემპერატურა და ტენიანობა, ან დააკავშიროთ სვეტოვანი დიაგრამა ხაზთან)
• არა მხოლოდ სახლის ასისტენტი იყენებს ყველაზე პრიმიტიულ 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 მბ-ით. ერთ კვირაში სისტემა ძლივს გადაიქცევა და ერთ თვეში მოკვდება ფლეშ დრაივი (როგორც ტიპიური სახლის ასისტენტის ინსტალაცია Raspberry PI-ზე) და არ შეიძლება იყოს მონაცემთა შენახვის საკითხი მთელი წლის განმავლობაში.

• თუ გაგიმართლათ, თქვენს მრიცხველს შეუძლია დათვალოს მოხმარება. შეგიძლიათ ნებისმიერ დროს დაუკავშირდეთ მრიცხველს და გკითხოთ რა დროზეა დაგროვილი მოხმარების ღირებულება. როგორც წესი, ასეთ შესაძლებლობას იძლევა ყველა ელექტროენერგიის მრიცხველი, რომელსაც აქვს ციფრული ინტერფეისი (RS232/RS485/Modbus/Zigbee).

  უარესი, თუ მოწყობილობას შეუძლია უბრალოდ გაზომოს მყისიერი პარამეტრი (მაგალითად, მყისიერი სიმძლავრე ან დენი), ან უბრალოდ გამოიმუშავებს იმპულსებს ყოველ X ვატ-საათში ან ლიტრში. შემდეგ თქვენ უნდა იფიქროთ იმაზე, თუ როგორ და რასთან უნდა გააერთიანოთ იგი და სად დააგროვოთ ღირებულება. არსებობს შემდეგი ანგარიშის გამოტოვების რისკი რაიმე მიზეზით და სისტემის სიზუსტე მთლიანობაში აჩენს კითხვებს. თქვენ, რა თქმა უნდა, შეგიძლიათ ეს ყველაფერი მიანდოთ ჭკვიან სახლის სისტემას, როგორიცაა სახლის ასისტენტი, მაგრამ არავის გაუუქმებია პუნქტი მონაცემთა ბაზაში ჩანაწერების რაოდენობის შესახებ და გამოკითხვის სენსორები წამში ერთხელ არ იმუშავებს (სახლის ასისტენტის არქიტექტურის შეზღუდვა).

მიდგომა 1

პირველი, ვნახოთ, რა სახლის ასისტენტია მოწოდებული ყუთიდან. მოხმარების გაზომვა გარკვეული პერიოდის განმავლობაში ძალიან მოთხოვნადი ფუნქციაა. რა თქმა უნდა, ის დიდი ხნის წინ განხორციელდა, როგორც სპეციალიზებული კომპონენტი - utility_meter.

კომპონენტის არსი იმაში მდგომარეობს, რომ ის იწყებს შიგნით მიმდინარე_დაგროვილი_მნიშვნელობის ცვლადს და აღადგენს მას განსაზღვრული პერიოდის შემდეგ (საათი/კვირა/თვე). თავად კომპონენტი აკონტროლებს შემომავალ ცვლადს (ერთგვარი სენსორის მნიშვნელობა), ეწერება თავად მნიშვნელობის ცვლილებებს - თქვენ უბრალოდ მიიღებთ დასრულებულ შედეგს. ეს ყველაფერი აღწერილია მხოლოდ რამდენიმე სტრიქონში კონფიგურაციის ფაილში

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

აქ sensor.water_meter_cold არის მრიცხველის მიმდინარე მნიშვნელობა ლიტრებში, რომელსაც მე ვიღებ პირდაპირ რკინისგან mqtt-ით. დიზაინი ქმნის 2 ახალ სენსორს water_cold_hour_um და water_cold_day_um, რომლებიც აგროვებენ საათობრივ და დღიურ მონაცემებს და აბრუნებენ მათ ნულამდე გარკვეული პერიოდის შემდეგ. აქ მოცემულია საათობრივი ბატარეის გრაფიკი ნახევარი დღის განმავლობაში.

საათობრივი და დღიური დიაგრამის კოდი lovelace-UI-სთვის ასე გამოიყურება:

      - 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

სინამდვილეში, ამ ალგორითმში დევს ამ მიდგომის პრობლემა. როგორც უკვე აღვნიშნე, ყოველი შემომავალი მნიშვნელობისთვის (მრიცხველის მიმდინარე მაჩვენებელი ყოველი მომდევნო ლიტრისთვის), მონაცემთა ბაზაში გენერირდება 1 კბ ჩანაწერი. თითოეული კომუნალური მრიცხველი ასევე წარმოქმნის ახალ მნიშვნელობას, რომელიც ასევე ემატება ბაზას. თუ მსურს საათობრივი/დღიური/კვირეული/თვიური მონაცემების შეგროვება, დიახ, რამდენიმე წყლის ამწეებისთვის და თუნდაც დავამატო ელექტრო მრიცხველების შეკვრა, ეს იქნება ბევრი მონაცემი. უფრო ზუსტად, ბევრი მონაცემი არ არის, მაგრამ რადგან სახლის ასისტენტი წერს არასაჭირო ინფორმაციის თაიგულს მონაცემთა ბაზაში, მონაცემთა ბაზის ზომა გაიზრდება ნახტომებით და საზღვრებით. მე კი მეშინია ყოველკვირეული და ყოველთვიური სქემებისთვის ბაზის ზომის შეფასება.

გარდა ამისა, კომუნალური მრიცხველი თავად არ წყვეტს პრობლემას. სასარგებლო მრიცხველის დიაგრამა არის მონოტონურად მზარდი ფუნქცია, რომელიც აღდგება 0-მდე ყოველ საათში. ჩვენ ასევე გვჭირდება მომხმარებლისთვის მოსახერხებელი მოხმარების გრაფიკი, რამდენი ლიტრი შეჭამეს პერიოდში. სტანდარტული ისტორია-გრაფიკის კომპონენტი ამას არ აკეთებს, მაგრამ გარე მინი-გრაფიკული ბარათის კომპონენტი დაგვეხმარება.

ეს არის ბარათის კოდი 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'

სტანდარტული პარამეტრების გარდა, როგორიცაა სენსორის სახელი, გრაფიკის ტიპი, ფერი (მე არ მომეწონა სტანდარტული ნარინჯისფერი), აქ მნიშვნელოვანია აღინიშნოს 3 პარამეტრი:

• group_by:hour - დიაგრამა გენერირებული იქნება სვეტებით, რომლებიც გასწორებულია საათის დასაწყისში
• ქულა_საათში: 1 - ერთი ბარი საათში
• და რაც მთავარია, aggregate_func: max არის მაქსიმალური მნიშვნელობის მიღება ყოველ საათში. სწორედ ეს პარამეტრი აქცევს ხერხის კბილის დიაგრამას ზოლებად.

ყურადღება არ მიაქციოთ სვეტების რიგს მარცხნივ - ეს არის კომპონენტის სტანდარტული ქცევა, თუ მონაცემები არ არის. მაგრამ მონაცემები არ იყო - მე ჩავრთე მხოლოდ მონაცემთა შეგროვება კომუნალური მრიცხველის გამოყენებით რამდენიმე საათის წინ მხოლოდ ამ სტატიის გულისთვის (მე აღვწერ ჩემს ამჟამინდელ მიდგომას ოდნავ დაბლა).

ამ სურათზე მინდოდა მეჩვენებინა, რომ ზოგჯერ მონაცემთა ჩვენებაც კი მუშაობს და ზოლები ნამდვილად ასახავს სწორ მნიშვნელობებს. მაგრამ ეს ყველაფერი არ არის. რატომღაც, ხაზგასმული სვეტი დილის 11 საათიდან დილის 12 საათამდე პერიოდისთვის აჩვენებს 19 ლიტრს, თუმცა დაკბილულ გრაფიკზე ოდნავ მაღლა იმავე პერიოდისთვის იმავე სენსორიდან ვხედავთ 62 ლიტრს. ან ბუზი ან ხელები კეხიანია. მაგრამ მე მაინც არ მესმის, რატომ გაწყდა მარჯვნივ მონაცემები - მოხმარება იქ ნორმალური იყო, რაც ასევე ჩანს დაკბილული გრაფიკიდან.

ზოგადად, მე ვერ მივაღწიე ამ მიდგომის დამაჯერებლობას - გრაფიკი თითქმის ყოველთვის აჩვენებს რაიმე სახის მწვალებლობას.

მსგავსი კოდი დღის სენსორისთვის.

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

გთხოვთ, გაითვალისწინოთ, რომ group_by პარამეტრი დაყენებულია ინტერვალზე და points_per_hour პარამეტრი ყველაფერს მართავს. და ეს არის კიდევ ერთი პრობლემა ამ კომპონენტთან დაკავშირებით - points_per_hour კარგად მუშაობს ერთი საათის ან ნაკლები გრაფიკით, მაგრამ ამაზრზენად უფრო დიდ ინტერვალებზე. ასე რომ, ერთ დღეში ერთი სვეტის მისაღებად, უნდა შემეტანა მნიშვნელობა 1/24=0.04166666. მე არ ვსაუბრობ ყოველკვირეულ და ყოველთვიურ ჩარტებზე.

მიდგომა 2

ჯერ კიდევ სახლის ასისტენტის გარკვევისას, წავაწყდი ამ ვიდეოს:

ამხანაგი აგროვებს მოხმარების მონაცემებს Xiaomi-ის რამდენიმე ტიპის სოკეტიდან. მისი ამოცანა ცოტა უფრო მარტივია - უბრალოდ აჩვენეთ მოხმარების ღირებულება დღევანდელი, გუშინდელი და თვისთვის. არ არის საჭირო დიაგრამები.

მოდი, თავი დავანებოთ არგუმენტებს მყისიერი სიმძლავრის მნიშვნელობების ხელით ინტეგრაციის შესახებ - მე უკვე დავწერე ზემოთ ამ მიდგომის "სიზუსტის" შესახებ. გაუგებარია, რატომ არ გამოიყენა დაგროვილი მოხმარების ღირებულებები, რომლებიც უკვე აგროვებს იმავე ობიექტს. ჩემი აზრით, რკინის ნაჭრის შიგნით ინტეგრაცია უკეთესად იმუშავებს.

ვიდეოდან ავიღებთ იდეას გარკვეული პერიოდის განმავლობაში მოხმარების ხელით დათვლაზე. კაცისთვის გათვალისწინებულია მხოლოდ დღევანდელი და გუშინდელი მნიშვნელობები, მაგრამ ჩვენ უფრო შორს წავალთ და ვეცდებით დავხატოთ გრაფიკი. შემოთავაზებული მეთოდის არსი ჩემს შემთხვევაში შემდეგია.

ჩვენ შევქმნით ცვლადს value_at_the_beginning_of_hour, რომელშიც ჩავწერთ მიმდინარე მრიცხველს
საათის ბოლოს (ან შემდეგის დასაწყისში) ტაიმერის მიხედვით ვიანგარიშებთ განსხვავებას მიმდინარე წაკითხვასა და საათის დასაწყისში შენახულს შორის. ეს სხვაობა იქნება მიმდინარე საათის მოხმარება - ჩვენ შევინახავთ მნიშვნელობას სენსორზე და მომავალში ამ მნიშვნელობის საფუძველზე ავაშენებთ გრაფიკს.
თქვენ ასევე უნდა „გადატვირთოთ“ ცვლადი value_at_beginning_of_hour იქ მრიცხველის მიმდინარე მნიშვნელობის ჩაწერით.

ეს ყველაფერი შეიძლება გაკეთდეს კარგად ... თავად სახლის ასისტენტის საშუალებით.

თქვენ მოგიწევთ ცოტა მეტი კოდის დაწერა, ვიდრე წინა მიდგომაში. დავიწყოთ ამ „ცვლადებით“. ჩვენ არ გვაქვს „ცვლადი“ ერთეული, მაგრამ შეგიძლიათ ისარგებლოთ mqtt ბროკერის მომსახურებით. ჩვენ გავაგზავნით მნიშვნელობებს იქ retain=true flag-ით - ეს დაზოგავს მნიშვნელობას ბროკერის შიგნით და მისი ამოღება ნებისმიერ დროს შეიძლება, მაშინაც კი, როდესაც სახლის ასისტენტი გადატვირთულია. საათობრივი და ყოველდღიური მრიცხველები ერთდროულად გავაკეთე.

- 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

მთელი ჯადოქრობა ხდება ავტომატიზაციაში, რომელიც მუშაობს ყოველ საათში და ყოველ ღამე, შესაბამისად.

- 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

ორივე ავტომატიზაცია აკეთებს 2 საქმეს:

• გამოთვალეთ მნიშვნელობა თითო ინტერვალზე, როგორც განსხვავება საწყის და დასასრულს შორის
• განაახლეთ საბაზისო მნიშვნელობა შემდეგი ინტერვალისთვის

გრაფიკების აგება ამ შემთხვევაში წყდება ჩვეულებრივი ისტორიის გრაფიკით:

      - 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

ეს ასე გამოიყურება:

პრინციპში, ეს უკვე გჭირდებათ. ამ მეთოდის უპირატესობა ის არის, რომ მონაცემები გენერირდება ერთხელ ინტერვალში. იმათ. სულ 24 ჩანაწერი დღეში საათობრივი გრაფიკისთვის.

სამწუხაროდ, ეს ჯერ კიდევ არ წყვეტს მზარდი ბაზის ზოგად პრობლემას. თუ ყოველთვიური მოხმარების გრაფიკი მინდა, მონაცემების შენახვა ერთი წელი მაინც მომიწევს. და რადგან სახლის ასისტენტი უზრუნველყოფს მხოლოდ ერთი შენახვის ხანგრძლივობის პარამეტრს მთელი მონაცემთა ბაზისთვის, ეს ნიშნავს, რომ სისტემაში ყველა მონაცემი უნდა იყოს შენახული მთელი წლის განმავლობაში. მაგალითად, წელიწადში 200 კუბურ მეტრ წყალს ვხმარობ, რაც ნიშნავს 200000 XNUMX ჩანაწერს მონაცემთა ბაზაში. და თუ გაითვალისწინებთ სხვა სენსორებს, მაშინ ფიგურა ხდება ზოგადად უხამსი.

მიდგომა 3

საბედნიეროდ, ჭკვიანმა ადამიანებმა უკვე გადაჭრეს ეს პრობლემა InfluxDB მონაცემთა ბაზის დაწერით. ეს მონაცემთა ბაზა სპეციალურად ოპტიმიზებულია დროზე დაფუძნებული მონაცემების შესანახად და იდეალურია სხვადასხვა სენსორების მნიშვნელობების შესანახად. სისტემა ასევე გთავაზობთ SQL-ის მსგავს შეკითხვის ენას, რომელიც საშუალებას გაძლევთ ამოიღოთ მნიშვნელობები მონაცემთა ბაზიდან და შემდეგ დააგროვოთ ისინი სხვადასხვა გზით. და ბოლოს, სხვადასხვა მონაცემების შენახვა შესაძლებელია სხვადასხვა დროს. მაგალითად, ხშირად ცვალებადი მაჩვენებლები, როგორიცაა ტემპერატურა ან ტენიანობა, შეიძლება შენახული იყოს მხოლოდ რამდენიმე კვირის განმავლობაში, ხოლო წყლის მოხმარების ყოველდღიური მონაცემების შენახვა შესაძლებელია მთელი წლის განმავლობაში.

InfluxDB-ის გარდა, ჭკვიანმა ადამიანებმა ასევე გამოიგონეს Grafana, სისტემა, რომელიც ასახავს გრაფიკებს InfluxDB-ის მონაცემებიდან. Grafana-ს შეუძლია სხვადასხვა ტიპის სქემების დახატვა, მათი დეტალურად მორგება და, რაც მთავარია, ეს სქემები შეიძლება „ჩაერთოს“ lovelace-UI სახლის ასისტენტში.

იყოს შთაგონებული აქ и აქ. სტატიები დეტალურად აღწერს InfluxDB-ისა და Grafana-ს სახლის ასისტენტთან ინსტალაციისა და დაკავშირების პროცესს. ყურადღებას გავამახვილებ ჩემი კონკრეტული პრობლემის მოგვარებაზე.

ასე რომ, პირველ რიგში, დავიწყოთ influxDB-ში მრიცხველის დამატება. სახლის ასისტენტის კონფიგურაციის ნაწილი (ამ მაგალითში გავერთობი არა მხოლოდ ცივი, არამედ ცხელი წყლით):

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

მოდით გამორთოთ იგივე მონაცემების შენახვა სახლის ასისტენტის შიდა მონაცემთა ბაზაში, რათა კიდევ ერთხელ არ გავბეროთ:

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

მოდით ახლა გადავიდეთ InfluxDB კონსოლზე და დავაყენოთ ჩვენი მონაცემთა ბაზა. კერძოდ, თქვენ უნდა დააკონფიგურიროთ, რამდენ ხანს შეინახება გარკვეული მონაცემები. ამას არეგულირებს ე.წ. შენახვის პოლიტიკა - ეს არის მონაცემთა ბაზების მსგავსი ძირითადი მონაცემთა ბაზაში, თითოეულ შიდა მონაცემთა ბაზას აქვს საკუთარი პარამეტრები. ნაგულისხმევად, ყველა მონაცემი ემატება შენახვის პოლიტიკას, რომელსაც ეწოდება autogen, ეს მონაცემები შეინახება ერთი კვირის განმავლობაში. მსურს საათობრივი მონაცემების შენახვა ერთი თვის განმავლობაში, ყოველკვირეული მონაცემები ერთი წლის განმავლობაში და ყოველთვიური მონაცემები საერთოდ არ წაიშალოს. ჩვენ შევქმნით შენარჩუნების შესაბამის პოლიტიკას

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

ახლა, ფაქტობრივად, მთავარი ხრიკი არის მონაცემთა აგრეგაცია უწყვეტი შეკითხვის გამოყენებით. ეს არის მექანიზმი, რომელიც ავტომატურად იწყებს მოთხოვნას მითითებულ ინტერვალებში, აგროვებს ამ მოთხოვნის მონაცემებს და ამატებს შედეგს ახალ მნიშვნელობას. მოდით შევხედოთ მაგალითს (წაკითხვისთვის ვწერ სვეტში, მაგრამ სინამდვილეში ეს ბრძანება ერთ ხაზზე უნდა შემეტანა)

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

ეს ბრძანება:

• ქმნის უწყვეტ მოთხოვნას სახელად cq_water_cold_hourly homeassistant მონაცემთა ბაზაში
• მოთხოვნა შესრულდება ყოველ საათში (დრო (1 სთ))
• მოთხოვნა ამოიღებს ყველა მონაცემს გაზომვებიდან homeassistant.autogen.l (ლიტრი), ცივი და ცხელი წყლის წაკითხვის ჩათვლით
• აგრეგირებული მონაცემები დაჯგუფდება entity_id-ის მიხედვით, რაც შექმნის ცალკეულ მნიშვნელობებს ცივი და ცხელი წყლისთვის.
• ვინაიდან ლიტრების მრიცხველი არის მონოტონურად მზარდი თანმიმდევრობა ყოველ საათში, თქვენ მოგიწევთ მაქსიმალური მნიშვნელობის აღება, ამიტომ აგრეგაცია განხორციელდება max(მნიშვნელობის) ფუნქციით.
• ახალი მნიშვნელობა ჩაიწერება homeassistant.month.water_meter_hour-ში, სადაც თვე არის შენარჩუნების პოლიტიკის სახელი ერთი თვის შენახვის ვადით. გარდა ამისა, ცივ და ცხელ წყალზე მონაცემები გაიფანტება ცალკეულ ჩანაწერებში შესაბამისი entity_id და მნიშვნელობის ველში.

ღამით ან როცა სახლში არავინ არის, წყლის მოხმარება არ არის და შესაბამისად არც homeassistant.autogen.l-ში არის ახალი ჩანაწერები. ნორმალურ შეკითხვებში მნიშვნელობების გამოტოვების თავიდან ასაცილებლად, შეგიძლიათ გამოიყენოთ შევსება (წინა). ეს აიძულებს InfluxDB გამოიყენოს გასული საათის მნიშვნელობა.

სამწუხაროდ, უწყვეტ შეკითხვას აქვს თავისებურება: შევსების (წინა) ხრიკი არ მუშაობს და ჩანაწერები უბრალოდ არ იქმნება. უფრო მეტიც, ეს არის ერთგვარი გადაულახავი პრობლემა, რომელიც წელიწადზე მეტია განიხილება. ამ პრობლემას მოგვიანებით გავუმკლავდებით და უწყვეტი შეკითხვის შევსება(წინა) იყოს იქ - ეს არ ერევა.

მოდით შევამოწმოთ რა მოხდა (რა თქმა უნდა, თქვენ უნდა დაელოდოთ რამდენიმე საათს):

> 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

გაითვალისწინეთ, რომ მონაცემთა ბაზაში არსებული მნიშვნელობები ინახება UTC-ში, ამიტომ ეს სია განსხვავდება 3 საათით - დილის 7 მნიშვნელობები InfluxDB გამომავალში ემთხვევა დილის 10 მნიშვნელობებს ზემოთ მოცემულ დიაგრამებში. ასევე გაითვალისწინეთ, რომ დილის 2-დან 5 საათამდე უბრალოდ ჩანაწერები არ არის - ეს არის უწყვეტი შეკითხვის თვისება.

როგორც ხედავთ, აგრეგირებული მნიშვნელობა ასევე მონოტონურად მზარდი თანმიმდევრობაა, მხოლოდ ჩანაწერები ნაკლებად ხშირია - საათში ერთხელ. მაგრამ ეს არ არის პრობლემა - ჩვენ შეგვიძლია დავწეროთ კიდევ ერთი მოთხოვნა, რომელიც ამოიღებს სწორ მონაცემებს დიაგრამისთვის.

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)

გავშიფრავ:

• homeassistant.month.water_meter_hour მონაცემთა ბაზიდან ჩვენ გამოვიყვანთ მონაცემებს entity_id='water_meter_cold' ბოლო დღისთვის (დრო >= now() -24h).
• როგორც აღვნიშნე, ზოგიერთი ჩანაწერი შეიძლება გამოტოვოს homeassistant.month.water_meter_hour თანმიმდევრობით. ჩვენ განვაახლებთ ამ მონაცემებს შეკითხვის გაშვებით GROUP BY time(1h). ამჯერად, შევსება (წინა) იმუშავებს გამართულად, გამოიმუშავებს გამოტოვებულ მონაცემებს (ფუნქცია მიიღებს წინა მნიშვნელობას)
• ამ შეკითხვაში ყველაზე მნიშვნელოვანი არის განსხვავება ფუნქცია, რომელიც გამოთვლის სხვაობას საათის ნიშნებს შორის. თავისთავად, ის არ მუშაობს და მოითხოვს აგრეგაციის ფუნქციას. დაე ეს იყოს ადრე გამოყენებული max().

შესრულების შედეგი ასე გამოიყურება

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

დილის 2 საათიდან დილის 5 საათამდე (UTC) არ იყო მოხმარება. მიუხედავად ამისა, მოთხოვნა დააბრუნებს იგივე მოხმარების მნიშვნელობას Fill(წინა) წყალობით და განსხვავების ფუნქცია თავის თავს გამოაკლებს ამ მნიშვნელობას და მიიღებს 0-ს გამოსავალზე, რაც რეალურად საჭიროა.

ერთადერთი რაც გასაკეთებელია არის გრაფიკის აგება. ამისათვის გახსენით Grafana, გახსენით არსებული (ან შექმენით ახალი) დაფა, შექმენით ახალი პანელი. დიაგრამის პარამეტრები შემდეგი იქნება.

იმავე გრაფიკზე გამოვაჩენ ცივი და ცხელი წყლის მონაცემებს. მოთხოვნა ზუსტად იგივეა, რაც ზემოთ აღვწერე.

ჩვენების პარამეტრები დაყენებულია შემდეგნაირად. ჩემთვის ეს იქნება გრაფიკი ხაზებით (ხაზებით), რომელიც მიდის ნაბიჯებით (კიბეები). Stack პარამეტრი იქნება ახსნილი ქვემოთ. ქვემოთ მოცემულია კიდევ რამდენიმე ჩვენების ვარიანტი, მაგრამ ისინი არც ისე საინტერესოა.

შედეგად მიღებული დიაგრამის სახლის ასისტენტის დასამატებლად, თქვენ უნდა:

• გამოდით დიაგრამის რედაქტირების რეჟიმიდან. რატომღაც, დიაგრამის გაზიარების სწორი პარამეტრები შემოთავაზებულია მხოლოდ დაფის გვერდიდან
• დააწკაპუნეთ სამკუთხედზე დიაგრამის სახელის გვერდით, აირჩიეთ გაზიარება მენიუდან
• ფანჯარაში, რომელიც იხსნება, გადადით ჩაშენების ჩანართზე
• მოხსენით მონიშვნა მიმდინარე დროის დიაპაზონში - ჩვენ დავაყენებთ დროის დიაპაზონს URL-ის საშუალებით
• აირჩიეთ საჭირო თემა. ჩემს შემთხვევაში მსუბუქია
• დააკოპირეთ მიღებული 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"

გთხოვთ, გაითვალისწინოთ, რომ დროის დიაპაზონი (ბოლო 2 დღე) დაყენებულია აქ და არა დაფის პარამეტრებში.

სქემა ასე გამოიყურება. ბოლო 2 დღეა ცხელი წყალი არ გამომიყენებია, ამიტომ მხოლოდ ცივი წყლის გრაფიკია დახატული.

მე თვითონ არ გადამიწყვეტია რომელი სქემა მომწონს ყველაზე მეტად, საფეხურის ხაზი თუ რეალური ზოლები. ამიტომ, მე უბრალოდ მაგალითს მოვიყვან ყოველდღიური მოხმარების განრიგს, მხოლოდ ამჯერად ბარებში. მოთხოვნები აგებულია ისევე, როგორც ზემოთ აღწერილი. ჩვენების ვარიანტებია:

ეს სქემა ასე გამოიყურება:

ასე რომ, Stack პარამეტრის შესახებ. ამ დიაგრამაში ცხელი ზოლის თავზე ცივი წყლის ზოლი არის დახატული. მთლიანი სიმაღლე შეესაბამება ამ პერიოდის განმავლობაში ცივი და ცხელი წყლის მთლიან მოხმარებას.

ყველა ნაჩვენები გრაფიკი დინამიურია. შეგიძლიათ მაუსის გადატანა საინტერესო წერტილზე და ნახოთ დეტალები და მნიშვნელობა კონკრეტულ წერტილში.

სამწუხაროდ, ეს არ იყო რამდენიმე ბუზის გარეშე მალამოში. ზოლიანი დიაგრამაზე (განსხვავებით გრაფიკისგან საფეხურების ხაზებით), ზოლის შუა არის არა დღის შუაში, არამედ 00:00 საათზე. იმათ. ზოლის მარცხენა ნახევარი შედგენილია წინა დღის ადგილზე. ასე რომ, შაბათისა და კვირის სქემები დახატულია მოლურჯო ზონიდან ოდნავ მარცხნივ. სანამ არ გავარკვიე, როგორ მოვიგო.

კიდევ ერთი პრობლემაა ყოველთვიური ინტერვალებით სწორად მუშაობის შეუძლებლობა. ფაქტია, რომ საათის/დღე/კვირის ხანგრძლივობა ფიქსირდება, მაგრამ თვის ხანგრძლივობა ყოველ ჯერზე განსხვავებულია. InfluxDB მუშაობს მხოლოდ თანაბარი ინტერვალებით. აქამდე ჩემი ტვინი საკმარისი იყო 30 დღის ფიქსირებული ინტერვალის დასაყენებლად. დიახ, ჩარტში წლის განმავლობაში ოდნავ ცურავს და ზოლები ზუსტად არ შეესაბამება თვეებს. მაგრამ რადგან ეს ნივთი ჩემთვის საინტერესოა, როგორც ჩვენების მრიცხველი, მე კარგად ვარ ამით.

მე ვხედავ მინიმუმ ორ გამოსავალს:

• ყოველთვიურ ჩარტებზე ქულების მოპოვება და ყოველკვირეულით შეზღუდვა. წელიწადში 52 ყოველკვირეული ბარი საკმაოდ კარგად გამოიყურება
• განიხილეთ თვით თვიური მოხმარება, როგორც მეთოდი No2 და გამოიყენეთ გრანა მხოლოდ ლამაზი გრაფიკებისთვის. საკმაოდ ზუსტი გამოსავალია. შედარებისთვის შეგიძლიათ გასული წლის დიაგრამების გადაფარვაც კი - grafana-ს შეუძლია ამის გაკეთება.

დასკვნა

არ ვიცი რატომ, მაგრამ მე მიყვარს ასეთი ჩარტები. ისინი აჩვენებენ, რომ ცხოვრება გაჩაღდა და ყველაფერი იცვლება. გუშინ ბევრი იყო, დღეს ცოტაა, ხვალ სხვა იქნება. რჩება ოჯახებთან მუშაობა მოხმარების თემაზე. მაგრამ ამჟამინდელი მადის პირობებშიც კი, კანონპროექტში მხოლოდ დიდი და გაუგებარი ფიგურა უკვე იქცევა მოხმარების საკმაოდ გასაგებ სურათად.

მიუხედავად ჩემი თითქმის 20 წლიანი პროგრამისტის კარიერისა, მე პრაქტიკულად არ ვკვეთავდი მონაცემთა ბაზებს. მაშასადამე, გარე მონაცემთა ბაზის დაყენება ისეთი აბსტრაქტული და გაუგებარი ჩანდა. Ყველაფერი შეიცვალა ზემოხსენებული სტატია - აღმოჩნდა, რომ შესაფერისი ხელსაწყოს ხრახნი კეთდება რამდენიმე დაწკაპუნებით და სპეციალიზებული ხელსაწყოს საშუალებით, შედგენის ამოცანა ცოტათი ადვილი ხდება.

სათაურში ვახსენე ელექტროენერგიის მოხმარება. სამწუხაროდ, ამ მომენტში ვერანაირი გრაფიკი ვერ მოგაწოდებთ. ერთი SDM120 მეტრი მკვდარია, მეორე კი ბუგირებულია Modbus-ით წვდომისას. თუმცა, ეს არანაირად არ იმოქმედებს ამ სტატიის თემაზე - გრაფიკები აშენდება ისე, როგორც წყლისთვის.

ამ სტატიაში მე მივეცი ის მიდგომები, რომლებიც მე თვითონ გამოვცადე. რა თქმა უნდა, არსებობს მონაცემების შეგროვებისა და ვიზუალიზაციის ორგანიზების სხვა გზები, რომელთა შესახებ არ ვიცი. მითხარით ამის შესახებ კომენტარებში, ძალიან დამაინტერესებს. მოხარული ვიქნები კონსტრუქციული კრიტიკით და ახალი იდეებით. იმედი მაქვს ზემოაღნიშნული მასალაც დაეხმარება ვინმეს.

წყარო: www.habr.com