Deconz-rest-plugin: Mejorar el soporte sin cabeza en Linux (dependencias de GUI)

Creado en 30 sept. 2020  ·  4Comentarios  ·  Fuente: dresden-elektronik/deconz-rest-plugin

Tipo de solicitud de función

Estoy ejecutando un servidor de automatización del hogar (en realidad, la misma máquina Linux que estoy usando como NAS) a la que me gustaría conectar mi ConnBee para leer sensores.

Me resulta muy extraño que deconz tenga solo un binario con Qt entre sus dependencias. Sé que se puede ejecutar en modo sin cabeza a través deconz.service , pero el paquete en sí incluye tantos paquetes relacionados con X11 (y Wayland) que es estúpido para un sistema sin cabeza (servidor).

Descripción

Mi solución sugerida para esto sería dividir deconz en múltiples archivos binarios (o incluso paquetes) para que pueda ejecutarse como demonio sin instalar todas las dependencias para la GUI.

No estoy seguro de cuánto de QtNetwork y similares usa en la ruta del código sin cabeza del binario, así que siéntase libre de descartar mi sugerencia si la operación sin cabeza todavía requiere mucho.

Alternativas consideradas

La única alternativa (que estoy tomando actualmente) es configurar un contenedor Debian/Ubuntu que tenga todos los paquetes X11, solo para ejecutar deconz . Eso es bastante exagerado en mi opinión, pero al menos mantiene el 'sistema host' (NAS) al mínimo.

Contexto adicional

¡Me gustaría usar esta sección para agradecerle todo el trabajo y el esfuerzo que pone en sus proyectos relacionados con Zigbee! Realmente aprecio que haya elegido un estilo de desarrollo abierto que permite sinergias con la comunidad.

Feature Request

Comentario más útil

Estoy absolutamente de acuerdo en que la GUI y las partes sin cabeza deben separarse en dos paquetes. En realidad, esto ya es un proceso en curso internamente desde hace bastante tiempo. deCONZ en sus primeros años no se desarrolló teniendo en cuenta el headless y ahora tiene muchas clases entremezcladas que no se pueden separar fácilmente. Esta refactorización está ocurriendo pero a un ritmo lento sin ETA.

Qt permanecerá como una dependencia, pero las partes relacionadas con X11/Wayland no serán necesarias para la configuración sin periféricos.

Un objetivo a largo plazo es exponer las partes del nodo de la GUI a través de REST-API para que, incluso en instalaciones sin periféricos, un cliente remoto pueda mostrar nodos interactivos, con todas las funciones de la GUI de CONZ, por ejemplo, en un navegador.

La alternativa sugerida es, de hecho, la única solución para mantener libre el sistema host X11 hasta que llegue la versión delgada sin cabeza.

Todos 4 comentarios

@ser valiente

Estoy absolutamente de acuerdo en que la GUI y las partes sin cabeza deben separarse en dos paquetes. En realidad, esto ya es un proceso en curso internamente desde hace bastante tiempo. deCONZ en sus primeros años no se desarrolló teniendo en cuenta el headless y ahora tiene muchas clases entremezcladas que no se pueden separar fácilmente. Esta refactorización está ocurriendo pero a un ritmo lento sin ETA.

Qt permanecerá como una dependencia, pero las partes relacionadas con X11/Wayland no serán necesarias para la configuración sin periféricos.

Un objetivo a largo plazo es exponer las partes del nodo de la GUI a través de REST-API para que, incluso en instalaciones sin periféricos, un cliente remoto pueda mostrar nodos interactivos, con todas las funciones de la GUI de CONZ, por ejemplo, en un navegador.

La alternativa sugerida es, de hecho, la única solución para mantener libre el sistema host X11 hasta que llegue la versión delgada sin cabeza.

Sé que esto está un poco fuera de tema aquí, pero me gustaría brindar un informe rápido sobre mis intentos de solucionar esta dependencia de la GUI mediante la creación de contenedores.

Soy consciente del hecho de que hay una imagen oficial de Docker disponible, pero para ser honesto, prefiero LXC o contenedores simples de systemd-nspawn sobre Docker y ya tenía otros contenedores LXC en mi NAS, así que traté de hacerlo. Después de todo, estas tecnologías se basan en los mismos mecanismos de aislamiento en el kernel, por lo que deberían dar resultados comparables, o al menos eso pensé.

Configuré un contenedor Ubuntu 18.04 y seguí estrictamente la Guía de instalación de ConnBee con respecto a la instalación de deCONZ. Luego tuve que saltar varios obstáculos para que la aplicación se ejecutara:

  • reenviar el dispositivo USB al contenedor LXC ( lxc.cgroup.devices.allow y lxc.mount.entry para el nodo del dispositivo)
  • sincronice los GID para que las reglas udev del host hagan que el dispositivo sea accesible para el grupo plugdev dentro del contenedor
  • elimine las capacidades de la unidad systemd porque no quería que el binario las tuviera (en mi configuración no son necesarias de todos modos) y LXC las bloqueó (se puede arreglar usando lxc.cap.keep )

(OT: Veo margen de mejora con respecto al empaquetado allí. En lugar de confiar en el UID 1000 codificado de forma rígida, sería mucho mejor tener un usuario dedicado creado durante la instalación del paquete, preferiblemente con UID<1000 y su directorio de inicio por debajo /var/lib para que coincida con la forma en que muchos otros demonios están configurados. Con gusto enviaría solicitudes de extracción para eso).

Entonces, la aplicación pareció funcionar, es decir, no mostró ningún error y pude establecer la configuración básica de la puerta de enlace en la aplicación Phoscon. Sin embargo, todo lo relacionado con el hardware real de ConnBee no funcionó. Phoscon mostró la versión del dispositivo pero no la versión del firmware y todas las propiedades de ZigBee (canal, etc.) se pusieron a cero. No pude vincular ningún sensor.

Así que terminé mostrando un Raspberry Pi 3 sobrante con la imagen oficial _stable_. Con eso, ahora todo funciona bien y tengo todos mis sensores integrados en un buen tablero Grafana.

(OT: la imagen de Pi tiene sus propios problemas técnicos, por ejemplo, en su configuración predeterminada, intentó iniciar hostapd en un ciclo sin fin que produjo alrededor de 700 MiB de registros en una sola semana (¡pobre tarjeta SD!) y una tonelada de carga innecesaria Me encantaría enviar solicitudes de extracción para mejorar la configuración (sucede que hago imágenes para dispositivos integrados como mi trabajo diario), pero no he encontrado un repositorio adecuado).

Un objetivo a largo plazo es exponer las partes del nodo de la GUI a través de REST-API para que, incluso en instalaciones sin periféricos, un cliente remoto pueda mostrar nodos interactivos, con todas las funciones de la GUI de CONZ, por ejemplo, en un navegador.

Eso sería un sueño hecho realidad.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

jan666 picture jan666  ·  4Comentarios

Thomas-Vos picture Thomas-Vos  ·  4Comentarios

wizkidorg picture wizkidorg  ·  3Comentarios

joecas1 picture joecas1  ·  6Comentarios

1onar picture 1onar  ·  5Comentarios