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:
- Telegram webhook limpio (evitar error 409)
- Telegram pairing aprobado
- Modelo: confirmar contexto ≥16k (evitar «Model context window too small»)
- Ollama: baseUrl correcto desde Docker, warm-up del modelo
- Timeouts:
timeoutSecondsampliado en CPU - 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
- Escribir al bot en DM → devuelve un código de pairing.
- 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=lany 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.
| Criterio | Ollama + Mistral (local) | API OpenAI (gpt-4o-mini) |
|---|---|---|
| Privacidad | 100 % local | Datos salen al proveedor |
| Recursos locales | 4+ GB RAM, CPU alta | Mínimos |
| Latencia | Minutos en CPU-only | Segundos |
| Coste | Gratis (electricidad) | Pay-per-token |
| Homelab modesto | Poco práctico para interacción conversacional frecuente | Recomendado |
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.
