bobaos.pub - KNX TP / UART, रास्पबेरी पाई और रेडिस

पूर्णता की कोई सीमा नहीं है। ऐसा लगता है कि सब कुछ अच्छी तरह से काम किया, मामूली कीड़े और इतने पर तय किए गए थे।

अब मैं आपको, सबसे पहले, उन समस्याओं के बारे में बताऊंगा जो मैंने पिछले लेख के बाद से पूरे समय के लिए सामना किया है, और दूसरी बात, उन समाधानों के बारे में जो परियोजना की वर्तमान स्थिति में योगदान करते हैं।

→ पिछले संस्करण के बारे में लेख

पदनाम

bobaos - bobaos मॉड्यूल का उपयोग करने के लिए BAOS 83x के साथ बातचीत करने के लिए UART का उपयोग करना। कच्चा डेटा लौटाता है। नीचे सूचीबद्ध अन्य सभी मॉड्यूल में उपयोग किया जाता है।

bdsd.sock - KNX वस्तुओं के साथ काम करने के लिए एक स्क्रिप्ट। डेटा पॉइंट्स की सूची को स्टोर करता है, भेजने / प्राप्त करते समय मूल्यों को परिवर्तित करता है। DPT1 से सही / गलत, DPT9 से फ्लोट तक। अन्य प्रक्रियाओं से अनुरोध प्राप्त करने के लिए यूनिक्स सॉकेट पर भी सुनता है।

bobaos.pub इंटरप्रोसेस संचार के लिए redis का उपयोग कर एक नया संस्करण है।
KNX / - BAOS 83x मॉड्यूल का एक संचार ऑब्जेक्ट जो ईटीएस में कॉन्फ़िगर किया गया है जिससे समूह पता (ए) मेल खाता है (या नहीं)। लोहे के वर्तमान संस्करणों में, अधिकतम राशि 1000 है।

कार्य

मुख्य कार्य पिछले संस्करण के समान है। सीरियल पोर्ट के लिए केवल एक कनेक्शन है। KNX के साथ बहुत सारी स्क्रिप्ट काम कर रही हैं। इसके अतिरिक्त, मैं इंटरप्रोसेस संचार लागू करना चाहता था। यानी इतना है कि न केवल एक bdsd.sock प्रक्रिया सॉकेट को bdsd.sock है, लेकिन प्रत्येक चलने वाली स्क्रिप्ट अनुरोध भेज और प्राप्त कर सकती है।

विचार

यूनिक्स सॉकेट्स के शीर्ष पर नोड.जेएस पर अपना संदेश ब्रोकर बनाने के लिए मेरे सिर में एक विचार पैदा हुआ था, जिसमें क्लाइंट कनेक्ट होंगे, विषयों की सदस्यता लेंगे और उनमें लिखे कोड के अनुसार संदेश प्राप्त / भेजेंगे। मुझे पता था कि पहले से तैयार समाधान थे, जिनके बारे में हाल ही में आलसी ने नहीं सुना था, अध्ययन किया था, लेकिन मेरा खुद का निर्णय लेने का विचार जुनूनी था।

और परिणामस्वरूप, सेवा लॉन्च की जाती है।

एक लकड़हारा लिखा जो विषय को संदेश भेजता है। सब्सक्राइबर प्राप्त करते हैं और कुछ भी करने के लिए स्वतंत्र हैं, या इसके बजाय, जो निर्धारित है। सुविधाजनक - कई स्रोतों से लॉग एक कंसोल आउटपुट में देखे जा सकते हैं।

मैंने npm में bobos.pub पैकेज लिखा और प्रकाशित किया, जो कि bdsd.sock के विपरीत, अब सॉकेट फ़ाइल नहीं बनाता है, लेकिन एक ब्रोकर से जुड़ता है। पहली नज़र में, सब कुछ वैसा ही काम करना चाहिए जैसा होना चाहिए।

समस्या

फिर मैंने एक स्क्रिप्ट चलाई जो समय-समय पर रात भर KNX बस को अनुरोध भेजता है। सुबह उठकर, एल ई डी के चमकने से डेटा भेजने / प्रेषित करने के संकेत से, मुझे एहसास हुआ कि कुछ गलत था। संदेश समय पर नहीं पहुंचे। मैंने पाया कि स्व-लिखित संदेश ब्रोकर ने उपलब्ध 512 एमबी रैम (बीगलबोर्ड ब्लैक से) लगभग सभी ले लिया। नोडज के साथ आगे के काम ने पुष्टि की कि स्मृति js स्क्रिप्ट का कमजोर बिंदु है।

निर्णय

नतीजतन, जेनेरिक यूनिक्स सॉकेट्स से रेडिस पर स्विच करने का निर्णय लिया गया (वैसे, वह यह भी जानता है कि उनके साथ कैसे काम करना है)। शायद यह स्मृति को छांटने लायक था, लीक को ढूंढना, लेकिन मैं तेजी से भागना चाहता था।

bobos का अर्थ है FT1.2 में रैपिंग संदेश के साथ UART संचार, हमारे पास सिंक्रोनस संचार है। यानी <..--..> । बोबोस मॉड्यूल, जो संचार के लिए जिम्मेदार है, सरणी में सभी अनुरोधों को संग्रहीत करता है, इसे बदले में बाहर निकालता है, इसे UART को भेजता है, और आने वाली प्रतिक्रिया के साथ, यह इस अनुरोध के लिए जिम्मेदार वचन की अनुमति देता है।

आप इस तरह से जा सकते हैं: सेवा रेडिस पब / एसयूबी चैनल को सुनती है, अनुरोधों को स्वीकार करती है, इसे KNX को भेजती है। इस स्थिति में, अनुरोध पंक्ति पर लोड js bobaos मॉड्यूल के साथ रहता है। कार्यान्वयन के लिए, आपको JSON.parse() पद्धति का उपयोग करके एक चैनल को सब्सक्राइब किए गए और परिवर्तित संदेशों के लिए एक सरल मॉड्यूल लिखना होगा। इसके अलावा इस मॉड्यूल का उपयोग अन्य लिपियों में किया जा सकता है।

एक अन्य विकल्प जो मैंने redis शीर्ष पर मौजूदा कार्य प्रबंधक का redis । bee-queue पर कई विकल्प बनाए गए हैं।

→ हुड के नीचे

यह बताता है कि bee-queue कैसे काम करती है। यदि आप इस लाइब्रेरी को अन्य प्रोग्रामिंग भाषाओं के लिए लागू करते हैं, तो आप इस तरह से bobaos लिए क्लाइंट लाइब्रेरी बना सकते हैं।

दूसरे संस्करण में, सभी अनुरोधों को redis सूचियों में संग्रहीत किया redis है, बदले में बाहर निकाला जाता है और सीरियल पोर्ट पर भेजा जाता है।

इसके अलावा, पिछले संस्करण की पुनर्लेखन इस प्रकार है, लेकिन मैं पहले से ही डेटा को redis डेटाबेस में डेटा redis पर संग्रहीत करता redis । एकमात्र असुविधा जो मुझे अनुभव होती है कि सभी अनुरोध अतुल्यकालिक हैं, इसलिए मानों का एक सरणी प्राप्त करना पहले से ही सरणी तक पहुंचने की तुलना में थोड़ा कठिन है।

मामूली अनुकूलन किए गए हैं।

यदि पहले अलग तरीके थे getValue/getValues/readValue/readValues/setValue/setValues , अब getValue/readValue/setValues दोनों एक ही मूल्य और एक सरणी स्वीकार करते हैं।

पिछले संस्करण में getValue([id1, id2, ...]) विधि getValue([id1, id2, ...]) ने प्रत्येक डेटाबेस के लिए सीरियल पोर्ट के लिए एक अनुरोध भेजा। लेकिन कई मूल्यों के लिए अनुरोध भेजने का अवसर है। सीमाएं - प्रतिक्रिया का आकार BufferSize बराबर होना चाहिए, अधिकतम - 250 बाइट्स; बीएओएस 83x मॉड्यूल के मौजूदा संस्करणों के लिए वस्तुओं की संख्या से परे जाना भी असंभव है - 1000।

मानों की लंबाई ज्ञात है, शीर्ष लेख भी। इसके अलावा, समय के साथ काफी सरल एल्गोरिथ्म और साइकिल का इंतजार =)

1. सरणी को सॉर्ट करें, डुप्लिकेट तत्वों को हटाएं, यदि कोई हो। हम एक idUniq सरणी प्राप्त करते हैं।
2. हम चक्र शुरू करते हैं i < idUniq.length , जिसमें हम निम्नलिखित करते हैं:
   a) टेक start: idUniq[i] , इसके लिए हम उन अधिकतम मानों पर विचार करते हैं जिन्हें हम प्राप्त कर सकते हैं। उदाहरण के लिए, यदि सभी वस्तुएँ DPT1 / DPT5 (1 बाइट) प्रकार की हैं, तो हम 48 की मात्रा में मान प्राप्त कर सकते हैं। एक टिप्पणी है: यदि, उदाहरण के लिए, हमने वस्तुओं को #[1, 2, 3, 10, 20] कॉन्फ़िगर किया है #[1, 2, 3, 10, 20] , फिर जब GetDatapointValue.Req(1, 30) क्वेरी करते हैं, तो प्रतिक्रिया शून्य-बाइट मानों को गैर-मौजूद डेटापॉइंट [4, 5, 6, ..., 30] लिए भी वापस कर देगी।
   बी) मतगणना एक नए चक्र में होती है j < i + max (जहां max 50 है, या, यदि 1000 के करीब है, तो अधिकतम 1000 - id + 1 , 990 के लिए यह 11 के लिए, 999 - 2 के लिए होगा), अगर गिनती की प्रक्रिया में मिलते हैं मूल क्वेरी से एरे के तत्व, फिर इंडेक्स i वेरिएबल i असाइन करते हैं।
   ग) यदि चक्र j गणना j गई लंबाई अधिकतम बफर लंबाई से अधिक है, तो हम क्वेरी कार्ड तत्व {start: start, number: number} बनाते हैं, इसे एक अलग सरणी में छोड़ते हैं, चर i बढ़ाते हैं (या सरणी में पाए जाने वाले idUniq को सूचकांक असाइन करते हैं), बीच में चक्र j , दोनों चक्र पुनः आरंभ होते हैं।

इस प्रकार, हम bobaos लिए कई अनुरोध bobaos । उदाहरण के लिए, यदि आप एक getValue([1, 2, 3, 40, 48, 49, 50, 100, 998, 999, 1000]) अनुरोध भेजते हैं getValue([1, 2, 3, 40, 48, 49, 50, 100, 998, 999, 1000]) , तो अनुरोध एक विशेष मामले के लिए निम्नानुसार हो सकते हैं:

 {start: 1, number: 48}, // 1, 2, 3, 40, 48 {start: 49, number: 48}, // 49, 50 {start: 100, number: 48}, // 100 {start: 998, number: 3} // 998, 999, 1000 

यह अलग तरीके से किया जा सकता है:

 {start: 1, number: 48}, // 1, 2, 3, 40, 48 {start: 49, number: 2}, // 49, 50 {start: 100, number: 1}, // 100 {start: 998, number: 3} // 998, 999, 1000 

उतने ही अनुरोध होंगे, कम डेटा। लेकिन मैंने पहले विकल्प पर रोक दिया, क्योंकि प्राप्त मूल्यों को redis डेटाबेस में संग्रहीत किया जाता है, क्रमशः, उन्हें getStoredValue विधि का उपयोग करके प्राप्त किया जा सकता है, जिसे मैं getStoredValue तुलना में अधिक बार उपयोग करने का प्रयास करता हूं, जो सीरियल पोर्ट के माध्यम से डेटा भेजता है।

ping/get sdk state/reset सेवा विधियों के लिए एक अलग कतार बनाई जाती है। इस प्रकार, यदि धारावाहिक पोर्ट पर संचार के साथ कुछ गलत है (फ्रेम काउंटर भटक गया, आदि) और निष्पादन कुछ कार्य पर रुक जाता है, तो आप दूसरी कतार में reset अनुरोध भेज सकते हैं और, तदनुसार, sdk पुनरारंभ करें।

ग्राहक पक्ष - bobaos.sub

उपयोगकर्ता स्क्रिप्ट में KNX bobaos.sub को नियंत्रित करने के लिए, bobaos.sub मॉड्यूल का उपयोग किया जा सकता है।

निम्नलिखित उदाहरण में मॉड्यूल के सभी कार्य शामिल हैं:

 const BobaosSub = require("bobaos.sub"); //     : // redis:   url // request_channel: "bobaos_req"  , // service_channel: "bobaos_service"  , // broadcast_channel: "bobaos_bcast"   let my = BobaosSub(); my.on("connect", _ => { console.log("connected to ipc, still not subscribed to channels"); }); my.on("ready", async _ => { try { console.log("hello, friend"); console.log("ping:", await my.ping()); console.log("get sdk state:", await my.getSdkState()); console.log("get value:", await my.getValue([1, 107, 106])); console.log("get stored value:", await my.getValue([1, 107, 106])); console.log("get server item:", await my.getServerItem([1, 2, 3])); console.log("set value:", await my.setValue({id: 103, value: 0})); console.log("read value:", await my.readValue([1, 103, 104, 105])); console.log("get programming mode:", await my.getProgrammingMode()); console.log("set programming mode:", await my.setProgrammingMode(true)); console.log("get parameter byte", await my.getParameterByte([1, 2, 3, 4])); console.log("reset", await my.reset()); } catch(e) { console.log("err", e.message); } }); my.on("datapoint value", payload => { //   ,  payload    ,    //     Array.isArray(payload) console.log("broadcasted datapoint value: ", payload); }); my.on("server item", payload => { //   ,  payload    ,    //     Array.isArray(payload) console.log("broadcasted server item: ", payload); }); my.on("sdk state", payload => { console.log("broadcasted sdk state: ", payload); }); 

bobaos.tool

कमांड लाइन इंटरफ़ेस को फिर से लिखा गया है। इसके बारे में मैंने इसे निम्नलिखित लेख में कैसे लागू किया:

→ NodeJS पर CLI लिखना

टीमें छोटी, स्पष्ट और अधिक कार्यात्मक हो गई हैं।

 bobaos> progmode ? BAOS module in programming mode: false bobaos> progmode 1 BAOS module in programming mode: true bobaos> progmode false BAOS module in programming mode: false bobaos> description 1 2 3 #1: length = 2, dpt = dpt9, prio: low, flags: [C-WTU] #2: length = 1, dpt = dpt1, prio: low, flags: [C-WT-] #3: length = 1, dpt = dpt1, prio: low, flags: [C-WT-] bobaos> set 2: 0 20:27:06:239, id: 2, value: false, raw: [AA==] bobaos> set [2: 0, 3: false] 20:28:48:586, id: 2, value: false, raw: [AA==] 20:28:48:592, id: 3, value: false, raw: [AA==] 

अंतभाषण

परिणाम एक स्थिर कार्य प्रणाली थी। एक बैकेंड के रूप में रेडिस अच्छी तरह से काम करता है। विकास के दौरान, बहुत सारे शंकु पैक किए गए थे। लेकिन सीखने की प्रक्रिया ऐसी है कि कभी-कभी यह अपरिहार्य है। अपने अनुभव से, मैं ध्यान देता nodejs कि nodejs प्रक्रियाएं बहुत अधिक रैम (20 एमबी की शुरुआत में) का उपभोग करती हैं और लीक हो सकती हैं। होम ऑटोमेशन के लिए, यह महत्वपूर्ण है - क्योंकि स्क्रिप्ट को लगातार काम करना चाहिए, और यदि यह समय के साथ अधिक से अधिक बढ़ता है, तो एक निश्चित बिंदु पर यह सभी स्थान ले सकता है। इसलिए, आपको सावधानीपूर्वक स्क्रिप्ट लिखना होगा, यह समझना होगा कि कचरा कलेक्टर कैसे काम करता है, और सब कुछ नियंत्रण में रखें।

प्रलेखन अद्यतन यहाँ पाया जा सकता है ।

अगले लेख में मैं बात करूंगा कि कैसे redis और bee-queue का उपयोग करके bee-queue सॉफ्टवेयर एक्सेसरीज़ के लिए एक सेवा बनाई।

UPD: boboskit - एक्सेसरीज, dnssd और WebSocket

मुझे किसी भी प्रतिक्रिया की खुशी होगी।