Mi stack de automatización 2026: Del caos a la autonomía en el homelab

Tener servicios autoalojados es el primer paso. El segundo es que hablen entre sí sin que tú actúes de intermediario. Hace un año mi homelab era una colección de contenedores Docker que funcionaban bien por separado pero no se enteraban unos de otros. Hoy es un ecosistema que reacciona solo a eventos, se autorepara en parte y me avisa solo cuando algo requiere atención humana.

El problema del homelab pasivo

El ciclo clásico del autoalojador: despliegas un servicio, lo configuras, funciona, y luego... lo olvidas hasta que falla. O peor: lo usas manualmente cientos de veces al día sin plantearte si podría hacerse solo.

Típico ejemplo: recibes una notificación de Home Assistant de que hay movimiento en la entrada. Tú abres la app, miras la cámara, decides que es el repartidor, y le abres. ¿Por qué no lo hace el sistema?

Otro: tu instancia de Ollama sirve modelos localmente, pero cuando quieres que resuma un PDF, copias el texto, pegas en un chat, esperas respuesta, y copias de vuelta. ¿Por qué no hay un pipeline automático?

Los cinco pilares de mi stack

Cada uno funciona solo. Juntos, forman algo que se parece mucho a un asistente real.

Arquitectura: cómo se conectan

El patrón es event-driven con n8n como cerebro central:

1. Un evento ocurre (sensor de puerta, webhook de GitHub, hora programada, llegada de un email).
2. n8n recibe el trigger y evalúa reglas (¿es de noche? ¿estoy en casa? ¿es urgente?).
3. Según la lógica, ejecuta acciones: encender luces, consultar Ollama para clasificar contenido, enviar mensaje a Mattermost, crear tarea en calendario.
4. MCP entra cuando la acción requiere inteligencia: el LLM decide qué hacer basándose en datos que obtiene a través de servidores MCP.

Flujos reales que funcionan ahora mismo

1. Clasificación automática de notificaciones

Home Assistant genera decenas de alertas al día. n8n las recoge en un nodo webhook, les pide a Ollama (vía MCP) que clasifique cada una como 'urgente', 'informativa' o 'ruido'. Las urgentes llegan a Mattermost con mención. Las informativas van a un canal silencioso. El ruido se descarta.

2. Resumen diario del homelab

Cada mañana a las 8:00, n8n consulta: estado de contenedores Docker, uso de CPU/RAM, backups completados, y logs de errores de las últimas 24 horas. Resume todo con Ollama y envía un mensaje a Mattermost. Si hay algo anómalo, añade un emoji de alerta.

3. Respuesta inteligente a visitas

Cámara de entrada detecta movimiento. n8n recibe el evento, comprueba si estoy en casa (por router/presencia). Si no, toma una captura, se la envía a Ollama con el prompt '¿Hay una persona? ¿Parece un repartidor o alguien sospechoso?'. Según la respuesta: si es repartidor, enciende luz del porche y envía mensaje. Si es sospechoso, graba video y alerta con prioridad alta.

4. Gestión de documentos entrantes

Recibo facturas por email. n8n las detecta, extrae el PDF, se lo pasa a un modelo local para extraer datos clave (proveedor, importe, fecha, concepto), y genera una entrada en una base de datos SQLite. Si el importe supera un umbral, notifica para revisión manual.

Por qué n8n y no scripts Python

Podría hacer todo esto con Python y cron. He estado ahí. Los scripts crecen, dependen de librerías específicas, fallan silenciosamente, y nadie más que tú puede mantenerlos. n8n aporta:

• **Visual**: ver el flujo ayuda a depurar y a explicárselo a otra persona (o a ti del futuro).
• **Manejo de errores integrado**: reintentos, bifurcaciones si falla, alertas automáticas.
• **Conectores nativos**: cientos de servicios con autenticación y API ya resuelta.
• **Webhook testing**: puedes simular triggers sin esperar a que ocurran de verdad.
• **Ejecución en Docker**: un contenedor, sin gestionar entornos Python.

La única excepción: cuando la lógica es muy compleja o requiere procesamiento pesado, sigo usando scripts que n8n ejecuta como pasos de shell. Lo mejor de ambos mundos.

El rol de MCP: el pegamento que faltaba

Hasta hace poco, conectar Ollama con el resto del sistema era frágil. Prompts ad-hoc, parsing de respuestas, errores difíciles de depurar. MCP (Model Context Protocol) estandariza esto: los LLMs descubren herramientas disponibles, deciden cuáles usar, y el protocolo se encarga de la comunicación.

En mi setup, MCP permite que Ollama:

• Consulte archivos de configuración antes de responder.
• Ejecute búsquedas web cuando necesite información actualizada.
• Interactúe con Home Assistant para leer sensores o ejecutar acciones.

Todo a través de servidores MCP independientes, aislados, y con permisos explícitos. El modelo nunca tiene acceso directo a nada; solo puede pedir al servidor que haga cosas que el servidor permite.

Cuándo no automatizar

No todo merece un flujo. Hay situaciones donde la automatización añade fragilidad:

• **Decisiones con alto coste de error**: si equivocarse tiene consecuencias graves (seguridad, finanzas), mejor notificación + confirmación humana.
• **Sistemas inestables**: si un servicio falla más que tu paciencia, automatizar sobre él genera cascadas de errores. Arregla la base primero.
• **Procesos que cambian constantemente**: si las reglas cambian semanalmente, mantener el flujo cuesta más que hacerlo manual.

La regla que uso: si hago algo más de tres veces por semana y tiene reglas claras, automatiza. Si es impredecible o crítico, notifica y deja que un humano decida.

El resultado

Mi homelab ahora se siente menos como una colección de servicios y más como un sistema. No es magia: es orquestación, buena arquitectura de eventos, y saber dónde poner el límite entre lo automático y lo manual.

El siguiente paso está en marcha: integrar un modelo de visión local para que el flujo de cámara no necesite descripción textual, sino que directamente interprete lo que ve. Pero eso es para otro post.

*¿Tienes un flujo de automatización interesante? Cuéntalo en los comentarios o en el canal #proyectos.*