ផ្ទះឆ្លាតវៃ៖ ការប្រើប្រាស់ទឹក និងអគ្គិសនីក្នុងកម្មវិធីជំនួយការផ្ទះ

រាល់ពេលដែលខ្ញុំទទួលបានថ្លៃភ្លើង និងទឹក ខ្ញុំភ្ញាក់ផ្អើល - តើគ្រួសារខ្ញុំពិតជាប្រើប្រាស់ច្រើនមែនទេ? បាទ បន្ទប់ទឹកមានកំរាលកំដៅ និងឡចំហាយទឹក ប៉ុន្តែវាមិនឆេះគ្រប់ពេលនោះទេ។ យើង​ក៏​ហាក់​ដូច​ជា​សន្សំ​សំចៃ​ទឹក​ដែរ (ទោះ​បី​ជា​យើង​ចូល​ចិត្ត​បាញ់​ទឹក​ក្នុង​បន្ទប់​ទឹក​ក៏​ដោយ)។ កាលពីប៉ុន្មានឆ្នាំមុនខ្ញុំរួចទៅហើយ ម៉ែត្រទឹកដែលបានតភ្ជាប់ и អគ្គិសនី ទៅផ្ទះឆ្លាត ប៉ុន្តែនោះជាកន្លែងដែលអ្វីៗជាប់គាំង។ ឥឡូវនេះយើងទើបតែទទួលបានការវិភាគអំពីការប្រើប្រាស់ ដែលជាអ្វីដែលអត្ថបទនេះគឺពិតជាអំពី។

ថ្មីៗនេះខ្ញុំបានប្តូរទៅ 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 MB ជារៀងរាល់ថ្ងៃ។ ក្នុងមួយសប្តាហ៍ប្រព័ន្ធនឹងស្ទើរតែផ្លាស់ទីហើយក្នុងមួយខែដ្រាយវ៍ពន្លឺនឹងស្លាប់ (ក្នុងករណីការដំឡើងជំនួយការផ្ទះធម្មតានៅលើ Raspberry PI) ហើយការរក្សាទុកទិន្នន័យពេញមួយឆ្នាំគឺគ្មានបញ្ហាទេ។

• ប្រសិនបើអ្នកមានសំណាង នោះម៉ែត្ររបស់អ្នកអាចរាប់ការប្រើប្រាស់ខ្លួនឯងបាន។ អ្នកអាចងាកទៅរកម៉ែត្រនៅពេលណាក៏បាន ហើយសួរថាតើតម្លៃនៃការប្រើប្រាស់បង្គរគឺនៅពេលណា។ តាមក្បួនមួយម៉ែត្រអគ្គិសនីទាំងអស់ដែលមានចំណុចប្រទាក់ឌីជីថល (RS232/RS485/Modbus/Zigbee) ផ្តល់ឱកាសនេះ។

  វាកាន់តែអាក្រក់ប្រសិនបើឧបករណ៍នេះអាចវាស់ប៉ារ៉ាម៉ែត្រភ្លាមៗមួយចំនួន (ឧទាហរណ៍ ថាមពលភ្លាមៗ ឬចរន្ត) ឬគ្រាន់តែបង្កើតជីពចររៀងរាល់ X វ៉ាត់ម៉ោង ឬលីត្រ។ បន្ទាប់មកអ្នកត្រូវគិតអំពីរបៀប និងជាមួយអ្វីដែលត្រូវបញ្ចូលវា និងកន្លែងដែលត្រូវប្រមូលតម្លៃ។ មានហានិភ័យនៃការបាត់របាយការណ៍បន្ទាប់សម្រាប់ហេតុផលណាមួយ ហើយភាពត្រឹមត្រូវនៃប្រព័ន្ធទាំងមូលបង្កឱ្យមានសំណួរ។ ជាការពិតណាស់ អ្នកអាចប្រគល់អ្វីៗទាំងអស់នេះទៅឱ្យប្រព័ន្ធផ្ទះឆ្លាតវៃដូចជាជំនួយការផ្ទះ ប៉ុន្តែគ្មាននរណាម្នាក់បានលុបចោលចំណុចអំពីចំនួនកំណត់ត្រានៅក្នុងមូលដ្ឋានទិន្នន័យនោះទេ ហើយវានឹងមិនអាចទៅរួចទេក្នុងការស្ទង់មតិឧបករណ៍ចាប់សញ្ញាច្រើនជាងម្តងក្នុងមួយវិនាទី (a ដែនកំណត់នៃស្ថាបត្យកម្មជំនួយការផ្ទះ) ។

វិធីសាស្រ្ត 1

ជាដំបូង សូមមើលអ្វីដែលជំនួយការផ្ទះផ្តល់ឱ្យក្រៅប្រអប់។ ការវាស់ស្ទង់ការប្រើប្រាស់ក្នុងរយៈពេលមួយគឺជាមុខងារដែលចង់បានយ៉ាងខ្លាំង។ ជាការពិតណាស់វាត្រូវបានអនុវត្តជាយូរមកហើយនៅក្នុងទម្រង់នៃសមាសភាគឯកទេស - utility_meter ។

ខ្លឹមសារនៃសមាសភាគគឺថាវាបង្កើតអថេរ current_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 ។ ការរចនានេះបង្កើតឧបករណ៍ចាប់សញ្ញាថ្មី 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 — ក្រាហ្វនឹងត្រូវបានបង្កើតជាមួយនឹងរបារតម្រឹមទៅដើមម៉ោង
• points_per_hour: 1 - របារមួយសម្រាប់រាល់ម៉ោង
• ហើយសំខាន់បំផុត aggregate_func: max - យកតម្លៃអតិបរមាក្នុងរយៈពេលមួយម៉ោងនីមួយៗ។ វាគឺជាប៉ារ៉ាម៉ែត្រនេះដែលប្រែក្រាហ្វ 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 ត្រូវបានកំណត់ជាចន្លោះពេល ហើយប៉ារ៉ាម៉ែត្រ point_per_hour គ្រប់គ្រងអ្វីគ្រប់យ៉ាង។ ហើយនៅក្នុងនោះមានបញ្ហាមួយទៀតជាមួយសមាសភាគនេះ - point_per_hour ដំណើរការល្អនៅលើតារាងមួយម៉ោង ឬតិចជាងនេះ ប៉ុន្តែវាជញ្ជក់យកចន្លោះពេលធំជាង។ ដូច្នេះដើម្បីទទួលបានជួរឈរមួយក្នុងមួយថ្ងៃ ខ្ញុំត្រូវបញ្ចូលតម្លៃ 1/24=0.04166666 ។ ខ្ញុំមិននិយាយសូម្បីតែតារាងប្រចាំសប្តាហ៍ និងប្រចាំខែ។

វិធីសាស្រ្ត 2

ខណៈពេលដែលខ្ញុំនៅតែយល់អំពីជំនួយការផ្ទះ ខ្ញុំបានឃើញវីដេអូនេះ៖

មិត្តម្នាក់ប្រមូលទិន្នន័យការប្រើប្រាស់ពីប្រភេទរន្ធ Xiaomi ជាច្រើន។ ភារកិច្ចរបស់គាត់គឺសាមញ្ញជាងនេះបន្តិច - គ្រាន់តែបង្ហាញតម្លៃប្រើប្រាស់សម្រាប់ថ្ងៃនេះ ម្សិលមិញ និងសម្រាប់ខែ។ មិនត្រូវការកាលវិភាគទេ។

ចូរទុកការពិភាក្សាអំពីការរួមបញ្ចូលដោយដៃនៃតម្លៃថាមពលភ្លាមៗ - ខ្ញុំបានសរសេរខាងលើរួចហើយអំពី "ភាពត្រឹមត្រូវ" នៃវិធីសាស្រ្តនេះ។ វាមិនច្បាស់ទេថាហេតុអ្វីបានជាគាត់មិនប្រើតម្លៃនៃការប្រើប្រាស់បង្គរដែលត្រូវបានប្រមូលរួចហើយដោយហាងតែមួយ។ តាមគំនិតរបស់ខ្ញុំ ការរួមបញ្ចូលខាងក្នុងផ្នែករឹងនឹងដំណើរការកាន់តែប្រសើរ។

ពីវីដេអូយើងនឹងយកគំនិតនៃការរាប់ការប្រើប្រាស់ដោយដៃក្នុងរយៈពេលមួយ។ បុរសនោះគ្រាន់តែរាប់តម្លៃសម្រាប់ថ្ងៃនេះ និងម្សិលមិញប៉ុណ្ណោះ ប៉ុន្តែយើងនឹងបន្តទៅមុខទៀត ហើយព្យាយាមគូរក្រាហ្វ។ ខ្លឹមសារនៃវិធីសាស្រ្តដែលបានស្នើឡើងនៅក្នុងករណីរបស់ខ្ញុំមានដូចខាងក្រោម។

ចូរបង្កើតអថេរ value_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

ស្វ័យប្រវត្តិកម្មទាំងពីរអនុវត្ត 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 កំណត់ត្រាក្នុងមួយថ្ងៃសម្រាប់តារាងមួយម៉ោង។

ជាអកុសល វានៅតែមិនអាចដោះស្រាយបញ្ហាទូទៅនៃមូលដ្ឋានដែលកំពុងលូតលាស់បានទេ។ ប្រសិនបើខ្ញុំចង់បានក្រាហ្វការប្រើប្រាស់ប្រចាំខែ ខ្ញុំនឹងត្រូវរក្សាទុកទិន្នន័យយ៉ាងហោចណាស់មួយឆ្នាំ។ ហើយចាប់តាំងពីជំនួយការផ្ទះផ្តល់នូវការកំណត់រយៈពេលផ្ទុកតែមួយសម្រាប់មូលដ្ឋានទិន្នន័យទាំងមូល នេះមានន័យថាទិន្នន័យទាំងអស់នៅក្នុងប្រព័ន្ធនឹងត្រូវរក្សាទុកពេញមួយឆ្នាំ។ ឧទាហរណ៍ ក្នុង​មួយ​ឆ្នាំ​ខ្ញុំ​ប្រើប្រាស់​ទឹក ២០០ ម៉ែត្រ​គុប ដែល​មាន​ន័យ​ថា នេះ​មាន​ន័យ​ថា ២០០,០០០ ធាតុ​ក្នុង​មូលដ្ឋាន​ទិន្នន័យ។ ហើយប្រសិនបើអ្នកយកទៅក្នុងគណនីឧបករណ៍ចាប់សញ្ញាផ្សេងទៀត នោះតួលេខនេះជាទូទៅមិនសមរម្យ។

វិធីសាស្រ្ត 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
• សំណើនឹងត្រូវបានប្រតិបត្តិរៀងរាល់ម៉ោង (ពេលវេលា(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 ម៉ោង - តម្លៃ 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) មិនមានការប្រើប្រាស់ទេ។ ទោះយ៉ាងណាក៏ដោយ សំណួរនឹងត្រឡប់តម្លៃនៃការប្រើប្រាស់ដូចគ្នាដោយអរគុណចំពោះការបំពេញ (ពីមុន) ហើយមុខងារខុសគ្នានឹងដកតម្លៃនេះចេញពីខ្លួនវា ហើយលទ្ធផលនឹងស្មើនឹង 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 ថ្ងៃចុងក្រោយនេះទេ ដូច្នេះមានតែក្រាហ្វទឹកត្រជាក់ប៉ុណ្ណោះដែលត្រូវបានគូរ។

ខ្ញុំនៅតែមិនទាន់សម្រេចចិត្តដោយខ្លួនឯងថាក្រាហ្វមួយណាដែលខ្ញុំចូលចិត្តជាង បន្ទាត់ជំហាន ឬរបារពិត ដូច្នេះ ខ្ញុំនឹងលើកឧទាហរណ៍នៃតារាងការប្រើប្រាស់ប្រចាំថ្ងៃ មានតែពេលនេះនៅក្នុងបារប៉ុណ្ណោះ។ សំណួរត្រូវបានសាងសង់ស្រដៀងគ្នាទៅនឹងអ្វីដែលបានពិពណ៌នាខាងលើ។ ជម្រើសបង្ហាញគឺ៖

ក្រាហ្វនេះមើលទៅដូចនេះ៖

ដូច្នេះអំពីប៉ារ៉ាម៉ែត្រជង់។ នៅក្នុងក្រាហ្វនេះ ជួរឈរនៃទឹកត្រជាក់ត្រូវបានគូរនៅលើកំពូលនៃជួរឈរនៃទឹកក្តៅ។ កម្ពស់សរុបត្រូវគ្នាទៅនឹងការប្រើប្រាស់សរុបនៃទឹកត្រជាក់ និងទឹកក្តៅសម្រាប់រយៈពេលនេះ។

ក្រាហ្វទាំងអស់ដែលបានបង្ហាញគឺថាមវន្ត។ អ្នកអាចដាក់កណ្ដុររបស់អ្នកលើចំណុចចាប់អារម្មណ៍ ហើយមើលព័ត៌មានលម្អិត និងតម្លៃនៅចំណុចជាក់លាក់ណាមួយ។

ជាអកុសលមានការហោះហើរពីរបីនៅក្នុងមួន។ នៅលើគំនូសតាងរបារ (មិនដូចគំនូសតាងដែលមានបន្ទាត់ជំហាន) ពាក់កណ្តាលរបារមិននៅពាក់កណ្តាលថ្ងៃទេ ប៉ុន្តែនៅម៉ោង 00:00 ។ ទាំងនោះ។ ពាក់កណ្តាលខាងឆ្វេងនៃជួរឈរត្រូវបានគូរជំនួសថ្ងៃមុន។ ដូច្នេះ ក្រាហ្វសម្រាប់ថ្ងៃសៅរ៍ និងថ្ងៃអាទិត្យត្រូវបានគូរបន្តិចទៅខាងឆ្វេងនៃតំបន់ពណ៌ខៀវ។ រហូតដល់ខ្ញុំរកវិធីកម្ចាត់វា។

បញ្ហាមួយទៀតគឺអសមត្ថភាពក្នុងការធ្វើការបានត្រឹមត្រូវនៅចន្លោះពេលប្រចាំខែ។ ការពិតគឺថារយៈពេលនៃម៉ោង/ថ្ងៃ/សប្តាហ៍ត្រូវបានជួសជុល ប៉ុន្តែរយៈពេលនៃខែគឺខុសគ្នារាល់ពេល។ InfluxDB អាចដំណើរការបានតែក្នុងចន្លោះពេលស្មើគ្នាប៉ុណ្ណោះ។ រហូតមកដល់ពេលនេះ ខួរក្បាលរបស់ខ្ញុំបានគ្រប់គ្រាន់ដើម្បីកំណត់ចន្លោះពេលថេរ 30 ថ្ងៃ។ បាទ/ចាស ក្រាហ្វនឹងអណ្តែតបន្តិចពេញមួយឆ្នាំ ហើយរបារនឹងមិនត្រូវគ្នានឹងខែនោះទេ។ ប៉ុន្តែ​ដោយសារ​ខ្ញុំ​ចាប់​អារម្មណ៍​លើ​រឿង​នេះ​ជា​ឧបករណ៍​វាស់​ស្ទង់ ខ្ញុំ​មិន​អី​ទេ​។

ខ្ញុំឃើញដំណោះស្រាយយ៉ាងតិចពីរ៖

• បោះបង់តារាងប្រចាំខែ ហើយដាក់កម្រិតខ្លួនអ្នកចំពោះតារាងប្រចាំសប្តាហ៍។ 52 របារប្រចាំសប្តាហ៍សម្រាប់ឆ្នាំមើលទៅល្អណាស់
• ពិចារណាការប្រើប្រាស់ប្រចាំខែដោយខ្លួនឯងជាវិធីសាស្រ្តលេខ 2 ហើយប្រើ Grafana សម្រាប់តែក្រាហ្វដ៏ស្រស់ស្អាតប៉ុណ្ណោះ។ វានឹងក្លាយជាដំណោះស្រាយដ៏ត្រឹមត្រូវមួយ។ អ្នកអាចសូម្បីតែក្រាហ្វិចត្រួតលើគ្នាសម្រាប់ឆ្នាំមុនសម្រាប់ការប្រៀបធៀប - Grafana ក៏អាចធ្វើដូច្នោះដែរ។

សេចក្តីសន្និដ្ឋាន

ខ្ញុំ​មិន​ដឹង​ថា​ហេតុ​អ្វី​ទេ ប៉ុន្តែ​ខ្ញុំ​ជក់​ចិត្ត​នឹង​ក្រាហ្វិក​ប្រភេទ​នេះ។ ពួកគេបង្ហាញថាជីវិតគឺស្ថិតនៅក្នុងការផ្លាស់ប្តូរពេញលេញហើយអ្វីគ្រប់យ៉ាងកំពុងផ្លាស់ប្តូរ។ ម្សិលមិញ​មាន​ច្រើន ថ្ងៃនេះ​មាន​តិច ស្អែក​មាន​អ្វី​ផ្សេង។ អ្វីដែលនៅសល់គឺត្រូវធ្វើការជាមួយសមាជិកគ្រួសារលើប្រធានបទនៃការប្រើប្រាស់។ ប៉ុន្តែទោះបីជាមានចំណង់អាហារបច្ចុប្បន្នក៏ដោយ តួលេខដ៏ធំ និងមិនអាចយល់បាននៅលើសន្លឹកការទូទាត់បានប្រែទៅជារូបភាពនៃការប្រើប្រាស់ដែលអាចយល់បានរួចទៅហើយ។

ថ្វីបើអាជីពជិត 20 ឆ្នាំរបស់ខ្ញុំជាអ្នកសរសេរកម្មវិធីក៏ដោយ ក៏ខ្ញុំស្ទើរតែគ្មានទំនាក់ទំនងជាមួយមូលដ្ឋានទិន្នន័យដែរ។ ដូច្នេះ ការ​ដំឡើង​មូលដ្ឋាន​ទិន្នន័យ​ខាង​ក្រៅ​ហាក់​ដូច​ជា​អ្វី​ដែល​មិន​ច្បាស់​លាស់ និង​មិន​អាច​យល់​បាន។ បានផ្លាស់ប្តូរអ្វីៗទាំងអស់។ អត្ថបទខាងលើ — វាបានប្រែក្លាយថាការភ្ជាប់ឧបករណ៍សមស្របមួយត្រូវបានធ្វើឡើងដោយការចុចពីរបីដង ហើយជាមួយនឹងឧបករណ៍ឯកទេស ភារកិច្ចនៃការគូរគំនូសតាងកាន់តែងាយស្រួលបន្តិច។

នៅក្នុងចំណងជើងខ្ញុំបានរៀបរាប់អំពីការប្រើប្រាស់អគ្គិសនី។ ជាអកុសល នៅពេលនេះ ខ្ញុំមិនអាចផ្តល់ក្រាហ្វណាមួយបានទេ។ មួយ SDM120 ម៉ែត្របានស្លាប់សម្រាប់ខ្ញុំ ហើយមួយទៀតមានកំហុសនៅពេលចូលប្រើតាមរយៈ Modbus ។ ទោះជាយ៉ាងណាក៏ដោយនេះមិនប៉ះពាល់ដល់ប្រធានបទនៃអត្ថបទនេះតាមរបៀបណាមួយទេ - ក្រាហ្វនឹងត្រូវបានសាងសង់តាមរបៀបដូចគ្នានឹងទឹក។

នៅក្នុងអត្ថបទនេះខ្ញុំបានបង្ហាញពីវិធីសាស្រ្តដែលខ្ញុំបានសាកល្បងខ្លួនឯង។ ប្រាកដណាស់ មានវិធីផ្សេងទៀតក្នុងការរៀបចំការប្រមូលទិន្នន័យ និងការមើលឃើញដែលខ្ញុំមិនដឹង។ ប្រាប់ខ្ញុំអំពីវានៅក្នុងមតិយោបល់ខ្ញុំនឹងចាប់អារម្មណ៍យ៉ាងខ្លាំង។ ខ្ញុំនឹងរីករាយចំពោះការរិះគន់ក្នុងន័យស្ថាបនា និងគំនិតថ្មីៗ។ ខ្ញុំសង្ឃឹមថាសម្ភារៈដែលបានបង្ហាញនឹងជួយនរណាម្នាក់ផងដែរ។

ប្រភព: www.habr.com