استعادة إعداد Wi-Fi عبر AP وتصميم اختبارات القبول

يصبح مسار إعداد Wi-Fi جاهزًا للمنتج عندما يستطيع المستخدم التعافي من بيانات اتصال خاطئة أو غياب الموجه أو انقطاع الإعداد أو الكهرباء دون إعادة تفليش البرنامج الثابت. صمّم الإعداد كآلة حالات ذات حدود زمنية ونتيجة ظاهرة وبيانات اتصال محمية وطريق مقصود للعودة إلى الضبط. نجاح إرسال HTTP إلى الجهاز مجرد خطوة في هذه العملية.

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

حدد النجاح قبل تصميم الشاشة

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

لا تعتبر تعطل السحابة دليلًا على خطأ كلمة مرور Wi-Fi. إذا نجح Wi-Fi وDHCP وتعذر الوصول إلى الخلفية، احتفظ بحالة منفصلة هي «الشبكة مهيأة، الخدمة غير متاحة». تقرر سياسة المنتج هل تكفي لإتمام التركيب، بدل إعادة المستخدم مرارًا إلى نموذج كلمة المرور.

حدد نطاقات الموجه المدعومة وأنماط الأمان وترميز SSID وطوله وسير الشبكات المخفية ومتطلبات شبكات المؤسسات. الوحدة التي تدعم 2.4 GHz فقط لا تصل إلى شبكة 5 GHz فقط بإعادة المحاولة. يحتاج WPA-Enterprise والبوابات المقيدة الصاعدة وشبكات الشركات المدارة إلى دعم صريح أو استثناء واضح.

اجعل تغيير الإعدادات معاملاتيًا

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

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

تخزن بعض مديرات SDK بيانات الاتصال قبل انتهاء تحقق التطبيق. مثلًا توثق ESP-IDF 5.2.6 فحص البيانات المخزنة وسلوك الفشل وإعادة التشغيل في دليل تهيئة Wi-Fi. تعامل مع ذلك كقيد تكامل خاص بالإصدار. تحقق من API إعادة الضبط والتهيئة للمدير المختار، وابن نموذج حالات المنتج حولها؛ وجود بيانات اتصال لا يعني نجاح التركيب.

احتفظ بمدخل استعادة متعمد

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

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

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

صمّم لاحتمال فقدان مسار الهاتف

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

لتعايش AP والمحطة قيود خاصة بالراديو. توضح وثائق ESP32 أن الوضعين يشتركان في قناة العمل مع أولوية للمحطة؛ لذا قد يؤثر الانضمام إلى موجه على قناة أخرى في اتصال الإعداد. راجع دليل برنامج تشغيل Wi-Fi ثم تحقق من إصدار SDK والوحدة الفعليين. تتطلب شرائح Linux أيضًا مجموعات واجهات يدعمها برنامج التشغيل؛ لا تستنتج عمل AP وSTA معًا من عرضين منفصلين.

اجعل نقطة الحالة تتحمل إعادة الاتصال. خزّن أحدث نتيجة بصورة مستقلة عن اتصال HTTP، وأدرج معرف المحاولة والمرحلة ورمز سبب آمنًا. امنع علامة تبويب قديمة من الكتابة فوق محاولة أحدث ناجحة.

احمِ نقل بيانات الاتصال والتشخيص

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

لا تنسخ تسجيلًا نموذجيًا يطبع كلمة مرور Wi-Fi. سجّل المرحلة والزمن المنقضي وسبب فصل SDK وعدد المحاولات وإصدار البرنامج ومعرف شبكة مخفي التفاصيل. قيد تصدير التشخيص وامسح البيانات المرشحة المؤقتة عند انتهاء الحاجة إليها. حدد المحاولات والجلسات المتزامنة، ومن يملك التحكم إذا حاول هاتفان إعداد الوحدة نفسها.

تحتاج الأسباب المختلفة إلى إجراءات مختلفة. رفض المصادقة يستدعي فحص البيانات أو نمط الأمان. عدم العثور على AP مطابق يوجه إلى النطاق أو المدى أو SSID المخفي أو سياسة البحث. مهلة DHCP تشير إلى خدمة العناوين أو الشبكة المحلية. فشل TLS أو التسجيل يخص التطبيق وقد يتعلق بالساعة أو الشهادات أو سياسة الحساب.

اجعل مصفوفة القبول تثبت الاستعادة

الاختبار	الاستعادة المتوقعة	الدليل المحفوظ
كلمة مرور خاطئة ثم صحيحة	قبول محاولة جديدة دون تفليش أو مسح الهوية	معرفات المحاولات والسبب والحالة النهائية
اختفاء الموجه أثناء الاتصال	مهلة محدودة وإمكان استعادة الإعداد الصحيح أو مدخل الضبط	خط زمني للمراحل وعدادات المحاولات والموارد
نجاح الارتباط مع حجب DHCP	إظهار فشل العنوان منفصلًا عن المصادقة	أحداث Wi-Fi والتقاط DHCP
الشبكة تعمل والسحابة غير متاحة	تشخيص فشل الخدمة وحفظ Wi-Fi الصحيح وفق السياسة	حالات IP وDNS والتطبيق بلا أسرار
قطع الكهرباء أثناء الاستقبال والاختبار والتثبيت	إقلاع بإعداد قديم أو جديد صالح أو وضع استعادة مقصود	سجل الإقلاع وإصدار السجل وفحص السلامة
الهاتف يغادر AP وينضم هاتف ثانٍ	حفظ ملكية المحاولة وإتاحة أحدث نتيجة	الحالة الظاهرة للعميل وسلوك الطلبات المتزامنة
انتهاء نافذة الإعداد وإعادة ضبط الشبكة بالزر	الإغلاق في وقته وإعادة الفتح المصرح بها دون فقد المعايرة	مسح الراديو وسجل الزر وLED ومقارنة الإعدادات

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

اعرض عقد تشخيص مختصرًا

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

{
  "schema": 1,
  "attempt_id": "setup-0042",
  "phase": "waiting_for_ip",
  "result": "pending",
  "elapsed_ms": 12400,
  "reason": null,
  "can_retry": false
}

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

اتفق على تسليم كامل للإعداد الأولي

تساعد خدمة اتصال الأجهزة من Obeita في تحديد نطاق تكامل الجهاز والهاتف والموجه. يصف مشروع بوابة ESP32 Wi-Fi وBluetooth المُسلَّم أعمالًا مرتبطة بـAP وSTA؛ ولا يثبت دور Mesh المنفصل أن مسار الإعداد هذا نُفذ أو اعتُمد بالفعل.

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