اختبار بوابة Matter: من ردود UART إلى مزامنة الحالة مع Apple Home

تصل لوحات التطوير، تضغط زرًا على الهاتف، فيضيء المصباح. في مشروع للمنزل الذكي، قد تبدو هذه اللحظة وكأن الجزء الأصعب انتهى.

ثم تفصل كهرباء المصباح، وقد يظل الهاتف يعرضه مضاءً. تعيد تشغيل البوابة، وربما تحتاج إلى إضافة الجهاز مجددًا. تطفئ الضوء بزر المصباح، لكن أيقونة Apple Home لا تتغير.

هذه مشكلات مختلفة: تنفيذ الأوامر، ومزامنة الحالة، والاستعادة. عرض ناجح واحد لا يكشفها بالضرورة.

تناولت قائمة لوحات التطوير والأدوات المعدات المطلوبة. هنا أحدد الأدلة التي ينبغي أن تنتجها جولة التكامل الأولى، والشروط اللازمة قبل الانتقال إلى الخطوة التالية.

نموذج Matter على الحاسوب يتصل بالفعل بـApple Home، وبُنيت صورة Linux. أما التوافق الفعلي بين NCP من Silicon Labs وأجهزة Telink، واستقبال حالات المصابيح الحقيقية، واستعادة المنظومة كاملة، فما زالت تحتاج إلى اختبار. هذه خطة قبول أولية، وليست تقريرًا عن تجارب عتاد مكتملة أو نتائج مقاسة.

مصباح واحد وإصدارات ثابتة

يتصل Apple Home ببوابة Linux عبر الشبكة المحلية. وتستدعي البوابة وظائف Bluetooth Mesh NCP من Silicon Labs عبر UART/BGAPI، ثم يتحكم NCP بجهاز Telink. ويجب أن تعود حالة الجهاز عبر الطبقات نفسها.

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

قبل الاختبار، نسجل معرّف نسخة برنامج المضيف، وإصدارات برنامج NCP الثابت وSDK، وإصدار الجهاز، وإعدادات المنفذ التسلسلي. ونصور التوصيلات، خصوصًا مستويات الجهد والأرضي وRTS/CTS. تغيير برنامج المضيف والبرنامج الثابت معًا يجعل معرفة سبب التحسن صعبة.

أبدأ بمثال المضيف الرسمي المرفق مع SDK المختار، ثم أستبدله ببرنامجنا المكتوب بـRust مع تثبيت العتاد والبرامج الثابتة. إذا فشل المثال الرسمي أيضًا، نراجع قدرات البرنامج الثابت وإعداد النماذج. وإذا فشل برنامجنا وحده، نركز على تحليل الإطارات وترتيب الاستدعاءات.

أربعة معانٍ مختلفة للنجاح

الطبقة	ما الذي تثبته؟	ما الذي لا تثبته بعد؟
الكتابة إلى UART	تسليم البايتات إلى الواجهة	أن NCP حللها بصورة صحيحة
وصول رد BGAPI	أن NCP أعاد نتيجة استدعاء API	أن المصباح نفذ الأمر
وصول حالة الجهاز	أن النموذج البعيد أبلغ عن حالة حالية أو مستهدفة	أن سمات Matter والهاتف تزامنت
تطابق Apple Home	أن العرض يطابق النتيجة المرصودة	أن الصحة ستستمر بعد انقطاع أو إعادة تشغيل

معنى رد BGAPI يتحدد بحسب الأمر. لا يعني كل رمز نجاح أن الضوء أضيء بالفعل. كما يمكن للأحداث غير المتزامنة أن تتداخل مع الردود، فلا يصح بناء المحلل على افتراض «إرسال واحد ثم قراءة واحدة».

أخطط لمنح كل عملية معرّفًا داخل برنامج المضيف، يربط الجهاز والحالة المطلوبة ووقت الإرسال ورد API وحدث الحالة والنتيجة. هذا معرّف داخلي للتطبيق، ولا يعني أن BGAPI أو كل رسالة Mesh ستعيده.

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

الانضمام إلى الشبكة لا يكفي

نجاح تهيئة الجهاز وإدخاله إلى الشبكة لا يثبت إمكان التحكم به. نقرأ Composition Data لتحديد العنصر والنموذج المسؤولين عن الوظيفة، ثم نضيف AppKey ونربطه بالنموذج ونضبط النشر والاشتراك اللازمين.

قد يتشارك جهازان يدعمان Bluetooth Mesh في بعض النماذج القياسية فقط. وظائف الشركة الخاصة تحتاج إلى تكييف منفصل.

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

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

ثلاثة مسارات تُختبر منفصلة

المسار الأول هو التحكم بالمصباح من المضيف دون Matter. نراقب التغير الحقيقي ثم الحالة التي تصل. وإذا كان الجهاز يدعم انتقالًا تدريجيًا، نفصل القيمة الحالية عن الهدف والزمن المتبقي؛ الوصول المتوقع ليس تنفيذًا مكتملًا.

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

المسار الثالث هو التحكم بالمصباح الحقيقي من Apple Home: أمر الهاتف، وتنفيذ الجهاز، واستقبال البوابة للحالة، ثم تحديث سمات Matter وإرسال تقاريرها إلى المتحكم. بعد ذلك نغير المصباح محليًا ونتحقق من متابعة الهاتف.

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

سأفصل الحالة المطلوبة عن آخر حالة فعلية مؤكدة. الطلب ينشئ عملية معلقة، والتقرير المناسب يؤكد النتيجة. وإذا حدث تحديث تفاؤلي في الواجهة، فيجب تحديد مهلة وطريقة تصحيح. نجاح الكتابة إلى UART لا يبرر إبقاء مصباح مفصول الكهرباء مسجلًا كمضاء إلى أجل غير محدد.

معيار أولي قابل للقياس

خطتي هي تنفيذ 20 دورة تشغيل وإطفاء لمصباح واحد على مسافة قصيرة ثابتة، مع انتظار انتهاء كل عملية قبل التالية. نسجل أزمنة التغير الفعلي ووصول الحالة وتحديث الهاتف بشكل منفصل. ستكون خمس ثوانٍ الحد الأولي للانتظار من البداية إلى النهاية؛ تجاوزها إخفاق تُحفظ سجلاته.

الدورات العشرون والثواني الخمس معياران مؤقتان لهذا المشروع، وليسا متطلبين في Matter أو Bluetooth Mesh ولا أداءً مقاسًا. الهدف جعل النتائج قابلة للمقارنة، ثم تعديل العتبة وفق قدرات الجهاز وتجربة الاستخدام.

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

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

عطل واحد في كل مرة

بعد نجاح التحكم الطبيعي، نختبر الحالات التالية، ونعود إلى وضع مستقر بين كل حالتين.

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

عدم الرد على استعلام واحد لا يكفي دائمًا للحكم بأن الجهاز غير متصل. نحدد نافذة مراقبة وعدد إخفاقات ونسجل سبب القرار. تختلف السياسة بحسب الطاقة وآلية الإبلاغ والشبكة؛ لا تناسب قاعدة heartbeat واحدة كل العقد.

منع التكرار يحتاج إلى هوية وربط ثابتين. لا يمكن منح المصباح رقم نقطة نهاية Matter جديدًا عند كل إعادة اكتشاف. يجب حفظ العلاقة بين الجهاز والعنصر ونقطة النهاية الممثلة عبر الجسر، واستعادتها وفق متطلبات المكدس.

مفاتيح Mesh وتخصيص العناوين وأرقام التسلسل وحالة الحماية من إعادة الإرسال تحتاج أيضًا إلى حفظ واستعادة بالآليات الصحيحة. نحدد ما يحفظه NCP وما يحفظه المضيف. إضافة قيمة يدوية إلى رقم التسلسل ليست حلًا عامًا لفقد الطاقة.

هذه الاختبارات تعيد تشغيل العتاد الأصلي. استبدال NCP مسألة أخرى تتضمن نقل حالته الدائمة، ولا يثبت نجاح إعادة التشغيل إمكان الاستبدال.

حفظ الأدلة قبل ضبط المصنع

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

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

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

ويجب تحديد المقصود بالحذف. إزالة البوابة من منصة Matter تختلف عن إزالة مصباح Mesh وإعادة ضبطه. تنظيف اقتران الهاتف لا ينبغي أن يمحو الشبكة التابعة كلها.

متى نضيف أجهزة أخرى؟

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

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

أهم ما نبنيه مبكرًا هو القدرة على تحديد موضع الخلل: أين توقف الأمر، وما آخر حالة موثوقة للجهاز عندما أخطأ الهاتف؟ هذه قاعدة مناسبة لإضافة وظائف جديدة.

قراءات مرتبطة

• اختيار لوحات بوابة Matter والتحقق منها
• Rust وrs-matter لربط الأجهزة بـApple Home
• مرجع Silicon Labs Bluetooth Mesh API: راجع إصدار SDK المستخدم لمعاني الأوامر والردود والأحداث الدقيقة.

إذا كنت تطور جسرًا بين Bluetooth Mesh وMatter، يسعدني تبادل الخبرات حول المزامنة والاستعادة: تواصل معي.