Guilgo Blog

Notas de mi quehacer diario con las técnologias.

Los que me conocen saben que soy un poco freak/nerd, y con mis posts queda bastante claro cuál es mi tendencia. Llevo tiempo automatizando tareas de casa y red con un script propio (cachifo.py) y flujos en n8n. Lo interesante de OpenClaw es su enfoque proactivo: no depender solo de cronjobs ni de interacción manual. La idea es integrarlo como parte del sistema existente.

OpenClaw es un asistente conversacional que puedes desplegar en tu propio homelab para usar LLMs locales (Ollama) o APIs como OpenAI vía Telegram. La instalación guiada suele ir bien en teoría, pero en un despliegue real con Docker, Telegram y Ollama en CPU aparecen varios errores que frustran y dan la sensación de «instalación rota». Este post documenta los problemas encontrados durante una instalación real y cómo resolverlos.

Complementa la guía oficial de OpenClaw y referencias como la Guía Completa 2026 de el diario IA, bajando a tierra los «gotchas» de despliegues homelab con Docker, Telegram y Ollama en CPU.


Checklist de instalación OpenClaw en homelab CPU-only

Antes de entrar en detalles, este orden evita el 80 % de fallos del primer día:

  1. Telegram webhook limpio (evitar error 409)
  2. Telegram pairing aprobado
  3. Modelo: confirmar contexto ≥16k (evitar «Model context window too small»)
  4. Ollama: baseUrl correcto desde Docker, warm-up del modelo
  5. Timeouts: timeoutSeconds ampliado en CPU
  6. Cloudflare (si aplica): WebSockets, endpoint correcto, bind=lan

Telegram: conflicto 409 (webhook vs getUpdates/polling)

Síntoma

En logs aparece algo como:

  • getUpdates conflict (409): terminated by setWebhook request

Y el bot deja de responder o se vuelve errático.

Causa

El mismo bot/token está siendo usado por webhook (p. ej. n8n) y por polling (OpenClaw con getUpdates) a la vez. Telegram no permite ambos.

Solución

Antes de depurar OpenClaw, revisa el webhook:

curl "https://api.telegram.org/bot<BOT_TOKEN>/getWebhookInfo"
curl "https://api.telegram.org/bot<BOT_TOKEN>/deleteWebhook?drop_pending_updates=true"

Si usas n8n u otro sistema con webhook en ese bot, no puedes usarlo a la vez con OpenClaw en modo polling.


Telegram: “You are not authorized” por dmPolicy pairing

Síntoma

/status u otros comandos devuelven: «You are not authorized to use this command.»

Causa

Por defecto, el canal de Telegram tiene dmPolicy: "pairing". Hasta que el propietario aprueba el pairing, el bot rechaza comandos.

Solución

  1. Escribir al bot en DM → devuelve un código de pairing.
  2. Aprobar:
openclaw pairing approve telegram <CODE>
# o con Docker:
docker compose run --rm openclaw-cli pairing approve telegram <CODE>

Para pruebas iniciales se puede cambiar a dmPolicy: "open" (útil solo para pruebas, no recomendado en despliegues expuestos a Internet):

jq '.channels.telegram.dmPolicy = "open" | .channels.telegram.allowFrom = ["*"]' ~/.openclaw/openclaw.json > tmp && mv tmp ~/.openclaw/openclaw.json

Docker + Ollama: “localhost” no es el host (baseUrl y red)

Síntoma

OpenClaw no detecta Ollama, timeouts o fetch failed si se apunta a 127.0.0.1:11434 desde el contenedor.

Causa

Dentro de Docker, 127.0.0.1 es el propio contenedor, no el host.

Solución

Ollama en otro contenedor (recomendado): misma red docker-compose y baseUrl: "http://ollama:11434".

Ollama en el host: usar IP del host o host-gateway. En Docker Desktop (Mac/Windows) funciona host.docker.internal:11434; en Linux nativo no existe por defecto — si lo necesitas, añade en el servicio del contenedor:

extra_hosts:
  - "host.docker.internal:host-gateway"

Y usa baseUrl: "http://host.docker.internal:11434". Nunca uses 127.0.0.1 desde el contenedor.


Modelo: el agente requiere ≥16k para herramientas y memoria conversacional

Síntoma

  • Model context window too small (8192 tokens). Minimum is 16000.

Causa

Modelos habituales (p. ej. llama3.2) con 8192 tokens no cumplen el mínimo de OpenClaw (16k). El onboarding puede crear el modelo con valores incorrectos.

Solución

Usar modelos con ≥16k de contexto; ideal 32k en CPU para ir seguro. Ejemplo válido: mistral (32768).

Verificar:

ollama show mistral | grep -i "context length"

Si el config tiene contextWindow o maxTokens bajos, corregir:

jq '.models.providers.ollama.models[0].contextWindow = 32768 | .models.providers.ollama.models[0].maxTokens = 8192' ~/.openclaw/openclaw.json > tmp && mv tmp ~/.openclaw/openclaw.json
jq '.agents.defaults.contextTokens = 16384' ~/.openclaw/openclaw.json > tmp && mv tmp ~/.openclaw/openclaw.json

Timeouts: el primer reply en CPU puede tardar (warm-up y timeoutSeconds)

Síntoma

«Request timed out before a response was generated.»

Causa

En CPU, la primera carga del modelo puede tardar varios minutos y la request se corta. La primera ejecución puede incluir compilación/optimización del modelo en Ollama además de la carga en memoria. El timeout por defecto (600 s) es insuficiente.

Solución

  • Subir timeout en el config:
jq '.agents.defaults.timeoutSeconds = 1800' ~/.openclaw/openclaw.json > tmp && mv tmp ~/.openclaw/openclaw.json
  • Hacer warm-up del modelo:
ollama run mistral "hola"

Otros problemas frecuentes en despliegue homelab

CRLF en scripts (Linux)

Síntoma: install.sh: line 4: set: -: invalid option / $'\r': command not found

Solución:

sed -i 's/\r$//' install.sh preflight.sh add-telegram.sh

Missing config / Gateway no arranca

Síntoma: Missing config. Run openclaw setup or set gateway.mode=local

Causa: Onboarding no ejecutado. Solución: ejecutar onboarding no interactivo con Ollama como custom provider:

docker compose run --rm openclaw-cli onboard --non-interactive --accept-risk --no-install-daemon \
  --auth-choice custom-api-key \
  --custom-base-url "http://ollama:11434/v1" \
  --custom-model-id "mistral" \
  --custom-api-key "ollama-local" \
  --custom-provider-id "ollama" \
  --custom-compatibility openai \
  --gateway-port 18789 --gateway-bind lan --skip-skills

Cloudflare / exposición: checklist WebSockets

Si expones OpenClaw con Cloudflare Tunnel o proxy inverso:

  • Habilitar WebSockets
  • Apuntar al puerto correcto (p. ej. http://<IP>:18789)
  • Confirmar bind=lan y autenticación token en la UI
  • Si el proxy requiere autenticación, revisa la configuración de token o API key del gateway en la documentación de OpenClaw

Ollama vs API de OpenAI en homelab modesto

En un homelab real con 12 GB RAM y CPU-only, Mistral 7B con Ollama puede saturar CPU (~350 %) y RAM (~4.7 GB). El sistema entra en swap intensivo y las respuestas llegan con timeout aunque timeoutSeconds esté en 1800.

Alternativa práctica: usar la API de OpenAI (p. ej. gpt-4o-mini). Latencia inmediata, sin presión en recursos locales. Requiere API key y pago por uso, pero en homelabs modestos suele ser la opción viable para un bot que responda en segundos.

CriterioOllama + Mistral (local)API OpenAI (gpt-4o-mini)
Privacidad100 % localDatos salen al proveedor
Recursos locales4+ GB RAM, CPU altaMínimos
LatenciaMinutos en CPU-onlySegundos
CosteGratis (electricidad)Pay-per-token
Homelab modestoPoco práctico para interacción conversacional frecuenteRecomendado

Para integrar Telegram con IA en proyectos de monitorización (alertas, bots), puedes combinar OpenClaw con Wazuh y Telegram o con stacks en Docker según tu caso de uso.


Verificación rápida de salud (Ollama + OpenClaw)

ollama list
docker compose run --rm openclaw-cli models list

Filtro de logs útil:

docker compose logs -f openclaw-gateway 2>&1 | grep -E "(error|fail|timeout|telegram|getUpdates|ollama)"

Conclusión

Con estos ajustes, OpenClaw pasa de parecer inestable a comportarse de forma predecible en entornos domésticos. La mayoría de problemas iniciales no son fallos del software sino supuestos implícitos sobre red, contexto del modelo y latencia de inferencia.