Deconz-rest-plugin: Melhore o suporte sem cabeça no Linux (dependências da GUI)

@manup

Eu concordo absolutamente que a GUI e as partes headless precisam ser separadas em dois pacotes. Na verdade, este já é um processo em andamento internamente há algum tempo. deCONZ em seus primeiros anos não foi desenvolvido com headless em mente e agora tem muitas classes misturadas que não podem ser separadas facilmente. Essa refatoração está acontecendo, mas em um ritmo lento, sem ETA.

O próprio Qt permanecerá como uma dependência, mas as partes relacionadas ao X11/Wayland não serão necessárias para configuração sem cabeça.

Um objetivo de longo prazo é expor as partes do nó da GUI via REST-API para que, mesmo para instalações headless, um cliente remoto possa exibir nós interativos, com todos os recursos da GUI do deCONZ, por exemplo, em um navegador.

A alternativa sugerida é de fato a única solução para manter o sistema host X11 livre até que a versão slim headless chegue.

Eu sei que isso é um pouco fora do tópico aqui, mas gostaria de fazer um relatório rápido sobre minhas tentativas de contornar essa dependência de GUI usando a conteinerização.

Estou ciente do fato de que há uma imagem oficial do Docker disponível, mas, para ser honesto, prefiro contêineres LXC ou systemd-nspawn simples sobre Docker e já tinha outros contêineres LXC no meu NAS, então tentei ir com isso. Afinal, essas tecnologias contam com os mesmos mecanismos de isolamento no kernel, então devem fornecer resultados comparáveis ​​- ou pelo menos assim eu pensei.

Configurei um contêiner do Ubuntu 18.04 e segui rigorosamente o Guia de instalação do ConnBee em relação à instalação do deCONZ. Então eu tive que pular vários aros para fazer o aplicativo funcionar:

• encaminhar o dispositivo USB para o contêiner LXC ( lxc.cgroup.devices.allow e lxc.mount.entry para o nó do dispositivo)
• sincronizar GIDs para que as regras do udev do host tornem o dispositivo acessível ao grupo plugdev dentro do contêiner
• remova os recursos da unidade systemd, pois eu não queria que o binário os tivesse (na minha configuração, eles não são necessários de qualquer maneira) e o LXC os bloqueou (corrigível usando lxc.cap.keep )

(OT: vejo espaço para melhorias em relação ao empacotamento. Em vez de confiar no UID 1000 codificado, seria muito melhor ter um usuário dedicado criado durante a instalação do pacote, de preferência com UID<1000 e seu diretório inicial abaixo /var/lib para corresponder à forma como muitos outros daemons são configurados. Ficaria feliz em enviar solicitações de pull para isso.)

O aplicativo então pareceu funcionar, ou seja, não apresentou nenhum erro e eu pude configurar a configuração básica do gateway no aplicativo Phoscon. No entanto, tudo relacionado ao hardware ConnBee real não funcionou. Phoscon mostrou a versão do dispositivo, mas não a versão do firmware e todas as propriedades do ZigBee (canal etc.) foram zeradas. Não consegui vincular nenhum sensor.

Então acabei exibindo um Raspberry Pi 3 que sobrou com a imagem oficial _stable_. Com isso, tudo agora funciona bem e tenho todos os meus sensores integrados em um belo painel Grafana.

(OT: A imagem Pi tem suas próprias falhas, por exemplo, em sua configuração padrão, ela tentou iniciar hostapd em um loop infinito que produziu cerca de 700 MiB de logs em uma única semana (cartão SD ruim!) e uma tonelada de carga desnecessária. Ficaria feliz em enviar solicitações de pull para melhorar a configuração (por acaso faço imagens para dispositivos incorporados como meu trabalho diário), mas não encontrei um repositório adequado.)

Um objetivo de longo prazo é expor as partes do nó da GUI via REST-API para que, mesmo para instalações headless, um cliente remoto possa exibir nós interativos, com todos os recursos da GUI do deCONZ, por exemplo, em um navegador.

Isso seria um sonho se tornando realidade