OpenClaw roda no Wiren Board: como um agente de IA controla o controlador e escreve scripts

O OpenClaw costuma ser usado como agente pessoal de IA em um computador comum, mas a Wiren Board decidiu ir além e instalou o agente direto no controlador. O experimento mostrou que ele consegue fazer mais do que responder no Telegram: também trabalha com hardware real, lê configs, escaneia o barramento Modbus, escreve scripts e corrige os próprios erros.

Como tudo foi instalado

Para o experimento, a equipe separou um Wiren Board 8 e optou por não instalar a versão mais recente do OpenClaw. O autor escolheu a versão 2026.2.22, já que os builds mais novos trouxeram bugs no Telegram e ficaram bem mais pesados. As dependências básicas são bem simples, `git` e `Node.js`, mas mesmo assim o sistema ocupa bastante espaço: cerca de 200 MB de dependências na partição do sistema e mais uns 700 MB para o aplicativo em si, principalmente por causa do `node_modules`. Tudo foi instalado no diretório home do `root`, na partição maior `/mnt/data/root`.

• Instalaram `git` e `nodejs`
• Prepararam uma pasta separada para o OpenClaw
• Desativaram a dependência desnecessária `node-llama-cpp` via `package.json`
• Instalaram `[email protected]` e conectaram a CLI com `npm link`
• Rodaram `gateway`, `doctor`, a verificação de modelos e os logs

Depois veio a parte menos agradável: as configs. O formato dos arquivos JSON mudou entre versões, então os comandos automáticos `onboard` e `configure` nem sempre geravam uma configuração correta para provedores de modelos personalizados. Também surgiu um comportamento estranho com as chaves: nos provedores padrão, elas eram lidas de `auth-profiles.json`, mas nos personalizados, inesperadamente, vinham de `models.json`. O autor diz abertamente que isso parece bug e duplica as chaves nos dois lugares. Além disso, foi instalado o `wireguard-tools` no controlador para contornar restrições regionais de alguns provedores de LLM.

O agente conhece o hardware

Com a configuração básica pronta, o OpenClaw foi conectado ao Telegram. Por padrão, o bot não pode executar utilitários, alterar o sistema nem fazer outras ações potencialmente perigosas. Por isso, as permissões ampliadas tiveram de ser ativadas manualmente e liberadas apenas para um usuário específico do Telegram. Em seguida, foi carregado no controlador o pacote `wb-openclaw-skills`, que reúne conhecimento sobre o hardware da Wiren Board, protocolos, registradores e utilitários comuns. A primeira instrução do agente foi a mais direta possível: ao lidar com equipamentos, sempre procurar e usar primeiro o `wb-*` Skill adequado.

O teste mostrou que esse contexto funciona de fato. O agente explicou com segurança a linha de medidores WB-MAP, depois escaneou o barramento RS-485 e encontrou os dispositivos conectados. A resposta curta foi:

«No momento, vejo na prática 3 dispositivos Modbus físicos».

Por trás disso havia ações reais no controlador: o bot identificou o sensor WB-MSW v4, o módulo de relés WB-MR6C e o medidor de energia WB-MAP6S. Em seguida, verificou o firmware do medidor, confirmou que a versão 2.12.0 é a mais atual e coletou leituras em tempo real de tensão, potência, temperatura, umidade e CO₂.

Onde o experimento ficou útil

O teste mais revelador partiu de uma tarefa prática: escrever um script `wb-rules` que envia uma notificação no Telegram quando uma das entradas do módulo MR6C é acionada. O bot criou o arquivo da regra, carregou-o e até avisou que estava tudo pronto. Na prática, porém, as mensagens não chegavam.

O agente então seguiu um ciclo normal de depuração: encontrou uma chamada `curl` pouco confiável, corrigiu a autorização, adicionou diagnósticos ao log, reiniciou o `wb-rules` e enviou uma mensagem de teste. O teste chegou, mas os eventos das entradas reais continuavam sem disparar, e isso também precisou ser investigado. A segunda causa era mais sutil: parte dos sinais não passava pelos `Input N` comuns, e sim pelos contadores de pulsos `Input N counter`. O agente adicionou um segundo fluxo de tratamento e, depois disso, as notificações passaram a chegar no Telegram.

O autor não parou por aí e deu ao OpenClaw uma tarefa ainda mais ambiciosa: projetar uma interface web de apartamento inteligente para o hardware já conectado. O bot sugeriu o que poderia ser automatizado, dividiu a interface em telas e acabou ajudando a montar uma página HTML+JavaScript que funciona via MQTT over WebSocket. Ela foi colocada em `/var/www/static/`, ganhou uma rota no `nginx` e foi aberta na rede local como um painel de controle separado.

O que isso significa

O experimento mostrou que o OpenClaw no Wiren Board já deixou de ser um chatbot de demonstração e virou o protótipo de um operador local, capaz de ler documentação, mexer no sistema e interagir com dispositivos físicos. O benefício é evidente: em vez de trabalhar manualmente com configs, registradores e utilitários, dá para definir tarefas em linguagem natural. Mas o custo de um erro também é muito maior, porque o agente ganha acesso não a um servidor abstrato, e sim a uma infraestrutura de engenharia real. O autor considera o OpenClaw um bom ponto de partida, embora pesado demais para esse cenário.