स्मार्ट होम: होम असिस्टंटमध्ये चार्टिंग पाणी आणि विजेचा वापर

प्रत्येक वेळी जेव्हा मला वीज आणि पाण्याचे पेमेंट मिळते तेव्हा मला आश्चर्य वाटते - माझे कुटुंब खरोखरच खूप जास्त वापरते का? ठीक आहे, होय, बाथरूममध्ये गरम मजला आणि बॉयलर आहे, परंतु ते सर्व वेळ फायरमन म्हणून काम करत नाहीत. आम्ही पाणी वाचवतो असे दिसते (जरी आम्हाला बाथरूममध्ये शिंपडणे देखील आवडते). काही वर्षांपूर्वी मी आधीच जोडलेले पाणी मीटर и वीज स्मार्ट घराकडे, पण इथेच गोष्टी अडकल्या. हात आता फक्त उपभोगाच्या विश्लेषणापर्यंत पोहोचले आहेत, ज्याबद्दल हा लेख आहे.

मी अलीकडेच माझी स्मार्ट होम सिस्टम म्हणून होम असिस्टंटवर स्विच केले. विविध प्रकारच्या आलेखांच्या सोयीस्कर बांधकामाच्या शक्यतेसह मोठ्या प्रमाणात डेटाचे संकलन आयोजित करण्याची क्षमता हे एक कारण होते.

या लेखात वर्णन केलेली माहिती नवीन नाही, वेगवेगळ्या सॉस अंतर्गत या सर्व गोष्टी इंटरनेटवर आधीच वर्णन केल्या गेल्या आहेत. परंतु प्रत्येक लेख, एक नियम म्हणून, फक्त एक दृष्टीकोन किंवा पैलू वर्णन करतो. मला या सर्व पद्धतींची तुलना करायची होती आणि स्वतःला सर्वात योग्य पर्याय निवडायचा होता. लेख अद्याप डेटा संकलनावर संपूर्ण माहिती प्रदान करत नाही, परंतु मी ते कसे केले याचा एक प्रकारचा सारांश आहे. त्यामुळे विधायक टीका आणि सुधारणांच्या सूचनांचे स्वागत आहे.

समस्येची निर्मिती

तर, पाणी आणि वीज वापराचे सुंदर आलेख मिळवणे हे आजच्या व्यायामाचे उद्दिष्ट आहे:

• 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 ने डेटाबेस सहज वाढवू शकतात. एका आठवड्यात, सिस्टम फक्त टॉस आणि वळेल आणि एका महिन्यात फ्लॅश ड्राइव्ह मरेल (रास्पबेरी पीआय वर सामान्य होम असिस्टंट इंस्टॉलेशनच्या बाबतीत), आणि संपूर्ण वर्षभर डेटा स्टोरेजचा प्रश्नच उद्भवू शकत नाही.

• तुम्ही भाग्यवान असल्यास, तुमचे मीटर स्वतःच वापर मोजू शकते. तुम्ही मीटरशी कधीही संपर्क साधू शकता आणि जमा केलेले उपभोग मूल्य किती वाजता आहे ते विचारू शकता. नियमानुसार, डिजिटल इंटरफेस असलेले सर्व वीज मीटर (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

वास्तविक, या अल्गोरिदममध्ये या दृष्टिकोनाची समस्या आहे. मी आधीच नमूद केल्याप्रमाणे, प्रत्येक इनकमिंग व्हॅल्यूसाठी (प्रत्येक पुढच्या लिटरसाठी वर्तमान मीटर रीडिंग), डेटाबेसमध्ये 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 - तासाच्या सुरूवातीस संरेखित केलेल्या स्तंभांसह चार्ट तयार केला जाईल
• पॉइंट्स_पर_तास: 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'

कृपया लक्षात घ्या की ग्रुप_बाय पॅरामीटर मध्यांतरावर सेट केले आहे आणि पॉइंट्स_पर_तास पॅरामीटर सर्व गोष्टींवर नियंत्रण ठेवते. आणि ही या घटकाची आणखी एक समस्या आहे - पॉइंट्स_पर_तास एक तास किंवा त्यापेक्षा कमी चार्टवर चांगले कार्य करते, परंतु मोठ्या अंतरावर घृणास्पदपणे. त्यामुळे एका दिवसात एक स्तंभ मिळविण्यासाठी, मला 1/24=0.04166666 मूल्य प्रविष्ट करावे लागेल. मी साप्ताहिक आणि मासिक चार्टबद्दल बोलत नाही.

दृष्टीकोन 2

गृह सहाय्यक शोधत असताना, मला हा व्हिडिओ आला:

कॉम्रेड अनेक प्रकारच्या Xiaomi सॉकेटमधून वापर डेटा संकलित करतो. त्याचे कार्य थोडे सोपे आहे - फक्त आज, काल आणि महिन्यासाठी वापराचे मूल्य प्रदर्शित करा. कोणतेही चार्ट आवश्यक नाहीत.

तात्काळ पॉवर व्हॅल्यूजच्या मॅन्युअल इंटिग्रेशनबद्दलचे युक्तिवाद बाजूला ठेवूया - मी वर या दृष्टिकोनाच्या "अचूकतेबद्दल" आधीच लिहिले आहे. त्याच आउटलेटद्वारे आधीच गोळा केलेली संचित उपभोग मूल्ये त्याने का वापरली नाहीत हे स्पष्ट नाही. माझ्या मते, लोखंडाच्या तुकड्याच्या आत एकत्रीकरण अधिक चांगले कार्य करेल.

व्हिडिओवरून, आम्ही एका कालावधीसाठी स्वहस्ते वापर मोजण्याची कल्पना घेऊ. माणसासाठी, फक्त आजची आणि कालची मूल्ये विचारात घेतली जातात, परंतु आपण पुढे जाऊन आलेख काढण्याचा प्रयत्न करू. माझ्या बाबतीत प्रस्तावित पद्धतीचे सार खालीलप्रमाणे आहे.

आम्ही एक व्हेरिएबल मूल्य_at_the_beginning_of_hour तयार करू, ज्यामध्ये आपण वर्तमान काउंटर रीडिंग लिहू
तासाच्या शेवटी (किंवा पुढच्या सुरूवातीला) टाइमरनुसार, आम्ही सध्याचे वाचन आणि तासाच्या सुरूवातीस संग्रहित केलेले फरक मोजतो. हा फरक सध्याच्या तासासाठी वापर असेल - आम्ही सेन्सरमध्ये मूल्य जतन करू आणि भविष्यात आम्ही या मूल्यावर आधारित आलेख तयार करू.
तुम्हाला तेथे काउंटरचे वर्तमान मूल्य लिहून व्हेरिएबल मूल्य_at_beginning_of_hour देखील "रीसेट" करावे लागेल.

हे सर्व चांगल्या प्रकारे करता येते... गृह सहाय्यकाद्वारेच.

तुम्हाला मागील पद्धतीपेक्षा थोडे अधिक कोड लिहावे लागेल. चला या "व्हेरिएबल्स" सह प्रारंभ करूया. बॉक्सच्या बाहेर, आमच्याकडे "व्हेरिएबल" अस्तित्व नाही, परंतु तुम्ही mqtt ब्रोकरच्या सेवा वापरू शकता. आम्ही तेथे retain=true फ्लॅगसह मूल्ये पाठवू - यामुळे ब्रोकरमधील मूल्य जतन होईल, आणि ते कधीही बाहेर काढले जाऊ शकते, जरी गृह सहाय्यक रीबूट केले तरीही. मी एकाच वेळी ताशी आणि दैनंदिन काउंटर बनवले.

- 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 नोंदी आहेत. आणि जर आपण इतर सेन्सर विचारात घेतले तर आकृती सामान्यतः अशोभनीय बनते.

दृष्टीकोन 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 कन्सोलवर जाऊ आणि आमचा डेटाबेस सेट करू. विशेषतः, आपल्याला विशिष्ट डेटा किती काळ संग्रहित केला जाईल हे कॉन्फिगर करणे आवश्यक आहे. हे तथाकथित द्वारे नियमन केले जाते. धारणा धोरण - हे मुख्य डेटाबेसमधील डेटाबेससारखेच आहे, प्रत्येक अंतर्गत डेटाबेसची स्वतःची सेटिंग्ज आहेत. डीफॉल्टनुसार, सर्व डेटा ऑटोजेन नावाच्या धारणा धोरणामध्ये जोडला जातो, हा डेटा एका आठवड्यासाठी संग्रहित केला जाईल. मला दर तासाचा डेटा एका महिन्यासाठी, साप्ताहिक डेटा एका वर्षासाठी आणि मासिक डेटा कधीही हटवला जाऊ नये असे वाटते. आम्ही योग्य धारणा धोरणे तयार करू

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

ही आज्ञा:

• homeassistant डेटाबेसमध्ये cq_water_cold_hourly नावाची सतत क्वेरी तयार करते
• क्वेरी दर तासाला कार्यान्वित केली जाईल (वेळ(1ता))
• क्वेरी थंड आणि गरम पाण्याच्या रीडिंगसह, मापन'a homeassistant.autogen.l (लिटर) वरून सर्व डेटा काढेल
• एकत्रित डेटा entity_id द्वारे गटबद्ध केला जाईल, जो थंड आणि गरम पाण्यासाठी स्वतंत्र मूल्ये तयार करेल.
• लीटरचा काउंटर हा प्रत्येक तासात नीरसपणे वाढणारा क्रम असल्याने, तुम्हाला कमाल मूल्य घेणे आवश्यक आहे, त्यामुळे एकत्रीकरण कमाल(मूल्य) फंक्शनद्वारे केले जाईल.
• नवीन मूल्य homeassistant.month.water_meter_hour वर लिहिले जाईल जेथे महिना हे एक महिन्याच्या प्रतिधारण कालावधीसह धारणा धोरणाचे नाव आहे. शिवाय, थंड आणि गरम पाण्यावरील डेटा संबंधित entity_id आणि मूल्य फील्डमधील मूल्यासह स्वतंत्र रेकॉर्डमध्ये विखुरला जाईल.

रात्री किंवा घरी कोणी नसताना, पाण्याचा वापर होत नाही आणि त्यानुसार homeassistant.autogen.l मध्ये कोणतेही नवीन रेकॉर्ड नाहीत. सामान्य क्वेरींमध्ये गहाळ मूल्ये टाळण्यासाठी, तुम्ही fill(previous) वापरू शकता. हे 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' साठी डेटा काढू (वेळ >= now() -24h).
• मी नमूद केल्याप्रमाणे, homeassistant.month.water_meter_hour क्रमातून काही नोंदी गहाळ असू शकतात. आम्ही GROUP BY वेळ (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) पर्यंत कोणतेही उपभोग नव्हते. तरीही, क्वेरी भरण्यासाठी (मागील) समान उपभोग मूल्य परत करेल आणि फरक फंक्शन हे मूल्य स्वतःहून वजा करेल आणि आउटपुटवर 0 मिळवेल, जे प्रत्यक्षात आवश्यक आहे.

फक्त एक आलेख तयार करणे बाकी आहे. हे करण्यासाठी, Grafana उघडा, काही विद्यमान (किंवा नवीन तयार करा) डॅशबोर्ड उघडा, एक नवीन पॅनेल तयार करा. चार्ट सेटिंग्ज खालीलप्रमाणे असतील.

मी त्याच आलेखावर थंड आणि गरम पाण्याचा डेटा प्रदर्शित करेन. मी वर वर्णन केल्याप्रमाणे विनंती अगदी तशीच आहे.

डिस्प्ले पॅरामीटर्स खालीलप्रमाणे सेट केले आहेत. माझ्यासाठी तो रेषा (रेषा) असलेला आलेख असेल, जो पायऱ्या (पायऱ्या) मध्ये जातो. स्टॅक पॅरामीटर खाली स्पष्ट केले जाईल. खाली आणखी काही प्रदर्शन पर्याय आहेत, परंतु ते इतके मनोरंजक नाहीत.

परिणामी आलेख होम असिस्टंटमध्ये जोडण्यासाठी, तुम्हाला हे करणे आवश्यक आहे:

• चार्ट संपादन मोडमधून बाहेर पडा. काही कारणास्तव, योग्य चार्ट सामायिकरण सेटिंग्ज फक्त डॅशबोर्ड पृष्ठावरून ऑफर केल्या जातात
• चार्टच्या नावापुढील त्रिकोणावर क्लिक करा, मेनूमधून शेअर निवडा
• उघडणाऱ्या विंडोमध्ये, एम्बेड टॅबवर जा
• वर्तमान वेळ श्रेणी अनचेक करा - आम्ही 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 दिवसात गरम पाणी वापरलेले नाही, त्यामुळे फक्त थंड पाण्याचा आलेख काढला आहे.

मला कोणता चार्ट सर्वात जास्त आवडेल, स्टेप लाइन किंवा रिअल बार हे मी स्वतः ठरवलेले नाही. म्हणून, मी फक्त या वेळी बारमध्ये दररोजच्या वापराच्या वेळापत्रकाचे उदाहरण देईन. वर वर्णन केल्याप्रमाणे क्वेरी तयार केल्या आहेत. प्रदर्शन पर्याय आहेत:

हा चार्ट यासारखा दिसतो:

तर, स्टॅक पॅरामीटर बद्दल. या आलेखामध्ये, गरम पट्टीच्या वर थंड पाण्याची पट्टी काढली आहे. एकूण उंची या कालावधीसाठी थंड आणि गरम पाण्याच्या एकूण वापराशी संबंधित आहे.

दाखवलेले सर्व आलेख डायनॅमिक आहेत. तुम्ही माऊसला रुचीच्या बिंदूवर हलवू शकता आणि विशिष्ट बिंदूवर तपशील आणि मूल्य पाहू शकता.

दुर्दैवाने, ते मलम मध्ये माशी एक दोन न होता. बार चार्टवर (स्टेप लाईन्स असलेल्या आलेखाच्या विपरीत), बारचा मध्य दिवसाच्या मध्यभागी नसून 00:00 वाजता असतो. त्या. बारचा डावा अर्धा भाग मागील दिवसाच्या जागी काढला आहे. त्यामुळे शनिवार आणि रविवारचे तक्ते निळसर झोनच्या थोडे डावीकडे काढले आहेत. ते कसे जिंकायचे हे मला समजेपर्यंत.

दुसरी समस्या मासिक अंतराने योग्यरित्या कार्य करण्यास असमर्थता आहे. वस्तुस्थिती अशी आहे की तास/दिवस/आठवड्याची लांबी ठरलेली असते, परंतु प्रत्येक वेळी महिन्याची लांबी वेगळी असते. InfluxDB फक्त समान अंतराने कार्य करू शकते. आतापर्यंत, माझा मेंदू 30 दिवसांचा एक निश्चित अंतराल सेट करण्यासाठी पुरेसा आहे. होय, चार्ट वर्षभरात थोडासा फ्लोट होईल आणि बार महिन्यांशी अचूकपणे जुळत नाहीत. पण ही गोष्ट माझ्यासाठी डिस्प्ले मीटर म्हणून रुचीपूर्ण असल्याने, मी यासह ठीक आहे.

मला किमान दोन उपाय दिसत आहेत:

• मासिक चार्टवर स्कोअर करण्यासाठी आणि स्वत:ला साप्ताहिकांपर्यंत मर्यादित करा. एका वर्षात 52 साप्ताहिक बार खूपच चांगले दिसतात
• मासिक वापराचाच विचार करा पद्धत क्रमांक 2, आणि ग्राफना फक्त सुंदर आलेखांसाठी वापरा. तो एक अतिशय अचूक उपाय आहे. तुलनेसाठी तुम्ही मागील वर्षाचे चार्ट देखील आच्छादित करू शकता - ग्राफाना ते करू शकतात.

निष्कर्ष

मला का माहित नाही, पण मला या प्रकारचे चार्ट आवडतात. ते दाखवतात की जीवन जोरात चालू आहे आणि सर्व काही बदलत आहे. काल खूप काही होतं, आज थोडं आहे, उद्या काहीतरी वेगळं असेल. उपभोगाच्या विषयावर घरांसोबत काम करणे बाकी आहे. परंतु सध्याच्या भूक असतानाही, बिलातील फक्त एक मोठी आणि न समजणारी आकृती आधीच उपभोगाच्या बर्‍यापैकी समजण्यायोग्य चित्रात बदलत आहे.

प्रोग्रामर म्हणून माझी जवळपास 20 वर्षांची कारकीर्द असूनही, मी व्यावहारिकपणे डेटाबेसला छेदत नाही. म्हणून, बाह्य डेटाबेस स्थापित करणे काहीतरी अमूर्त आणि अनाकलनीय वाटले. सर्व काही बदलले आहे वरील लेख - हे निष्पन्न झाले की योग्य साधन स्क्रू करणे दोन क्लिकमध्ये केले जाते आणि एका विशेष साधनासह, प्लॉटिंगचे कार्य थोडे सोपे होते.

शीर्षकात मी विजेच्या वापराचा उल्लेख केला आहे. दुर्दैवाने, याक्षणी मी कोणताही आलेख देऊ शकत नाही. एक SDM120 मीटर मृत आहे, आणि दुसरा मॉडबस मार्गे प्रवेश करताना बग्गी आहे. तथापि, याचा या लेखाच्या विषयावर कोणत्याही प्रकारे परिणाम होत नाही - आलेख पाण्याप्रमाणेच तयार केले जातील.

या लेखात, मी स्वतः प्रयत्न केलेले दृष्टिकोन दिले आहेत. निश्चितपणे डेटाचे संकलन आणि व्हिज्युअलायझेशन आयोजित करण्याचे काही इतर मार्ग आहेत ज्याबद्दल मला माहिती नाही. टिप्पण्यांमध्ये याबद्दल मला सांगा, मला खूप रस असेल. मला विधायक टीका आणि नवीन कल्पनांबद्दल आनंद होईल. मला आशा आहे की वरील सामग्री देखील एखाद्यास मदत करेल.

स्त्रोत: www.habr.com