Jeff Bruchado
Voltar para o Blog

Casa Inteligente Sem Internet em 2026: Como Montar uma Automação Local-First Que Não Morre com a Nuvem

Olá HaWkers, um texto chamado "Smart home devices should work without the internet" passou de 940 pontos e 330 comentários no Hacker News nesta semana. O autor automatiza a própria casa há mais de dez anos e resume tudo numa regra: sem internet, sem problema. Nada essencial na casa dele depende do servidor de um fabricante.

O assunto pegou porque todo mundo tem uma história parecida. A Belkin encerrou o suporte em nuvem da linha Wemo em 31 de janeiro de 2026. A Vorwerk desligou a nuvem dos robôs aspiradores da Neato três anos antes do prometido. Tem gente nos comentários com geladeira que não muda a temperatura por bug no app e forno que resolveu atualizar o software no meio do preparo. Você já parou para contar quantos aparelhos da sua casa deixam de funcionar se a internet cair? Neste artigo você vai entender por que isso acontece, como avaliar o que você já tem e como montar uma automação que continua funcionando com o cabo do modem desligado, com código de verdade.

O Problema: Você Comprou o Aparelho, Mas Não Comprou o Servidor

A maior parte dos dispositivos "smart" vendidos nos últimos dez anos segue a mesma arquitetura. O aparelho conecta no Wi-Fi, abre uma conexão com o servidor do fabricante e espera comandos de lá. O app do seu celular também fala com esse servidor. Quando você aperta "ligar" no app, o comando sai do celular, vai até um data center, volta pela internet e chega no aparelho que está a três metros de você.

Isso tem vantagens para o fabricante: setup fácil, acesso remoto sem configurar nada, telemetria, atualização centralizada. O problema é que a função básica do aparelho passa a depender de três coisas que você não controla:

  • A sua conexão com a internet. Caiu a operadora, a lâmpada não acende pelo app.
  • O servidor do fabricante. Fora do ar, certificado vencido, mudança de API.
  • A existência da empresa. Faliu, foi vendida ou decidiu que o produto não dá mais lucro.

O autor do texto conta que a integração dele com o termostato Nest funcionava até o Google quebrar a API. Um leitor relatou um termômetro de carne que parou de funcionar quando a empresa fechou. A frase que resume o caso é dura: o hardware sobreviveu à empresa e parou de funcionar mesmo assim.

Os casos recentes que viraram exemplo

Produto O que aconteceu Quando
Belkin Wemo Fim do suporte em nuvem e do app; só 4 modelos com HomeKit via Thread seguem funcionando 31/01/2026
Neato (Vorwerk) Nuvem desligada antes de 2028, prazo que tinha sido prometido Fim de 2025

Repare no detalhe da Wemo: os quatro modelos que sobreviveram (WLS0503, WSC010, WSP100 e WDC010) são justamente os que falam um protocolo local, o HomeKit sobre Thread. Os outros dependiam só da nuvem da Belkin. Essa é a lição técnica inteira em uma linha.

O Que Significa Local-First na Prática

Local-first, no contexto de casa inteligente, quer dizer que o comando sai do interruptor, do sensor ou do celular e chega no aparelho sem sair da sua rede. A internet vira um extra: serve para acesso remoto, para assistente de voz, para notificação. Se ela some, a casa continua funcionando.

O autor do post organizou isso em regras que valem copiar. As principais:

  1. Sem internet, sem problema. Função essencial nunca depende de servidor externo.
  2. Não remova o jeito antigo. O interruptor da parede continua funcionando mesmo com automação.
  3. Dispositivo em nuvem precisa de API com log. Se não tem, não entra em nada importante.
  4. Configuração centralizada. Um lugar só para ver e mudar as automações.
  5. Várias formas de interagir. Botão físico, app, voz e automação, nenhuma obrigatória.
  6. Bateria tem que durar pelo menos um ano. Sensor que pede troca todo mês vira sensor desligado.

A regra 2 parece óbvia, mas é a que mais gente quebra. O exemplo clássico, citado no próprio texto, é a fita adesiva em cima do interruptor para a lâmpada inteligente nunca ficar sem energia. Funciona até a visita apagar a luz do jeito normal. A solução é trocar o interruptor por um modelo inteligente de parede, que mantém o gesto que todo mundo já conhece.

As peças de uma casa local-first

Hoje a pilha mais comum tem quatro camadas:

  • Um hub local, quase sempre o Home Assistant rodando num Raspberry Pi, num mini PC ou num servidor que você já tem.
  • Um broker MQTT, como o Mosquitto, para dispositivos que publicam e assinam mensagens na rede.
  • Protocolos locais: Zigbee e Z-Wave por rádio próprio, Thread e Matter no padrão novo, e Wi-Fi com firmware aberto como Tasmota ou ESPHome.
  • Acesso remoto opcional, por VPN (WireGuard, Tailscale) em vez de nuvem do fabricante.

Matter e Thread em 2026: O Padrão Ficou Bom o Suficiente?

O Matter nasceu exatamente para resolver esse problema: um padrão comum, mantido pela Connectivity Standards Alliance, em que o controle acontece na rede local. Ele roda sobre Wi-Fi, Ethernet ou Thread, que é uma rede mesh de baixo consumo pensada para sensores e lâmpadas.

Em 2026 o padrão deu dois passos importantes. Em 17 de junho a CSA anunciou o Matter 1.6, com setup por NFC (você encosta o celular no interruptor antes mesmo de instalar), o Joint Fabric, que deixa vários controladores administrarem a mesma rede Matter, e sugestões de temperatura para termostatos em vez de comandos diretos. No Home Assistant, a atualização de 23 de junho trocou o motor do Matter por um servidor novo baseado no matter.js, a implementação open source em TypeScript, subiu o suporte para a especificação 1.5.1 e atualizou o OpenThread Border Router para o Thread 1.4. Segundo o próprio projeto, o Matter já roda em 38% das instalações do Home Assistant.

Mas atenção a uma armadilha: ter o selo Matter não garante que tudo funciona sem internet. O controle básico (ligar, desligar, ler o sensor) é local, mas alguns fabricantes ainda mandam recursos extras pela nuvem e exigem a conta deles para o setup inicial. Na hora de comprar, procure aparelho que faça o pareamento direto no seu controlador e teste com a internet desligada logo no primeiro dia, ainda dentro do prazo de devolução.

Passo 1: Subindo o Home Assistant e o Mosquitto com Docker

Se você já tem um servidor em casa, o caminho mais rápido é Docker Compose. O arquivo abaixo sobe o Home Assistant e o broker MQTT na mesma máquina:

# docker-compose.yml
# Home Assistant + Mosquitto rodando 100% na rede local
services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    # network_mode host é necessário para descoberta de dispositivos (mDNS, Matter)
    network_mode: host
    volumes:
      - ./ha-config:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped

  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mosquitto
    ports:
      - "1883:1883"   # MQTT sem TLS, só para a rede interna
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data
    restart: unless-stopped

A partir da versão 2, o Mosquitto não aceita conexões externas sem configuração explícita. Crie o arquivo de configuração e um usuário:

# Cria a configuração mínima do Mosquitto com autenticação
mkdir -p mosquitto/config mosquitto/data

cat > mosquitto/config/mosquitto.conf <<'EOF'
listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd
persistence true
persistence_location /mosquitto/data/
EOF

# Sobe os containers
docker compose up -d

# Cria o usuário "casa" (o comando pede a senha)
docker exec -it mosquitto mosquitto_passwd -c /mosquitto/config/passwd casa
docker restart mosquitto

Depois disso, acesse http://IP-DO-SERVIDOR:8123, crie a conta local do Home Assistant e adicione a integração MQTT apontando para o mesmo IP, porta 1883, com o usuário que você acabou de criar. Note que a conta do Home Assistant fica na sua máquina: não existe login em servidor externo para a casa funcionar.

Passo 2: Um Dispositivo Que Fala MQTT Direto, Sem Nuvem

O exemplo mais barato de dispositivo local são as tomadas e relés com chip ESP8266 ou ESP32 rodando Tasmota, firmware aberto que fala MQTT nativamente. Com o broker no ar, você controla a tomada de qualquer máquina da rede:

# Liga a tomada "sala" via MQTT (tópico padrão do Tasmota: cmnd/<nome>/POWER)
mosquitto_pub -h 192.168.1.10 -u casa -P 'sua-senha' \
  -t cmnd/sala/POWER -m ON

# Em outro terminal, acompanha o estado que a tomada publica de volta
mosquitto_sub -h 192.168.1.10 -u casa -P 'sua-senha' \
  -t 'stat/sala/#' -v

Esse é o ponto que muda a cabeça: o comando foi do seu terminal até o broker e do broker até a tomada. Nenhum pacote saiu da sua casa. Se amanhã o fabricante da tomada fechar as portas, nada acontece, porque a tomada nunca dependeu dele.

Passo 3: Descobrindo Quem na Sua Casa Liga para Fora

Antes de trocar qualquer coisa, vale medir. A maioria dos roteadores com OpenWrt usa o dnsmasq, que pode registrar cada consulta DNS. Com o log ativado (log-queries na configuração), este script em Python agrupa os domínios consultados por aparelho e mostra quem mais conversa com a internet:

# quem_liga_para_fora.py
# Lê um log do dnsmasq e conta domínios consultados por IP de origem
import re
import sys
from collections import Counter, defaultdict

# Linha típica: "query[A] api.fabricante.com from 192.168.1.42"
PADRAO = re.compile(r"query\[\w+\] (\S+) from (\d+\.\d+\.\d+\.\d+)")

def analisar(caminho_log):
    por_aparelho = defaultdict(Counter)
    with open(caminho_log, encoding="utf-8", errors="ignore") as arquivo:
        for linha in arquivo:
            achado = PADRAO.search(linha)
            if achado:
                dominio, ip = achado.groups()
                por_aparelho[ip][dominio] += 1
    return por_aparelho

if __name__ == "__main__":
    resultado = analisar(sys.argv[1])
    # Ordena os aparelhos pelo total de consultas
    for ip, dominios in sorted(resultado.items(), key=lambda item: -sum(item[1].values())):
        print(f"\n{ip}  ({sum(dominios.values())} consultas)")
        for dominio, total in dominios.most_common(5):
            print(f"   {total:>6}  {dominio}")

Rode com python3 quem_liga_para_fora.py /tmp/dnsmasq.log depois de deixar o log coletando por um dia. É comum descobrir que a TV, o aspirador e a lâmpada mais barata da casa fazem milhares de consultas por dia. Isso não prova que algo está errado, mas mostra exatamente quais aparelhos têm dependência de nuvem e merecem atenção.

Se você quer ir mais fundo em como separar esses aparelhos do resto da rede, eu já mostrei a parte de roteador no artigo sobre como configurar o roteador Wi-Fi dual band para dispositivos IoT.

Passo 4: Cortando a Internet de Quem Não Precisa Dela

Com a lista em mãos, você pode bloquear o acesso externo de um aparelho que já é controlado localmente. Assim ele continua funcionando na rede, mas não manda telemetria nem recebe atualização surpresa. No OpenWrt com firewall4 (nftables), uma regra por endereço MAC resolve:

# /etc/config/firewall (OpenWrt) - bloqueia a saída para a internet
# de um dispositivo específico, mantendo o acesso na rede local
config rule
	option name 'iot-sem-internet-tomada-sala'
	option src 'lan'
	option dest 'wan'
	option src_mac 'AA:BB:CC:DD:EE:FF'
	option target 'REJECT'

# Aplique com:
#   service firewall restart

Faça isso só depois de testar que o aparelho funciona com o Home Assistant sem internet. Bloquear um aparelho que depende da nuvem só transforma ele num enfeite mais cedo. O caminho mais organizado, quando o roteador permite, é criar uma rede separada (VLAN ou SSID de convidados) só para IoT e bloquear o acesso à internet da rede inteira, liberando exceções.

Passo 5: Automação Que Não Depende de Ninguém

Com os dispositivos locais no Home Assistant, as automações rodam na sua máquina. Este exemplo liga um ventilador da garagem quando a temperatura passa de 32 °C, no mesmo espírito do fluxo que o autor do post usa para evitar superaquecimento:

# automations.yaml - roda localmente no Home Assistant
- alias: "Garagem: ventilar quando esquentar"
  description: "Liga o ventilador se a garagem passar de 32 °C e desliga abaixo de 28 °C"
  mode: single
  triggers:
    - trigger: numeric_state
      entity_id: sensor.garagem_temperatura
      above: 32
      for: "00:05:00"   # evita ligar por um pico momentâneo
  conditions:
    - condition: state
      entity_id: binary_sensor.garagem_porta
      state: "off"      # porta fechada
  actions:
    - action: switch.turn_on
      target:
        entity_id: switch.garagem_ventilador
    - wait_for_trigger:
        - trigger: numeric_state
          entity_id: sensor.garagem_temperatura
          below: 28
      timeout: "02:00:00"
    - action: switch.turn_off
      target:
        entity_id: switch.garagem_ventilador

Repare que nenhum passo depende de serviço externo. O sensor manda a leitura por Zigbee ou MQTT, o Home Assistant decide e a tomada liga. Se você quer receber uma notificação no celular quando isso acontecer, aí sim pode usar a internet, mas como extra, nunca como condição para o ventilador funcionar.

Os Cuidados Que Ninguém Conta

Local-first não é de graça. Algumas coisas que valem saber antes de começar:

  • Você vira o administrador. Backup da configuração do Home Assistant, atualização do sistema e troca de cartão SD que morreu passam a ser responsabilidade sua. Use SSD sempre que possível.
  • Automação conflitante existe. O autor descobriu quatro agendamentos disparando a mesma bomba do jardim. Revise as automações de tempos em tempos.
  • Acesso remoto precisa de cuidado. Nunca exponha a porta 8123 direto na internet. Use VPN como WireGuard ou Tailscale.
  • Nem tudo tem alternativa local. Câmera com nuvem, geladeira e lava-louça muitas vezes não oferecem controle local. Nesses casos, a regra é aceitar que a função "smart" é descartável e garantir que a função básica funcione pelo painel físico.
  • Compre pensando no fim da empresa. Prefira Matter, Zigbee, Z-Wave ou dispositivos que aceitem firmware aberto. Comunidades como a de direito ao reparo, incluindo a FULU Foundation citada nos comentários, mantêm listas e projetos de firmware alternativo para produtos abandonados.

Perspectivas: A Casa Inteligente Está Voltando para Casa

O sentimento dos comentários no Hacker News é claro: muita gente cansou de pagar por aparelho que vira peso de papel quando uma empresa muda de ideia. Ao mesmo tempo, o padrão técnico finalmente amadureceu. Matter 1.6 com setup por NFC, Home Assistant com servidor Matter novo e Thread 1.4, e uma geração de dispositivos que aceita controle direto na rede local tornam o caminho local-first muito menos trabalhoso do que era há cinco anos.

A pergunta que fica para você é simples: dos aparelhos da sua casa, quantos ainda funcionariam amanhã se o fabricante fechasse hoje? Se a resposta incomoda, comece pequeno. Suba o Home Assistant, troque uma tomada, rode o script de DNS por uma semana e veja o que aparece. A internet continua sendo ótima para acesso remoto e para conveniência. Ela só não deveria ser o motivo de a luz da sala não acender.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu como montar uma casa inteligente que funciona sem internet, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso

Comentários (0)

Esse artigo ainda não possui comentários 😢. Seja o primeiro! 🚀🦅

Adicionar comentário