أجهزة Bluetooth Mesh بالبطارية: لماذا تُبلّغ سريعاً ولا تستقبل التحكم فوراً؟

تخيّل حساس باب يعمل بالبطارية: عند فتحه يصل إشعار الهاتف سريعاً، لكن تغيير إعداداته من الهاتف يحتاج وقتاً حتى يصبح نافذاً.

لماذا يستطيع الجهاز نفسه الإبلاغ بسرعة، بينما يتأخر الاستقبال؟

ليس السبب بالضرورة ضعف الإشارة أو تعطل البرنامج. قد يتبع جهاز Bluetooth Mesh منخفض الطاقة إيقاعاً مختلفاً للإرسال والاستقبال.

الجواب المختصر: الحدث المحلي قد يوقظه للإرسال، بينما تُحفظ الرسائل الواردة أثناء النوم لدى Friend حتى يطلبها. افصل المسارين لتعرف أين يحدث الانتظار.

نوضح كيف يقلل الجهاز الاستماع، وكيف يحتفظ Friend بالرسائل، وكيف تفحص أثر التوفير على الاستجابة المطلوبة.

حساس الباب مثال افتراضي وليس تجربة مقاسة. نتناول آليات SIG Mesh Low Power وFriend؛ يجب التحقق من SDK واللوحة والمنصة على حدة. لم نجر اختبارات عمر بطارية أو تأخير.

1. ابدأ بالرسم: القدرة على الإرسال لا تعني الاستقبال الدائم

تخيّل شخصاً لا يراقب صندوق البريد طوال الوقت: يستطيع الخروج لتسليم رسالة، بينما يحتفظ الجار بالبريد الوارد حتى يأتي لاستلامه.

الجار هو Friend، والعقدة التي تستخدم الميزة منخفضة الطاقة هي Low Power Node أو LPN. التشبيه يشرح توقيت الاستقبال؛ لا يضمن التسليم ولا يعني أن Friend يوقظ شريحة نائمة عن بُعد.

افحص أولاً: ارسم الإبلاغ عن الأحداث والإعداد عن بُعد منفصلين. قد تشمل جهة الهاتف بوابة وسحابة وذاكرات مؤقتة؛ لا تنسب كل انتظار إلى راديو Mesh.

2. لماذا يرسل الزر بينما ينتظر تغيير الإعداد؟

توضح Silicon Labs أن LPN يستطيع الإرسال دون انتظار الاستطلاع التالي للرسائل. أما سرعة إيقاظه بزر أو تماس الباب فتعتمد على العتاد والتطبيق.

• حدث محلي: حدث ← إيقاظ ومعالجة ← إرسال ← معالجة الطرف الآخر.
• رسالة هابطة: وصول إلى Friend ← انتظار الطلب ← استقبال ومعالجة LPN ← تقرير النتيجة إن لزم.

عدم انتظار الاستطلاع لا يضمن سرعة من طرف إلى طرف؛ فالقياس والإعادات والطبقات العليا مؤثرة أيضاً. وبطء النزول لا يثبت بطء كل حدث صادر. إشعار فتح سريع لا يكفي للوعد بتطبيق الإعداد فوراً.

افحص أولاً: سجّل الحدث والإرسال وانتظار Friend وطلب LPN وتطبيق الإعداد فعلياً. لا تطرح أوقات أجهزة غير متزامنة مباشرة.

3. لماذا يتطلب التوفير أكثر من إرسال رسائل أقل؟

الحساس الذي يُبلغ نادراً قد يستهلك كثيراً إن بقي مستقبله مفتوحاً.

تشرح Bluetooth SIG ميزة Low Power بخفض زمن تشغيل المستقبل. بعد إنشاء العلاقة يستطيع LPN تقليل الاستماع المستمر، ويخزن Friend الرسائل المناسبة لاسترجاعها لاحقاً.

لكن Friend ليس صندوقاً بلا حدود. عدد العقد والرسائل والاشتراكات تابع للتنفيذ والموارد. التراكم والإعادات وتكرار إنشاء العلاقة قد تزيد الاستهلاك.

افحص أولاً: ماذا يحدث في منحنى التيار: قياس أم مسح أم إرسال أم استرجاع أم بحث عن Friend؟ أدنى تيار نوم في ورقة الشريحة لا يصف المنتج كله.

4. هل تكبير PollTimeout يوفر أكثر؟

ليس بالضرورة. فرّق بين تكرار جمع الرسائل والمدة المسموحة دون تواصل قبل انتهاء العلاقة.

فاصل الاستطلاع الفعلي تحدده جدولة المكدس والتطبيق، وقد يتكرر الاستطلاع عند بقاء رسائل.

PollTimeout مهلة لصيانة Friendship. قد ينهي Friend العلاقة إذا لم تصل الطلبات المطلوبة خلال الزمن المحدد. ليست مؤقت إيقاظ التطبيق ولا قياس تأخير النزول.

ReceiveDelay يخص الانتظار من طلب LPN حتى بدء الاستماع، وReceiveWindow يخص نافذة الاستقبال. لا يساويان تلقائياً دورة عملية التطبيق.

تقليل تكرار الجمع يجعل بعض الرسائل تنتظر عادةً، لكن الصفوف والإعادات والتنفيذ تؤثر أيضاً. لا يضمن معامل واحد زمناً أقصى للتسليم.

افحص أولاً: سياسة استطلاع التطبيق ومعاملات الصيانة والتوقيت المرصود معاً، لا حقل timeout وحده.

5. لماذا قد يزيد استهلاك الحساس عند إطفاء مصباح؟

افترض أن مصباحاً يدعم Friend يخدم العقدة، ثم يفصل المستخدم طاقته بمفتاح ميكانيكي. لن تواصل علاقة الاستقبال القديمة العمل كالمعتاد.

تنبه Silicon Labs إلى ضرورة إعادة إنشاء العلاقة بعد إعادة تشغيل Friend أو LPN. ضعف الإشارة الذي يكرر الفقد والإنشاء يزيد الاستهلاك كذلك. البحث في حلقة مشغولة ليس توفيراً؛ صمّم تراجعاً زمنياً واستعادة يناسبان التنفيذ.

الموقع مهم: توضح مقدمة Bluetooth SIG أن Friend Request لا يُرحَّل. دعم الرسائل العادية لقفزات متعددة لا يعني اكتشاف Friend عبر عدد اعتباطي من القفزات.

Friend وRelay وبوابة التطبيق أدوار مختلفة. الترحيل لا يعني تخزين رسائل LPN، واسم «بوابة» لا يضمن إتاحة Friend. ولا يُفترض أن عقدة البطارية ترحّل باستمرار للآخرين.

افحص أولاً: إمكانات المرشح والوصول اللاسلكي المباشر وعادات تغذيته، ثم اختبر انقطاعه. لا تفترض انتقال الصف القديم أو التبديل دون انقطاع.

6. قِس متوسط تيار المنتج قبل توقع عمر البطارية

بين وضع التوفير ووعد العمر يوجد منتج كامل: حساسات ومنظم وLED وأداة تصحيح وسجلات. تشمل الأحمال القياس واستخدام العميل والتقارير والاسترجاع والإعادات والبحث.

متوسط التيار ≈ مجموع تيار كل حالة × مدتها ÷ زمن المراقبة الكلي.

على أساس متسق من جانب البطارية: السعة المتاحة (mAh) ÷ متوسط التيار (mA) ≈ ساعات التشغيل. مع تحويل الجهد، احسب الكفاءة أو استخدم أساس طاقة موحداً؛ لا تخلط طرفي المحوّل.

هذا ليس ضماناً: الحرارة والتقادم والتفريغ الذاتي وقدرة النبضات وجهد القطع تغير السعة القابلة للاستخدام.

افحص أولاً: التشغيل المستقر واستعادة الأعطال منفصلين. مقطع خمول قصير بعد الإعداد بإشارة جيدة لا يمثل الدورة كاملة. وعند انخفاض الشحنة راقب هبوط الجهد وأخطاء الاتصال.

7. احتفظ بالقائمة لاختبار النموذج الأولي

هذه فحوص هندسية وليست اعتماداً. استخدم بيئة معزولة واتفق على الحمل والانتظار المقبول ومعيار النجاح قبل القياس.

الظاهرة	ما يُفحص أولاً	لا تستنتج بسرعة
الإبلاغ يعمل والإعداد ينتظر	المساران والاستطلاع والصف وزمن التطبيق	الإشارة سيئة حتماً
نوم منخفض لكن استهلاك المنتج مرتفع	القياس والاستماع والإرسال والإعادات والدوائر	تغيير البطارية أو الشريحة يكفي
خلل بعد فصل Friend	فقد العلاقة والتراجع وإعادة الإنشاء والاستعادة	الصف ينتقل والتبديل سلس دائماً
إعدادات متلاحقة تعطي نتيجة غير متوقعة	حدود الصف ومعالجة التطبيق والحالة النهائية	كل أمر قديم محفوظ للأبد
نقص رسائل المجموعة	اشتراكات النموذج وFriend والحمل	الإرسال الجماعي يضمن نجاح الجميع
فقد اتصال عند شحنة منخفضة	جهد الإرسال وقدرة التغذية والاستعادة	كامل السعة الاسمية متاح

سجّل اللوحة وSDK والمعاملات والموقع ونافذة المراقبة. أخف هويات الأجهزة ولا تنشر NetKey أوAppKey أوDevKey أو المفاتيح الخاصة.

ابدأ الاختيار بهذه الأسئلة:

• هل الغالب أحداث صادرة متباعدة؟ قيّم LPN وFriend مع قياس الحمل الحقيقي.
• هل الاستقبال في الوقت المناسب ضروري؟ اتفق على الانتظار واختبر السياسة وميزانية البطارية معاً.
• هل تريد استعداداً طويلاً واستقبالاً فورياً وترحيلاً دائماً؟ تحقّق من توافق الأهداف قبل الوعد بالعمر.

السؤال المفيد ليس مجرد دعم Bluetooth Mesh للبطاريات: متى يستيقظ الجهاز، وماذا يفعل، وما السلوك حين يتعذر الاستقبال مؤقتاً؟ أجب أولاً ثم ناقش المدة.

للمتابعة: قائمة اختيار وقبول Bluetooth Mesh.

المصادر ونطاق التطبيق

• Bluetooth SIG: Bluetooth Mesh Networking: Friendship، 2017-08-24. مقدمة تاريخية للآليات وليست بديلاً عن المواصفة الحالية للمشروع.
• Silicon Labs: Bluetooth Mesh Node Power Consumption, 11.0.1. الإرسال والنوافذ والاستعادة والطاقة؛ اعتمد SDK الفعلي.

رُوجعت المصادر في 2026-11-06. هذا تحليل وثائق وتوصيات هندسية، وليس تجربة شخصية أو ضماناً مقاساً للعمر أو التأخير أو السعة.