स्मार्ट होम डेवलपर का घोषणापत्र: 15 सिद्धांत

आज मैं स्मार्ट घरों और IoT उपकरणों के बारे में बोलना चाहता हूं। लेकिन यह कोई साधारण लेख नहीं है। आपको हार्डवेयर, निर्माताओं के लिंक, कोड या रिपॉजिटरी के बैच नहीं मिलेंगे। आज हम कुछ उच्च स्तर के सिद्धांतों पर चर्चा करेंगे - जो "स्मार्ट" सिस्टम को व्यवस्थित करने के लिए उपयोग किए जाते हैं।

---

स्मार्ट होम एक ऐसी प्रणाली है जो किसी व्यक्ति के बजाय कुछ रोजमर्रा की दिनचर्या कर सकती है। यह हमें पहले और मुख्य सिद्धांत की ओर ले जाता है:

1. स्मार्ट होम को जीवन को आसान बनाना चाहिए।

स्मार्ट होम जीने के लिए एक प्रणाली है, यह गीक्स के लिए एक खिलौना नहीं है। एक स्विच की तुलना में उपयोग ¹ में जटिल होने वाले सिस्टम स्मार्ट होम नहीं हैं।

इस सिद्धांत के खिलाफ किसी भी नई चीज का परीक्षण किया जाना है। यदि यह जीवन को आसान नहीं बनाता है, और आप यह नहीं समझते हैं कि जीवन को आसान बनाने के लिए इसे कैसे सुधारें, तो यह स्मार्ट होम के लिए नहीं है।

---

दूसरा महत्वपूर्ण सिद्धांत यह है कि उपयोगकर्ता सिस्टम के साथ कैसे इंटरैक्ट करता है:

2. अच्छा उपयोगकर्ता अनुभव कार्यक्षमता से अधिक महत्वपूर्ण है।

एक शांत उपकरण जो उपयोग करना मुश्किल है, वह एक पैसा वसूल नहीं है। सीमित कार्यों वाले सुविधाजनक और विश्वसनीय उपकरणों में सभी संभावित उपयोगों और अनुप्रयोगों के लिए जटिल उपकरणों की तुलना में सफलता की बहुत अधिक संभावना है।

2.1। अनुकूलन की तुलना में सुविधाजनक इंटरफेस बेहतर हैं।

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

यदि आपको समझ में नहीं आता है कि सुविधा और कई कार्यों को कैसे एकीकृत किया जाए, तो कुछ सेटिंग्स से छुटकारा पाएं। कोई भी फ़ंक्शन नियमित स्विच से बेहतर है। लेकिन अगर यह अधिक जटिल है तो उपयोगकर्ता स्विच पर वापस आ जाएगा।

काम की गुणवत्ता के बारे में भी यही कहा जा सकता है। एक बटन जो बस लाइट बंद कर देता है वह एक डिमर से बेहतर है जो कभी काम करता है और कभी कभी काम नहीं करता है

2.2। एहसास कार्यों की गुणवत्ता कार्यों की संख्या से अधिक महत्वपूर्ण है

कई खराबी वालों की तुलना में कुछ विश्वसनीय कार्य करना बेहतर है।

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

2.3। सिस्टम का उपयोग काम की सामान्य गति को कम नहीं करना चाहिए

देरी अनुचित है क्योंकि वे एक उपयोगकर्ता अनुभव पर बुरा प्रभाव डालते हैं। यह एक नकारात्मक उत्तेजना भी है। यदि किसी व्यक्ति को स्विच को बदलने और प्रकाश को चालू करने के बीच ^{2 में} कोई देरी नहीं दिखाई देती है, तो उसे आपके सिस्टम में इसे नोटिस नहीं करना चाहिए।

आधुनिक हार्डवेयर उच्च गति पर काम करता है। नियंत्रकों पर दर्जनों मेगाहर्ट्ज की आवृत्तियों तक पहुंचने और रेडियो चैनल के माध्यम से भी कम से कम दर्जनों किलोबाइट प्रति सेकंड तक पहुंचने की कोई समस्या नहीं है। यदि इस हार्डवेयर के साथ आपका उपयोगकर्ता अभी भी काम में देरी का अनुभव करता है - आपको अपने करियर की पसंद पर पुनर्विचार करना चाहिए।

2.4। सिस्टम को पहले से गठित उपयोगकर्ता की आदतों को नहीं तोड़ना चाहिए।

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

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

क्या करें?

2.5। सिस्टम को नया अनुभव लाना चाहिए और पुराने को बदलना नहीं चाहिए।

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

---

स्मार्ट होम में लॉजिस्टिक्स ऑफ़ वर्क महत्वपूर्ण भूमिका निभाता है। यह नियम को परिभाषित करता है स्मार्ट होम काम करता है। और यह हमें अगले सिद्धांत की ओर ले जाता है:

3. उपयोगकर्ता के तर्क सीमित नहीं हो सकते।

यदि कोई उपयोगकर्ता एक केतली ³ को उबालना चाहता है जब एक कमरे में तापमान बढ़ता है, तो उसे ऐसा करने दें। आपको उस स्थिति से भी बचना चाहिए जब हार्डवेयर या सॉफ़्टवेयर स्तरों पर आवश्यक कार्रवाई की जा सकती है, लेकिन यह केवल इसलिए उपलब्ध नहीं है क्योंकि एक डेवलपर ने सोचा कि "किसी को भी इसकी आवश्यकता नहीं होगी"।

3.1। सरल - बेहतर: लॉजिक बनाने के लिए सिस्टम संरचना के विशेष ज्ञान की आवश्यकता नहीं होनी चाहिए।

यदि आपके पास विभिन्न संस्करणों के उपकरण हैं और विभिन्न प्रोटोकॉल के साथ, तो सुनिश्चित करें कि उपयोगकर्ता केवल उन मामलों के बारे में जानता है जब यह वास्तव में आवश्यक और अनुपलब्ध है।

यदि आप किसी उपयोगकर्ता को डेवलपर्स के समय की कीमत पर भी विशेष ज्ञान प्राप्त करने की परेशानी से दूर कर सकते हैं, तो यह करें। एक डेवलपर इस पर दो दिन बिताएगा और इसे एक घंटे में एक हजार उपयोगकर्ता लेंगे। यदि हम 1000 घंटे के मुकाबले 48 घंटे देखते हैं, तो उत्तर स्पष्ट है।

क्या आप अच्छी तरह से सोते हैं, जॉन, एक सीरियल प्रोग्रामर?

3.2। समान फ़ंक्शन वाले उपकरणों को उसी तरह नियंत्रित किया जाना चाहिए।

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

---

हम भौतिक दुनिया में रहते हैं। मनुष्य का शरीर और मस्तिष्क भौतिक वस्तुओं के साथ बातचीत करने के लिए बनता है। यह हमें अगले सिद्धांत की ओर ले जाता है।

4. फिजिकल कंट्रोल डिवाइस वर्चुअल से बेहतर है।

स्मार्ट फोन पर कोई भी ऐप यहां तक ​​कि सबसे अच्छे भी नहीं होते हैं क्योंकि आवश्यक स्थान पर एक नियमित भौतिक स्विच के रूप में अच्छा नहीं होता है।

यह और बात है कि एक स्विच को सही जगह पर स्थित होना चाहिए। यह एक और नियम की ओर जाता है:

5. वायरलेस सिस्टम वायर्ड वाले से बेहतर हैं।

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

5.1। खराब वायरलेस सिस्टम वायर्ड वाले से भी बदतर हैं।

यह अच्छी वायरलेस प्रणाली के लिए कोई फर्क नहीं पड़ता कि केंद्रीय नियंत्रक से कितनी दूर उपकरण हैं। जाल-नेटवर्क के साथ अच्छे वायरलेस सिस्टम प्रोटोकॉल हैं: ZigBee, Z-Wave, 6LoWPAN, आदि।

वाई-फाई सहित अन्य सभी विकल्प इतने अच्छे नहीं हैं। "433 मेगाहर्ट्ज" जैसे मालिकाना प्रोटोकॉल, हालांकि वे अन्य आवृत्तियों में काम कर सकते हैं और एक दूसरे से बहुत भिन्न होते हैं और वे भी अच्छे नहीं होते हैं।

वाई-फाई के नुकसान यह है कि आप पूरी तरह कार्यात्मक "नींद" डिवाइस नहीं बना सकते हैं, स्वचालित सेटिंग घर में अन्य वाई-फाई उपकरणों के साथ जटिल, असंगति है।

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

---

आप 100% विश्वसनीय प्रणाली नहीं बना सकते हैं जिसे बनाए रखने की आवश्यकता नहीं है। डिवाइस क्रम से बाहर निकलते हैं, वहाँ मुझे गन्ने की बिजली लाइन बढ़ती है, पड़ोसी आपको बाढ़ कर सकते हैं, बैटरी डिस्चार्ज कर सकते हैं, एक बच्चा दीपक पर सूप छिड़क सकता है, आदि। लेकिन:

6. फिक्सिंग, अपडेट, रखरखाव और निदान करना आसान होना चाहिए।

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

सिस्टम खरीदने के बारे में एक बुद्धिमान समाधान, मालिक की कुल लागतों की गणना के आधार पर बनाया गया है जो सिस्टम की कीमत और रखरखाव के खर्च से बना है।

यह उन प्रणालियों में थोड़ा अधिक जटिल है जो घरों में उपयोग किए जाते हैं। एक ऑपरेटर और एक उपयोगकर्ता एक और एक ही व्यक्ति हैं जिन्हें सिस्टम का आवश्यक ज्ञान नहीं है। दुर्भाग्य से, ये उपभोक्ता बाजार की सीमाएं हैं। और यह निम्नलिखित सिद्धांतों की ओर जाता है।

6.1। उपकरण या तो काम करते हैं या काम नहीं करते हैं। कोई तीसरा विकल्प नहीं है।

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

यदि आप निश्चित हैं कि सिस्टम की गिरावट संभव है, तो एक उपयोगकर्ता को एक संदेश की मदद से इसके बारे में सूचित करें जो समझने में आसान है: "दूसरा डिमर चैनल क्रम से बाहर है। डिमर को बदलें। पहले डिमर चैनल का उपयोग जारी रखें? हां / नहीं »

6.2। टूटे हुए उपकरण को बदलना आसान होना चाहिए।

सिस्टम को एक मॉड्यूल होना चाहिए। यदि कोई सेंसर ऑर्डर से बाहर हो जाता है, तो केवल इस सेंसर को बदलना होगा। एक सेंसर के साथ रिमोट कंट्रोल के साथ रिले को बदलने की आवश्यकता के लिए यह सही नहीं है, क्योंकि वे विनिर्माण चरण में जोड़े जाते हैं।

यह मांग करना सही नहीं है कि "एक नया सेंसर केवल हमारे विशेषज्ञ द्वारा ही स्थापित किया जा सकता है", क्योंकि यह स्पष्ट है कि समय के साथ आपके विशेषज्ञ लाखों उपयोगकर्ताओं को सेवा करने के लिए पर्याप्त नहीं होंगे क्योंकि आपके सिस्टम की लोकप्रियता बढ़ती है। इस प्रकार, एक निश्चित समय पर समस्याएं दिखाई देंगी। बेशक एक उपयोगकर्ता खुद एक उपकरण को ठीक नहीं करेगा, लेकिन जब वह क्रम से बाहर हो जाता है तो उसे खुद को बदलने का अवसर होना चाहिए।

6.3। उपयोगकर्ता के अनुकूल संदेश।

यदि कुछ गलत होता है, तो एक उपयोगकर्ता को इसके बारे में जानना चाहिए और यह जानना चाहिए कि वास्तव में क्या गलत हुआ। आप "त्रुटि # 45" संदेश दिखा सकते हैं कि वह इसे समझना चाहिए। इस तरह का एक संदेश उपयोगकर्ता को दिखाया जाना चाहिए "डिवाइस जवाब नहीं देता है। इसे पुनः लोड करने और इसे फिर से असाइन करने या तकनीकी सहायता से संपर्क करने का प्रयास करें। त्रुटि # 45 "

आप यह नहीं सीख सकते कि कोई डिवाइस जवाब नहीं देता (यदि आप ऐसा कर सकते हैं) और उपयोगकर्ता से इस जानकारी को वापस ले लें। किसी समस्या के बारे में संदेश प्राप्त करना सुखद नहीं है। लेकिन यह जानने के लिए बहुत अधिक अप्रिय है कि एक डिवाइस उस समय एक सप्ताह के लिए ऑर्डर से बाहर हो गया है जब आपको अंततः इस डिवाइस की आवश्यकता होती है।

6.4। संदेशों में कोई अतिरिक्त जानकारी नहीं।

लॉग वाले उपयोगकर्ता को स्पैम न करें। एक उपयोगकर्ता को पिछले सिद्धांत की तरह जानकारी की आवश्यकता होती है, क्योंकि इसमें जानकारी होती है कि वास्तव में क्या गलत हुआ। यदि वह जानकारी नहीं समझ सकता है या वह पता करने वाला नहीं है, तो उसे इसकी आवश्यकता नहीं है।

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

6.5। रखरखाव कार्यों के लिए किसी विशेष ज्ञान या उपकरण की आवश्यकता नहीं होनी चाहिए।

बटन के एक जोड़े को क्लिक करके उपयोगकर्ता को फर्मवेयर अपडेट करने की अनुमति दें। यह एक मानक इंटरफ़ेस (यूएसबी / बीटी / वाई-फाई) के माध्यम से किया जा सकता है, या एसपीआई-प्रोग्रामर के माध्यम से अपडेट करने का उल्लेख नहीं करता है।

आप किसी डिवाइस को कॉन्फ़िगर करने के लिए उपयोगकर्ता से बिट मास्क की गणना करने की उम्मीद नहीं कर सकते।

6.6। सिस्टम को निरंतर रखरखाव की आवश्यकता नहीं होनी चाहिए।

यदि हर महीने एक डिमर कनेक्शन खो देता है और एक उपयोगकर्ता को एक दीपक तक पहुंचने के लिए सीढ़ी पर चढ़ना पड़ता है और फिर से एक्ट्यूएटर को जोड़ता है - यह सुविधाजनक है। अगर बैटरी को हर दो महीने में एक स्विच में बदलना पड़ता है - तो यह सुविधाजनक नहीं है। यहां तक ​​कि अगर डिवाइस को बनाए रखने की औसत अवधि छह महीने है - यह सुविधाजनक नहीं है। यदि घर में लगभग बीस उपकरण हैं, तो एक उपयोगकर्ता को हर नौ दिनों में कुछ करना होगा।

6.7। सिस्टम में अपडेट करने और विस्तार करने के अवसर होने चाहिए।

एक प्रणाली का विस्तार करने पर व्यय रैखिक प्रगति में बढ़ना चाहिए।

उन स्थितियों से बचें जब एक उपयोगकर्ता जो एक सेंसर जोड़ना चाहता है, उसे एक नया नियंत्रक खरीदना होगा, क्योंकि पुराना 6 सेंसर ⁵ से अधिक का समर्थन नहीं करता है।

ऐसी स्थितियों से बचें जब नया सेंसर फर्मवेयर नियंत्रक के नए संस्करण के साथ ही काम कर सकता है।

इस तरह की सीमाओं का आय पर सकारात्मक प्रभाव पड़ता है, जिससे उपयोगकर्ता नए उपकरण खरीदते हैं। लेकिन यह कहीं नहीं है। आप ऐसी चालों के कारण अपने उपयोगकर्ताओं का भरोसा खो सकते हैं और परिणामस्वरूप आप जितना कमा सकते हैं उससे कहीं अधिक खो देंगे।

7. आत्मनिर्भरता: बाहरी जाल एक विकल्प है, आवश्यकता नहीं है।

एक प्रणाली जहां कमांड को बाहरी सर्वर से गुजरना पड़ता है वह सुविधाजनक नहीं है। आप सुविधाजनक इंटरफेस, आधुनिक ऐप, कूल न्यूरो नेटवर्क के बारे में घंटों तक बोल सकते हैं, लेकिन उनका मतलब कुछ भी नहीं है अगर कोई उपयोगकर्ता इंटरनेट के डाउन होने पर शौचालय में लाइट चालू नहीं कर सकता है। क्या आप वास्तव में सोचते हैं कि इस तरह की व्यवस्था को अच्छा माना जा सकता है?

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

8. केंद्रीकरण: केंद्रीय हब की अनुपलब्धता उपलब्ध लॉजिक्स को सीमित करती है।

लेकिन एक विकेंद्रीकृत प्रणाली भी आदर्श नहीं है, हालांकि यह विश्वसनीय है।

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

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

विकेंद्रीकरण को आंशिक रूप से बचाया जा सकता है, क्योंकि जब कोई हब नहीं होता है, तो कमांड को सीधे विफल-सुरक्षित मोड के रूप में भेजा जा सकता है। कोई लॉजिक्स नहीं है, लेकिन प्रकाश को चालू किया जा सकता है।

---

9. सिस्टम को उपयोगकर्ता को सूचित किए बिना या उससे पुष्टि प्राप्त किए बिना संभावित खतरनाक कार्रवाई नहीं करनी चाहिए।

जब तक हम एक ऐसी दुनिया में रहते हैं, जहां एक प्रोग्रामर अपने सॉफ़्टवेयर द्वारा किए गए नुकसान के लिए ज़िम्मेदार नहीं है, तो स्मार्ट होम के सॉफ़्टवेयर सहित सॉफ़्टवेयर में त्रुटियां होंगी। सिस्टम को स्वतंत्र क्रियाओं को सीमित करने के लिए एक परिणाम को गंभीर परिणाम की अनुमति नहीं देने का एकमात्र तरीका है। संभावित रूप से खतरनाक क्रियाएं केवल तभी की जानी चाहिए जब कोई उपयोगकर्ता उनके बारे में सूचित किया जाए या उपयोगकर्ता द्वारा पुष्टि करने के बाद भी बेहतर हो। प्रकाश को स्वचालित रूप से चालू किया जा सकता है, सॉफ़्टवेयर में एक बग रात में एक उपयोगकर्ता को जगाएगा या अपने बिजली के बिल में वृद्धि करेगा। यह सुखद नहीं है, लेकिन यह खतरनाक नहीं है। लेकिन पानी के नल को स्वचालित रूप से नहीं खोला जा सकता है, अगर बाढ़ को रोकने वाले उपकरण नहीं हैं। सोचा कि स्वचालित रूप से पानी के नल को बंद करना खतरनाक नहीं है।

इसका मतलब यह नहीं है कि हीटर, बॉयलर, फायर-प्लेस, केटल्स आदि का स्वत: नियंत्रण वर्जित है। इसका अर्थ है कि यदि आप एक संभावित खतरनाक कार्रवाई को स्वचालित बनाना चाहते हैं, तो सुनिश्चित करें कि खतरा उपयोगकर्ता के स्तर तक नहीं पहुंचेगा। सुनिश्चित करें कि एक केतली स्वचालित रूप से बंद हो जाती है जब यह एक निश्चित तापमान तक पहुँच जाती है, कि स्नान में रिसाव सेंसर आदि होते हैं।

10. सिस्टम में स्व-नियंत्रण और आत्म-निदान के विकल्प होने चाहिए।

स्मार्ट होम सिस्टम के एक वर्तमान दिन के डेवलपर को थोड़ा पागल होना चाहिए। इंटरनेट पर भरोसा नहीं किया जा सकता है, यह नीचे हो सकता है। कोड पर भरोसा नहीं किया जा सकता है, बग हो सकते हैं। क्या हार्डवेयर पर भरोसा किया जा सकता है? नहीं, हार्डवेयर पर भरोसा नहीं किया जा सकता है। रिले छड़ी कर सकते हैं, triacs खोल सकते हैं, फ़्यूज़ जला सकते हैं। यहां तक ​​कि एक उपयोगकर्ता एक किलोवाट केतली को 100 - वाट सॉकेट से जोड़ सकता है। इस प्रकार, एक वोल्टेज सेंसर, एक वर्तमान सेंसर और एक तापमान सेंसर की आवश्यकता होती है। यदि तापमान सीमा से अधिक है - सब कुछ बंद करें और चेतावनी भेजें। यदि करंट सीमा से अधिक है - सब कुछ बंद करें। यदि कोई रिले बंद है, लेकिन अभी भी वोल्टेज है - एक अधिसूचना भेजें। यदि आप एक रिले की ओर मुड़ते हैं और कोई वोल्टेज नहीं है - एक अधिसूचना भेजें।

11. सिस्टम में मैनुअल कंट्रोल होना चाहिए।

यहां तक ​​कि अगर आप सभी समानताओं पर विचार करते हैं, तो एक स्थिति होगी जब सभी नियंत्रण विफल हो गए और कुछ टूट गया। यह एक स्विच, एक राउटर या सेंट्रल हब हो सकता है, लेकिन फिर भी एक उपयोगकर्ता शौचालय में प्रकाश चालू करना चाहता है। क्या करें?

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

12. हैकर्स नियमित उपयोगकर्ताओं के रूप में महत्वपूर्ण हैं।

नियमित उपयोगकर्ता आपके लिए पैसे, हैकर्स लाते हैं ⁶ नए कार्यों के बारे में सोच सकते हैं। एक निर्माण प्रणाली के उपयोग के सभी दृश्यों को विकसित नहीं कर सकता है और न ही करना चाहिए, क्योंकि उसे सभी क्षेत्रों में ज्ञान नहीं है और वह ऐसी चीजों के प्रभाव की गणना नहीं कर सकता है। यह काफी संभव है कि एक स्मार्ट सॉकेट मोबाइल ब्रूअरी के थर्मोस्टेट के माध्यम से नियंत्रित करने के लिए सुविधाजनक हो सकता है, क्योंकि इसमें एक पीआईडी-नियामक है। उदाहरण थोड़ा दूर का है, लेकिन विचार यह है कि हैकर्स के लिए सुविधाजनक स्थिति बनाना बुरा नहीं है क्योंकि वे आपके सिस्टम में चलती शक्ति जोड़ सकते हैं।

13. खुलापन: सिस्टम में अन्य प्रणालियों के साथ एकीकृत करने के लिए खुला एपीआई होना चाहिए।

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

14. प्रलेखन: यह उतना ही महत्वपूर्ण है जितना कि हार्डवेयर और कोड।

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

और अंतिम लेकिन कम से कम नहीं:

15. आत्मनिर्भरता और आत्मनिर्भरता: सिस्टम को काम करना चाहिए, भले ही कंपनी अब मौजूद न हो।

एक व्यक्ति लगभग 70-90 वर्ष रहता है, उसके घर में स्थापित एक सिस्टम लगभग 5-10 वर्ष (सबसे अच्छा) में काम करता है, कंपनियां इससे भी कम समय तक चलती हैं। ऐसी प्रणाली न बनाएं जो आपकी कंपनी के मरने पर काम करना बंद कर दे। उपयोगकर्ताओं के लिए महसूस करें। सिस्टम को इस तरह से प्लान करें कि उस पर काम किया जा सके, यहां तक ​​कि कंपनी और डेवलपर भी इस दुनिया में नहीं हैं।

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

---

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

टिप्पणियाँ

1. "उपयोग" से मेरा मतलब है कि सिस्टम के साथ नियमित बातचीत की प्रक्रिया, लेकिन सेटिंग नहीं।
2. मैं इस बात पर जोर देना चाहता हूं कि मैं कहता हूं "एक उपयोगकर्ता को नोटिस नहीं करना चाहिए", लेकिन "देरी के समान नहीं होना चाहिए"। अभ्यास से पता चलता है कि एक मानव 300 मिलीसेकेंड की देरी को नोटिस नहीं करता है।
3. शायद वह एशिया में बढ़ गया और वह सोचता है कि गर्मी के लिए सबसे अच्छा उपाय गर्म हरी चाय है।
4. जब मैं कहता हूं कि "जानकारी न दिखाएं", तो इसका मतलब है कि उपयोगकर्ता को हर बार इसके बारे में संदेश नहीं भेजा जाना चाहिए। यह एक उपयोगकर्ता के अनुरोध पर दिखाया जाना चाहिए - उदाहरण के लिए, "लॉग दिखाएं", या "डिबग जानकारी दिखाएं" जब एक बटन दबाया जाता है। उपयोगकर्ताओं को बेवकूफ के रूप में न देखें, उनके समय का सम्मान करें।
5. ऐसी प्रणाली को डिजाइन करना असंभव है जो असीमित संख्या में उपकरणों का समर्थन करता है। हमेशा सीमाएं होंगी, लेकिन 99% मामलों में उन्हें अप्रासंगिक बनाने के लिए यह एक डेवलपर का काम है। 6 सेंसर की सीमा अस्वीकार्य है। एक नेट में एक सौ या दो सैकड़ों डिवाइस स्मार्ट घरों के अधिकांश उपयोगकर्ताओं के लिए पर्याप्त हैं।
6. मैं RFC1983 के अनुसार इस शब्द के आवश्यक अर्थ में "हैकर" शब्द का उपयोग करता हूं, न कि मैं ऐसे व्यक्ति का अर्थ हूं जो डेटा का अनधिकृत उपयोग प्राप्त करने के लिए कंप्यूटर का उपयोग करता है।

इस पाठ को इरिडियम मोबाइल द्वारा अंग्रेजी में अनुवाद करने में मदद की गई, जिसके लिए मैं उन्हें बहुत धन्यवाद देता हूं।