Qual a melhor opção HA em NUC?

Dúvidas
#1

Boas,

Depois de muito tempo a usar HASSBIAN num raspberry e ter experimentado criar uma máquina virtual com HASSIO decidi avançar para a compra de um Intel NUC dedicado para o HA.

Instalei no NUC o Ubuntu Server + Docker e HASSIO, mas depois de “inventar” um pouco por diversas vezes tive que instalar o SO novamente e restaurar o HA. Após algumas pesquisas aqui pelo fórum vejo quem esteja a usar Proxmox que ontem instalei numa máquina virtual para experimentar pois nunca tinha usado mas ainda não instalei nada.

Gostava assim de saber qual seria para vocês a melhor opção, se Ubuntu + Docker + HASSIO ou Proxmox e SO (Qual?)

Umas dos problemas que encontrei com Docker e que depois de muitas instalações o bluetooth ou não encontra dispositivos ou não funciona com o sensor Mijia da Xiaomi (temperatura e humidade). Quer seja o BT onboard ou Dongle, pois também já tentei desativar na bios o BT Onboard mas não tenho essa opção.

#2

A minha experiência passou por RPI 3B+ (Hass.io) e, agora, NUC com Proxmox. Em Proxmox, usei até há pouco tempo uma VM com HassOS, com instalação automática das imagens para VM, através de este script: https://github.com/whiskerz007/proxmox_hassos_install

Desde há umas semanas para cá, a minha opção de produção é usar uma instalação em LXC (com Debian 10), invés de VM, através de este script de instalação automático: https://github.com/whiskerz007/proxmox_hassio_lxc Em desempenho computacional e utilização de recursos, é da noite para o dia.

Quanto a Bluetooth, em linux costuma ser uma péssima experiência. Tratei de integrar tudo o que tenho em BLE, com recurso a um ESP32 com o firmware ESPHome. Nomeadamente, os Xiaomi Miflora. A balança da Xiaomi v1 e v2 está em desenvolvimento no ESP32.

#3

Em lxc só se utilizares o HA core.

#4

É em tudo semelhante ao HassOS - com HA Core, também com dockers. Só que em vez de virtualizar uma máquina inteira, usa os recursos no host, que é o Proxmox.

Os full snapshots do HA provindos de uma VM de HassOS são 100% compatíveis com esta metodologia em LXC. Assim o fiz na migração.

As configurações de hardware (especialmente, do CC2531) são instantâneas, pois os LXC bebem dos recursos que estão no host. (Desde que não estejam alocados a uma VM.)

#5

Existem inúmeras limitações e problemas como podes verificar no issues abertos… para além das naturalmente conhecidas a nível de performance e a mais importante: A segurança em correr docker dentro de um LXC, por motivos relacionados com o isolamento e estado privilegiado que o LXC necessita estar para a coisa funcionar. Não sei como é possível dizer que o desempenho será superior quando tens este nível de problemas e… está a ser criado não só um container inception como o acesso aberto ao host.

#7

A desempenho, refiro-me a reduzir os recursos consumidos para 20% do que os que tinha na VM (consumo CPU e alocação de RAM), resposta do frontend muito mais rápida, etc.

Até ver, não tenho tido problemas, nem sofrido dos relatados no github. Só tenho a dizer bem.

Eu reconheço que é uma configuração avançada e que pode causar alguns arrepios aos mais avessos ao risco. Todavia, com as devidas precauções em cascata/cebola, não é muito menos seguro do que uma configuração padrão em máquina física.

#8

A configuração não é avançada… muito pelo oposto. Saliento que este tipo de instalação vai contra as recomendações do proxmox e envolve um risco de segurança que não deve ser descuidado.

#9

Risco esse que inclui o Supervisor quando recebe um pedido de reboot do host, o fazer ao Proxmox em vez de o fazer ao LXC…

#10

Na minha primeira instalação no NUC consegui (não sei como) receber a informação do sensor sem qualquer problema. Depois tive que fazer nova instalação e deixei de conseguir. Estou a por a hipótese de configurar um ESP32 pois também tenho a MiScale que tentei configurar recentemente mas sem sucesso.

#11

Testei num setup de desenvolvimento durante vários dias, com múltiplos reboots (é onde testo tudo, antes de portar para o de produção). Não confirmo isso.

Não descarto problemas futuros.

Apresento aqui apenas como uma solução alternativa, automatizada (basta executar 1 script) e com grandes ganhos de performance em configurações complexas de HA Core, Add-ons e automações. A minha ex-VM de HA consumia quase 3 GB de RAM a 100%. Agora, nem 1GB… CPU, quase a relantim…

imagem

#12

Será somente uma solução alternativa se for entendido e aceite os riscos da mesma e suas limitações face a ter uma VM. Podes consultar no fórum oficial do proxmox várias threads sobre este tema que basicamente vão dar tudo ao mesmo :

Screenshot_20200309-171031_Chrome
Screenshot_20200309-171031_Chrome1080×1085 411 KB

1 Curtiu
#13

O problema parece-me ser precisamente esse, cada reboot ao host é uma lotaria… Nunca acontece nada até ao dia que acontece.

Em relação ao consumo de memória, podes fazer um teste: três VMs com valores de memória atribuída diferentes (por exemplo 1, 2 e 4gb) com o mesmo HA lá dentro. Vais ver que o “consumo” de memória é sempre elevado, isto porque o Supervisor trata de reservar o máximo possível de memória para garantir o funcionamento do HA.

#14

Reforçando o que o @j_assuncao disse: tens o caso dos addons de bd que vão consumir “muita” RAM (caso esteja disponível) para aumentar a velocidade, tempos de resposta e reduzir os IOs ao disco. Tal como este exemplo, existem muitos outros que “abusivamente” vão aproveitar de forma ótima os recursos que são dados como disponíveis e tirar partido dos mesmos para melhorar a performance do sistema e proporcionar uma melhor experiência ao utilizador.

#15

Boas!

Muito bom tópico. É um tema que gera sempre discussão, e há várias maneiras de ter o HA nos NUCs…

A mais recente que utilizo é exatamente a referida pelo ReDaLeRt, e confirmo que:

  1. Notei uma diferença significativa de performance. O vosso “site” do HA abre rapido? abre bem mais rápido com HA sob LXC. Os boots são também mais rápidos.
    O meu CPU idle da instalação HassOS andava sempre entre os 7-10%, agora anda entre os 1-3%.

  2. Além do ponto anterior, tal como o ReDaLert, notei um consumo de RAM inferior em 30% aproximadamente.

  3. Fiz restore de um hassio backup e não precisei de fazer mais nada, tudo ficou a funcionar perfeitamente, inclusivamente o zigbee2mqtt que desta forma nem precisa de “passar” o USB para a VM (o que leva ao ponto seguinte).

  4. A crítica que mais se lê pelos foruns é precisamente que esta abordagem é menos segura. Eu vivo bem com este risco.
    Aliás, a própria dev team num post do blog oficial do HA refere precisamente que esta abordagem não deve ser seguida (bem explicado aqui: https://github.com/whiskerz007/proxmox_hassio_lxc/issues/12), no entanto a explicação é de certo modo esclarecida pelo whiskerz007, que eu passo a citar:

The way this Hass.io LXC container has been setup for use is to remove any security limitations applied to the container, which in effect allows the applications inside of the container to run as if it is on the host OS. Specific devices are also passed into the container that Hass.io, and it’s addons, has an interest in. Docker is installed using their installation script. Hass.io is installed using their installation script. In effect, the LXC is configured just like you would if you were going to install Hass.io onto a Debian OS on bare metal.

Some benefits of running Hass.io in a LXC versus a VM are: ability to pass the same device to multiple LXC (VM needs solitary access), increased performance, quicker access to Hass.io UI from cold boot, access and control to underlying OS running Hass.io, isolation from host OS (in this case Proxmox) and other containers, ability to manage resources (CPU cores, RAM size, HDD size, network settings) from a UI without the need to reboot the container.

  1. Isto a meu ver é quase uma discussão ideológica, e a análise deve ser relativizada.
    Para quem usa o HA num RPI dedicado só para isso, ou num NUC dedicado só para isso, não é questão.

  2. A minha motivação para usar esta abordagem é simplesmente obter o melhor de 2 mundos. Performance excelente, e ter a capacidade de usar o proxmox para gerir os outros LXCs e VMs que tenho, sabendo à partida que não é a opção mais segura.

1 Curtiu
#16

Cada um deve usar aquilo que acha ser melhor para si, mas é preciso que se esclareça os riscos que essa solução tem. Quem não tem conhecimentos na área e de repente lê que há uma solução que oferece maior rapidez e redução dos consumos de recursos da máquina, poderá ficar com a ideia que esta será uma solução milagrosa e sem riscos.

Além disso, se fosse uma solução “válida” e sem riscos estaria na pagina oficial do Home Assistant como método de instalação recomendado ou alternativo. Mas como disse acima, caso o utilizador esteja ciente dos riscos que corre e disposto a correr esses mesmos riscos, não vejo problema em utilizar este método de instalação.

#17

Como é que fizeste para utilizar esse script de instalaçao do H mas no container em vez da VM? obrigado

#18

Na linha de comandos do Proxmox.

#19

Ah ok… o script cria logo por defeito a imagem do home assistant em container em vez de VM. A pen usb conbee depois é fácil de adicionar?

#20

Basta seguir os tutoriais que há aqui no fórum. Sim, é fácil.

#21

Instalando o HA através do LXC, não ficas com esta mensagem? Conseguiste instalar o HACS?

image

Copyright © 2017-2021. Todos os direitos reservados
CPHA.pt - info@cpha.pt

FAQ | Termos de Serviço/Regras | Política de Privacidade