La trampa simétrica es montarse un modelo local creyendo que sustituye al frontier. No sustituye. Para razonamiento profundo, contexto largo, código nuevo desde cero, el frontier sigue ganando por mucho. Quien pretende reemplazarlo entero se encontrará rehaciendo a mano lo que el frontier hubiera resuelto en una iteración.

Entre los dos extremos hay un patrón que sí funciona: que el modelo frontier dirija y un modelo local ejecute la rutina. Lo llamamos Capataz y Obrero, y va a ser la primera carga real del servidor Aveiro del que hablamos en el post anterior.

El patrón

La división es asimétrica por diseño.

Exhibit 1 — Capataz piensa, Obrero ejecuta. La línea entre ambos es MCP.

El Capataz (Claude Code en el portátil) hace lo que requiere razonamiento amplio: leer el repo, entender qué se pide, descomponer en pasos concretos, decidir cuáles delega y cuáles ejecuta él mismo, revisar el resultado y cerrar el bucle. Es caro por minuto, pero su tiempo se compensa con creces en las decisiones que toma.

El Obrero (un LLM local — en nuestro caso, Qwen 2.5 Coder 14B cuantizado a 4 bits, corriendo en Ollama sobre el servidor de Aveiro) recibe instrucciones acotadas y devuelve resultados acotados. No decide qué hacer; hace lo que se le pide. Cuesta cero por petición, está siempre disponible, y su latencia es predecible — del orden de un par de segundos por respuesta corta.

El conector es MCP (Model Context Protocol). MCP estandariza cómo un cliente como Claude Code llama a herramientas externas. Un servidor MCP que envuelve Ollama aparece ante Claude Code como un conjunto de funciones invocables: clasifica esto, resume aquello, busca el patrón en este texto. Claude decide cuándo llamarlas, espera el resultado y sigue su trabajo.

Qué tarea va a quién

La regla de reparto no es “tareas fáciles al obrero”. Es más fina: cualquier tarea con criterio de éxito objetivo y formato de salida estable es candidata a ir al obrero. Cualquier tarea que requiere juicio sobre el qué, no sobre el cómo, se queda con el capataz.

Exhibit 2 — La regla de reparto. La columna del medio es donde está el dinero.

Algunos ejemplos concretos del flujo real de Proportione:

• Clasificar tickets entrantes por área y departamento. Taxonomía cerrada, salida estructurada, repetitivo. Al obrero.
• Extraer entidades (nombre, empresa, asunto) de un correo libre. Formato estable, criterio objetivo. Al obrero.
• Decidir si un PR introduce regresión arquitectónica. Requiere entender el repo, el contexto del cambio, la intención del autor. Al capataz.
• Generar 30 variantes de copy para un A/B test con tono y restricciones dadas. Al obrero, con plantilla del capataz.
• Diseñar el módulo nuevo de SLA. Al capataz, sin discusión.

El patrón gana cuando una sesión real combina las dos cosas. El capataz lee la conversación, identifica que hay 50 tickets que clasificar, los manda en lote al obrero, recibe el resultado y sigue con el problema arquitectónico que le ocupaba. La clasificación cuesta cero, ocurre en segundo plano, y libera al capataz para lo que solo él puede hacer.

Stack técnico

El montaje físico es deliberadamente simple, en parte para que se pueda replicar en otra organización sin equipo de plataforma.

Exhibit 3 — Cuatro componentes, cero dependencias externas tras la instalación.

Las decisiones que conviene explicar:

Por qué Ollama y no llama.cpp directo. Ollama envuelve a llama.cpp con una API estable y un sistema de modelos versionados. Para una organización que va a cambiar de modelo cada pocos meses (porque la frontera abierta se mueve rápido), el coste de mantener invocaciones a llama.cpp directas no compensa.

Por qué Qwen 2.5 Coder 14B Q4 y no algo más grande. Es la combinación que cabe holgada en 16 GB de VRAM dejando margen para contexto largo (32 K tokens) sin descargar pesos a CPU. La cuantización a 4 bits degrada la calidad por debajo del umbral perceptible para tareas rutinarias. Cuando entre la GPU de Fase 2, sustituiremos por Qwen 32B o Llama 70B sin tocar el resto del stack.

Por qué Tailscale y no abrir el puerto 11434. Tailscale crea una red privada entre los equipos sin exponer servicios a internet. El servidor Aveiro no tiene IP pública, no aparece en escáneres, y solo los dispositivos del tailnet corporativo pueden hablarle. Reduce la superficie de ataque a cero sin la fricción habitual de una VPN tradicional.

Por qué un servidor MCP propio en lugar de uno genérico. Los servidores MCP genéricos para Ollama existen pero no aplican prompts específicos de Proportione (taxonomías de tickets, formato de extracción, restricciones de copy). Mantener un servidor MCP local de 200 líneas que sí los aplica es trivial y permite versionar los prompts junto al resto del código.

Tradeoffs honestos

Tres cosas que no funcionan tan bien como una presentación dejaría creer:

La calidad del obrero degrada con prompts mal diseñados. Un modelo de 14B cuantizado tolera muchísimo peor un prompt ambiguo que Claude. Si la tarea no se puede explicar en cinco líneas con ejemplos, probablemente no es candidata a delegación. Lo aprendimos con un primer intento de delegar generación de mensajes de commit: el resultado era inconsistente porque el prompt era impreciso. Reescribirlo más estricto resolvió el problema, pero exige tiempo del capataz que hay que contar como inversión.

Latencia de red al delegar mata el ahorro en lotes pequeños. Para una sola petición, llamar al servidor MCP, ir hasta Aveiro por Tailscale y volver añade unos 200 ms de overhead. Si la tarea individual cuesta 800 ms al obrero, hablamos del 25 % de la ejecución total. Para una sola tarea no compensa. Para un lote de 50 sí: el overhead se diluye.

Cuando el obrero falla, el capataz no se entera bien. Un modelo local que devuelve basura formateada como JSON válido pasa los validadores básicos. Necesitamos validadores semánticos sencillos — ¿el área devuelta está en la taxonomía? ¿el resumen es más corto que el original? — y un fallback explícito al capataz cuando saltan. Todavía afinando estos validadores.

Cuándo este patrón gana

No siempre compensa. Tres condiciones que conviene verificar antes de montarlo:

1. Volumen suficiente para amortizar el setup. Si la previsión es delegar menos de unos cientos de tareas al mes, el ahorro económico es marginal frente al coste de mantener el stack. Mejor pagar al frontier y olvidarse.
2. Tareas con formato cerrado. Si el formato de salida varía mucho entre llamadas, el modelo local sufre y la consistencia cae. El patrón requiere disciplina en la definición de las herramientas MCP.
3. Capacidad de mantener un nodo de cómputo propio. Si el servidor exige más atención operativa de la que la organización puede sostener, lo barato sale caro. El patrón presupone que la decisión de tener nodo propio ya está tomada y validada por otros motivos — en nuestro caso, los del post anterior.

Cuando las tres se cumplen, el patrón es genuinamente diferencial. No por el ahorro económico — que existe pero rara vez es el motor — sino por algo más importante: libera la atención del capataz para lo que solo el capataz puede hacer. Y esa atención, en un equipo pequeño, es el recurso más escaso.

Próximo post de la serie: cómo el patrón cambia el ticketing y la gestión de SLA cuando uno de los pasos es “esperar respuesta del cliente” y otro es “una persona del equipo está revisando”. Para hablar de este, abre una Discussion o escribe a info@proportione.com.

Por el camino acumulamos dos lecciones que nos vinieron por sorpresa: una sobre el desfase entre la placa que eliges en hoja de cálculo y la que de verdad puedes comprar; otra sobre cómo los marketplaces europeos rompen los pedidos enterprise en pedazos.

Marco de decisión: cuatro opciones reales

Antes de elegir hardware, listamos qué soluciones cumplían los criterios mínimos: cómputo suficiente para inferencia LLM local, almacenamiento ampliable, un canal de réplica al nodo Madrid y vida útil mayor de cinco años. Salieron cuatro candidatos.

Exhibit 1 — Las cuatro opciones que evaluamos. La fila clave es la última.

La nube hyperscaler perdió por una razón concreta: nuestro perfil de carga es continuo y predecible (inferencia LLM más servicios internos), no a ráfagas. Pagar por hora un cómputo que necesitamos siempre es la peor combinación. Cuando hicimos números a tres años, cualquier instancia con GPU equivalente nos salía entre tres y cinco veces más cara que comprar el hardware una vez.

El Mac Mini quedó fuera por el techo de RAM (24 GB en el modelo base, 64 GB en el M2 Pro) y por la imposibilidad de instalar Proxmox o pasar GPU a un contenedor. Es un equipo excelente como puesto de trabajo. Como nodo de cómputo central, no.

El NAS con módulo de cálculo lo descartamos por un detalle que solo se ve cuando ya tienes uno: el cómputo va al ritmo del NAS, y el NAS se diseña para ser silencioso y ahorrador, no para mover modelos de lenguaje. Mantenemos el NAS Synology de Madrid como nodo de réplica fría y de Time Machine, que es exactamente para lo que es bueno.

Quedó el servidor x86 propio. La decisión no era qué comprar, sino con qué placa, qué procesador y qué GPU.

La BOM y por qué cada componente

Apuntamos a una arquitectura de cuatro fases. Fase 1 es funcional desde el día uno: hipervisor, almacenamiento, red interna y un modelo LLM local de tamaño medio. Las fases siguientes añaden GPU mayor, más RAM y redundancia.

Exhibit 2 — Cada componente lleva una razón. La razón vale más que el modelo.

Tres principios marcaron las elecciones:

1. Nada se desperdicia al escalar. La fuente está dimensionada para una GPU de gama alta futura. La caja admite el largo de tarjetas de la próxima generación. La RAM se añade en módulos, no se sustituye. La GPU actual pasa a tarjeta secundaria cuando entre la siguiente.
2. Server-grade siempre que el sobrecoste sea pequeño. Placa con IPMI fuera de banda, RAM ECC, fuente Titanium con garantía de diez años, discos enterprise. La diferencia frente a componentes consumer está entre el 10 % y el 30 %, y compra años de tranquilidad.
3. Comprable desde Aveiro. Todo el catálogo se podía pedir a Amazon.es, PCComponentes o Worten con envío a Portugal. Sin importaciones internacionales, sin segunda mano, sin “lo trae alguien que viaja”.

Trampa 1: la placa que eliges no es la placa que llegas a comprar

Aquí ocurrió el episodio más educativo del proceso. La hoja de cálculo dijo claramente que la placa correcta era una Supermicro server-grade con IPMI maduro y dos NVMe nativos. La validación externa lo confirmó: una alternativa de ASRock Rack que también encajaba tenía dos bugs documentados en el foro de Proxmox — uno relacionado con passthrough de GPU, otro con la NIC integrada que desaparecía después de ciertos reinicios. Decisión clara: Supermicro.

Cuando fuimos a comprar, la Supermicro elegida no estaba disponible ni en Amazon, ni en PCComponentes, ni en Senetic, ni en los proveedores españoles habituales con envío a Portugal. La estimación más optimista era de seis a ocho semanas. La ASRock con los bugs sí estaba disponible, en stock, con envío inmediato.

Exhibit 3 — La realidad pragmática del stock. Lo importante no es no cambiar de opinión: es saber por qué cambias.

Volvimos a la ASRock con los bugs documentados. Pero no como antes — esta vez con un plan de mitigación específico para cada bug:

• Bug del passthrough de GPU: actualización de BIOS a la última versión del fabricante (donde el bug está corregido) y BMC a la versión 6.01 o superior. Verificación durante el montaje, antes de poner el servidor en producción.
• Bug de la NIC integrada: tener a mano la utilidad de recuperación del fabricante de la NIC y, como salvaguarda, una NIC PCIe de Intel para sustituirla si el problema persiste.

La lección no es “Supermicro es mejor que ASRock” ni al contrario. Es que una decisión de hardware sin verificar disponibilidad real es solo una preferencia. Y que cambiar de opinión está bien siempre que el motivo del cambio se documente en algún sitio donde el yo del futuro pueda releerlo.

Trampa 2: comprar hardware enterprise en marketplaces europeos

Esta nos sorprendió más. Los componentes enterprise — placa, CPU, fuente, NIC — viven en Amazon.es como vendedores marketplace, no como artículos de Amazon directo. Eso tiene tres consecuencias que conviene saber antes:

Un pedido se convierte en varios. Confirmas siete artículos en una transacción y el sistema los fragmenta en cinco o seis subpedidos, uno por vendedor. Cada uno tiene su propia fecha de entrega, su propio código y su propia política de devolución. La gestión postventa se multiplica.

Anti-fraude se activa con valor alto en poco tiempo. Confirmar dos pedidos con varios cientos de euros cada uno en menos de diez minutos disparó los algoritmos de Amazon. El pedido más grande quedó cancelado automáticamente, “por seguridad”. Resolverlo requirió enviar documentación de empresa por su canal de recurso. Aprendido para la siguiente vez: separar las compras grandes por al menos un día.

Amazon Locker no funciona con marketplace. Probablemente el detalle más doloroso. Los puntos de recogida automática que tan bien funcionan para artículos directos están vetados para vendedores externos. Hay que recibir en dirección física durante ventana laboral, lo que en una sede pequeña requiere coordinación o dejar plantón a alguien.

Ninguna de las tres es un drama, pero las tres juntas alargaron el proceso de un día previsto a una semana real. Si vas a montar un servidor enterprise por catálogo, presupuestar tiempo de gestión de pedidos como si fuera una tarea aparte, no como un click final.

Plan de fases y por qué importa contarlo

El servidor no nace adulto. Lo levantamos por fases para que cada euro tenga una utilidad inmediata, y para que el upgrade futuro a una GPU de gama alta no obligue a tirar nada.

Exhibit 4 — Cuatro fases. Cada una entrega valor sin depender de la siguiente.

La Fase 1 entrega el grueso del valor: hipervisor con contenedores, almacenamiento espejado, réplica al nodo Madrid, modelo LLM local de tamaño medio funcional desde el primer día y tailnet con acceso desde portátil y móvil sin abrir puertos. El retorno frente al ahorro de la API externa es directo y medible — del orden de varias decenas de euros al mes desde la primera semana.

Las fases siguientes son optativas. Si Fase 1 cubre la carga real durante seis meses, no hay urgencia. Si el modelo medio se queda corto, la Fase 2 sustituye la GPU por una mayor — y la GPU original pasa a tarjeta secundaria para embeddings, voz a texto y generación de imagen, sin tirar nada.

Patrón reutilizable

Tres cosas nos llevamos para repetir en futuras decisiones de hardware:

1. Empezar por el marco, no por el componente. La pregunta correcta no es “¿qué placa?” sino “¿qué carga real, qué horizonte temporal, qué presupuesto operativo a tres años?”. El componente cae solo cuando esas tres respuestas están claras.
2. Validar disponibilidad antes de cerrar la decisión. La especificación ideal sin stock es un mock-up, no una decisión. Reservar siempre una alternativa con plan B documentado.
3. Server-grade donde el sobrecoste sea moderado. ECC, IPMI, fuente Titanium y discos enterprise no son lujo: son tiempo que no gastarás depurando inestabilidades raras dentro de tres años.

El servidor entra en servicio durante mayo. El siguiente post de esta serie contará el patrón “Capataz y Obrero” que monta encima — cómo Claude Code en el portátil delega tareas rutinarias a un modelo LLM local que vive en este hardware.

Si estás evaluando algo parecido y quieres contraste honesto sobre alguna decisión concreta, abre una Discussion o escribe a info@proportione.com.

Ninguna de las dos nos servía. Levantamos un pipeline intermedio en cuatro fases y lo probamos primero en industria portuguesa. Va el detalle.

Exhibit 1 — Las cuatro fases y la regla que las gobierna.

La regla, antes que la arquitectura

Una regla innegociable antes de elegir herramienta: nunca contactar a un decisor sin contexto previo.

Contexto quiere decir dos cosas. Una, que la empresa del decisor ha visto contenido nuestro antes del primer mensaje — un artículo, un post, una mención en prensa sectorial. Dos, que el mensaje habla de algo concreto de su industria, no de “nuestras capacidades”. El email genérico al CEO pidiendo una reunión es lo que intentamos no enviar jamás.

Esa regla nos obligó a separar dos flujos que muchas pipelines de prospección funden: el descubrimiento de empresas y la conversación con decisores. Descubrir es rápido y masivo. Conversar es lento y selectivo. Mezclar los tiempos es la raíz de la mayoría de los emails fríos que todos detestamos.

Fase 1 — Descubrimiento

Fuente principal: Google Maps. No es glamoroso, pero es honesto — cada ficha en Maps corresponde a una empresa que existe, tiene dirección física verificable y declara un sector. Para industria portuguesa eso es suficiente.

El tramo automatizable lo cubre BrowserAct con dos plantillas encadenadas: una que barre resultados de búsqueda (“metalurgia {ciudad}”, “moldes {municipio}”, “cerâmica {região}”) y otra que entra en cada ficha para sacar web, teléfono y código postal. El output llega a un JSON que procesamos con un script pequeño (collect-browseract-results.mjs) que descarta duplicados por dominio.

Sobre esos datos corre un filtro ICP en enrich-and-qualify.mjs. Elimina restaurantes, farmacias y servicios de proximidad que se cuelan por el barrido amplio, y asigna un score por tamaño, claridad de industria y presencia web profesional. El criterio de “web profesional” es una heurística tosca pero útil: empresas con sitio propio moderno suelen tener también capacidad para invertir en consultoría.

Orden de magnitud real tras un ciclo completo: 500-700 empresas raw, 300-500 candidatas ICP, 20 targets seleccionados a mano. El recorte brutal no es casualidad. Preferimos 20 conversaciones posibles que 500 contactos imposibles.

Exhibit 2 — El embudo. El −95 % de la última fase es manual y a propósito.

Fase 2 — Enriquecimiento

Aquí buscamos los decisores. No el genérico info@empresa.pt, que nunca llega a nadie: los nombres, los cargos y los correos personales. Cuatro fuentes en orden de rendimiento decreciente:

1. Web de la empresa — página “Equipa” u “Órgãos Sociais”. Las grandes la tienen. Las medianas, rara vez.
2. Hunter.io Domain Search — devuelve emails con emailStatus (valid, accept_all, invalid). Criterio: aceptamos valid siempre, accept_all con precaución, invalid nunca.
3. Registros públicos portugueses — Racius devuelve gerentes de sociedades. Información pública, gratuita, fiable.
4. Social Media Finder en BrowserAct — para los casos en que la empresa no publica LinkedIn en su web.

La tasa de éxito del Social Media Finder fue del 12 % en nuestra primera ronda. No es espectacular, pero entra a coste casi cero en el flujo. LinkedIn por Playwright lo probamos y lo descartamos: funciona, sí, pero es lento, frágil y los cambios del front de LinkedIn rompen cualquier scraper cada pocas semanas. Para LinkedIn hay herramientas mejores.

Decisión 1 — Firestore como CRM

Aquí es donde mucha gente elige HubSpot, Pipedrive o Salesforce. Nosotros elegimos Firestore. El argumento:

• Nuestros datos, nuestra lógica. Un CRM SaaS te cobra por contacto, te mete en su embudo y convierte tu base comercial en un activo que no controlas. Firestore es almacenamiento ligero — los flujos los modelamos nosotros.
• Integración nativa con el resto del stack. Las entidades viven en la misma base que ticketing y soporte, con el mismo orgId, las mismas convenciones de createdAt, las mismas reglas de auditoría.
• Coste marginal. Unas decenas de miles de registros en Firestore cuestan céntimos al mes. Un CRM comercial, varios cientos de euros desde el primer día.

El tradeoff honesto: Firestore no trae interfaz de CRM de caja. Hemos tenido que construir la vista de deals, la cadencia de follow-ups, los dashboards BI. Nos salió a cuenta porque lo necesitábamos también para ticketing — pero no es universalmente buena decisión. Si solo hicieras CRM, el SaaS probablemente gana.

Exhibit 3 — Cuándo gana cada uno. La fila clave es la última.

Decisión 2 — Canal dual, no solo email

Aun con dominio verificado y calentado, solo el 30-40 % de los emails llegan a la bandeja de entrada. Eso deja fuera a seis de cada diez destinatarios. Para no perderlos, el canal secundario es LinkedIn.

El orquestador de LinkedIn es SendPilot: gestiona conexiones, secuencias de mensajes y warmup automáticamente, y nos devuelve estado vía webhook. El integrador local (sendpilot-routing.mjs, sendpilot-status-poll.mjs, sendpilot-warmup-queue.mjs) consume esos eventos, los escribe en la misma entidad Firestore del contacto y deja a Brevo — nuestro canal email — funcionar en paralelo sobre el mismo decisor.

La regla operativa: primero Brevo, después SendPilot, nunca los dos a la vez. La cadencia típica es blog post enviado por newsletter → esperar 2-3 días → si no hay apertura, activar secuencia LinkedIn. Nunca empezamos por LinkedIn frío. Nunca mandamos email genérico sin blog detrás. El único mensaje que el decisor recibe de nosotros sin contenido previo es una conexión de LinkedIn, sin pitch.

Exhibit 4 — La cadencia. La bifurcación ocurre solo si el email se ignora.

Lo que no funcionó

Merece la pena anotar los caminos cerrados:

• Scraping de LinkedIn con Playwright. Funcionaba el lunes, roto el viernes. Mantener scrapers caseros contra un target que se defiende activamente es un sumidero de horas.
• Hunter.io Email Verifier como único filtro. Un accept_all parece un email válido, pero el 30-40 % de ellos rebotan. Combinar con otra señal (presencia en LinkedIn, dominio con MX razonable) lo hace fiable.
• Primer mensaje LinkedIn pidiendo reunión. Tasa de aceptación de conexión al suelo. Cambiar a “conexión sin pitch + mensaje con contenido dos semanas después” subió la tasa al rango útil.

Patrón reutilizable

Dos cosas que nos llevamos para replicar en otra región o sector:

1. Separar descubrimiento de conversación por tiempo y por herramienta. Un scraper de ICP no es un CRM, y un CRM no es un sistema de outreach. Meterlos en la misma caja es la raíz de la prospección mal hecha.
2. Dos canales paralelos con una regla de precedencia clara. Email por delante, LinkedIn detrás, nunca los dos a la vez. Contenido antes que pitch, siempre.

El pipeline completo corre desde el ordenador de una persona en un par de sesiones al mes por región. No hace falta un SDR a tiempo completo. No hay misterio: hay un orden, un filtro duro al principio y una regla innegociable en el último tramo.

Si estás montando algo parecido y atascas en alguna parte concreta, abre una Discussion o escribe a info@proportione.com. Compartimos las decisiones que tomamos, no las cifras que tomaron nuestros clientes.

La causa no estaba en las Alexas ni en Amazon. Estaba en un parámetro del router que tiene sentido en una oficina densa y casi ninguno en una casa.

Síntoma

• Seis dispositivos Alexa (Echo Dot mezclados con Show 5) sin conectividad simultáneamente.
• Ninguno aparecía en la tabla de clientes DHCP del router.
• Reiniciar una Alexa la devolvía a la lista, pero solo durante unos minutos.
• Otros dispositivos 2.4 GHz (termostato, sensores Zigbee vía hub) funcionaban con normalidad.

Sospechas descartadas

Una por una:

• Canal 2.4 GHz saturado — ya estaba fijado en canal 1 con 20 MHz desde el fix de marzo (un episodio anterior de ACSD cambiando canal por la noche). No era eso.
• DHCP agotado — la tabla tenía espacio.
• Interferencia bluetooth o microondas — las Alexas son robustas a esto; además no explicaba las seis a la vez.
• Firmware del router obsoleto — ya era la última (3.0.0.4.388_24305 en el ASUS TUF-AX5400).

Causa raíz

En el syslog del router aparecían decenas de eventos en eth5 (la interfaz 2.4 GHz):

Disassociated due to inactivity

Ese mensaje no significa “el dispositivo dejó de responder”. Significa “yo, el router, decidí expulsarlo”. Y lo decidió por una razón concreta: el Roaming Assistant con umbral de -70 dBm.

Qué hace el Roaming Assistant

El Roaming Assistant está pensado para entornos con varios puntos de acceso. Su trabajo es empujar a un cliente a reasociarse con otro AP cuando su señal cae por debajo de un umbral. Para conseguirlo, lo desauthentica activamente, confiando en que el cliente buscará un AP mejor a continuación.

La lógica tiene dos problemas en una casa:

1. No hay otro AP al que migrar. El cliente queda desconectado y punto.
2. Los IoT baratos no implementan bien el reconnect tras una desasociación forzada. Algunos dejan de intentarlo hasta un ciclo de corriente.

Con la señal de las Alexas fluctuando alrededor de -70 dBm (el salón no estaba justo al lado del router), el Roaming Assistant las iba expulsando una tras otra. Tras varios intentos fallidos de reasociarse, se rendían.

Fix aplicado

Cinco cambios en la configuración 2.4 GHz (NVRAM persistente):

Configuración final 2.4 GHz verificada: canal 1 fijo, 20 MHz, WiFi 6 desactivado, WPA2-Personal/AES, MU-MIMO y OFDMA desactivados, Smart Connect desactivado. Un router “tonto” en la banda 2.4, que es exactamente lo que los IoT necesitan.

Lecciones

1. El router “inteligente” no es siempre tu amigo. Las optimizaciones pensadas para entornos empresariales densos pueden romper un setup doméstico con IoT heterogéneo.

2. El syslog del router es infravalorado. El mensaje Disassociated due to inactivity era la pista completa. Sin acceso al log, habríamos seguido culpando a las Alexas.

3. 2.4 GHz merece configuración separada de 5 GHz. Los IoT viven en 2.4 GHz y no necesitan nada de lo que hace atractivo a 5 GHz. Mezclarlos con “Smart Connect” empeora las dos bandas.

4. Documentar el fix en el punto donde alguien lo leerá. En nuestro caso, router_credentials.md con el “Known issue” anotado. El próximo episodio — y lo habrá — empezará por ahí.

Acción manual restante

Para cerrar el incidente hubo que desenchufar y reenchufar las seis Alexas (una por una, 10-15 segundos entre cada una). El ciclo de corriente es la única forma fiable de que un Echo que lleva rato “rendido” vuelva a intentar asociarse.

Si ves algo que está mal o tienes un caso parecido, abre un Issue o comparte en LinkedIn.