De rádio FM a Alexa: a evolução de um apaixonado por tecnologia

Como transformei um velho notebook em meu servidor doméstico

Sempre fui apaixonado por eletrônica. Quando criança, adorava comprar revistas do gênero e tentar reproduzir os projetos que encontrava nelas. Montava rádios FM, sistemas de alarme e praticamente qualquer circuito que me parecesse interessante.

Essa paixão acabou se transformando em profissão. Quando eu tinha 14 anos, meu pai me matriculou em um curso técnico de rádio e TV. Não demorou muito para que eu começasse a trabalhar como técnico de televisores e passasse a ganhar dinheiro com aquilo que, até então, era apenas uma paixão.

Da eletrônica para os computadores

Com o passar dos anos, a eletrônica começou a dividir espaço com outra paixão: os computadores.

Vieram a informática, as redes e, principalmente, a programação. Em 2008, cheguei até mesmo a criar meu próprio "Jarvis" em Python — um assistente caseiro inspirado no assistente virtual de Tony Stark, o Homem de Ferro.

E funcionava!

Claro que estava muito longe do Jarvis dos filmes, mas já era extremamente interessante conseguir controlar algumas coisas da casa usando programas que eu mesmo havia escrito.

Até que conheci a Alexa.

Eu já tinha assistido a vídeos no YouTube e lido bastante sobre ela, mas foi durante uma visita à casa de um primo que tive meu primeiro contato com uma funcionando de verdade.

Foi diferente.

Fiquei maravilhado com as possibilidades, comprei a minha e comecei a automatizar minha casa. Primeiro vieram algumas lâmpadas e tomadas; depois, computadores e outros dispositivos.

Como geralmente acontece com quem gosta de tecnologia, uma coisa foi puxando a outra.

Até que comecei a querer algo além.

Eu não queria apenas comprar dispositivos inteligentes e conectá-los a serviços de terceiros. Queria entender melhor o que estava acontecendo, integrar equipamentos diferentes e, principalmente, criar minhas próprias automações localmente.

Foi assim que surgiu a ideia de montar meu homelab.

O começo: um velho Acer E5-571

Eu tinha um notebook Acer Aspire E5-571, com 16 GB de memória RAM e um SSD de 500 GB, que já não utilizava normalmente porque sua tela estava danificada.

Apesar disso, o restante do equipamento continuava funcionando perfeitamente.

Em vez de deixá-lo encostado, resolvi transformá-lo em um servidor doméstico.

Comprei um adaptador caddy para substituir a unidade de DVD por um segundo disco — afinal, espaço de armazenamento nunca é demais. Nele instalei outro SSD que eu já tinha, com 320 GB.

Não era um servidor de última geração. Era simplesmente um equipamento que eu já possuía, ainda tinha um bom desempenho e poderia ganhar uma nova utilidade.

Foi nesse velho Acer que começou meu homelab.

E é justamente essa jornada que pretendo compartilhar nesta série: desde a preparação do servidor até os softwares, serviços, automações, erros, acertos e soluções que fui encontrando pelo caminho.

Não pretendo apresentar uma receita dizendo que esta é "a maneira correta" de montar um homelab. Quero mostrar como montei o meu, explicar minhas escolhas e compartilhar aquilo que aprendi.

Escolhendo o sistema operacional

Um servidor de automação residencial precisa estar disponível 24 horas por dia, sete dias por semana. Por isso, contar com algum tipo de proteção contra quedas de energia é bastante importante.

Nesse ponto, utilizar um notebook como servidor doméstico traz uma vantagem interessante: ele já possui sua própria bateria, funcionando, na prática, como uma pequena UPS (nobreak). Se faltar energia por alguns minutos, o servidor continua funcionando normalmente, evitando desligamentos abruptos e possíveis problemas nos serviços ou nos dados.

Como a bateria original do meu Acer já apresentava problemas devido ao tempo de uso, fui ao Mercado Livre e comprei uma nova.

Assim, além de devolver autonomia ao notebook, ganhei uma camada adicional de proteção para o meu homelab em caso de pequenas interrupções no fornecimento de energia.

Havia ainda outra particularidade no meu projeto.

Eu queria um sistema operacional Linux leve, estável e que consumisse poucos recursos, mas não queria que o computador funcionasse apenas através do terminal, como acontece normalmente com um servidor sem ambiente gráfico.

Queria ter uma interface gráfica disponível. Dessa forma, se eventualmente precisasse navegar pela internet, acessar alguma ferramenta ou até editar rapidamente um artigo do blog — como este aqui, rsrs... — poderia fazer isso diretamente no próprio notebook, sem precisar ligar outro computador.

Foi procurando conciliar essas duas coisas — baixo consumo de recursos e uma interface gráfica leve — que cheguei à escolha do sistema operacional.

Minha escolha foi o DietPi.

Apesar do nome remeter imediatamente ao Raspberry Pi, o DietPi também pode ser instalado em computadores x86_64. Ele é extremamente leve e possui uma ferramenta muito interessante chamada dietpi-software, que facilita bastante a instalação de diversos programas utilizados em servidores domésticos.

Depois da instalação, adicionei o LXDE como ambiente gráfico.

A ideia era simples: manter o servidor o mais leve possível, mas ainda ter uma interface gráfica disponível quando fosse necessário.

O primeiro grande serviço: Home Assistant

Com o sistema funcionando, chegou a hora de instalar o coração da minha automação residencial: o Home Assistant.

O DietPi oferece maneiras bastante simples de instalar diversos softwares através de suas próprias ferramentas. No meu caso, porém, decidi utilizar o Home Assistant em um container Docker.

Essa escolha foi intencional.

O Docker me oferece algumas vantagens importantes para a maneira como pretendo administrar este servidor:

• Isolamento: o Home Assistant fica separado dos demais serviços e pacotes instalados diretamente no sistema.
• Atualizações mais controladas: posso atualizar a imagem do container sem alterar diretamente as dependências do sistema operacional.
• Backup simplificado: a configuração persistente fica armazenada fora do container, facilitando cópias de segurança e restaurações.
• Portabilidade: se futuramente eu trocar o notebook por outro servidor, posso recriar o container e reutilizar os dados persistentes.
• Organização: como pretendo hospedar vários serviços nesse servidor, o Docker ajuda a manter cada aplicação organizada.
• Experimentação: containers também facilitam testes e alterações sem precisar modificar diretamente o sistema base.

Docker acrescenta uma camada a mais de administração, portanto não significa necessariamente que tudo fique mais simples. No meu caso, porém, as vantagens de organização, isolamento e portabilidade compensam essa complexidade adicional.

É importante mencionar também que estou utilizando o Home Assistant Container. Essa modalidade é diferente do Home Assistant OS: aqui eu mesmo sou responsável pelo Docker, pelo sistema operacional, pelas atualizações e pelos demais serviços que desejo instalar no servidor.

Para mim isso é justamente uma vantagem, pois o objetivo não é ter uma máquina dedicada exclusivamente ao Home Assistant, mas um servidor capaz de executar vários serviços diferentes.

Organizando os containers

Antes de instalar o Home Assistant, decidi estabelecer um padrão para os meus containers.

Criei o diretório:

/opt/stacks/

Nele mantenho os arquivos que definem minhas stacks Docker. Cada aplicação possui seu próprio diretório.

Para o Home Assistant, por exemplo:

/opt/stacks/homeassistant/

Existe ainda uma separação importante.

Os arquivos que definem os containers ficam em /opt/stacks, enquanto os dados persistentes das aplicações ficam em /srv/appdata.

No caso do Home Assistant:

/opt/stacks/homeassistant/docker-compose.yml

define como o container será executado, enquanto:

/srv/appdata/homeassistant/

armazena sua configuração persistente.

Essa separação deixa a estrutura do servidor muito mais organizada e também facilita bastante os backups.

Em outras palavras, /opt/stacks guarda a "receita" para criar meus containers, enquanto /srv/appdata guarda os dados que eu realmente não quero perder.

Antes de criar o arquivo do Docker Compose, podemos preparar os diretórios:

sudo mkdir -p /opt/stacks/homeassistant
sudo mkdir -p /srv/appdata/homeassistant

Dependendo do usuário utilizado para administrar o servidor, também pode ser necessário ajustar proprietário e permissões desses diretórios. Não recomendo simplesmente aplicar permissões 777 para resolver problemas de acesso. O ideal é conceder apenas as permissões necessárias ao usuário ou serviço que realmente precisa acessar cada diretório.

Voltarei à organização de diretórios, usuários, permissões e backups em outro artigo, pois esse assunto merece uma explicação própria.

Criando o container do Home Assistant

Dentro de:

/opt/stacks/homeassistant/

criei o arquivo:

docker-compose.yml

com a seguinte configuração:

services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    restart: unless-stopped
    network_mode: host
    privileged: true

    volumes:
      - /srv/appdata/homeassistant:/config
      - /etc/localtime:/etc/localtime:ro

    environment:
      TZ: America/Sao_Paulo

Aqui há alguns detalhes importantes que vale a pena entender em vez de simplesmente copiar o arquivo.

A linha:

network_mode: host

faz com que o Home Assistant utilize diretamente a rede do servidor, em vez de ficar limitado a uma rede virtual criada pelo Docker.

Para automação residencial isso pode ser bastante conveniente, principalmente por causa de protocolos e mecanismos de descoberta utilizados por diferentes dispositivos e integrações existentes na rede local.

Por isso, nessa configuração não é necessário fazer algo como:

ports:
  - "8123:8123"

Com network_mode: host, o Home Assistant utiliza diretamente as interfaces de rede do próprio servidor.

Onde ficam os dados do Home Assistant?

A linha:

- /srv/appdata/homeassistant:/config

faz com que a configuração do Home Assistant seja armazenada no próprio servidor, fora do container.

Isso é fundamental.

O container pode ser removido e recriado, mas os dados permanecem em:

/srv/appdata/homeassistant

É como separar o programa dos seus documentos: posso substituir o programa sem jogar meus arquivos fora.

É justamente esse diretório que merece atenção especial na hora de criar uma rotina de backup.

E o privileged: true?

Existe outra linha no meu arquivo que merece uma explicação especial:

privileged: true

Um container executado em modo privilegiado recebe acesso muito mais amplo aos recursos do sistema hospedeiro.

Isso pode ser útil quando precisamos acessar determinados dispositivos de hardware ou recursos específicos do host, mas também reduz parte do isolamento que normalmente esperamos de um container.

Portanto, não devemos utilizar privileged: true automaticamente em todo container Docker.

No meu arquivo ele está presente por causa da maneira como configurei e utilizo meu ambiente, mas isso não significa que seja obrigatório para toda instalação do Home Assistant.

Se você estiver reproduzindo este projeto, vale primeiro tentar executar o Home Assistant sem essa opção. Quando for necessário fornecer acesso a algum dispositivo específico, muitas vezes é melhor liberar apenas aquele recurso explicitamente do que conceder acesso privilegiado ao container inteiro.

Essa é uma boa regra não apenas para o Home Assistant, mas para Docker de maneira geral: conceda ao container somente aquilo de que ele realmente precisa.

Iniciando o Home Assistant

Depois de criar e salvar o arquivo, basta abrir o terminal e entrar no diretório da stack:

cd /opt/stacks/homeassistant

Em seguida:

docker compose up -d

O Docker fará o download da imagem necessária e criará o container.

A opção -d significa detached mode, fazendo com que o container seja iniciado em segundo plano e devolvendo o controle do terminal.

Podemos verificar se ele está funcionando com:

docker compose ps

Também é possível acompanhar os logs durante a primeira inicialização:

docker compose logs -f

Para sair da visualização dos logs sem interromper o container, basta pressionar Ctrl+C.

Quando o Home Assistant terminar de iniciar, sua interface poderá ser acessada pelo navegador através da porta 8123 do servidor:

http://IP-DO-SERVIDOR:8123

Por exemplo, se o endereço IP do seu servidor fosse 192.168.1.100, o endereço seria:

http://192.168.1.100:8123

A partir daí começa a configuração propriamente dita do Home Assistant.

E isso foi apenas o começo...

Quando comecei, a ideia era simplesmente aproveitar um notebook antigo para executar o Home Assistant.

Não ficou só nisso.

Aos poucos, aquele Acer E5-571 foi ganhando novas funções e se transformando em um verdadeiro servidor doméstico. Vieram Docker, Zigbee2MQTT, Mosquitto, AdGuard Home, Jellyfin, Tailscale, FreshRSS, Stirling PDF e vários outros serviços.

Alguns deles rodam em containers Docker; outros preferi instalar diretamente no sistema. E essa também foi uma decisão importante: nem tudo precisa estar em Docker simplesmente porque Docker está disponível.

Cada serviço tem suas particularidades, e ao longo desta série pretendo explicar por que escolhi determinada forma de instalação para cada um deles.

Também vieram problemas, configurações que precisei refazer, experiências que deram certo e outras que não deram tão certo assim.

E talvez essa seja justamente uma das partes mais interessantes de manter um homelab: ele nunca está realmente "pronto".

Sempre existe alguma coisa para aprender, melhorar, automatizar ou simplesmente experimentar.

É justamente isso que pretendo compartilhar nesta série.

No próximo artigo, antes de começar a instalar novos serviços, quero mostrar como organizei meu homelab: Docker, stacks, dados persistentes, diretórios e backups. Essa organização acabou se tornando a base para praticamente tudo o que instalei depois.

Depois disso, entraremos individualmente nos serviços e integrações que fazem parte do servidor.

Talvez aquele computador antigo que está encostado aí também possa ganhar uma segunda vida.