سمارٹ ہوم: ہم ہوم اسسٹنٹ میں پانی اور بجلی کے استعمال کے گراف بناتے ہیں۔

جب بھی مجھے بجلی اور پانی کی ادائیگی ملتی ہے، میں حیران ہوتا ہوں - کیا واقعی میرا خاندان اتنا استعمال کرتا ہے؟ ٹھیک ہے، ہاں، باتھ روم میں ایک گرم فرش اور ایک بوائلر ہے، لیکن وہ ہر وقت آگ نہیں جلتے۔ ایسا لگتا ہے کہ ہم پانی کی بچت بھی کر رہے ہیں (حالانکہ ہم باتھ روم میں بھی چھڑکنا پسند کرتے ہیں)۔ کئی سال پہلے میں نے پہلے ہی منسلک پانی کے میٹر и بجلی ایک سمارٹ ہوم میں، لیکن وہیں چیزیں پھنس گئیں۔ ہم نے ابھی صرف کھپت کا تجزیہ کیا ہے، جس کے بارے میں یہ مضمون ہے۔

میں نے حال ہی میں ہوم اسسٹنٹ کو اپنے سمارٹ ہوم سسٹم کے طور پر تبدیل کیا ہے۔ وجوہات میں سے ایک خاص طور پر مختلف قسم کے گرافس کو آسانی سے بنانے کی صلاحیت کے ساتھ ڈیٹا کی ایک بڑی مقدار کو جمع کرنے کا موقع تھا۔

اس مضمون میں بیان کردہ معلومات نئی نہیں ہیں، یہ تمام چیزیں مختلف ساس کے تحت پہلے ہی انٹرنیٹ پر بیان کی جا چکی ہیں۔ لیکن ہر مضمون عام طور پر صرف ایک نقطہ نظر یا پہلو کو بیان کرتا ہے۔ مجھے ان تمام طریقوں کا آپس میں موازنہ کرنا تھا اور خود سب سے موزوں طریقہ کا انتخاب کرنا تھا۔ مضمون اب بھی ڈیٹا اکٹھا کرنے کے بارے میں جامع معلومات فراہم نہیں کرتا ہے، لیکن یہ ایک قسم کا خلاصہ ہے کہ میں نے یہ کیسے کیا۔ اس لیے تعمیری تنقید اور بہتری کے لیے تجاویز خوش آئند ہیں۔

مسئلہ کی تشکیل

لہذا، آج کی مشق کا مقصد پانی اور بجلی کے استعمال کے خوبصورت گراف حاصل کرنا ہے:

• 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 واٹ گھنٹے یا لیٹر پر دالیں پیدا کرتا ہے۔ پھر آپ کو یہ سوچنے کی ضرورت ہے کہ اسے کس طرح اور کس چیز کے ساتھ مربوط کرنا ہے اور کہاں قیمت جمع کرنی ہے۔ کسی بھی وجہ سے اگلی رپورٹ کے گم ہونے کا خطرہ ہے، اور مجموعی طور پر سسٹم کی درستگی سوال اٹھاتی ہے۔ یقیناً آپ یہ سب کچھ ہوم اسسٹنٹ جیسے سمارٹ ہوم سسٹم کو سونپ سکتے ہیں، لیکن ڈیٹا بیس میں ریکارڈز کی تعداد کے بارے میں کسی نے بھی اس نکتے کو منسوخ نہیں کیا ہے، اور یہ ممکن نہیں ہوگا کہ سینسرز کو سیکنڈ میں ایک سے زیادہ مرتبہ ہوم اسسٹنٹ فن تعمیر کی حد)۔

نقطہ نظر 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 سیٹنگز کو نوٹ کرنا ضروری ہے:

• گروپ_بائی: گھنٹہ — گراف گھنٹہ کے آغاز سے منسلک سلاخوں کے ساتھ تیار کیا جائے گا۔
• پوائنٹس فی گھنٹہ: 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 بروکر کی خدمات استعمال کر سکتے ہیں۔ ہم وہاں ریٹین = ٹرو فلیگ کے ساتھ ویلیو بھیجیں گے - اس سے بروکر کے اندر ویلیو محفوظ ہو جائے گی، اور اسے کسی بھی وقت وہاں سے نکالا جا سکتا ہے، یہاں تک کہ جب ہوم اسسٹنٹ کو دوبارہ شروع کیا جائے۔ میں نے فی گھنٹہ اور روزانہ کاؤنٹر ایک ساتھ بنائے۔

- 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 ڈیٹا بیس لکھ کر اس مسئلے کو حل کر چکے ہیں۔ یہ ڈیٹا بیس خاص طور پر وقت پر مبنی ڈیٹا کو ذخیرہ کرنے کے لیے موزوں ہے اور مختلف سینسر کی قدروں کو ذخیرہ کرنے کے لیے مثالی ہے۔ یہ سسٹم ایس کیو ایل جیسی استفسار کی زبان بھی فراہم کرتا ہے جو آپ کو ڈیٹا بیس سے قدریں نکالنے اور پھر انہیں مختلف طریقوں سے جمع کرنے کی اجازت دیتا ہے۔ آخر میں، مختلف ڈیٹا کو مختلف اوقات کے لیے محفوظ کیا جا سکتا ہے۔ مثال کے طور پر، درجہ حرارت یا نمی جیسے کثرت سے تبدیل ہونے والی ریڈنگز کو صرف چند ہفتوں کے لیے ذخیرہ کیا جا سکتا ہے، جبکہ روزانہ پانی کے استعمال کی ریڈنگز کو پورے سال کے لیے ذخیرہ کیا جا سکتا ہے۔

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 کو آخری گھنٹے کی قدر استعمال کرنے پر مجبور کرے گا۔

بدقسمتی سے، مسلسل استفسار کی ایک خاصیت ہے: فل (پچھلی) چال کام نہیں کرتی ہے اور ریکارڈ آسانی سے نہیں بنائے جاتے ہیں۔ مزید یہ کہ یہ ایک طرح کا ناقابل تسخیر مسئلہ ہے۔ اب کئی سالوں سے بحث ہو رہی ہے۔. ہم بعد میں اس مسئلے سے نمٹیں گے، لیکن fill(previous) کو مسلسل استفسار میں رہنے دیں - یہ مداخلت نہیں کرتا۔

آئیے چیک کرتے ہیں کہ کیا ہوا (یقیناً، آپ کو چند گھنٹے انتظار کرنا ہوگا):

> 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 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 am (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 میٹر میرے لیے مر گیا، اور دوسرا Modbus کے ذریعے رسائی حاصل کرنے پر خراب ہے۔ تاہم، یہ اس مضمون کے موضوع کو کسی بھی طرح متاثر نہیں کرتا ہے - گراف اسی طرح بنائے جائیں گے جیسے پانی کے لیے۔

اس مضمون میں میں نے وہ نقطہ نظر پیش کیے جو میں نے خود آزمائے۔ یقینی طور پر ڈیٹا اکٹھا کرنے اور ویژولائزیشن کو منظم کرنے کے کچھ اور طریقے ہیں جن کے بارے میں میں نہیں جانتا ہوں۔ مجھے اس کے بارے میں تبصرے میں بتائیں، مجھے بہت دلچسپی ہوگی۔ مجھے تعمیری تنقید اور نئے خیالات سے خوشی ہوگی۔ مجھے امید ہے کہ پیش کردہ مواد بھی کسی کی مدد کرے گا۔

ماخذ: www.habr.com