Deconz-rest-plugin: تحسين الدعم بدون رأس على Linux (تبعيات واجهة المستخدم الرسومية)
نوع طلب الميزة
أنا أقوم بتشغيل خادم أتمتة منزلي (في الواقع نفس جهاز Linux الذي أستخدمه كـ NAS) والذي أرغب في توصيل ConnBee به من أجل مستشعرات القراءة.
أجد أنه من الغريب جدًا أن يحتوي deconz على ثنائي واحد فقط مع Qt بين تبعياته. أعلم أنه يمكن تشغيلها في وضع مقطوعة الرأس عبر deconz.service ، لكن الحزمة نفسها تسحب الكثير من الحزم ذات الصلة بـ X11 (و Wayland) وهو أمر غبي بالنسبة لنظام (خادم) بدون رأس.
وصف
سيكون الحل الذي اقترحه لهذا هو تقسيم deconz إلى ثنائيات متعددة (أو حتى حزم) بحيث يمكنك تشغيلها كخادم دون تثبيت جميع التبعيات الخاصة بواجهة المستخدم الرسومية.
لست متأكدًا من مقدار QtNetwork وما شابه ذلك الذي تستخدمه في مسار الشفرة بدون رأس للثنائي ، لذلك لا تتردد في تجاهل اقتراحي إذا كانت العملية بدون رأس لا تزال تتطلب الكثير منها.
تعتبر البدائل
البديل الوحيد (الذي أتناوله حاليًا) هو إعداد حاوية Debian / Ubuntu التي تحتوي على جميع حزم X11 ، فقط لتشغيل deconz . هذا مبالغة في نظري ، لكنه على الأقل يبقي "النظام المضيف" (NAS) في حده الأدنى.
سياق إضافي
أود استخدام هذا القسم لأشكركم على كل العمل والجهد الذي بذلتموه في المشاريع المتعلقة بـ Zigbee! أنا أقدر حقًا أنك اخترت أسلوب تطوير مفتوح يسمح بالتآزر مع المجتمع.
lynix
ال 4 كومينتر
@استرجل
Mimiix
في ١ أكتوبر ٢٠٢٠
أوافق تمامًا على ضرورة فصل واجهة المستخدم الرسومية والأجزاء التي لا رأس لها إلى حزمتين. هذه بالفعل عملية مستمرة داخليًا لبعض الوقت. لم يتم تطوير deCONZ في سنواتها الأولى مع وضع بلا رأس في الاعتبار ولديها الآن العديد من الفصول المختلطة التي لا يمكن فصلها بسهولة. تتم عملية إعادة البناء هذه ولكن بوتيرة بطيئة مع عدم وجود ETA.
ستبقى Qt نفسها بمثابة تبعية ، ولكن لن تكون هناك حاجة إلى الأجزاء ذات الصلة بـ X11 / Wayland للإعداد بدون رأس.
يتمثل أحد الأهداف طويلة المدى في الكشف عن أجزاء عقدة واجهة المستخدم الرسومية عبر REST-API بحيث يمكن للعميل البعيد عرض العقد التفاعلية ، مع جميع ميزات واجهة المستخدم الرسومية deCONZ ، على سبيل المثال في المستعرض ، حتى بالنسبة للتثبيتات بدون رأس.
البديل المقترح هو في الواقع الحل الوحيد لإبقاء النظام المضيف X11 مجانيًا حتى وصول الإصدار النحيف مقطوع الرأس.
manup
في ١ أكتوبر ٢٠٢٠
أعلم أن هذا خارج الموضوع قليلاً هنا ولكني أرغب في تقديم تقرير سريع حول محاولاتي للتغلب على تبعية واجهة المستخدم الرسومية هذه باستخدام الحاوية.
أنا على دراية بحقيقة أن هناك صورة Docker رسمية متاحة ، ولكن لأكون صادقًا ، أفضل حاويات LXC أو systemd-nspawn العادية على Docker ولديها بالفعل حاويات LXC أخرى على NAS الخاص بي لذا حاولت استخدام ذلك. بعد كل شيء ، تعتمد هذه التقنيات على نفس آليات العزل في Kernel لذا يجب أن تعطي نتائج مماثلة - أو على الأقل هكذا اعتقدت.
قمت بإعداد حاوية Ubuntu 18.04 واتبعت بدقة دليل تثبيت ConnBee فيما يتعلق بتثبيت deCONZ. ثم اضطررت للقفز عدة أطواق لتشغيل التطبيق:
- إعادة توجيه جهاز USB إلى حاوية LXC (
lxc.cgroup.devices.allowوlxc.mount.entryلعقدة الجهاز) - مزامنة معرّفات GID حتى تتيح قواعد udev للمضيف إمكانية وصول الجهاز إلى مجموعة
plugdevداخل الحاوية - قم بإزالة الإمكانات من وحدة systemd لأنني لم أرغب في أن يمتلكها النظام الثنائي (في تهيئتي ليست مطلوبة على أي حال) وقام LXC بحظرها (قابل للإصلاح باستخدام
lxc.cap.keep)
(الوقت الإضافي: أرى مجالًا للتحسين فيما يتعلق بالتعبئة هناك. بدلاً من الاعتماد على UID 1000 ذي الترميز الثابت ، سيكون من الأفضل كثيرًا أن يكون لديك مستخدم مخصص تم إنشاؤه أثناء تثبيت الحزمة ، ويفضل أن يكون مع UID <1000 ودليله الرئيسي أقل من /var/lib لمطابقة الطريقة التي يتم بها إعداد العديد من الشياطين الأخرى. سأرسل طلبات سحب لذلك لحسن الحظ.)
ثم يبدو أن التطبيق يعمل ، أي أنه لم يبث أي خطأ ويمكنني إعداد التكوين الأساسي للبوابة في تطبيق Phoscon. ومع ذلك ، فإن كل ما يتعلق بأجهزة ConnBee الفعلية لم يعمل. أظهر Phoscon إصدار الجهاز ولكن ليس إصدار البرنامج الثابت وجميع خصائص ZigBee (القناة وما إلى ذلك) تم صفر. لم أتمكن من ربط أي أجهزة استشعار.
لذلك انتهى بي الأمر برش صورة Raspberry Pi 3 المتبقية مع صورة _stable_ الرسمية. مع ذلك ، يعمل كل شيء الآن بشكل جيد وقد تم دمج جميع المستشعرات الخاصة بي في لوحة تحكم Grafana لطيفة.
(الوقت الإضافي: تحتوي صورة Pi على مواطن الخلل الخاصة بها ، على سبيل المثال ، في تكوينها الافتراضي ، حاولت بدء hostapd في حلقة لا نهاية لها أنتجت حوالي 700 ميجابايت من السجلات في غضون أسبوع واحد (بطاقة SD ضعيفة!) وطنًا من التحميل غير الضروري. يسعدني إرسال طلبات السحب لتحسين الإعداد (تصادف أن أجعل الصور للأجهزة المضمنة وظيفتي النهارية) ، لكنني لم أجد الريبو المناسب.)
lynix
في ١٤ أكتوبر ٢٠٢٠
يتمثل أحد الأهداف طويلة المدى في الكشف عن أجزاء عقدة واجهة المستخدم الرسومية عبر REST-API بحيث يمكن للعميل البعيد عرض العقد التفاعلية ، مع جميع ميزات واجهة المستخدم الرسومية deCONZ ، على سبيل المثال في المستعرض ، حتى بالنسبة للتثبيتات بدون رأس.
سيكون هذا حلم يتحقق
MattL0
في ١ نوفمبر ٢٠٢٠
القضايا ذات الصلة
jan666
·
4تعليقات
stevenwfoley
·
3تعليقات
philko123
·
3تعليقات
marthoc
·
6تعليقات
qm3ster
·
3تعليقات
التعليق الأكثر فائدة
أوافق تمامًا على ضرورة فصل واجهة المستخدم الرسومية والأجزاء التي لا رأس لها إلى حزمتين. هذه بالفعل عملية مستمرة داخليًا لبعض الوقت. لم يتم تطوير deCONZ في سنواتها الأولى مع وضع بلا رأس في الاعتبار ولديها الآن العديد من الفصول المختلطة التي لا يمكن فصلها بسهولة. تتم عملية إعادة البناء هذه ولكن بوتيرة بطيئة مع عدم وجود ETA.
ستبقى Qt نفسها بمثابة تبعية ، ولكن لن تكون هناك حاجة إلى الأجزاء ذات الصلة بـ X11 / Wayland للإعداد بدون رأس.
يتمثل أحد الأهداف طويلة المدى في الكشف عن أجزاء عقدة واجهة المستخدم الرسومية عبر REST-API بحيث يمكن للعميل البعيد عرض العقد التفاعلية ، مع جميع ميزات واجهة المستخدم الرسومية deCONZ ، على سبيل المثال في المستعرض ، حتى بالنسبة للتثبيتات بدون رأس.
البديل المقترح هو في الواقع الحل الوحيد لإبقاء النظام المضيف X11 مجانيًا حتى وصول الإصدار النحيف مقطوع الرأس.