سمارټ کور: موږ د کور معاون کې د اوبو او بریښنا مصرف ګرافونه جوړوو

هرکله چې زه د بریښنا او اوبو لپاره پیسې ترلاسه کوم، زه حیران یم - ایا زما کورنۍ واقعیا دومره مصرف کوي؟ ښه، هو، تشناب یو ګرم پوړ او بویلر لري، مګر دوی هر وخت اور نه سوځوي. موږ داسې ښکاري چې اوبه خوندي کوو (که څه هم موږ هم په تشناب کې شاوخوا ویشل خوښوو). څو کاله دمخه زه لا دمخه د اوبو سره نښلول شوي میترونه и بریښنا هوښیار کور ته، مګر دا هغه ځای دی چې شیان ودرول شول. موږ اوس یوازې د مصرف تحلیل ته نږدې شوي یو ، کوم چې دا مقاله واقعیا په اړه ده.

ما پدې وروستیو کې د کور معاون ته زما د سمارټ کور سیسټم په توګه بدل کړ. یو له دلیلونو څخه دقیقا فرصت و چې د ډیری ډیټا راټولولو تنظیم کولو وړتیا سره د مختلف ډوله ګرافونو رامینځته کولو وړتیا سره.

په دې مقاله کې بیان شوي معلومات نوي ندي؛ دا ټول شیان د بیلابیلو ساسونو لاندې دمخه په انټرنیټ کې بیان شوي. مګر هره مقاله معمولا یوازې یو نظر یا اړخ بیانوي. زه باید دا ټولې طریقې پرتله کړم او پخپله ترټولو مناسب انتخاب غوره کړم. مقاله لاهم د معلوماتو راټولولو په اړه هراړخیز معلومات نه ورکوي ، مګر یو ډول لنډیز دی چې ما دا څنګه ترسره کړ. نو د ښه والي لپاره رغنده نیوکې او وړاندیزونه ښه راغلاست دي.

د ستونزې تشکیل

نو، د نن ورځې تمرین موخه دا ده چې د اوبو او بریښنا مصرف ښکلي ګرافونه ترلاسه کړئ:

• په ساعت کې د 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 MB ته لوړ کړي. په یوه اونۍ کې به سیسټم په سختۍ سره حرکت وکړي ، او په یوه میاشت کې به فلش ډرایو مړ شي (په راسبیري PI کې د کور د ځانګړي معاون نصب کولو په حالت کې) ، او د ټول کال لپاره د معلوماتو ذخیره کول له پوښتنې څخه بهر دي.

• که تاسو خوشحاله یاست، ستاسو میټر کولی شي پخپله مصرف حساب کړي. تاسو کولی شئ هر وخت میټر ته وګرځئ او پوښتنه وکړئ چې د مصرف شوي مصرف ارزښت څه وخت دی. د یوې قاعدې په توګه، ټول بریښنا میټرونه چې ډیجیټل انٹرفیس لري (RS232/RS485/Modbus/Zigbee) دا فرصت چمتو کوي.

  دا بدتر دی که چیرې وسیله په ساده ډول یو څه سمدستي پیرامیټر اندازه کړي (د مثال په توګه ، فوري بریښنا یا اوسني) ، یا په ساده ډول په هر ایکس واټ ساعت یا لیټر کې نبض تولید کړي. بیا تاسو اړتیا لرئ د دې په اړه فکر وکړئ چې څنګه او څه شی سره یوځای کړئ او چیرې ارزښت راټول کړئ. د هر دلیل لپاره د راتلونکي راپور ورکیدو خطر شتون لري، او په ټولیز ډول د سیسټم دقت پوښتنې راپورته کوي. البته تاسو کولی شئ دا ټول د کور اسسټنټ په څیر د سمارټ کور سیسټم ته وسپارئ، مګر هیچا په ډیټابیس کې د ریکارډونو شمیره نه ده رد کړې، او دا به امکان ونلري چې په ثانیه کې له یو ځل څخه زیات د رای ورکولو سینسرونه (a. د کور معاون جوړښت محدودیت).

طریقه 1

لومړی ، راځئ وګورو چې د کور معاون له بکس څخه څه چمتو کوي. د یوې مودې په اوږدو کې د مصرف اندازه کول خورا مطلوب فعالیت دی. البته، دا ډیر وخت دمخه د یوې ځانګړې برخې - utility_meter په بڼه پلي شوی و.

د برخې جوهر دا دی چې دا په داخلي توګه یو متغیر اوسني_accumulated_value رامینځته کوي او د یوې ټاکلې مودې (ساعت/اونیو/میاشتو) وروسته یې بیا تنظیموي. برخه پخپله د ان پټ متغیر نظارت کوي (د ځینې سینسر ارزښت) ، ځان په ارزښت کې بدلونونو ته ګډون کوي ​​- تاسو یوازې پای پایله ترلاسه کوئ. دا شی د ترتیب کولو فایل کې یوازې په څو کرښو کې بیان شوی

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 لخوا. ډیزاین دوه نوي سینسرونه 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

په حقیقت کې، د دې طریقې سره ستونزه پدې الګوریتم کې ده. لکه څنګه چې ما مخکې یادونه وکړه، د هر ان پټ ارزښت لپاره (د هر راتلونکي لیټر لپاره د اوسني میټر لوستل) په ډیټابیس کې 1kb ریکارډونه تولید شوي. هر یوټیلټي میټر هم یو نوی ارزښت تولیدوي، کوم چې په بیس کې هم اضافه کیږي. که زه غواړم چې ساعت/ورځنی/اونیز/میاشتنۍ لوستل راټول کړم، او د څو اوبو رایسرز لپاره، او د بریښنا میټرونو یوه کڅوړه اضافه کړم، دا به ډیر معلومات وي. ښه ، په دقیق ډول ، ډیری ډیټا شتون نلري ، مګر له هغه وخته چې د کور معاون ډیټابیس ته د غیر ضروري معلوماتو یوه ډله لیکي ، د ډیټابیس اندازه به د کود او حد سره وده وکړي. زه ویره لرم چې حتی د اونۍ او میاشتني چارټونو لپاره د بیس اندازه اټکل کړم.

برسېره پر دې، د کارولو میټر پخپله ستونزه نه حل کوي. د یوټیلیټ میټر لخوا تولید شوي ارزښتونو ګراف یو واحد مخ په زیاتیدونکي فعالیت دی چې په هر ساعت کې 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 - ګراف به د ساعت په پیل کې د بارونو سره جوړ شي
• ټکي_per_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'

مهرباني وکړئ په یاد ولرئ چې د ګروپ_بای پیرامیټر وقفې ته ټاکل شوی، او د پوائنټ_per_hour پیرامیټر هرڅه تنظیموي. او پدې کې د دې برخې سره بله ستونزه شتون لري - points_per_hour د یو ساعت یا لږ په چارټونو کې ښه کار کوي ، مګر دا په لویو وقفو کې خوند کوي. نو په یوه ورځ کې د یو کالم ترلاسه کولو لپاره، زه باید 1/24 = 0.04166666 ارزښت داخل کړم. زه حتی د اونۍ او میاشتني چارټونو په اړه خبرې نه کوم.

طریقه 2

پداسې حال کې چې لاهم د کور معاون پوهیدل ، ما پدې ویډیو کې ولیدل:

یو ملګری د Xiaomi ساکټونو ډیری ډولونو څخه د مصرف ډاټا راټولوي. د هغه دنده یو څه ساده ده - په ساده ډول د نن ، پرون او میاشتې لپاره د مصرف ارزښت ښکاره کړئ. هیڅ مهال ویش ته اړتیا نشته.

راځئ چې د سمدستي بریښنا ارزښتونو د لاسي ادغام په اړه بحثونه پریږدو - ما دمخه د دې تګلارې "دقت" په اړه پورته لیکلي. دا روښانه نده چې ولې هغه د مصرف شوي راټول شوي ارزښتونو څخه کار نه دی اخیستی ، کوم چې دمخه د ورته پلورنځی لخوا راټول شوي. زما په اند، د هارډویر دننه ادغام به ښه کار وکړي.

له ویډیو څخه به موږ د یوې مودې په اوږدو کې په لاسي ډول د مصرف شمیرلو نظر واخلو. سړی یوازې د نن او پرون ارزښتونه حسابوي، مګر موږ به نور هم ځو او هڅه به وکړو چې ګراف رسم کړو. زما په قضیه کې د وړاندیز شوي میتود جوهر په لاندې ډول دی.

راځئ چې یو متغیر ارزښت_at_the_beginning_of_hour جوړ کړو، په کوم کې چې موږ به د اوسني میټر لوستل ثبت کړو
د ټایمر په کارولو سره ، د ساعت په پای کې (یا د راتلونکي په پیل کې) موږ د اوسني لوستلو او د ساعت په پیل کې زیرمه شوي ترمینځ توپیر محاسبه کوو. دا توپیر به د اوسني ساعت لپاره مصرف وي - موږ به ارزښت په سینسر کې خوندي کړو، او په راتلونکي کې به د دې ارزښت پراساس یو ګراف جوړ کړو.
تاسو اړتیا لرئ چې د اوسني کاونټر ارزښت په لیکلو سره د ارزښت_at_beginning_of_hour متغیر "ری سیٹ" کړئ.

دا ټول پخپله د کور مرستیال له لارې ترسره کیدی شي.

تاسو باید د تیرې طریقې په پرتله یو څه ډیر کوډ ولیکئ. لومړی، راځئ چې ورته "متغیرونه" جوړ کړو. د بکس څخه بهر موږ "متغیر" وجود نلرو، مګر موږ کولی شو د mqtt بروکر خدمتونه وکاروو. موږ به هلته د ریټین = ریښتیني بیرغ سره ارزښتونه واستوو - دا به د بروکر دننه ارزښت خوندي کړي ، او دا په هر وخت کې له هغه ځایه ایستل کیدی شي ، حتی کله چې د کور معاون ریبوټ شي. ما په یو وخت کې ساعت او ورځنۍ شمیرې جوړې کړې.

- 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

دواړه اتومات دوه کړنې ترسره کوي:

• د وقفې لپاره ارزښت د پیل او پای ارزښتونو ترمنځ توپیر په توګه محاسبه کړئ
• د راتلونکي وقفې لپاره اساس ارزښت تازه کړئ

په دې قضیه کې د ګرافونو جوړول د معمول تاریخ ګراف لخوا حل کیږي:

      - 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 ننوتل. او که تاسو نور سینسرونه په پام کې ونیسئ، نو دا ارقام په عمومي ډول بې رحمه کیږي.

طریقه 3

خوشبختانه ، هوښیار خلکو دمخه دا ستونزه د InfluxDB ډیټابیس لیکلو سره حل کړې. دا ډیټابیس په ځانګړي ډول د وخت پراساس ډیټا ذخیره کولو لپاره غوره شوی او د مختلف سینسرونو ارزښتونو ذخیره کولو لپاره غوره دی. سیسټم د SQL په څیر د پوښتنې ژبه هم چمتو کوي چې تاسو ته اجازه درکوي له ډیټابیس څخه ارزښتونه راوباسئ او بیا یې په بیلابیلو لارو راټول کړئ. په نهایت کې ، مختلف معلومات د مختلف وختونو لپاره زیرمه کیدی شي. د مثال په توګه، د تودوخې یا رطوبت په څیر په مکرر ډول بدلیدل یوازې د څو اونیو لپاره زیرمه کیدی شي ، پداسې حال کې چې د ورځني اوبو مصرف لوستل د ټول کال لپاره زیرمه کیدی شي.

د InfluxDB سربیره، هوښیار خلکو Grafana هم اختراع کړه، د InfluxDB څخه د معلوماتو پراساس د ګرافونو رسم کولو سیسټم. ګرافانا کولی شي مختلف ډوله ګرافونه رسم کړي ، په تفصیل سره یې تنظیم کړي ، او خورا مهم ، دا ګرافونه د 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 کنسول ته لاړ شو او زموږ ډیټابیس تنظیم کړئ. په ځانګړې توګه، تاسو اړتیا لرئ چې تنظیم کړئ چې څومره وخت به ځینې ډاټا ذخیره شي. دا د نامتو لخوا تنظیم کیږي. د ساتلو پالیسي - دا په اصلي ډیټابیس کې ډیټابیس ته ورته دی، هر داخلي ډیټابیس خپل ترتیبات لري. په ډیفالټ کې، ټول معلومات د ساتلو پالیسي کې زیرمه شوي چې د آټوجن په نوم یادیږي؛ دا ډاټا به د یوې اونۍ لپاره زیرمه شي. زه غواړم د ساعت معلومات د یوې میاشتې لپاره وساتل شي، د اونۍ ډاټا د یو کال لپاره وساتل شي، او میاشتني معلومات هیڅکله حذف نشي. راځئ چې د ساتلو مناسبه پالیسي جوړه کړو

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 په نوم دوامداره پوښتنه رامینځته کوي
• غوښتنه به په هر ساعت کې اجرا شي (وخت (1h))
• غوښتنه به د اندازه کولو له homeassistant.autogen.l (لیټرو) څخه ټول معلومات وغورځوي ، پشمول د سړو او ګرمو اوبو لوستل
• راټول شوي معلومات به د entity_id په واسطه ګروپ شي، کوم چې موږ ته د سړو او ګرمو اوبو لپاره جلا ارزښتونه راکوي
• څرنګه چې د لیټر کاونټر د هر ساعت په اوږدو کې یو واحد زیاتیدونکي ترتیب دی، نو دا به اړین وي چې اعظمي ارزښت واخلي، نو راټولول به د فعالیت اعظمي (ارزښت) لخوا ترسره شي.
• نوی ارزښت به 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 ساعتونو لخوا توپیر لري - د InfluxDB محصول کې د 7am ارزښتونه په پورته ګرافونو کې د 10am ارزښتونو سره مطابقت لري. دا هم په یاد ولرئ چې د ماسپښین له 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' لپاره ډاټا استخراج کړو (وخت >= اوس() -24h).
• لکه څنګه چې ما مخکې یادونه وکړه، ځینې ننوتل ممکن د homeassistant.month.water_meter_hour په ترتیب کې ورک وي. موږ به دا ډاټا د GROUP BY وخت (1h) سره د پوښتنې په چلولو سره بیا تولید کړو. دا ځل ډک (پخوانی) به د تمې سره سم کار وکړي، ورک شوي ډاټا تولید کړي (فعالیت به پخوانی ارزښت واخلي)
• په دې غوښتنه کې ترټولو مهم شی د توپیر فعالیت دی، کوم چې به د ساعتونو نښو ترمنځ توپیر محاسبه کړي. دا پخپله کار نه کوي او د راټولولو فعالیت ته اړتیا لري. اجازه راکړئ چې دا اعظمي () وي چې دمخه کارول شوی و.

د اعدام پایله داسې ښکاري

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) هیڅ مصرف نه و. په هرصورت، پوښتنه به د ډکولو (مخکیني) څخه مننه ورته مصرف ارزښت بیرته راستانه کړي، او د توپیر فعالیت به دا ارزښت له ځانه څخه کم کړي او محصول به 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 اونۍ بارونه خورا ښه ښکاري
• میاشتنی مصرف پخپله د میتود نمبر 2 په توګه په پام کې ونیسئ، او یوازې د ښکلي ګرافونو لپاره ګرافانا وکاروئ. دا به خورا دقیق حل وي. تاسو حتی کولی شئ د پرتله کولو لپاره د تیر کال ګرافونه پوښ ​​​​کړئ - ګرافانا دا هم کولی شي.

پایلې

زه نه پوهیږم ولې، مګر زه د دې ډول ګرافونو سره مینه لرم. دوی ښیې چې ژوند په بشپړ ډول روان دی او هرڅه بدلیږي. پرون ډېر وو، نن لږ دي، سبا به بل څه وي. ټول هغه څه چې پاتې دي د مصرف په موضوع کې د کورنۍ غړو سره کار کول دي. مګر حتی د اوسني اشتها سره ، د تادیې سلیپ کې یوازې یو لوی او نه پوهیدونکی شخصیت دمخه د مصرف په کافي پوهیدو وړ عکس بدل شوی.

د پروګرامر په توګه زما د نږدې 20 کلن مسلک سره سره، ما په حقیقت کې د ډیټابیسونو سره هیڅ اړیکه نه درلوده. له همدې امله ، د بهرني ډیټابیس نصب کول داسې بریښي چې یو څه خورا بې بنسټه او د پوهیدو وړ ندي. هر څه بدل کړل پورته مقاله - دا معلومه شوه چې د مناسبې وسیلې ضمیمه کول په څو کلیکونو کې ترسره کیږي، او د یوې ځانګړې وسیلې سره، د چارټونو د جوړولو دنده یو څه اسانه کیږي.

په سرلیک کې ما د بریښنا مصرف یادونه وکړه. له بده مرغه، دا مهال زه نشم کولی کوم ګراف چمتو کړم. یو SDM120 میټر زما لپاره مړ شو، او بل د موډبس له لارې د لاسرسي په وخت کې خراب دی. په هرصورت، دا په هیڅ ډول د دې مقالې موضوع اغیزه نه کوي - ګرافونه به د اوبو په څیر جوړ شي.

پدې مقاله کې ما هغه لارې وړاندې کړې چې ما پخپله هڅه کړې. یقینا د معلوماتو راټولولو او لید تنظیم کولو لپاره ځینې نورې لارې شتون لري چې زه یې په اړه نه پوهیږم. په نظرونو کې یې راته ووایاست، زه به ډیره علاقه ولرم. زه به رغنده انتقاد او نوي نظرونو ته خوشحاله شم. زه امید لرم چې وړاندې شوي مواد به د یو چا سره مرسته وکړي.

سرچینه: www.habr.com