Deconz-rest-plugin: लिनक्स पर हेडलेस सपोर्ट में सुधार (जीयूआई निर्भरता)

को निर्मित 30 सित॰ 2020 · 4टिप्पणियाँ · स्रोत: dresden-elektronik/deconz-rest-plugin

फ़ीचर अनुरोध प्रकार

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

मुझे यह बहुत अजीब लगता है कि deconz की निर्भरता के बीच Qt के साथ केवल एक बाइनरी है। मुझे पता है कि इसे deconz.service के माध्यम से हेडलेस मोड में चलाया जा सकता है, लेकिन पैकेज स्वयं इतने सारे X11 (और वेलैंड) संबंधित पैकेजों को खींचता है जो एक हेडलेस (सर्वर) सिस्टम के लिए बेवकूफी है।

विवरण

इसके लिए मेरा सुझाया गया समाधान deconz को कई बायनेरिज़ (या यहां तक कि पैकेज) में विभाजित करना होगा ताकि आप इसे GUI के लिए सभी निर्भरताओं को स्थापित किए बिना डेमॉन के रूप में चला सकें।

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

माना विकल्प

एकमात्र विकल्प (जिसे मैं वर्तमान में ले रहा हूं) एक डेबियन/उबंटू कंटेनर स्थापित कर रहा है जिसमें सभी एक्स 11 पैकेज हैं, बस deconz चलाने के लिए। यह मेरी नजर में काफी अधिक है, लेकिन कम से कम यह 'होस्ट सिस्टम' (NAS) को न्यूनतम रखता है।

अतिरिक्त संदर्भ

मैं इस अनुभाग का उपयोग आपके Zigbee संबंधित परियोजनाओं में किए गए सभी कार्यों और प्रयासों के लिए धन्यवाद देने के लिए करना चाहता हूं! मैं वास्तव में सराहना करता हूं कि आपने एक खुली विकास शैली चुनी है जो समुदाय के साथ तालमेल की अनुमति देती है।

Feature Request

स्रोत

lynix

👍3

सबसे उपयोगी टिप्पणी

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

Qt स्वयं एक निर्भरता के रूप में रहेगा, लेकिन हेडलेस सेटअप के लिए X11/Wayland संबंधित भागों की आवश्यकता नहीं होगी।

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

सुझाया गया विकल्प वास्तव में होस्ट सिस्टम X11 को स्लिम हेडलेस संस्करण आने तक मुक्त रखने का एकमात्र समाधान है।

manup 1 अक्तू॰ 2020

❤3 👍2 🎉1

सभी 4 टिप्पणियाँ

@मर्द बनो

Mimiix 1 अक्तू॰ 2020

manup 1 अक्तू॰ 2020

❤3 👍2 🎉1

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

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

मैंने एक Ubuntu 18.04 कंटेनर स्थापित किया और deCONZ की स्थापना के संबंध में ConnBee इंस्टॉल गाइड का सख्ती से पालन किया। तब मुझे एप्लिकेशन चलाने के लिए कई हुप्स कूदना पड़ा:

यूएसबी डिवाइस को एलएक्ससी कंटेनर में अग्रेषित करें ( lxc.cgroup.devices.allow और lxc.mount.entry डिवाइस नोड के लिए)
GIDs को सिंक करें ताकि होस्ट के udev नियम डिवाइस को कंटेनर के अंदर plugdev समूह तक पहुंच योग्य बना सकें
सिस्टमड यूनिट से क्षमताओं को हटा दें क्योंकि मैं नहीं चाहता था कि बाइनरी उनके पास हो (मेरे कॉन्फ़िगरेशन में वे वैसे भी आवश्यक नहीं हैं) और एलएक्ससी ने उन्हें अवरुद्ध कर दिया ( lxc.cap.keep का उपयोग करके ठीक करने योग्य)

(ओटी: मुझे वहां पैकेजिंग के संबंध में सुधार के लिए जगह दिखाई दे रही है। हार्ड-कोडेड यूआईडी 1000 पर निर्भर होने के बजाय पैकेज स्थापना के दौरान एक समर्पित उपयोगकर्ता बनाया जाना बेहतर होगा, अधिमानतः यूआईडी <1000 और इसकी होम निर्देशिका /var/lib से कम है।

तब एप्लिकेशन काम करने लगता था, यानी इसमें कोई त्रुटि नहीं थी और मैं Phoscon ऐप में मूल गेटवे कॉन्फ़िगरेशन सेट कर सकता था। हालाँकि, वास्तविक ConnBee हार्डवेयर से जुड़ी हर चीज़ काम नहीं करती थी। Phoscon ने डिवाइस संस्करण दिखाया लेकिन फर्मवेयर संस्करण नहीं दिखाया और सभी ZigBee गुण (चैनल आदि) शून्य थे। मैं किसी भी सेंसर को बांध नहीं सका।

इसलिए मैंने आधिकारिक _stable_ छवि के साथ एक बचे हुए रास्पबेरी पाई 3 को फ्लैश करना समाप्त कर दिया। इसके साथ, अब सब कुछ ठीक काम करता है और मैंने अपने सभी सेंसरों को एक अच्छे ग्राफाना डैशबोर्ड में एकीकृत कर दिया है।

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

lynix 14 अक्तू॰ 2020

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

यह एक सपना सच होने जैसा होगा

MattL0 1 नव॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स