سمارٽ گهر: اسان گهر اسسٽنٽ ۾ پاڻي ۽ بجلي جي استعمال جا گراف ٺاهيندا آهيون

هر دفعي جڏهن مون کي بجلي ۽ پاڻي جي ادائيگي ملي ٿي، مون کي حيرت ٿيندي آهي - ڇا منهنجو خاندان واقعي ايترو استعمال ڪري ٿو؟ خير، ها، غسل خاني ۾ هڪ گرم فرش ۽ هڪ بوائلر آهي، پر اهي هر وقت باهه نه ٻاريندا آهن. اسان کي پڻ پاڻي بچائڻ لڳي ٿو (جيتوڻيڪ اسان پڻ غسل خاني ۾ ڀرپاسي ڪرڻ چاهيندا آهيون). مون کي ڪيترائي سال اڳ ۾ ئي ڳنڍيل پاڻي ميٽر и بجلي هڪ سمارٽ گهر ڏانهن، پر اهو آهي جتي شيون بيٺا آهن. اسان هاڻي صرف واپرائڻ جي تجزيي جي چوڌاري حاصل ڪيو آهي، جيڪو اهو مضمون اصل ۾ آهي.

مون تازو تبديل ڪيو هوم اسسٽنٽ کي منهنجي سمارٽ گهر سسٽم طور. هڪ سببن مان هڪ خاص طور تي ڊيٽا جي هڪ وڏي مقدار جي گڏ ڪرڻ کي منظم ڪرڻ جو موقعو هو، آساني سان مختلف قسم جا گراف تعمير ڪرڻ جي صلاحيت سان.

هن مضمون ۾ بيان ڪيل معلومات نئين ناهي؛ اهي سڀ شيون مختلف ساسن جي تحت اڳ ۾ ئي انٽرنيٽ تي بيان ڪيا ويا آهن. پر هر مضمون عام طور تي صرف هڪ طريقو يا پاسو بيان ڪري ٿو. مون کي انهن سڀني طريقن جو مقابلو ڪرڻو هو ۽ پاڻ کي سڀ کان وڌيڪ مناسب چونڊڻو هو. مضمون اڃا تائين ڊيٽا گڏ ڪرڻ تي جامع معلومات مهيا نٿو ڪري، پر هڪ قسم جو خلاصو آهي ته مون اهو ڪيئن ڪيو. تنهن ڪري تعميري تنقيد ۽ بهتري لاءِ تجويزون ڀليڪار آهن.

مسئلو جي ترتيب

تنهن ڪري، اڄ جي مشق جو مقصد پاڻي ۽ بجلي جي استعمال جا خوبصورت گراف حاصل ڪرڻ آهي:

• 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.

جزو جو جوهر اهو آهي ته اهو اندروني طور تي هڪ متغير موجوده_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 — گراف ٺاھيو ويندو بارن سان گڏ ڪلاڪ جي شروعات سان
• پوائنٽس_ في ڪلاڪ: 1 - هر ڪلاڪ لاءِ هڪ بار
• ۽ سڀ کان وڌيڪ اهم، aggregate_func: وڌ ۾ وڌ - وڌ ۾ وڌ قيمت هر ڪلاڪ اندر. اهو اهو پيٽرولر آهي جيڪو صوتوت گراف کي بارن ۾ تبديل ڪري ٿو

کاٻي پاسي ڪالمن جي قطار تي ڌيان نه ڏيو - اھو آھي جزو جو معياري رويو جيڪڏھن ڪو ڊيٽا نه آھي. پر ڪا به ڊيٽا نه هئي - مون صرف هن مضمون جي خاطر ڪجهه ڪلاڪ اڳ يوٽيلٽي ميٽر ڊيٽا گڏ ڪرڻ کي چالو ڪيو (مان هيٺ ڏنل منهنجي موجوده طريقي کي بيان ڪندس).

هن تصوير ۾ مان اهو ڏيکارڻ چاهيان ٿو ته ڪڏهن ڪڏهن ڊيٽا ڊسپلي پڻ ڪم ڪري ٿو ۽ بار اصل ۾ صحيح قدر ظاهر ڪن ٿا. پر اهو سڀ ڪجهه ناهي. ڪجهه سببن جي ڪري، 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 ساکٽس مان واپرائڻ واري ڊيٽا گڏ ڪري ٿو. هن جو ڪم ٿورو سادو آهي - صرف اڄ، ڪالهه ۽ مهيني لاء استعمال جي قيمت ڏيکاري. ڪابه شيڊول گهربل ناهي.

اچو ته فوري طاقت جي قيمتن جي دستي انضمام بابت بحث کي ڇڏي ڏيو - مون اڳ ۾ ئي مٿي لکيو آهي ته هن طريقي جي "درستگي" بابت. اهو واضح ناهي ته هن جمع ٿيل واهپي جي قيمتن کي ڇو نه استعمال ڪيو، جيڪي اڳ ۾ ئي ساڳئي دڪان طرفان گڏ ڪيا ويا آهن. منهنجي خيال ۾، هارڊويئر اندر انضمام بهتر ڪم ڪندو.

وڊيو مان اسان خيال ڪنداسين دستي طور تي استعمال جي ڳڻپ جي مدت دوران. ڇوڪرو صرف اڄ ۽ ڪالهه جي قيمتن کي ڳڻيندو آهي، پر اسان اڳتي وڌنداسين ۽ گراف ٺاهڻ جي ڪوشش ڪنداسين. منهنجي معاملي ۾ تجويز ڪيل طريقي جو خلاصو هن ريت آهي.

اچو ته هڪ variable value_at_the_beginning_of_hour ٺاهيون، جنهن ۾ اسان موجوده ميٽر ريڊنگ کي رڪارڊ ڪنداسين
ٽائمر کي استعمال ڪندي، ڪلاڪ جي آخر ۾ (يا ايندڙ جي شروعات ۾) اسان موجوده پڙھڻ ۽ ڪلاڪ جي شروعات ۾ ذخيرو ٿيل ھڪڙي جي وچ ۾ فرق کي حساب ڪريون ٿا. اهو فرق موجوده ڪلاڪ لاء استعمال ٿيندو - اسان قيمت کي سينسر ۾ محفوظ ڪنداسين، ۽ مستقبل ۾ اسان هن قدر جي بنياد تي گراف ٺاهينداسين.
توھان کي پڻ "ري سيٽ" ڪرڻ جي ضرورت آھي value_at_beginning_of_hour variable اتي موجوده ڪائونٽر ويل لکڻ سان.

اهو سڀ ڪجهه گهر جي اسسٽنٽ ذريعي ئي ڪري سگهجي ٿو.

توهان کي پوئين طريقي جي ڀيٽ ۾ ٿورو وڌيڪ ڪوڊ لکڻو پوندو. پهرين، اچو ته اهي ساڳيا "متغير" ٺاهي. دٻي مان ٻاهر اسان وٽ ”متغير“ ادارو ناهي، پر اسان 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 داخلائون. ۽ جيڪڏھن اوھان کي ٻين sensors اڪائونٽ ۾ وٺي، پوء انگ اکر عام طور تي غير معمولي ٿي ويندي.

طريقه 3

خوشقسمتيءَ سان، سمارٽ ماڻهن اڳ ۾ ئي ان مسئلي کي حل ڪري ڇڏيو آهي InfluxDB ڊيٽابيس لکڻ سان. هي ڊيٽابيس خاص طور تي وقت جي بنياد تي ڊيٽا کي محفوظ ڪرڻ لاء بهتر آهي ۽ مختلف سينسرز جي قدرن کي محفوظ ڪرڻ لاء مثالي آهي. سسٽم پڻ مهيا ڪري ٿو هڪ SQL-جهڙي سوال جي ٻولي جيڪا توهان کي ڊيٽابيس مان قيمتون ڪڍڻ جي اجازت ڏئي ٿي ۽ پوء انهن کي مختلف طريقن سان گڏ ڪري ٿو. آخرڪار، مختلف ڊيٽا مختلف وقتن لاء محفوظ ڪري سگھجن ٿيون. مثال طور، بار بار تبديل ٿيندڙ پڙھڻ جھڙوڪ گرمي پد يا نمي کي صرف چند ھفتن لاءِ ذخيرو ڪري سگھجي ٿو، جڏھن ته روزاني پاڻي جي استعمال جي پڙھڻ کي پوري سال لاءِ محفوظ ڪري سگھجي ٿو.

InfluxDB کان علاوه، سمارٽ ماڻهن Grafana پڻ ايجاد ڪيو، هڪ سسٽم گرافي ڊرائنگ لاءِ InfluxDB کان ڊيٽا جي بنياد تي. گرافانا مختلف قسم جا گراف ٺاهي سگھي ٿو، انھن کي تفصيل سان ترتيب ڏئي سگھي ٿو، ۽، سڀ کان وڌيڪ اھم، اھي گرافس ”پلگ“ ڪري سگھجن ٿا lovelace-UI گھر جي اسسٽنٽ تي.

حوصلا حاصل ڪريو هتي и هتي. آرٽيڪل تفصيل سان بيان ڪري ٿو InfluxDB ۽ Grafana کي انسٽال ڪرڻ ۽ ڳنڍڻ جي عمل کي گهر اسسٽنٽ سان. مان پنهنجي خاص مسئلي کي حل ڪرڻ تي ڌيان ڏيندس.

تنهن ڪري، سڀ کان پهريان، اچو ته انفلوڪس ڊي بي ۾ انسداد قيمت شامل ڪرڻ شروع ڪريون. گهر جي اسسٽنٽ جي ترتيب جو هڪ ٽڪرو (هن مثال ۾ آئون نه رڳو ٿڌو، پر گرم پاڻي سان پڻ مزو ڪندس):

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، جيڪو اسان کي ٿڌو ۽ گرم پاڻي لاء الڳ قدر ڏيندو
• جيئن ته ليٽر ڪائونٽر هر ڪلاڪ جي اندر هڪ monotonically وڌندڙ تسلسل آهي، ان کي وڌ ۾ وڌ قدر وٺڻ ضروري آهي، تنهنڪري مجموعي ڪارڪردگي وڌ ۾ وڌ (قيمت) ذريعي ڪيو ويندو.
• نئين قيمت کي لکيو ويندو 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' لاءِ آخري ڏينهن لاءِ (وقت >= هاڻي() -24h).
• جيئن ته مون اڳ ۾ ئي ذڪر ڪيو آهي، ڪجهه داخلا غائب ٿي سگهن ٿيون homeassistant.month.water_meter_hour تسلسل ۾. اسان GROUP BY time(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 parameter. ھيٺ ڏنل ڪجھ وڌيڪ ڊسپلي جا اختيار آھن، پر اھي دلچسپ نه آھن.

گھر جي اسسٽنٽ ۾ نتيجو چارٽ شامل ڪرڻ لاء توھان کي ضرورت آھي:

• چارٽ ايڊيٽنگ موڊ مان نڪرڻ. ڪجھ سببن لاء، صحيح چارٽ شيئرنگ سيٽنگون صرف ڊيش بورڊ صفحي مان پيش ڪيا ويا آھن
• چارٽ جي نالي جي اڳيان ٽڪنڊي تي ڪلڪ ڪريو ۽ مينيو مان شيئر چونڊيو
• کليل ونڊو ۾، ايمبيڊ ٽيب ڏانھن وڃو
• موجوده وقت جي حد کي چيڪ ڪريو - اسان 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