Tem uma fechadura aqui em casa — uma Elsys ESF-DE4000B — que nenhuma integração do Home Assistant suportava. A integração oficial da Tuya não pegava, a Tuya-Local também não. Sair caçando alguém pra resolver isso ia ser provavelmente um projeto de fim de semana inteiro, e como tudo funcionava OK pelo app proprietário, eu vinha empurrando esse “trabalho” há anos.
Resolvi em 30 minutos com o Opus 4.7. A primeira versão funcionando saiu em 5.
Hoje a fechadura tem sensores, desbloqueio remoto e eventos detalhados no HA: quando foi destrancada, por quem, por qual método (senha, app, biometria), quando o modo campainha foi acionado. O custom_component que o Claude escreveu faz polling na Tuya IoT Cloud e expõe entidades do HA. Já até abri uma issue pra contribuir com isso a uma biblioteca existente ao invés de criar uma nova.
O que antes era “impossível” — não tecnicamente, mas que ninguém ia parar pra fazer — ficou muito mais fácil. E desbloqueou um monte de automação que antes eu nem cogitava.
O que destravou: ha-mcp
Eu uso o Home Assistant aqui em casa há alguns anos como central de tudo que é IoT. Já tinha o MCP oficial do projeto instalado há um tempo, que faz o básico — ler estado e mandar comandos, basicamente o que um assistente de voz tipo Alexa ou Google já fazem.
O problema do MCP oficial é que ele só fala “lê e escreve estado” (eu acho, ou pelo menos da última vez que testei). Pra criar automações ou ajustar o setup, eu acabava copiando trechos na mão pelo painel do HA ou via SSH — perdendo todo o contexto que o Claude tinha acabado de construir.
Daí instalei o ha-mcp, um MCP server não oficial que cobre praticamente toda a API do HA. Dá pra criar automações, scripts, scenes, blueprints, dashboards, mexer em devices, ler logs, avaliar template, debugar — quase tudo que dá pra fazer pelo painel ou por arquivo de configuração. Dá até pra instalar direto no HAOS pra acesso remoto, então funciona até pelo Claude.ai ou ChatGPT.
A configuração que mais gostei
Mas o que destravou de verdade não foi o ha-mcp sozinho — foi criar uma pasta local de projeto pro Claude Code apontar.
A pasta tem:
- Um
CLAUDE.mdcom contexto do meu setup (contexto da minha casa, infra do HA, integrações chave) - Os
custom_componentsque ele já escreveu (incluindo o da fechadura) - Uma pasta
.claude/memory/que o CC salva sua auto-memory
A memória é o pulo do gato. A cada sessão, o Claude registra coisas que ele percebe que vão ser úteis no futuro — restrições físicas do meu setup, quirks de hardware que parecem bug mas não são, gaps conhecidos das ferramentas, jeitos preferidos de fazer cada coisa.
Cada conversa nova já começa com ele sabendo disso tudo. O problema é que ainda não sei bem como deixar isso disponível pro Claude.ai pra eu ter esse mesmo contexto também através do app.
O que isso já me deu
Em algumas semanas usando esse setup, já consegui:
- Corrigir várias inconsistências da instalação que existiam há anos
- Criar automações por linguagem natural (ex: “me manda uma notificação se a porta estiver aberta por mais de 2 minutos”)
- Auditar a config inteira atrás de configurações ineficientes ou erradas
- Subir um stack de armazenamento de longo prazo (recorder de 60 dias + InfluxDB + Grafana)
- E, claro, a integração da fechadura
Um monte de caminho que antes eu não ia explorar simplesmente porque o custo de começar era alto demais.