स्मार्ट होम: गृह सहायकमा चार्टिङ पानी र बिजुली खपत

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

मैले भर्खरै मेरो स्मार्ट घर प्रणालीको रूपमा गृह सहायकमा स्विच गरें। एक कारण ठ्याक्कै विभिन्न प्रकारका ग्राफहरू निर्माण गर्ने क्षमताको साथ ठूलो मात्रामा डाटाको सङ्कलनलाई व्यवस्थित गर्ने अवसर थियो।

यस लेखमा वर्णन गरिएको जानकारी नयाँ छैन; विभिन्न सॉस अन्तर्गत यी सबै चीजहरू पहिले नै इन्टरनेटमा वर्णन गरिएको छ। तर प्रत्येक लेखले सामान्यतया एउटा दृष्टिकोण वा पक्षलाई मात्र वर्णन गर्छ। मैले यी सबै दृष्टिकोणहरू तुलना गर्नुपर्‍यो र आफैलाई सबैभन्दा उपयुक्त छनौट गर्नुपर्‍यो। लेखले अझै पनि डेटा सङ्कलनमा व्यापक जानकारी प्रदान गर्दैन, तर मैले यो कसरी गरें भन्ने एक प्रकारको सारांश हो। त्यसैले सुधारको लागि रचनात्मक आलोचना र सुझावहरू स्वागत छ।

समस्याको गठन

त्यसैले, आजको अभ्यासको लक्ष्य पानी र बिजुली खपतको सुन्दर ग्राफहरू प्राप्त गर्नु हो:

• २ दिनको लागि प्रति घण्टा
• 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) भएका सबै बिजुली मिटरहरूले यो अवसर प्रदान गर्छन्।

  यदि यन्त्रले केही तात्कालिक प्यारामिटरहरू (उदाहरणका लागि, तात्कालिक पावर वा वर्तमान) मापन गर्न सक्छ वा प्रत्येक X वाट-घण्टा वा लीटरमा पल्स उत्पन्न गर्न सक्छ भने यो खराब हुन्छ। त्यसोभए तपाईंले यसलाई कसरी र केसँग एकीकृत गर्ने र कहाँ मूल्य जम्मा गर्ने भनेर सोच्न आवश्यक छ। कुनै पनि कारणले अर्को रिपोर्ट हराउने जोखिम छ, र समग्र रूपमा प्रणालीको शुद्धताले प्रश्न खडा गर्छ। तपाईले यो सबै घर सहायक जस्तै स्मार्ट होम सिस्टममा सुम्पन सक्नुहुन्छ, तर डाटाबेसमा रेकर्डहरूको संख्याको बारेमा कसैले पनि बिन्दु रद्द गरेको छैन, र सेन्सरहरू एक सेकेन्डमा एक पटक भन्दा बढी पोल गर्न सम्भव हुनेछैन। गृह सहायक वास्तुकला को सीमा)।

दृष्टिकोण १

पहिले, गृह सहायकले बक्स बाहिर के प्रदान गर्दछ हेरौं। एक अवधि मा खपत मापन एक उच्च खोजिएको कार्यक्षमता हो। निस्सन्देह, यो एक विशेष घटक को रूप मा एक लामो समय पहिले लागू भएको थियो - 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 — ग्राफ घण्टाको सुरुमा पङ्क्तिबद्ध बारहरूसँग उत्पन्न हुनेछ
• अंक_प्रति_घण्टा: १ - प्रत्येक घण्टाको लागि एक बार
• र सबैभन्दा महत्त्वपूर्ण, aggregate_func: अधिकतम - प्रत्येक घण्टा भित्र अधिकतम मान लिनुहोस्। यो यो प्यारामिटर हो जसले sawtooth ग्राफलाई बारहरूमा बदल्छ

बायाँमा स्तम्भहरूको पङ्क्तिमा ध्यान नदिनुहोस् - यदि कुनै डाटा छैन भने यो घटकको मानक व्यवहार हो। तर त्यहाँ कुनै डाटा थिएन - मैले यो लेखको खातिर केही घण्टा अघि मात्र उपयोगिता मिटर डेटा संग्रह खोलेको छु (म तल मेरो हालको दृष्टिकोण वर्णन गर्नेछु)।

यस चित्रमा म कहिलेकाहीँ डाटा प्रदर्शनले पनि काम गर्दछ र बारहरूले वास्तवमा सही मानहरू प्रतिबिम्बित गर्दछ भनेर देखाउन चाहन्छु। तर यति मात्र होइन। केही कारणका लागि, 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 प्यारामिटरले सबै कुरा नियम गर्दछ। र यसमा यो कम्पोनेन्टको साथ अर्को समस्या छ - अंक_प्रति_घण्टा एक घण्टा वा कमको चार्टहरूमा राम्रोसँग काम गर्दछ, तर यसले ठूलो अन्तरालहरूमा बेकार हुन्छ। त्यसोभए एक दिनमा एउटा स्तम्भ प्राप्त गर्न, मैले मान 1/24=0.04166666 प्रविष्ट गर्नुपर्‍यो। म साप्ताहिक र मासिक चार्टहरूको बारेमा पनि कुरा गरिरहेको छैन।

दृष्टिकोण १

गृह सहायकलाई अझै बुझ्दै गर्दा, मैले यो भिडियो भेटें:

एक साथीले धेरै प्रकारका Xiaomi सकेटहरूबाट खपत डेटा सङ्कलन गर्दछ। उसको कार्य थोरै सरल छ - केवल आज, हिजो र महिनाको लागि उपभोग मूल्य प्रदर्शन गर्नुहोस्। कुनै तालिका आवश्यक छैन।

तात्कालिक पावर मानहरूको म्यानुअल एकीकरणको बारेमा छलफलहरू छोडौं - मैले पहिले नै यस दृष्टिकोणको "सटीकता" बारे माथि लेखेको छु। यो स्पष्ट छैन किन उनले संचित उपभोग मूल्यहरू प्रयोग गरेनन्, जुन पहिले नै उही आउटलेटद्वारा सङ्कलन गरिएको छ। मेरो विचारमा, हार्डवेयर भित्र एकीकरण राम्रो काम गर्नेछ।

भिडियोबाट हामी एक अवधिमा म्यानुअल रूपमा खपत गणना गर्ने विचार लिनेछौं। केटाले आज र हिजोको लागि मात्र मानहरू गणना गर्दछ, तर हामी अगाडि जान्छौं र ग्राफ कोर्न प्रयास गर्नेछौं। मेरो मामला मा प्रस्तावित विधि को सार निम्नानुसार छ।

चलो मान_at_the_beginning_of_hour सिर्जना गरौं, जसमा हामी हालको मिटर रिडिङहरू रेकर्ड गर्नेछौं।
टाइमर प्रयोग गरेर, घण्टाको अन्त्यमा (वा अर्कोको सुरुमा) हामी हालको पढाइ र घण्टाको सुरुमा भण्डारण गरिएको बीचको भिन्नता गणना गर्छौं। यो भिन्नता हालको घण्टाको लागि खपत हुनेछ - हामी सेन्सरमा मूल्य बचत गर्नेछौं, र भविष्यमा हामी यो मानमा आधारित ग्राफ निर्माण गर्नेछौं।
तपाईंले त्यहाँ हालको काउन्टर मान लेखेर value_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

दुबै स्वचालनले २ कार्यहरू गर्दछ:

• सुरु र अन्त्य मानहरू बीचको भिन्नताको रूपमा अन्तरालको लागि मान गणना गर्नुहोस्
• अर्को अन्तरालको लागि आधार मान अपडेट गर्नुहोस्

यस मामला मा ग्राफ को निर्माण सामान्य इतिहास ग्राफ द्वारा हल गरिएको छ:

      - 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 प्रविष्टिहरू छन्। र यदि तपाइँ खातामा अन्य सेन्सरहरू लिनुहुन्छ, तब आंकडा सामान्यतया अशोभनीय हुन्छ।

दृष्टिकोण १

सौभाग्य देखि, स्मार्ट मानिसहरूले पहिले नै 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

यो आदेश:

• गृह सहायक डाटाबेसमा cq_water_cold_hourly नामक निरन्तर क्वेरी सिर्जना गर्दछ
• अनुरोध प्रत्येक घण्टा कार्यान्वयन गरिनेछ (समय (1h))
• अनुरोधले मापन' 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) सम्म कुनै खपत थिएन। तैपनि, क्वेरीले उही उपभोग मान फिर्ता गर्नेछ, भर्नका लागि धन्यवाद (पूर्व), र भिन्नता प्रकार्यले यो मान आफैबाट घटाउनेछ र आउटपुट ० हुनेछ, जुन वास्तवमा आवश्यक छ।

केवल ग्राफ निर्माण गर्न बाँकी छ। यो गर्नको लागि, 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"

कृपया ध्यान दिनुहोस् कि समय दायरा (पछिल्लो २ दिन) यहाँ सेट गरिएको छ, र ड्यासबोर्ड सेटिङहरूमा होइन।

ग्राफ यस्तो देखिन्छ। मैले पछिल्लो २ दिनमा तातो पानी प्रयोग गरेको छैन, त्यसैले चिसो पानीको ग्राफ मात्र कोरिएको छ।

मैले अझै पनि आफ्नो लागि निर्णय गरेको छैन कि मलाई कुन ग्राफ राम्रो मनपर्छ, एक लाइन-चरण, वा वास्तविक बारहरू। त्यसकारण, म केवल दैनिक उपभोग चार्टको उदाहरण दिनेछु, यो पटक मात्र बारहरूमा। प्रश्नहरू माथि वर्णन गरिएका जस्तै बनाइएका छन्। प्रदर्शन विकल्पहरू हुन्:

यो ग्राफ यस्तो देखिन्छ:

त्यसोभए स्ट्याक प्यारामिटरको बारेमा। यस ग्राफमा, तातो पानीको स्तम्भको माथि चिसो पानीको स्तम्भ कोरिएको छ। कुल उचाइ अवधिको लागि चिसो र तातो पानीको कुल खपतसँग मेल खान्छ।

देखाइएका सबै ग्राफहरू गतिशील छन्। तपाइँ तपाइँको माउस को रुचि को बिन्दु मा होभर र एक विशेष बिन्दु मा विवरण र मूल्य हेर्न सक्नुहुन्छ।

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

अर्को समस्या मासिक अन्तरालहरूमा ठीकसँग काम गर्न असमर्थ छ। तथ्य यो हो कि घण्टा/दिन/हप्ताको लम्बाइ निश्चित छ, तर महिनाको लम्बाइ प्रत्येक पटक फरक हुन्छ। InfluxDB ले समान अन्तरालहरूमा मात्र काम गर्न सक्छ। अहिलेसम्म मेरो दिमागले ३० दिनको निश्चित अन्तराल सेट गर्न पर्याप्त छ। हो, ग्राफ वर्षभरि थोरै फ्लोट हुनेछ र बारहरू महिनाहरूसँग ठ्याक्कै मेल खाँदैन। तर मलाई यो कुरामा केवल डिस्प्ले मिटरको रूपमा रुचि भएकोले, म यसको साथ ठीक छु।

म कम्तिमा दुई समाधान देख्छु:

• मासिक चार्टहरू छोड्नुहोस् र आफूलाई साप्ताहिकमा सीमित गर्नुहोस्। वर्षको लागि 52 साप्ताहिक बारहरू राम्रो देखिन्छन्
• मासिक उपभोगलाई नै विधि नम्बर २ को रूपमा विचार गर्नुहोस्, र सुन्दर ग्राफहरूको लागि मात्र ग्राफाना प्रयोग गर्नुहोस्। यो एकदम सही समाधान हुनेछ। तपाईंले तुलनाको लागि गत वर्षको ग्राफहरू ओभरले पनि गर्न सक्नुहुन्छ - ग्राफानाले त्यो पनि गर्न सक्छ।

निष्कर्षमा

मलाई थाहा छैन किन, तर म यी प्रकारका ग्राफहरूसँग पागल छु। तिनीहरूले देखाउँछन् कि जीवन पूर्ण जोशमा छ र सबै कुरा परिवर्तन हुँदैछ। हिजो धेरै थियो, आज थोरै छ, भोलि अर्कै हुनेछ । उपभोगको विषयमा घरपरिवारका सदस्यहरूसँग काम गर्ने मात्र बाँकी छ। तर हालको भोकको साथ पनि, भुक्तान पर्चीमा केवल एक ठूलो र बुझ्न नसकिने आंकडा पहिले नै उपभोगको एकदम बुझ्न योग्य तस्वीरमा परिणत भएको छ।

प्रोग्रामरको रूपमा मेरो लगभग 20-वर्षको क्यारियरको बावजुद, मसँग डाटाबेसहरूसँग कुनै सम्पर्क थिएन। तसर्थ, बाह्य डाटाबेस स्थापना गर्न केहि अमूर्त र बुझ्न नसकिने जस्तो देखिन्थ्यो। सबै कुरा बदलियो माथिको लेख - यो बाहिरियो कि उपयुक्त उपकरण संलग्न गर्न क्लिक को एक जोडी मा गरिन्छ, र एक विशेष उपकरण संग, चार्ट प्लटिङ को कार्य अलि सजिलो हुन्छ।

शीर्षकमा मैले बिजुली खपत उल्लेख गरेको छु। दुर्भाग्यवश, यस समयमा म कुनै ग्राफहरू प्रदान गर्न सक्दिन। एउटा SDM120 मिटर मेरो लागि मरेको छ, र अर्को Modbus मार्फत पहुँच गर्दा ग्लिचि छ। यद्यपि, यसले यस लेखको विषयलाई कुनै पनि हिसाबले असर गर्दैन - ग्राफहरू पानीको लागि जस्तै बनाइनेछ।

यस लेखमा मैले आफूले प्रयास गर्ने दृष्टिकोणहरू प्रस्तुत गरें। पक्कै पनि त्यहाँ डेटा सङ्कलन र भिजुअलाइजेसन व्यवस्थित गर्ने केही अन्य तरिकाहरू छन् जुन मलाई थाहा छैन। मलाई टिप्पणीहरूमा यसको बारेमा बताउनुहोस्, मलाई धेरै चासो हुनेछ। रचनात्मक आलोचना र नयाँ विचारहरू पाउँदा खुसी हुनेछु। मलाई आशा छ कि प्रस्तुत सामग्रीले पनि कसैलाई मद्दत गर्नेछ।

स्रोत: www.habr.com