پروفایل دستگاه
از نسخه 3.2 ThingsConnect، مدیر مستأجر میتواند تنظیمات مشترک برای چندین دستگاه را با استفاده از پروفایل دستگاه پیکربندی کند. هر دستگاه در هر لحظه تنها یک پروفایل دارد.
کاربران با تجربه ThingsConnect متوجه میشوند که نوع دستگاه در این نسخه به نفع پروفایل دستگاه منسوخ شده است. اسکریپت بهروزرسانی بهطور خودکار پروفایلهای دستگاه را بر اساس انواع دستگاه منحصربهفرد ایجاد کرده و آنها را به دستگاههای مناسب اختصاص میدهد.
بیایید نگاهی به تنظیمات موجود در پروفایل دستگاه بیندازیم.
جزئیات پروفایل دستگاه
زنجیره قوانین
بهطور پیشفرض، زنجیره قوانین اصلی تمام پیامها و رویدادهای ورودی برای هر دستگاه را پردازش میکند. با این حال، هرچه انواع دستگاههای مختلف بیشتری داشته باشید، زنجیره قوانین اصلی شما پیچیدهتر میشود. بسیاری از کاربران پلتفرم، زنجیره قوانین اصلی خود را تنها به منظور ارسال پیامها به زنجیرههای قوانین خاص بر اساس نوع دستگاه ایجاد میکنند.
برای جلوگیری از این فعالیت دردناک و کسلکننده، از نسخه 3.2 ThingsConnect، میتوانید زنجیره قوانین سفارشی برای دستگاههای خود تعیین کنید. زنجیره قوانین جدید همه تلمتری، فعالیت دستگاه (فعال/غیرفعال) و رویدادهای چرخه زندگی دستگاه (ایجاد/بهروزرسانی/حذف) را دریافت خواهد کرد. این تنظیم در جادوگر پروفایل دستگاه و در جزئیات پروفایل دستگاه موجود است.
نام صف
بهطور پیشفرض، صف اصلی برای ذخیره تمامی پیامها و رویدادهای ورودی از هر دستگاهی استفاده میشود. لایه انتقال، پیامها را به این صف ارسال میکند و موتور قوانین، صف را برای پیامهای جدید بررسی میکند. با این حال، برای موارد استفاده متعدد، ممکن است بخواهید از صفهای مختلف برای دستگاههای مختلف استفاده کنید. به عنوان مثال، ممکن است بخواهید پردازش دادهها برای سنسورهای هشدار آتشسوزی/دتکتور دود را از سایر دستگاهها جدا کنید. به این ترتیب، حتی اگر سیستم شما تحت بار اوج باشد که توسط میلیونها کنتور آب تولید میشود، هر زمان که هشدار آتشسوزی گزارش شود، بدون تأخیر پردازش خواهد شد. جداسازی صفها همچنین به شما این امکان را میدهد که استراتژیهای ارسال و پردازش مختلف را سفارشی کنید.
این تنظیم در جادوگر پروفایل دستگاه و جزئیات پروفایل دستگاه موجود است.
لطفاً توجه داشته باشید:
اگر قصد دارید از یک صف سفارشی استفاده کنید، باید آن را پیش از استفاده با مدیر سیستم تنظیم کنید.
پیکربندی انتقال
نسخهی فعلی پلتفرم ThingsConnect از انواع انتقال زیر پشتیبانی میکند: پیشفرض، MQTT، CoAP، LWM2M و SNMP.
نوع انتقال پیشفرض
نوع انتقال پیشفرض برای سازگاری با نسخههای قبلی طراحی شده است. با استفاده از نوع انتقال پیشفرض، میتوانید همچنان از APIهای پیشفرض MQTT، HTTP، CoAP و LwM2M پلتفرم برای اتصال دستگاههای خود استفاده کنید. برای نوع انتقال پیشفرض تنظیمات خاصی وجود ندارد.
نوع انتقال MQTT
نوع انتقال MQTT امکان تنظیمات پیشرفته انتقال MQTT را فراهم میسازد. اکنون میتوانید فیلترهای موضوعات MQTT سفارشی را برای دادههای سریزمانی و بهروزرسانی ویژگیها که به ترتیب مربوط به API آپلود تلومتری و API بهروزرسانی ویژگیها هستند، مشخص کنید.
نوع انتقال MQTT شامل تنظیمات زیر است:
- فیلترهای موضوعات دستگاه MQTT
فیلترهای موضوعات MQTT سفارشی از کاراکترهای جانشین تکسطحی ‘+’ و چندسطحی ‘#’ پشتیبانی میکنند و به شما اجازه میدهند تقریباً به هر دستگاه مبتنی بر MQTT که با استفاده از JSON یا Protobuf پیام ارسال میکند، متصل شوید.
بیایید به مثالی نگاه کنیم که در آن از فیلترهای موضوعات دستگاه MQTT سفارشی برای انتشار دادههای سریزمانی با استفاده از اعتبارنامههای دستگاه "MQTT Basic" استفاده میکنیم:
- فیلتر موضوعات دستگاه MQTT سفارشی را برای پروفایل دستگاه مشخص کنید، به عنوان مثال:
- فیلتر موضوع تلومتری: /telemetry
- فیلتر موضوع ویژگیها: /attributes
- اعتبارنامههای پایه MQTT را برای دستگاه خود با شناسه مشتری 'c1'، نام کاربری 't1' و رمز عبور 'secret' ارائه دهید.
- از دستور زیر برای انتشار دادههای سریزمانی استفاده کنید. فراموش نکنید که $THINGSCONNECT_HOST_NAME را با میزبان خود جایگزین کنید.
mosquitto_pub -h '$THINGSBOARD_HOST_NAME' -i 'c1' -u 't1' -P 'secret' -t '/telemetry' -m '{"humidity": 10.3}'
- دادههای انتقال یافته در زبانه "تلومتری اخیر" دستگاه نمایش داده خواهند شد.
اگر از پیکربندی فیلترهای موضوع دستگاه MQTT استاندارد استفاده میکنید، میتوانید با استفاده از دستورات زیر دادههای سری زمانی و ویژگیها را منتشر کنید.
فراموش نکنید که $THINGSCONNECT_HOST_NAME را با نام میزبان خود جایگزین کنید.
- دستور برای انتشار دادههای سری زمانی:
mosquitto_pub -h '$THINGSBOARD_HOST_NAME' -i 'c1' -u 't1' -P 'secret' -t 'v1/devices/me/telemetry' -m '{"humidity": 10.3}'
- دستور برای بهروزرسانی ویژگیها:
mosquitto_pub -h '$THINGSBOARD_HOST_NAME' -i 'c1' -u 't1' -P 'secret' -t 'v1/devices/me/attributes' -m '{"firmwareVersion": "1.3"}'
- بار داده دستگاه MQTT
به طور پیشفرض، پلتفرم انتظار دارد که دستگاهها دادهها را از طریق JSON ارسال کنند. با این حال، امکان ارسال دادهها از طریق Protocol Buffers نیز وجود دارد.
Protocol Buffers یا Protobuf، یک روش زبانمحور و پلتفرمبیطرف برای سریالسازی دادههای ساختاریافته است. این روش برای کاهش اندازه دادههای ارسالی مناسب است.
نسخه کنونی پلتفرم ThingsConnect از اسکیماهای سفارشیسازیشده پروتو برای آپلود تلهمتری و آپلود ویژگیها پشتیبانی میکند و امکان تعریف یک اسکیما برای پیامهای داونلینک (تماسهای RPC و بهروزرسانی ویژگیها) را فراهم کرده است.
ThingsConnect به صورت پویا ساختارهای protobuf را تجزیه میکند، به همین دلیل برخی ویژگیهای protobuf مانند OneOf، extensions و maps را هنوز پشتیبانی نمیکند.
- سازگاری با سایر قالبهای payload
هنگامی که فعال باشد، پلتفرم به طور پیشفرض از قالب payload پروتوباف استفاده میکند. اگر تجزیه موفقیتآمیز نباشد، پلتفرم سعی میکند از قالب payload JSON استفاده کند. این قابلیت برای حفظ سازگاری با نسخههای قبلی در طول بهروزرسانیهای firmware مفید است. برای مثال، نسخه اولیه firmware از JSON استفاده میکند، در حالی که نسخه جدید از پروتوباف استفاده میکند. در طی فرآیند بهروزرسانی firmware برای ناوگان دستگاهها، لازم است که هر دو پروتوباف و JSON به طور همزمان پشتیبانی شوند.
حالت سازگاری مقداری کاهش در عملکرد را به همراه دارد، بنابراین توصیه میشود این حالت پس از بهروزرسانی همه دستگاهها غیرفعال شود.
نوع انتقال CoAP
نوع انتقال CoAP امکان تنظیمات پیشرفتهی این پروتکل را فراهم میکند. با استفاده از نوع انتقال CoAP، میتوانید نوع دستگاه CoAP را انتخاب کنید.
نوع دستگاه CoAP دارای تنظیمات زیر است:
- پیش فرض
به طور پیشفرض، نوع دستگاه CoAP دارای payload دستگاه CoAP تنظیمشده به JSON است که از API پایه CoAP مشابه نوع انتقال پیشفرض پشتیبانی میکند. با این حال، میتوان با تغییر پارامتر payload دستگاه CoAP به Protobuf، دادهها را از طریق Protocol Buffers ارسال کرد.
Protocol Buffers یا Protobuf یک روش زبان و پلتفرمبیطرف برای سریالسازی دادههای ساختار یافته است. این روش برای به حداقل رساندن اندازه دادههای ارسالی مناسب است.
نسخه فعلی پلتفرم ThingsConnect از schemaهای پروتوباف سفارشی برای بارگذاری تلماتری و بارگذاری ویژگیها پشتیبانی میکند و امکان تعریف schema برای پیامهای downlink (تماسهای RPC و بهروزرسانی ویژگیها) را فراهم کرده است.
ThingsConnect بهطور پویا ساختارهای protobuf را تجزیه میکند، به همین دلیل هنوز برخی ویژگیهای protobuf مانند OneOf، extensions و maps را پشتیبانی نمیکند.
- Efento NB-IoT
نسخه کنونی پلتفرم ThingsConnect از ادغام با سنسورهای زیر از سری Efento NB-IoT پشتیبانی میکند:
- دما
- رطوبت
- فشار هوا
- فشار تفاضلی
- باز/بسته
- نشت
- ورودی/خروجی
نیازمند دستگاههای Efento با نسخه فریمور: 06.02 و بالاتر.
قوانین هشدار
کاربران پلتفرم میتوانند از Rule Engine برای پیکربندی هشدارها استفاده کنند. Rule Engine ویژگی قدرتمند و پیشرفتهای است که نیازمند دانش برنامهنویسی میباشد. از نسخه 3.2 ThingsConnect به بعد، قوانین هشدار (Alarm Rules) معرفی شدهاند تا فرآیند پیکربندی انواع مختلف هشدارها را سادهتر کنند. اکنون برای تنظیم منطق پردازش نیازی به تخصص عمیق در Rule Engine نیست. در پسزمینه، Rule Engine قوانین هشدار را با استفاده از نود قانون Device Profile ارزیابی میکند.
ویژگیهای زیر در قانون هشدار وجود دارد:
نوع هشدار (Alarm Type) - نوع هشدار را مشخص میکند. نوع هشدار باید درون قوانین هشدار پروفایل دستگاه منحصر به فرد باشد.
ایجاد شرایط (Create Conditions) - معیارهایی را تعریف میکند که بر اساس آنها هشدار ایجاد یا بهروزرسانی میشود. این شرایط شامل ویژگیهای زیر است:
شدت (Severity) - برای ایجاد یا بهروزرسانی هشدار استفاده میشود. ThingsConnect شرایط ایجاد هشدار را بر اساس شدت به ترتیب نزولی ارزیابی میکند. به عنوان مثال، اگر شرایط با شدت "بحرانی" (Critical) برقرار باشد، پلتفرم هشدار با شدت "بحرانی" را صادر میکند و دیگر شرایط با شدتهای "عمده" (Major)، "کماهمیت" (Minor) یا "هشدار" (Warning) ارزیابی نخواهند شد. شدت باید برای هر قانون هشدار منحصر به فرد باشد (یعنی دو شرط در یک قانون هشدار نمیتوانند شدت مشابهی داشته باشند).
- فیلترهای کلیدی (Key Filters) - لیستی از عبارات منطقی بر اساس ویژگیها یا مقادیر تلماتری است. برای مثال، “(temperature < 0 OR temperature > 20) AND softwareVersion = ‘2.5.5’”.
- نوع شرط (Condition Type) - میتواند ساده، مدتدار یا تکراری باشد. به عنوان مثال، سه بار متوالی یا در طول ۵ دقیقه. شرط ساده هشدار را پس از اولین وقوع رویداد مطابق صادر میکند.
- برنامهریزی (Schedule) - زمانبندی فعال بودن قانون را تعریف میکند. میتواند "فعال در تمام طول زمان"، "فعال در زمان خاص" یا "سفارشی" باشد.
- جزئیات (Details) - الگوی جزئیات هشدار از جایگزینی مقادیر تلماتری و/یا ویژگیها با استفاده از نحوهی نوشتار ${attributeName} پشتیبانی میکند.
- شرط پاکسازی (Clear Condition) - معیارهایی را تعریف میکند که بر اساس آنها هشدار پاک میشود.
- تنظیمات پیشرفته (Advanced Settings) - انتشار هشدار به داراییهای مرتبط، مشتریان، مستأجران یا سایر موجودیتها را تعریف میکند.
بیایید با یک مثال نحوه استفاده از قوانین هشدار را بررسی کنیم. فرض کنید که میخواهیم دمای داخل یخچالی که حاوی کالاهای ارزشمند است را زیر نظر داشته باشیم. همچنین فرض میکنیم که پروفایل دستگاهی به نام "سنسورهای دما" ایجاد کردهایم و دستگاه خود را با یک سنسور دما و توکن دسترسی پیکربندی کردهایم. با استفاده از دستور زیر، میتوانید دادههای دما را بارگذاری کنید.
mosquitto_pub -d -h '$THINGSBOARD_HOST_NAME' -t "v1/devices/me/telemetry" -u "$ACCESS_TOKEN" -m '{"temperature": 5.3}'
کجا:
- $THINGSCONNECT_HOST_NAME - نام میزبان محلی شما یا آدرس پلتفرم؛
- $ACCESS_TOKEN - توکن دسترسی دستگاه.
مثال 1. شرایط هشدار ساده
ما میخواهیم یک هشدار بحرانی (Critical) ایجاد کنیم هنگامی که دما بیش از 10 درجه سانتیگراد باشد.
- مرحله 1: پروفایل دستگاه را باز کرده و حالت ویرایش را فعال کنید.
- مرحله 2: بر روی دکمه "افزودن قانون هشدار" کلیک کنید.
- مرحله 3: نوع هشدار را وارد کرده و بر روی علامت قرمز "+" کلیک کنید.
- مرحله 4: بر روی دکمه "افزودن فیلتر کلیدی" کلیک کنید.
- مرحله 5: نوع کلید را به "Timeseries" انتخاب کرده، نام کلید "temperature" را وارد کنید. نوع "Value type" را به "Numeric" تغییر دهید و سپس بر روی دکمه "افزودن" کلیک کنید.
- مرحله 6: عملگر "بزرگتر از" را انتخاب کرده و مقدار آستانه را وارد کنید. سپس بر روی "افزودن" کلیک کنید.
- مرحله 7: بر روی دکمه "ذخیره" کلیک کنید.
- مرحله 8: در نهایت، تغییرات را اعمال کنید.
مثال 2. شرایط هشدار با مدتزمان
فرض کنیم که میخواهیم مثال 1 را تغییر دهیم و هشدارها را تنها در صورتی فعال کنیم که دما به مدت 1 دقیقه از آستانه مشخصی تجاوز کند.
برای این کار، باید شرط هشدار را ویرایش کرده و نوع شرط را از "ساده" به "مدتدار" تغییر دهیم. همچنین باید مقدار و واحد مدتزمان را مشخص کنیم.
- مرحله 1: شرط هشدار را ویرایش کرده و نوع شرط را به "مدتدار" تغییر دهید. سپس مقدار و واحد مدتزمان را تعیین کرده و شرط را ذخیره کنید.
- مرحله 2: تغییرات را اعمال کنید.
حال فرض کنید که میخواهید مدتزمان 1 دقیقه را با مقداری پویا که به تنظیمات دستگاه خاص، مشتری یا مستأجر بستگی دارد، جایگزین کنید.
برای این کار، باید از ویژگی Server-Side Attributes استفاده کنید.
لطفاً یک ویژگی سمت سرور به نام “highTemperatureDurationThreshold” با مقدار عددی “1” برای دستگاه خود ایجاد کنید.
مرحله 3: شرط هشدار را ویرایش کنید. برای دسترسی به مقدار پویا تأخیر هشدار، بر روی دکمه "انتقال به مقدار پویا" کلیک کنید.
مرحله 4: یکی از گزینهها را انتخاب کنید: دستگاه فعلی، مشتری فعلی یا مستأجر فعلی. سپس ویژگیای را مشخص کنید که مقدار آستانه هشدار از آن گرفته میشود. بهطور اختیاری میتوانید گزینه "وراثت از مالک" را انتخاب کنید. این ویژگی به این معناست که اگر مقدار آستانه در سطح دستگاه تنظیم نشده باشد، از مشتری گرفته میشود. اگر مقدار ویژگی در هر دو سطح دستگاه و مشتری تنظیم نشده باشد، قانون مقدار را از ویژگیهای مستأجر دریافت میکند.
مرحله 5: تمامی تغییرات را اعمال کنید.
مثال 3. شرایط هشدار تکراری
فرض کنیم که میخواهیم مثال 1 را تغییر دهیم و هشدارها را تنها زمانی فعال کنیم که سنسور دما گزارش دهد که دما به مدت سه بار متوالی از آستانه مشخص شده است.
برای این کار، باید شرط هشدار را ویرایش کرده و نوع شرط را از "ساده" به "تکراری" تغییر دهیم. همچنین باید "3" را به عنوان "تعداد رویدادها" مشخص کنیم.
- مرحله 1: شرایط هشدار را ویرایش کرده و نوع شرط را به "تکرار شونده" تغییر دهید. مقدار "3" را به عنوان "تعداد رویدادها" برای فعالسازی هشدار مشخص کنید. این مقدار به طور پیشفرض استفاده خواهد شد، اگر برای دستگاه شما ویژگیای تنظیم نشده باشد. شرایط را ذخیره کنید.
- مرحله 2: تغییرات را اعمال کنید.
اکنون فرض کنید که میخواهید تعداد معینی از دفعاتی که شرایط هشدار تجاوز میکند را با یک مقدار پویا که به تنظیمات دستگاه، مشتری یا مستأجر خاص بستگی دارد، جایگزین کنید.
برای این منظور، باید از ویژگی ویژگیهای سمت سرور استفاده کنید.
لطفاً یک ویژگی سمت سرور با نام «highTemperatureRepeatingThreshold» ایجاد کنید و مقدار صحیح «3» را برای دستگاه خود تنظیم نمایید.
مرحله 4: به مقدار پویا برای شرایط هشدار تکرار شونده بروید و دکمه «تغییر به مقدار پویا» را فشار دهید؛
مرحله 5: یک گزینه را انتخاب کنید: دستگاه جاری، مشتری جاری یا مستأجر جاری. سپس ویژگیای را که مقدار از آن گرفته خواهد شد، مشخص کنید و تعیین نمایید که آستانه باید چند بار تجاوز کند تا هشدار فعال شود. بهطور اختیاری، میتوانید گزینه «به ارث بردن از مالک» را علامت بزنید. این ویژگی به شما این امکان را میدهد که مقدار آستانه را از مشتری دریافت کنید اگر در سطح دستگاه تنظیم نشده باشد. اگر مقدار ویژگی در هر دو سطح دستگاه و مشتری تنظیم نشده باشد، قانون مقدار را از ویژگیهای مستأجر میگیرد؛
مرحله 6: تمام تغییرات را اعمال کنید.
مثال 4: قانون حذف هشدار
فرض کنید بخواهیم هشدار را بهطور خودکار پاک کنیم اگر دمای یخچال به حالت طبیعی برگردد.
مرحله 1: پروفایل دستگاه را باز کرده و حالت ویرایش را فعال کنید. روی دکمه «افزودن شرط پاکسازی» کلیک کنید.
مرحله 2: روی علامت قرمز "+" کلیک کنید.
مرحله 3: فیلتر کلید را اضافه کنید. سپس روی «افزودن» کلیک کنید.
مرحله 4: شرایط قانون هشدار را ذخیره کنید.
مرحله 5: در نهایت، تغییرات را اعمال کنید.
مثال 5: تعریف برنامه زمانی قانون هشدار
فرض کنید بخواهیم قانون هشدار تنها در ساعات کاری به ارزیابی هشدارها بپردازد.
- مرحله 1: برنامه زمانی قانون هشدار را ویرایش کنید.
- مرحله 2: منطقه زمانی، روزها و بازه زمانی را انتخاب کرده و روی «ذخیره» کلیک کنید.
- مرحله 3: در نهایت، تغییرات را اعمال کنید.
مثال 6: آستانههای پیشرفته
فرض کنید بخواهیم به کاربران این امکان را بدهیم که آستانهها را از رابط کاربری داشبورد تغییر دهند. همچنین میتوانیم پرچمهایی اضافه کنیم تا هشدارهای خاص را برای هر دستگاه فعال یا غیرفعال کنیم. برای این منظور، از مقادیر پویا در شرایط قانون هشدار استفاده خواهیم کرد. ما از دو ویژگی استفاده خواهیم کرد: ویژگی بولی «temperatureAlarmFlag» و ویژگی عددی «temperatureAlarmThreshold». هدف ما این است که هنگامی که «temperatureAlarmFlag = True» و دما بیشتر از «temperatureAlarmThreshold» باشد، یک هشدار ایجاد کنیم.
- مرحله 1: فیلتر کلید دما را تغییر داده و نوع مقدار را به پویا تغییر دهید.
- مرحله 2: نوع منبع پویا را انتخاب کرده و temperatureAlarmThreshold را وارد کنید، سپس روی «بهروزرسانی» کلیک کنید. بهطور اختیاری میتوانید گزینه «به ارث بردن از مالک» را علامت بزنید. وراثت به شما این امکان را میدهد که مقدار آستانه را از مشتری دریافت کنید اگر در سطح دستگاه تنظیم نشده باشد. اگر مقدار ویژگی در هر دو سطح دستگاه و مشتری تنظیم نشده باشد، قانون مقدار را از ویژگیهای مستأجر میگیرد.
- مرحله 3: فیلتر کلید دیگری برای temperatureAlarmFlag اضافه کنید، سپس روی «افزودن» کلیک کنید.
- مرحله 4: در نهایت، روی «ذخیره» کلیک کرده و تغییرات را اعمال کنید.
- مرحله 5: ویژگیهای دستگاه را بهصورت دستی یا از طریق اسکریپت تنظیم کنید.
مثال 7: آستانههای پویا بر اساس ویژگیهای مستأجر یا مشتری
مثال 6 نحوه فعال یا غیرفعال کردن قانون بر اساس مقدار ویژگی «temperatureAlarmFlag» دستگاه را نشان میدهد. اما اگر بخواهید قانونی خاص را برای تمام دستگاههایی که به یک مستأجر یا مشتری تعلق دارند، فعال یا غیرفعال کنید، چه باید کرد؟ برای جلوگیری از نیاز به پیکربندی ویژگی برای هر دستگاه بهطور جداگانه، میتوانید قانون هشدار را طوری پیکربندی کنید که مقدار ثابت را با مقدار ویژگی مستأجر یا مشتری مقایسه کند. برای این منظور، باید از نوع کلید «ثابت» استفاده کرده و آن را با مقدار پویا مقایسه کنید. مثال پیکربندی زیر را مشاهده کنید:
نوع و مقدار ثابت را انتخاب کرده و آن را با مقدار ویژگی مستأجر یا مشتری مقایسه کنید. سپس تغییرات را اعمال کنید.
از تکنیک مذکور میتوان برای فعال یا غیرفعال کردن قوانین، یا ترکیب فیلترها بر روی دادهها و ویژگیهای دستگاه با فیلترها بر روی ویژگیهای مستأجر یا مشتری استفاده کرد.