स्मार्ट होम वायरलेस संचार

जब शुरुआती (या निरंतर) "शौकिया रेडियो" ने एल ई डी के साथ पर्याप्त खेला और विभिन्न पदों में सर्वो को मोड़ने से थक गए, तो उनमें से कुछ सामान्य घरेलू क्षेत्र में अपने ज्ञान को लागू करना शुरू करते हैं।
एक नियम के रूप में, यह आवेदन दो क्षेत्रों में है - एक कार या एक घर।
निजी तौर पर, मुझे किसी भी तरह से "ट्यूनिंग" कार में दिलचस्पी नहीं है, लेकिन अपने आवास को थोड़ा "स्मार्ट" बनाने के लिए और अधिक आरामदायक एक योग्य विकल्प है।


ऊपर दिया गया फोटो मेरे "स्मार्ट" होम द्वारा "कंट्रोल पैनल" का एक कार्यशील प्रोटोटाइप दिखाता है।

वायरलेस मॉड्यूल की पसंद काफी सहज थी, लेकिन ऑपरेशन के कई महीनों के बाद, इसने पूरी तरह से भुगतान किया।

सस्ते 2.4GHz nRF24L01 + ट्रांसीवर खरीदे गए:


विशेषताओं के अनुसार, यह कहा गया है कि सीमा 100 मीटर (प्रत्यक्ष दृश्यता में) तक है और डेटा अंतरण दर 2 एमबीपीएस तक है। आप 126 उपलब्ध आवृत्ति चैनलों में से किसी का भी उपयोग कर सकते हैं। ऐसे "टुकड़ों" के लिए बहुत योग्य है।

बस मामले में, सबसे "महत्वपूर्ण" मॉड्यूल के लिए, "प्रबलित" संस्करण पाए गए:


ये मॉड्यूल "साधारण" लोगों के साथ पूरी तरह से संगत हैं, लेकिन अतिरिक्त रूप से एक शक्ति एम्पलीफायर और एक बाहरी एंटीना से लैस हैं।

वैसे, वे अभी भी निष्क्रिय हैं - यह पता चला है कि मेरे मामले में पर्याप्त "साधारण" मॉड्यूल हैं।

मॉड्यूल एसपीआई के माध्यम से एमके से जुड़े हुए हैं।
मॉड्यूल की ख़ासियत यह है कि उन्हें बिजली के लिए 3.3V की आवश्यकता होती है (यानी उन्हें व्यक्तिगत शक्ति प्रदान करने की आवश्यकता होती है यदि शेष सर्किट संचालित होता है, उदाहरण के लिए, 5V से)। अच्छी खबर यह है कि ये आरएफ 5 वी संकेतों के लिए सहिष्णु हैं (कोई स्तर मिलान योजना की आवश्यकता नहीं है)।



और ऐसा लगता है कि सब कुछ काम करता है और सब कुछ ठीक है, लेकिन किसी भी तरह बहुत सुविधाजनक नहीं है - केवल एसएमएस के माध्यम से, और नई सुविधाओं को पेश करना काफी मुश्किल था। प्रदर्शन नियंत्रण "सेंसर" के वर्तमान मूल्य के लिए एक अनुरोध के साथ या वीडियो निगरानी प्रणाली (उदाहरण के लिए, प्रकाश को चालू करने के लिए) को देखकर या तो किसी अन्य एसएमएस द्वारा किया गया था।

मॉड्यूल के साथ काम करते समय, मुझे "कागज का एक टुकड़ा" हमारे सामने रखना पड़ता था, जहां यह दर्ज किया जाता था कि यह या उस सेंसर को क्या कहा जाता है, इसके मापदंडों की संख्या, प्रत्येक पैरामीटर का उद्देश्य।

डेटा ट्रांसफर के लिए संरचना प्रारूप इष्टतम नहीं था (मेरे मामले के लिए)। मैं प्रारूप के इस संस्करण को भी नहीं देना चाहता।

यह स्पष्ट है कि इसे किसी भी तरह से संशोधित करना आवश्यक है (# 1 आधार)।

स्वाभाविक रूप से, लैन के माध्यम से भी जानकारी प्राप्त करने और प्रबंधित करने की इच्छा थी। एक iBoard बोर्ड खरीदा गया था (atmega328, Wiznet W5100 पर आधारित LAN, nrf24l01 के लिए इंटरफ़ेस, SD, एनालॉग पिन का एक गुच्छा, आदि):


और सब कुछ जीबोर्ड पर एक जैसा ही लगता है, लेकिन यह पता चला कि वायरलेस मॉड्यूल उम्मीद के मुताबिक तलाकशुदा नहीं है। इस बोर्ड में हार्डवेयर SPI का उपयोग LAN और SD के लिए किया जाता है, लेकिन वायरलेस मॉड्यूल के लिए इस इंटरफ़ेस को अपने दम पर लागू करने का प्रस्ताव था। लैन और आरएफ दोनों के साथ "एक साथ" काम करने में सक्षम होने के लिए यह सबसे अधिक संभावना थी।

इस तरह के स्विचिंग मॉड्यूल वाले इस बोर्ड के मिर्फ़ लाइब्रेरी ने स्पष्ट रूप से काम करने से इनकार कर दिया। Nrf24l01 के साथ बातचीत के लिए अपनी खुद की लाइब्रेरी लिखने के लिए मेरी योजना बिल्कुल भी नहीं थी।

जाहिर है, आपको कुछ करने की ज़रूरत है, अन्यथा एक अच्छा बोर्ड बेहतर समय तक मेज पर जाएगा (# 2 आधार)।

अद्भुत पुस्तकालय RF24 (लेखक मनिकबग , सिएटल, यूएसए) और एंड्रे कारपोव (कीव, यूक्रेन) द्वारा बनाई गई और भी अधिक अद्भुत कांटा iBoardRF24 की खोज की गई ।

सभी उपलब्ध उपकरणों (परीक्षण मामलों) पर पुस्तकालयों ने अद्भुत रूप से काम किया, लेकिन विभिन्न पुस्तकालयों (Mirf और RF24) वाले उपकरण एक-दूसरे के साथ संवाद नहीं कर सकते हैं (# 3 आधार)।

यह स्पष्ट हो गया कि वह क्षण आ गया था जब सब कुछ पुनः प्राप्त करना था।

वर्तमान समाधान को दर्शाने के लिए कोड (Arduino IDE) के टुकड़े हैं। रचनात्मकता के लिए जगह छोड़ने के लिए मैं पूरी सूची नहीं देता।

पहले से ही काफी अनुभव प्राप्त करने के बाद, मैंने प्रेषित डेटा की संरचना से सभी अच्छे को लिया और मौजूदा कमियों को ध्यान में रखा और इस निष्कर्ष पर पहुंचा कि डेटा के "पैकेज" की निम्न संरचना का उपयोग करना बेहतर है:

//     typedef struct{ int SensorID; //   int CommandTo; //    ... int Command; //  // 0 -     // 1 -   // 2 -   int ParamID; //   float ParamValue; //   boolean Status; //  0 - , 1 -  char Comment[16]; //  } Message; 

टिप्पणियों से लगभग हर जगह यह स्पष्ट है कि किस पैरामीटर का उपयोग किसके लिए किया जाता है। जो स्पष्ट नहीं है, उसे नीचे समझाया जाएगा।

प्रत्येक "सेंसर" के अंदर, मापदंडों के लिए संरचनाएं होना आवश्यक है:

 //      typedef struct{ float Value; //  boolean Status; //  - 0- (false), 1- (true) char Note[16]; //  } Parameter; 

संरचना के तीन पैरामीटर हैं। खैर, "मूल्य" के साथ सब कुछ स्पष्ट है, "नोट" फ़ील्ड का उपयोग किसी प्रकार के समझदार (लेकिन संक्षिप्त) विवरण देने के लिए किया जाता है कि यह किस प्रकार का सेंसर है और, संभवतः, माप की एक इकाई।
स्थिति नियंत्रण और भविष्य में संभावित लचीलेपन के लिए अधिक घायल है।
अब इसका उपयोग किया जाता है, उदाहरण के लिए, यदि किसी कारण से कुछ सेंसर से डेटा पढ़ना संभव नहीं था, तो सिस्टम शांति से इस स्थिति को संभाल सकता है और 0 को पास कर सकता है, समस्या का संकेत देता है।

यह देखा जा सकता है कि दूसरी संरचना पूरी तरह से प्रेषित पैकेट की संरचना के "अंत" को दोहराती है।

प्रेषित "पैकेट" का प्रारूप "मास्टर" (जो आदेश भेजता है और डेटा एकत्र करता है) और "दास" (वह जो काम पर आदेश और रिपोर्ट प्राप्त करता है) दोनों के लिए बिल्कुल समान है। इसके अलावा, इस दृष्टिकोण के साथ, मास्टर और दास काफी पारंपरिक संकेतन हैं। मॉड्यूल वास्तव में "समान शर्तों पर" संवाद करते हैं और जवाब के साथ अनुरोध दोनों तरीकों से जा सकते हैं।

अब आप एक विशिष्ट मॉड्यूल का वर्णन करना शुरू कर सकते हैं। 3 मापदंडों के साथ कुछ काल्पनिक मॉड्यूल लें। इसे निम्नानुसार एन्कोड किया जाएगा:

 //    #define SID 100 //   #define NumSensors 3 //   (     -  ) Parameter MySensors[NumSensors+1] = { //   (  ) NumSensors,1,"Sensor 100: LED", //   ""        , 1    "  " 0,0,"value A0", 0,0,"counter", 0,0,"set_value", }; Message sensor; 

कृपया ध्यान दें कि इस तथ्य के बावजूद कि 3 पैरामीटर हैं, 4 तत्वों की एक संरचना घोषित की गई है। खुद के लिए, मैंने स्वीकार किया कि "शून्य" तत्व में मैं हमेशा "मॉड्यूल" के बारे में जानकारी को सांकेतिक शब्दों में बदलना होगा - इसके सेंसर की संख्या, जानकारी दें कि सेंसर कमांड प्राप्त कर सकता है या यह सिर्फ एक "सेंसर" और सेंसर का एक पाठ विवरण है।

अब मुझे लगता है कि सेंसर का वर्णन करते समय, स्थिति पैरामीटर का उपयोग यह इंगित करने के लिए किया जा सकता है कि क्या यह पैरामीटर बदला जा सकता है (यानी, "एक्चुएटर") या नहीं (बस "सेंसर मूल्य")।
या इसके लिए एक और पैरामीटर दर्ज करें?

छांटे गए डेटा के साथ, चलिए फ़ंक्शन पर चलते हैं:

 boolean sendMasterMessage(int From, int To, int Command, int ParamID, float Value, char* Comment, Message* answer); 

इसलिए जिस फ़ंक्शन के साथ कमांड भेजा जाता है वह घोषित किया जाता है।
यदि सही उत्तर आ गया या "गलत" असफल होने पर "सही" रिटर्न।
इनपुट पैरामीटर: किस मॉड्यूल से कमांड आ रहा है, किस मॉड्यूल, कमांड (हम पढ़ें या इंस्टॉल करें), जो पैरामीटर, मूल्य, टिप्पणी और प्रतिक्रिया के लिए संरचना से लिंक करें।
यहां "टिप्पणी" पैरामीटर "भविष्य के लिए एक बुकमार्क" से अधिक है ताकि, उदाहरण के लिए, आप मॉड्यूल के नाम और मापदंडों के नाम बदल सकते हैं।

फ़ंक्शन का परिणाम निम्नलिखित नियमों द्वारा निर्धारित किया जाता है:

1. उस सेंसर से प्रतिक्रिया प्राप्त की जानी चाहिए जिसे एक्सेस किया गया था
2. उत्तर उस मास्टर के लिए होना चाहिए जिसने अनुरोध शुरू किया था
3. प्रतिक्रिया एक होनी चाहिए जो हस्तांतरण में भाग लेती है

इस प्रकार, हमारे काल्पनिक सेंसर से पहले सेंसर के मूल्य का पता लगाने के लिए, यह मास्टर पर पर्याप्त है (इसकी SID 900 होने दें) फ़ंक्शन को निम्नानुसार कॉल करें:

  ... Message answer; ... if(sendMasterMessage(900, 100, 1, 1, 0, "", answer)) { Serial.println(answer.ParamValue); } else { Serial.println("No answer"); } ... 

तदनुसार, मुख्य लूप में "प्राप्त करना" पक्ष इस कोड की तरह होना चाहिए:

  //    if (radio.available()) { bool done = false; while (!done) { done = radio.read( &sensor, sizeof(sensor) ); //     -  if (sensor.CommandTo == SID) { //   ( , , , ) doCommand(sensor.SensorID, sensor.Command, sensor.ParamID, sensor.ParamValue, sensor.Status, sensor.Comment); } } } 

DoCommand फ़ंक्शन कुछ इस तरह हो सकता है:

 void doCommand(int From, int Command, int ParamID, float ParamValue, boolean Status, char* Comment) { switch (Command) { case 0: //    break; case 1: //     sendSlaveMessage(From, ParamID); break; case 2: //  setValue(From, ParamID, ParamValue, Comment); break; default: break; } //  "" sendSlaveMessage(From, ParamID); return; } 

SendSlaveMessage फ़ंक्शन लगभग SendMasterMessage के समान है, लेकिन डेटा भेजे जाने के बाद प्रतिक्रिया की शुद्धता की जांच नहीं करता है और इसमें कम इनपुट पैरामीटर होते हैं - फ़ंक्शन मॉड्यूल के पहचानकर्ता को स्वीकार करता है, जिसके लिए पैरामीटर एम्पलीफायर, जिसके बारे में जानकारी भेजी जानी चाहिए, इनपुट पर प्राप्त होती है।
सिस्टम को भेजने के "पैकेज" की संरचना के लिए शेष आवश्यक डेटा पहले से ही पता है (मैं आपको याद दिलाता हूं कि आवश्यक फ़ील्ड भी हैं - मॉड्यूल की पहचानकर्ता जो फिलहाल डेटा भेज रहा है, कमांड (इस मामले में यह 0 होगा, क्योंकि हम वर्तमान मूल्य भेजते हैं) ))।

इस प्रकार, कार्य का तर्क सरल है:

• मास्टर मॉड्यूल के लिए एक पता अनुरोध शुरू करता है और एक विशिष्ट पैरामीटर के मूल्य को पढ़ने (या सेट) की आवश्यकता होती है।
• दास इस आदेश को स्वीकार करता है (और यदि इसे संबोधित किया जाता है) और आवश्यक कार्य करता है, जो प्रतिक्रिया संदेश में "रिपोर्ट" किया जाता है।
• मास्टर प्राप्त पैकेज का विश्लेषण करता है और, यदि परिणाम से संतुष्ट है, तो यह अपने स्वयं के मामलों के साथ आगे बढ़ता है या दूसरा अनुरोध करता है (जितनी बार आवश्यक हो)।

GBoard के लिए कोड भी तदनुसार लिखा गया था और अब एसएमएस के माध्यम से बातचीत कुछ इस तरह दिखती है (आपके फोन से स्क्रीनशॉट का हिस्सा):

पहला एसएमएस मैं "मौसम" मॉड्यूल से पूर्वी सेंसर के तापमान का अनुरोध करता हूं, दूसरा एसएमएस - मैं वांछित तापमान को "मजबूर" थर्मोस्टैट पर सेट करता हूं। जवाब में, मुझे एक मापा मूल्य या एक सफलतापूर्वक निर्धारित मूल्य के बारे में प्रतिक्रिया मिलती है (संदेश के अंत में "" "") है)।

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

इस "पता" पर डेटा एक्सचेंज वर्णन खत्म करते हैं।

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

फिर मैं इस विचार के साथ आया कि हवा पर "बाढ़" की व्यवस्था करना संभव है: सेंसर नियमित रूप से सभी के लिए अपने मापदंडों (सभी या केवल कुछ - विशेष कार्यान्वयन पर निर्भर करता है) के मूल्यों को भेज सकते हैं (फिर पैरामीटर के लिए (किसके लिए) मान 0 लेता है (यानी, ") सभी "))।

यह एक तरह का "मल्टीकास्ट" निकला - मॉड्यूल जाग गया, इसकी स्थिति प्रसारित करें (और इससे कोई फर्क नहीं पड़ता कि किसी ने इसे सुना या नहीं) और फिर से सो गया।

बाढ़ मोड को लगभग सभी मॉड्यूलों में जोड़ा गया था जो "निश्चित रूप से" काम करते हैं ताकि वे नियमित रूप से अपनी स्थिति (लॉगिंग सिस्टम के लिए) भी प्रसारित करें।

फिर से लिखने के लिए (या "सही" कहने के लिए) उन मॉड्यूलों के स्केच का कोड जो पहले से काम करते थे (नई लाइब्रेरी के लिए) एक बहुत ही सरल कार्य निकला - प्रति मॉड्यूल 15-20 मिनट से अधिक नहीं। "प्रवास" की प्रक्रिया पूरी तरह से दर्द रहित थी।

और अब यह केवल एक साथ डेटा एकत्र करने के लिए बनी हुई है। यह वह जगह है जहां iBoard बोर्ड काम में आया (एक बार फिर, मैं उसे पहले से स्थापित आरएफ मॉड्यूल के साथ एक फोटो दूंगा):


इस मॉड्यूल में एक सरल लेकिन बहुत महत्वपूर्ण कार्य है - वेब सर्वर पर "बाढ़" सुनने और डेटा (POST विधि) भेजने के लिए। IBoard पर मॉड्यूल संचरित मॉड्यूल की संख्या और "संरचना" के बारे में कुछ भी नहीं जानता है - यह सब कुछ सुनता है।

वेब सर्वर के लिए डेटा पैकेट में, "कुंजी" प्रसारित होती है (ताकि सर्वर समझता है कि यह "उनका अपना" है) और प्राप्त पूरा पैकेट (मैं दोहराता हूं कि पैकेट में निम्न कुंजी डेटा आता है: मॉड्यूल एसआईडी, पैरामीटर आईडी, इस पैरामीटर का मान, टिप्पणी (पैरामीटर नाम और / या इकाई))।
यदि प्राप्त पैकेट परमिड में शून्य के बराबर है, तो पैरामीटर मान में हमारे पास मॉड्यूल के "सेंसर" की संख्या है, और "टिप्पणी" में - मॉड्यूल का नाम।

वेब सर्वर पर स्वचालित मोड में प्रविष्टियां 2 प्लेटों में उत्पन्न होती हैं: सेंसर_लिस्ट और सेंसर_वेल्यू (नामों से, मुझे लगता है, सब कुछ स्पष्ट है)।

लागू दृष्टिकोण किसी भी दर्द के बिना सिस्टम में मॉड्यूल जोड़ने की अनुमति देता है और iBoard के लिए कोड को सही नहीं करता है - नए मूल्य डेटाबेस में काम करेंगे योजना के अनुसार।

एक वेब सर्वर के रूप में मैंने "हाथ में" (Synology DS411 + II) का उपयोग किया था - php और mySQL के साथ वेब सर्वर के कुछ ही क्लिक में उठाया गया था। यदि हाथ में कुछ भी उपयुक्त नहीं है और आप इसके लिए कंप्यूटर चालू नहीं रखना चाहते हैं, तो आप तृतीय-पक्ष होस्टिंग का उपयोग कर सकते हैं, इस तरह से कुछ खरीद सकते हैं (अच्छा और उपयोगी), या, उदाहरण के लिए, cosm.com सेवा

"संग्रहण" की पसंद के आधार पर, LAN मॉड्यूल के साथ MK के लिए कोड न्यूनतम तरीके से बदल जाएगा (arduinki के लिए cosm.com की अपनी लाइब्रेरी और एक सुविधाजनक डीबगिंग मोड है - यह उपयोग करने के लिए बहुत सरल है)।

डेटा एकत्र किया गया था (और cosm.com का उपयोग करने के मामले में, यह पहले से ही चार्ट पर प्रदर्शित किया गया था)।

प्रदर्शन के लिए मेरी परियोजना में, मैंने Google चार्ट का उपयोग किया। यह कुछ इस तरह से निकलता है (केवल मौसम पैरामीटर):


मैं विशेष रूप से एक स्क्रीनशॉट प्रदान करता हूं, लेकिन मैं पृष्ठ का लिंक नहीं देता हूं - NAS, मुझे लगता है, हब से लोड का सामना नहीं करेगा।
सेंसर से डेटा "शोर" है, यह कलमन फ़िल्टर को लागू करने के लिए आवश्यक होगा, लेकिन हाथ इस बिंदु तक नहीं पहुंचे हैं।

दरअसल, डेटा के संग्रह और प्रदर्शन के साथ - यह भी समाप्त हो गया।

यह लैन पर नियंत्रण को लागू करने के लिए बना हुआ है (लेकिन यह अभी तक नहीं किया गया है और अगर यह दिलचस्प है, तो एक और पोस्ट का विषय होगा (हालांकि मूल सिद्धांतों को पहले ही आवाज दी गई है - यह कैसे करना है यह पहले से ही स्पष्ट है, आपको बस "बैठना और लिखना" चाहिए))।

आप पूछ सकते हैं: "वह तस्वीर जिसके साथ पोस्ट शुरू हुई थी?"

और यह तेजी से प्रोटोटाइप के लिए एक और बोर्ड है - iBoardPro (पहले से ही मेगा 2560, लैन, आरटीसी, एसडी, आरएफ इंटरफ़ेस, एक टचस्क्रीन और अन्य "उपहार" के साथ TFT डिस्प्ले को जोड़ने के लिए 40-पिन कनेक्टर):


एक प्रतिरोधक टचस्क्रीन ITDB02-2.4E के साथ TFT 2.4 "320 * 240 डिस्प्ले फोटो में स्पष्ट रूप से दिखाई देता है। यह अच्छा लग रहा है, लेकिन यह उंगलियों के साथ काम करने के लिए बहुत छोटा है, और मैं बड़े ग्रंथों को पसंद करूंगा (मैं 5 या 7 इंच के डिस्प्ले की ओर देखूंगा)।

उपरोक्त सिद्धांतों का उपयोग करते हुए, यह बोर्ड लागू होता है (लेकिन अभी भी जोड़ा जा रहा है) एक "नियंत्रण मॉड्यूल" जिसमें वांछित सेंसर से डेटा आउटपुट है और समर्थन करने वाले डिवाइस को नियंत्रित किया जा सकता है।

प्रोटोटाइप के वर्तमान संचालन को प्रदर्शित करने वाला एक छोटा वीडियो:


कार्य का तर्क इस प्रकार है:

• "मुख्य" स्क्रीन हैं - "सारांश" डेटा उन पर पड़ता है ("मौसम" - हरा, "होम" - पीला)
• "उप-स्क्रीन" हैं - सेंसर से डेटा उन पर प्रदर्शित किया जाता है (वीडियो में इसे "पीले" बुकमार्क के लिए दिखाया गया है - "होम पैरामीटर": घर के दो बिंदुओं पर तापमान और आर्द्रता और बिजली की खपत पर डेटा)।
• "रेड" स्क्रीन एक "सारांश का सारांश" है - सबसे अनुरोधित डेटा।
• "ब्लू" स्क्रीन - नियंत्रण। इसके मध्य भाग में एक हल्का नियंत्रण होता है, निचले हिस्से में - एक "मजबूर" थर्मोस्टैट का नियंत्रण। नीचे बाईं ओर, लाल "संकेतक" उसी पैरामीटर (जो मैंने ऊपर लिखा था) का एक प्रदर्शन है, जो इंगित करता है कि मौजूदा समय में गैस बॉयलर संचालित किया जा सकता है या नहीं।

स्क्रीन पर नियंत्रण के "बटन" "प्रतिक्रिया" है: i.e. एक विशिष्ट मोड पर स्विच करने के बाद - यह इसी रंग में प्रदर्शित होता है। यदि कुछ पहले से ही चालू हो गया है, तो जब आप नियंत्रण स्क्रीन पर जाते हैं, तो यह तुरंत दिखाई देगा।
प्रत्येक "दबाने" से एक बटन उचित मापदंडों के साथ SendMasterMessage फ़ंक्शन पर कॉल उत्पन्न करता है और एक विशिष्ट सेंसर से प्रतिक्रिया प्राप्त करता है (यह इन आंकड़ों से है कि बटन "repainted" या मूल्य परिवर्तन हैं, जैसा कि "मजबूर" थर्मोस्टेट के सेट तापमान के लिए स्पष्ट है)।

यह देखा जा सकता है कि जब बटन "पुन: अंकित" होता है तो एक निश्चित विलंब होता है और पैरामीटर बदल जाता है - यह न केवल प्रतिपादन के दौरान एमके की सुस्ती के कारण होता है, बल्कि इस तथ्य के लिए भी है कि अनुरोध भेजने और प्रतिक्रिया प्राप्त करने में समय लगता है (कभी-कभी अनुरोध-प्रतिक्रिया प्रक्रिया एक से अधिक बार होती है - मास्टर जानता है कि अपने "आदेश" को कैसे दोहराना है यदि वह अपेक्षित उत्तर की प्रतीक्षा नहीं करता है)।

सिस्टम की स्थिति के बारे में डेटा प्रदर्शित करने के लिए "वायलेट" स्क्रीन का उपयोग करने की योजना बनाई गई है: वर्तमान आईपी पते, प्रारंभ समय, एनटीपी के माध्यम से अंतिम सिंक्रनाइज़ेशन का समय, अंतिम "कनेक्शन" (या "सुन") विशिष्ट सेंसर के साथ, आदि।

शायद आज वह सब है जिसके बारे में मैं बात करना चाहता था (और इसलिए यह बहुत लंबा निकला)।

फोटो की गुणवत्ता के लिए क्षमा करें - मैं एक माइक्रोवेव में एक फोन की शूटिंग कर रहा था।

पुनश्च मैंने इस स्टोर से जेलेज़की को खरीदा (बेशक, मैंने इसे ओवरपेड कर दिया था, लेकिन मैं चीन से लंबे समय तक इंतजार नहीं करना चाहता था, इस दौरान मैं एनएससी से कई पार्सल ऑर्डर करने और प्राप्त करने में कामयाब रहा)। करीब और तेजी से कहीं नहीं पाया जा सकता है।

PPS हाँ, इन सभी "ग्रंथियों" (अच्छी तरह से, शायद प्रदर्शन को छोड़कर) को घर पर इकट्ठा किया जा सकता है, लेकिन यह लक्ष्य नहीं था।