OpenClaw en casa: un asistente de IA local conectado a Home Assistant, Frigate, Gmail, Patrick y Suno

Durante mucho tiempo busqué el caso de uso que diera un interés real a OpenClaw en mi día a día. Otro chatbot más no me ahorraba tiempo. En cambio, un asistente capaz de razonar con un modelo local, ejecutar tareas programadas, consultar Gmail, leer Patrick, comunicarse con Home Assistant, procesar eventos de Frigate e incluso preparar cada noche una canción para mi hija resulta mucho más interesante.

Este artículo presenta la arquitectura que utilizo y la que estoy desplegando progresivamente en mi homelab. El objetivo no es publicar una configuración que contenga mis direcciones IP, credenciales, tokens o nombres reales de entidades de Home Assistant. Prefiero mostrar una arquitectura reproducible, las decisiones que realmente han funcionado en mi caso, los límites encontrados y las fronteras de seguridad que he impuesto de forma deliberada.

01Por qué OpenClaw y no simplemente un chat de IA

Un modelo de lenguaje por sí solo sabe responder. OpenClaw añade a su alrededor lo que suele faltar para convertir una respuesta en una acción: un Gateway siempre activo, sesiones persistentes, un navegador controlable, tareas programadas, herramientas, skills, nodes móviles y conexiones con otros sistemas.

En mi caso, quería un único punto de entrada capaz de trabajar con varios universos:

• mis correos electrónicos y mi calendario;
• las tareas, proyectos y ausencias almacenados en Patrick;
• mi domótica Home Assistant;
• los eventos de Frigate y las cámaras locales;
• mi blog y mis temas de vigilancia;
• automatizaciones creativas como la canción diaria de Jeanne.

El verdadero interés no proviene del número de integraciones. Proviene de que el asistente puede conservar un contexto, seleccionar una herramienta, ejecutar una acción, observar el resultado y continuar la tarea.

Eso también hace que la seguridad sea más compleja. Un chatbot que se equivoca produce una mala respuesta. Un agente que se equivoca puede enviar un correo, modificar una tarea o activar un dispositivo. Por tanto, la arquitectura debe diseñarse alrededor de los permisos, las fronteras y la verificación, no solo alrededor del modelo más inteligente.

02Arquitectura general de mi homelab

Mi infraestructura está separada de forma deliberada en varios roles. El servidor de IA no sustituye a Home Assistant, al NAS ni a los Raspberry Pi. Cada componente conserva una responsabilidad clara.

• Servidor de IA con Ubuntu: Ollama, OpenClaw, modelos locales, almacenamiento de historiales y tratamientos agenticos.
• Dos RTX 3060 de 12 GB: 24 GB de VRAM acumulada para modelos cuantificados.
• 64 GB de DDR4 y Ryzen 5600X3D: memoria del sistema y CPU para servicios, desbordamientos y tareas fuera de la GPU.
• Coral USB TPU: aceleración dedicada a las detecciones utilizadas por Frigate.
• Home Assistant en una máquina separada: orquestación domótica, helpers, scripts, Google Cast y automatizaciones.
• Frigate: detección de objetos, reconocimiento facial y publicación de eventos MQTT.
• Synology y Raspberry Pi: almacenamiento, copias de seguridad y servicios complementarios.
• Nodes móviles: notificaciones, ubicación o acciones autorizadas según los dispositivos y sus permisos.

[Teléfono / Mac / WebChat]
             |
             v
      [OpenClaw Gateway]
        |      |      |
        |      |      +--> [Skills navegador / gog / himalaya]
        |      |
        |      +---------> [MCP Patrick / MCP Home Assistant]
        |
        +----------------> [Ollama en servidor GPU]
                              |
                    muse-glimmer / Ornith / visión

[Cámaras PoE] --> [Frigate] --> [MQTT] --> [Home Assistant]
                                           |
                                           +--> Google Cast cocina
                                           +--> notificaciones móviles

[OpenClaw + Suno Web] --> MP3 local --> webhook HA

Para el acceso remoto, prefiero una VPN como WireGuard a exponer directamente el Gateway, Home Assistant u Ollama a Internet.

03Instalación y supervisión del Gateway de OpenClaw

OpenClaw se articula alrededor de un Gateway. Es el plano de control encargado de las sesiones, el enrutamiento, los canales, las tareas programadas, los nodes y las llamadas a herramientas.

La instalación recomendada utiliza el asistente de onboarding:

npm install -g openclaw@latest

openclaw onboard --install-daemon

openclaw gateway status --require-rpc
openclaw channels status --probe
openclaw dashboard

El panel local suele exponerse en el puerto 18789 mediante loopback. No recomiendo sustituir este comportamiento por una escucha pública sin haber leído antes las opciones de autenticación y acceso remoto.

Los comandos que utilizo para las comprobaciones habituales son sencillos:

openclaw gateway status
openclaw gateway restart
openclaw logs --follow
openclaw doctor

En una instalación doméstica en producción, el Gateway debe estar supervisado. En Linux puede funcionar mediante un servicio systemd de usuario o del sistema. Lo importante es evitar dos supervisores competidores que intenten reiniciar el mismo proceso.

04Ollama: contexto de 128k y optimización de VRAM

Ollama funciona como servicio en el servidor GPU. Mi objetivo es conservar un contexto suficientemente grande para las tareas agenticas evitando que varios modelos y varias solicitudes paralelas compitan por los 24 GB de VRAM.

La lógica de mi override de systemd es la siguiente:

# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_CONTEXT_LENGTH=128000"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q4_0"
Environment="OLLAMA_KEEP_ALIVE=8h"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"

Después:

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl status ollama
ollama ps

¿Por qué estos parámetros?

• OLLAMA_CONTEXT_LENGTH=128000 proporciona al modelo un presupuesto importante para historiales, herramientas y tareas largas.
• OLLAMA_FLASH_ATTENTION=1 reduce la presión de memoria cuando el backend y el modelo lo admiten.
• OLLAMA_KV_CACHE_TYPE=q4_0 comprime fuertemente la caché de contexto. Es una elección agresiva para hacer caber un contexto amplio, con un posible compromiso de calidad.
• OLLAMA_KEEP_ALIVE=8h evita recargar el modelo principal en cada interacción.
• OLLAMA_MAX_LOADED_MODELS=1 impide que varios modelos grandes permanezcan simultáneamente en memoria.
• OLLAMA_NUM_PARALLEL=1 evita multiplicar el consumo de la KV cache con varias solicitudes paralelas.

Con mi configuración actual, ollama ps muestra el modelo principal cargado al 100 % en la GPU, con un contexto de 128k y un keep-alive de ocho horas. Es el resultado que buscaba: sin offload masivo hacia la CPU, porque el rendimiento de un agente cae rápidamente cuando pasa su tiempo moviendo datos entre la RAM y la VRAM.

Conectar OpenClaw con Ollama

OpenClaw utiliza la API nativa de Ollama. No hay que añadir /v1 a la URL, porque el modo compatible con OpenAI puede degradar la gestión de las llamadas a herramientas.

Ejemplo simplificado en ~/.openclaw/openclaw.json:

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://<SERVIDOR_OLLAMA_LAN>:11434",
        apiKey: "ollama-local",
        api: "ollama",
        timeoutSeconds: 300,
        contextWindow: 128000,
        models: [
          {
            id: "muse-glimmer:latest",
            name: "muse-glimmer:latest",
            input: ["text"],
            params: {
              num_ctx: 128000,
              keep_alive: "8h"
            }
          }
        ]
      }
    }
  },
  agents: {
    defaults: {
      model: {
        primary: "ollama/muse-glimmer:latest"
      }
    }
  }
}

El valor contextWindow informa a OpenClaw del presupuesto disponible. El valor num_ctx se transmite a Ollama. Prefiero mantenerlos coherentes para evitar que OpenClaw construya un contexto que el backend no pueda ejecutar realmente.

05Elegir los modelos según el uso

Ya no busco «el mejor modelo absoluto». Busco el mejor modelo que mi hardware pueda ejecutar correctamente para una tarea concreta.

Mi ollama list contiene más modelos, pero conservarlos en disco no significa cargarlos todos. El parámetro OLLAMA_MAX_LOADED_MODELS=1 obliga a realizar una elección clara y evita una fragmentación innecesaria de la VRAM.

También hay que mantener una realidad en mente: un modelo local cuantificado de 20 a 35 mil millones de parámetros puede ser muy útil, pero no ofrece la misma robustez que un gran modelo cloud frente a largas cadenas de herramientas, instrucciones ambiguas o contenidos susceptibles de contener inyecciones de prompt.

06Skills, MCP y separación de permisos

OpenClaw distingue varios conceptos que a menudo se mezclan:

• el modelo, que razona;
• la herramienta, que ejecuta una acción;
• el skill, que explica al modelo cuándo y cómo debe utilizar las herramientas;
• el servidor MCP, que expone funciones estructuradas procedentes de una aplicación externa;
• el Gateway, que orquesta el conjunto.

Un skill de OpenClaw es principalmente un conjunto de instrucciones Markdown, normalmente organizado alrededor de un archivo SKILL.md. Eso no significa que deba instalarse cualquier skill sin leerlo previamente.

openclaw skills search "suno"
openclaw skills verify @machinesbefree/suno-browser-songmaking
openclaw skills verify @machinesbefree/suno-browser-songmaking --card
openclaw skills install @machinesbefree/suno-browser-songmaking

Mis principales integraciones

• gog: acceso automatizable a Gmail, Calendar, Drive, Docs, Sheets y Contacts.
• Himalaya: gestión de correos mediante IMAP, SMTP, Gmail o Microsoft Graph según la cuenta.
• Home Assistant MCP: lectura del contexto domótico y ejecución de acciones autorizadas.
• Patrick MCP: lectura de tareas, proyectos y ausencias.
• Browser automation: interacción con servicios web que no disponen de una API adecuada.
• blogwatcher: vigilancia, análisis de fuentes y preparación de temas para el blog.

Separo tanto como puedo las integraciones de solo lectura de las capaces de escribir o activar una acción. Una herramienta que lee el calendario no necesita permiso para enviar un correo. Un workflow de Suno no necesita un token de administrador de Home Assistant.

07Gmail y Google Workspace con gog

Para Google Workspace utilizo gog, una CLI pensada para scripts y agentes. Expone comandos estables con salidas JSON o de texto sencillas de procesar.

Ejemplos:

gog gmail search 'newer_than:7d' --max 20
gog calendar events --today
gog drive ls --max 20 --json

La autenticación se basa en OAuth. Los permisos deben limitarse a los servicios necesarios y los tokens deben permanecer en el llavero o en el almacén de secretos previsto, nunca en un prompt, un repositorio Git o un archivo de log.

Un primer workflow analiza cada mañana los correos recibidos durante las últimas 24 horas:

1. buscar los nuevos mensajes;
2. eliminar el ruido evidente;
3. resumir los asuntos importantes;
4. extraer acciones y fechas límite;
5. relacionar las acciones con los proyectos existentes en Patrick;
6. producir un resumen persistente en memory/YYYY-MM-DD-email-summary.md;
7. enviar una notificación a un node móvil.

Empiezo en modo de solo lectura. La creación automática de tareas o el envío de respuestas solo deben activarse después de comprobar que la extracción es fiable y que el modelo no convierte cada frase en una urgencia.

08Patrick IA como fuente de contexto operativo

Patrick es mi asistente de gestión de equipo. Centraliza las tareas, los proyectos, las actas de reunión, las ausencias y parte del contexto operativo.

Ya he dedicado un artículo completo a su funcionamiento: Patrick IA: el asistente de gestión de equipo.

La integración MCP utilizada por OpenClaw expone, entre otras, herramientas de lectura:

patrick-read__get-person-open-tasks
patrick-read__get-project-operational-context
patrick-read__get-team-upcoming-time-off

El nombre de pila basta para consultar las tareas de una persona; el agente no necesita solicitar un UUID al usuario.

Esta integración permite a OpenClaw responder a solicitudes como:

• «¿Cuáles son las tareas abiertas de esta persona?»
• «¿Cuál es el contexto operativo del proyecto IFS?»
• «¿Quién estará ausente la próxima semana?»
• «¿Las acciones detectadas en mis correos ya existen en Patrick?»

La elección de una superficie de solo lectura es deliberada. El día que OpenClaw pueda crear o modificar tareas directamente, esas herramientas estarán separadas y sometidas a reglas más estrictas.

09Home Assistant: control conversacional y alcance expuesto

Home Assistant ofrece ahora un servidor MCP oficial expuesto en /api/mcp. Un cliente MCP puede acceder a las herramientas de la API Assist y al contexto de las entidades autorizadas.

En mi arquitectura, un puente MCP local puede escuchar en un puerto interno dedicado antes de reenviar las llamadas a Home Assistant. Este puerto no debe exponerse a Internet.

El punto esencial es el control de acceso:

• usuario dedicado de Home Assistant cuando sea posible;
• entidades expuestas explícitamente a Assist;
• ningún acceso a dominios innecesarios;
• ninguna cerradura, portal o acción sensible disponible sin una regla adicional;
• registro de las llamadas importantes.

De este modo se vuelven posibles comandos conversacionales como:

• «Apaga las luces del salón»;
• «¿Cuál es el estado de la bomba de calor?»;
• «Activa el modo noche»;
• «Dime las temperaturas de las habitaciones principales».

10Frigate: separar reconocimiento facial y visión generativa

Frigate realiza localmente la detección de objetos y el reconocimiento facial. Cuando se produce un reconocimiento, publica en MQTT un mensaje frigate/tracked_object_update que contiene, entre otros, los siguientes campos:

{
  "type": "face",
  "id": "...",
  "name": "Jeanne",
  "score": 0.95,
  "camera": "camera_cuisine",
  "timestamp": 178...
}

Frigate debe seguir siendo la fuente de verdad sobre la identidad de una persona. Un modelo de visión como Qwen VL puede describir una escena, la ropa, un paquete o el contexto. No debe utilizarse para improvisar la identidad de alguien a partir de una sola imagen.

Por tanto, separo dos pipelines:

• Reconocimiento de identidad: Frigate, base local de rostros, puntuación y cámara conocidas.
• Descripción semántica opcional: modelo de visión local para enriquecer una notificación, por ejemplo «persona con abrigo rojo y una bolsa».

Esta distinción evita un error frecuente: preguntar al LLM «¿Quién aparece en la imagen?» y tratar su respuesta como un hecho. El modelo generativo puede alucinar. Frigate, en cambio, produce un nombre, una puntuación y un identificador de cámara estructurados.

En mis automatizaciones sensibles siempre filtro:

• el tipo de evento;
• el verdadero nombre técnico devuelto por Frigate;
• la cámara exacta;
• una puntuación mínima configurable;
• las zonas relevantes, si procede.

11Gran caso de uso: la canción matinal de Jeanne

Probablemente sea la automatización más innecesariamente compleja y más divertida de mi instalación.

Cada noche, OpenClaw prepara una canción original para Jeanne. Por la mañana, la canción no se inicia a una hora fija. Home Assistant espera a que Frigate reconozca a Jeanne en la cocina, mediante una única cámara concreta, y después reproduce la canción en el Google Cast de esa misma habitación.

02:00
OpenClaw
   |
   +--> historial de las últimas 30 canciones
   +--> previsión meteorológica de la mañana
   +--> concepto + letra + estilo
   +--> navegador Suno autenticado
   +--> generación y selección
   +--> descarga del MP3
   +--> almacenamiento local + URL HTTP
   +--> POST al webhook de Home Assistant
                         |
                         v
                 canción preparada = sí

06:30 - 10:30
Cámara Frigate de la cocina
   |
   +--> type = face
   +--> name = Jeanne
   +--> score >= 0,80
                         |
                         v
                 Home Assistant
                         |
                         +--> una única reproducción al día
                         +--> Google Cast de la cocina

11.1 Una frontera de seguridad muy clara

OpenClaw gestiona únicamente:

• la creación de la canción;
• la interacción con Suno;
• la descarga;
• la exposición local del MP3;
• la notificación mediante webhook.

Home Assistant gestiona únicamente:

• la espera hasta la mañana;
• los eventos MQTT de Frigate;
• el reconocimiento de Jeanne;
• la cámara autorizada;
• la franja horaria;
• la prevención de repeticiones;
• el volumen y el Google Cast de la cocina.

OpenClaw nunca controla directamente el Google Home. No recibe ningún token de administrador de Home Assistant y no intenta reconocer a Jeanne por sí mismo.

11.2 Instalar y comprobar el skill Suno

No utilizo ninguna API Suno de terceros. El skill @machinesbefree/suno-browser-songmaking automatiza el sitio web mediante una sesión de navegador persistente.

openclaw skills verify @machinesbefree/suno-browser-songmaking
openclaw skills install @machinesbefree/suno-browser-songmaking

El skill es, en esencia, un runbook de navegación: recopilar un brief, escribir la letra, pasar al modo personalizado, introducir la letra y las etiquetas de estilo, iniciar la generación y revisar los resultados.

Utilizo un perfil de navegador dedicado a Suno. Cuando es necesario volver a autenticarse, lo hago manualmente dentro de ese perfil. El agente nunca recibe la contraseña en texto plano.

11.3 Programar el job a las 02:00

OpenClaw dispone de su propio planificador Cron. Las tareas se almacenan en el Gateway y sobreviven a sus reinicios.

Ejemplo de job aislado:

openclaw cron create "0 2 * * *" \
  --name "Jeanne - canción matinal" \
  --session isolated \
  --tz "Europe/Paris" \
  --exact \
  --model "ollama/muse-glimmer:latest" \
  --tools "browser,exec,read,write" \
  --timeout-seconds 3600 \
  --message "Ejecuta el workflow documentado de creación de la canción diaria de Jeanne. Una sola generación real, historial obligatorio, almacenamiento local, comprobación HTTP y después notificación por webhook."

La tarea está aislada para no contaminar la conversación principal. El timeout es deliberadamente amplio, porque la generación y la descarga mediante un servicio web pueden tardar.

11.4 Producir canciones realmente diferentes

Lo más difícil no es generar una canción. Es evitar generar todos los días la misma canción cambiando únicamente tres palabras.

Cada ejecución consulta un historial persistente, por ejemplo:

{
  "date": "2026-08-20",
  "title": "Jeanne y la araña que bailaba disco",
  "story": "Una araña enseña a Jeanne un baile mágico",
  "characters": ["Jeanne", "Araña Disco"],
  "style": "disco funk infantil",
  "weather": "soleado",
  "filename": "2026-08-20-jeanne-arana-disco.mp3",
  "media_url": "http://<SERVIDOR_OPENCLAW>:8088/music/jeanne/2026/08/..."
}

Antes de crear un nuevo concepto, el agente revisa al menos las 30 últimas canciones y presta especial atención a los siete últimos días.

Evita:

• el mismo tema dos días seguidos;
• el mismo estilo musical;
• el mismo personaje central;
• la misma estructura de historia;
• estribillos y formulaciones repetitivas.

Aproximadamente una canción de cada cinco debe utilizar un universo completamente original. A Jeanne le gustan las brujas, las arañas, los ositos, las historias mágicas, las aventuras y algunos universos conocidos, pero los prompts nunca piden copiar una canción, una letra, una melodía o el estilo exacto de un artista.

La previsión meteorológica de la mañana se utiliza únicamente como inspiración:

• lluvia: botas mágicas, charcos y ranas;
• sol: jardín, tesoro y picnic;
• viento: cometa o viaje entre las nubes;
• nieve: osito y castillo de nieve;
• niebla: bosque mágico y divertido.

Si la previsión no está disponible, la canción debe generarse igualmente. Una fuente de inspiración nunca debe convertirse en un punto de fallo obligatorio.

11.5 Letra y descripción musical

La letra se escribe en francés para una niña de cinco años, con una duración objetivo de dos a tres minutos.

Estructura preferida:

Introducción corta
Estrofa 1
Estribillo
Estrofa 2
Estribillo
Puente
Estribillo final
Conclusión

El tono se mantiene alegre, divertido, tranquilizador y mágico. Pueden aparecer brujas, arañas o monstruos, pero siempre son amables o graciosos.

Los estilos varían mucho: pop infantil, pop-rock, disco, funk, synthpop, swing, jazz alegre, folk, música de cuento, aventura orquestal o electrónica ligera.

11.6 Almacenar y exponer el MP3

El archivo no se limita a descargarse. Debe servirse por HTTP para que el Chromecast pueda recuperarlo directamente.

Organización:

/srv/openclaw/music/
└── jeanne/
    └── 2026/
        └── 08/
            └── 2026-08-20-jeanne-arana-disco.mp3

Ejemplo de servidor HTTP mínimo con Nginx en Docker:

services:
  jeanne-music:
    image: nginx:alpine
    restart: unless-stopped
    ports:
      - "8088:80"
    volumes:
      - /srv/openclaw/music:/usr/share/nginx/html/music:ro

La URL pasa a ser:

http://<IP_OPENCLAW_LAN>:8088/music/jeanne/2026/08/archivo.mp3

El puerto debe permanecer accesible únicamente desde la LAN. El volumen se monta en solo lectura y no se expone ningún otro directorio del servidor.

Antes de llamar a Home Assistant, OpenClaw comprueba que la URL responde correctamente y que el tipo MIME permite reproducir el MP3.

11.7 Notificar a Home Assistant sin darle un token

El webhook no desencadena una reproducción inmediata. Solo anuncia que la canción del día está preparada.

{
  "date": "2026-08-20",
  "title": "Jeanne y la araña que bailaba disco",
  "media_url": "http://<IP_OPENCLAW>:8088/music/jeanne/2026/08/archivo.mp3",
  "filename": "archivo.mp3",
  "style": "disco funk infantil",
  "story": "Jeanne conoce a una araña a la que le encanta bailar",
  "weather": "soleado"
}

Prueba:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "date":"2026-08-20",
    "title":"Prueba Jeanne",
    "media_url":"http://<IP_OPENCLAW>:8088/music/jeanne/test.mp3"
  }' \
  "http://<IP_HOME_ASSISTANT>:8123/api/webhook/<SECRETO_ALEATORIO>"

En Home Assistant:

trigger:
  - platform: webhook
    webhook_id: !secret suno_daily_webhook_id
    allowed_methods:
      - POST
    local_only: true

El identificador del webhook debe ser largo, aleatorio y tratarse como una contraseña. Nunca debe aparecer en el artículo, en un repositorio público ni en una captura de pantalla.

11.8 La máquina de estados de Home Assistant

Home Assistant conserva como mínimo los siguientes estados:

• input_boolean.suno_daily_enabled;
• input_boolean.suno_daily_ready;
• input_boolean.suno_daily_played;
• input_text.suno_daily_title;
• input_text.suno_daily_media_url;
• input_text.suno_daily_date;
• input_number.suno_daily_volume;
• input_number.suno_daily_face_score;
• input_datetime.suno_daily_start_time;
• input_datetime.suno_daily_end_time.

Valores iniciales:

• volumen: 35 %;
• puntuación facial mínima: 0,80;
• inicio: 06:30;
• fin: 10:30;
• una sola reproducción diaria.

El webhook comprueba que la fecha recibida corresponda al día actual, almacena el título y la URL, activa ready y restablece played a falso.

Una automatización a las 00:05 reinicia los estados. Si la generación falla durante la noche, la canción del día anterior no puede volver a reproducirse por error.

11.9 Desencadenar únicamente con Jeanne, en la cocina

El trigger MQTT escucha:

frigate/tracked_object_update

La condición lógica es estrictamente equivalente a:

type == "face"
AND name == VALOR_REAL_FRIGATE_PARA_JEANNE
AND camera == VALOR_REAL_CAMARA_9_COCINA
AND score >= umbral_configurable
AND hora entre 06:30 y 10:30
AND canción preparada
AND fecha canción == hoy
AND canción no reproducida
AND Google Cast cocina disponible

Nunca hay que inventar el nombre técnico de la cámara, de Jeanne o del media_player. Deben leerse en Frigate y Home Assistant durante la instalación.

Los siguientes casos no desencadenan nada:

• Louis reconocido;
• otra persona reconocida;
• una simple detección person;
• Jeanne reconocida en otra cámara;
• una puntuación insuficiente;
• un evento fuera de la franja horaria;
• una canción antigua o ya reproducida.

11.10 Prevención de repeticiones y race conditions

Frigate puede publicar varios reconocimientos en pocos segundos. Una simple condición played == false no siempre basta si dos ejecuciones empiezan simultáneamente.

La estrategia robusta combina:

• una automatización Home Assistant con mode: single;
• un bloqueo temporal in_progress opcional pero recomendado;
• un script de reproducción separado;
• una espera breve hasta que el reproductor pase al estado playing;
• cambiar played a verdadero únicamente después de enviar la orden de reproducción.

El script:

1. selecciona el Google Cast de la cocina;
2. ajusta el volumen;
3. llama a media_player.play_media;
4. utiliza la URL recibida;
5. indica el título cuando el reproductor lo admite.

11.11 Gestión de errores

• Suno no disponible: reintentar de forma razonable durante la noche.
• Sesión caducada: detenerse correctamente y solicitar una nueva autenticación manual.
• Generación fallida: reintentar sin consumir una cantidad incontrolada de créditos.
• Descarga fallida: reanudar la descarga sin volver a crear la canción.
• Servidor HTTP inaccesible: no notificar a Home Assistant hasta que el archivo pueda leerse.
• Webhook inaccesible: conservar el MP3 y reintentar únicamente la notificación.
• Fallo nocturno: no sustituir nunca de forma silenciosa la canción de hoy por la de ayer.

12OpenClaw como asistente de vigilancia y blog

OpenClaw también puede convertirse en un punto de entrada para mi vigilancia tecnológica: seguir las novedades de OpenClaw, Ollama, Home Assistant, Frigate, IFS o PC SOFT, recuperar temas ya tratados y preparar una lista de ideas.

No quiero que publique automáticamente. Puede:

• recopilar fuentes;
• detectar cambios;
• relacionar un tema con mis artículos anteriores;
• preparar una estructura;
• señalar afirmaciones que deben verificarse;
• proponer un borrador.

La publicación sigue siendo una acción humana, porque un error factual o una mala interpretación no deben convertirse automáticamente en un artículo público.

13Seguridad, privacidad y reducción del radio de impacto

El principal riesgo de un agente no es que sea «inteligente». Es que disponga de demasiados permisos.

Mis reglas principales son:

• Gateway no expuesto directamente a Internet;
• acceso remoto mediante WireGuard u otra VPN;
• Ollama limitado a la LAN y filtrado;
• skills de terceros verificados y leídos antes de su instalación;
• perfiles de navegador dedicados a los servicios automatizados;
• OAuth y tokens almacenados en un llavero o gestor de secretos;
• agentes y workspaces separados para los usos profesionales y familiares;
• herramientas de escritura separadas de las herramientas de lectura;
• Home Assistant limitado a las entidades expuestas;
• webhook Suno local, únicamente POST y sin token de HA;
• logs locales con un periodo de conservación controlado;
• ningún secreto en Git, los prompts o los artículos.

14Límites reales del agente local

Un contexto de 128k cuesta caro

Un contexto amplio mejora las tareas largas, pero aumenta considerablemente el consumo de la KV cache. La cuantificación q4_0 ayuda a hacerlo caber, a cambio de un compromiso.

Un modelo local no sustituye siempre a un gran modelo cloud

Para una conversación sencilla, muse-glimmer produce muy buenos resultados en mi instalación. Para agentes complejos con muchas herramientas, un modelo local puede entrar en bucle, olvidar una restricción o interpretar mal un resultado.

Los nodes móviles consumen batería

Las funciones de ubicación, movimiento, captura o notificación dependen de los permisos del sistema y pueden verse limitadas cuando el teléfono optimiza agresivamente la aplicación en segundo plano.

OAuth y las sesiones web caducan

Gmail, Google Workspace y Suno pueden solicitar una nueva autenticación. Una buena automatización debe detenerse claramente en lugar de intentar sortear una página de inicio de sesión.

La infraestructura local requiere operaciones

Hay que supervisar los servicios, las copias de seguridad, los discos, la VRAM, las actualizaciones, los certificados y los logs. La nube oculta una parte de este trabajo; la infraestructura local te lo devuelve.

15Lo que esta arquitectura cambia realmente

OpenClaw empieza a tener valor cuando dejo de considerarlo una interfaz de chat y lo trato como un orquestador.

Ollama proporciona el razonamiento local. OpenClaw aporta las sesiones, las tareas programadas, las herramientas y el navegador. Home Assistant conserva las decisiones domóticas. Frigate sigue siendo responsable del reconocimiento. Patrick proporciona el contexto de negocio. Suno genera la música dentro de una frontera claramente identificada.

Cada componente tiene una responsabilidad y, sobre todo, cada integración tiene un nivel de confianza diferente.

El resultado no es un asistente omnipotente con un token de administrador para toda la casa. Es una colección de workflows limitados, observables y sustituibles.

Y probablemente esa sea la lección más importante: para que un agente sea realmente útil, no hay que empezar dándole todos los accesos. Hay que empezar con una necesidad precisa, una frontera clara, una prueba reproducible y una forma sencilla de detenerlo.