Los termostatos inteligentes aprenden rutinas, pero no entienden explicaciones. Si cambia el horario de la familia, hay que esperar días a que el aparato se adapte. Un autor de How-To Geek quiso comprobar si un modelo de lenguaje local podía hacerlo mejor. Le dio el control de su sistema Tado durante cuatro días y le escribió una consigna en lenguaje normal. El modelo recibía datos de temperatura, humedad y presencia cada 30 minutos. El resultado fue desigual. Calculó bien los tiempos de precalentamiento, pero falló al decidir qué habitaciones calentar. Repasamos cómo se montó el experimento, qué datos arrojó y qué conclusiones deja para quien tenga un servidor doméstico y ganas de probar.

Qué se quería probar

Un termostato como el Nest o el Ecobee observa cuándo estás en casa y construye un horario. Funciona bien con rutinas estables. Falla cuando algo cambia, porque no se le puede decir que los niños no tienen colegio hoy.

Un modelo de lenguaje sí admite esa explicación. Ese era el atractivo del experimento. Se trataba de sustituir un algoritmo de aprendizaje por una consigna escrita, y de ejecutarlo todo en local, sin enviar datos a la nube.

La idea tiene lógica. La pregunta es si un modelo pequeño, que corre en un equipo modesto, puede tomar decisiones fiables sobre algo tan cotidiano como la calefacción.

El montaje: Tado, Home Assistant y una consigna en texto

La casa tenía un sistema Tado. Incluye un módulo que controla la caldera y termostatos en algunos radiadores, lo que permite regular cada habitación por separado. Todo estaba integrado en Home Assistant, así que bastaba con enviarle órdenes desde allí.

La consigna describía la distribución de la vivienda y la rapidez con que se calentaba cada estancia. También recogía la rutina semanal y la del fin de semana. Cada 30 minutos, el modelo revisaba temperaturas, humedad y ubicación de los teléfonos. Además consultaba sensores de movimiento, de presencia y proxies Bluetooth repartidos por la casa.

Con esa información decidía qué habitaciones necesitaban calor, cuándo y a qué temperatura. Un pequeño script traducía la decisión en órdenes. Calculaba cuándo debía arrancar la calefacción según los datos históricos de calentamiento y la enviaba a Tado a través de Home Assistant.

Antes de dar el control real, el autor hizo un fin de semana de pruebas en modo sombra. El modelo decidía, pero las órdenes no llegaban a la calefacción. Con unos retoques en la consigna, pasó a la fase real.

Cinco modelos pequeños y un ganador

El hardware era modesto: un Dell OptiPlex antiguo con 16 GB de RAM, con Ollama como servidor de modelos. No cabía nada enorme. Y eso era justo lo que se quería medir, qué puede hacer un modelo local en un equipo normal.

Se probaron cinco modelos pequeños con escenarios basados en datos reales de Tado y otros hipotéticos. Granite 4 7B y Nemotron 3 Nano 4B acertaron menos de la mitad de las decisiones. Los modelos con razonamiento activado tardaban más de 20 minutos en decidir. Con ciclos de 30 minutos, eso ocupa dos tercios del tiempo y resulta inútil.

El ganador fue Qwen 3.5 9B. Acertó el 74 % de las decisiones y tardó entre dos y cinco minutos en cada una. Eso supone entre el 7 y el 17 % del ciclo, un margen razonable para una calefacción.

El 74 % tiene su cara oculta. Significa que uno de cada cuatro juicios era erróneo. Con 48 ejecuciones diarias, y si ese ritmo se mantuviera, saldrían unos doce errores al día. La estimación es nuestra, no del autor, pero ayuda a medir el riesgo.

Cabe una precisión sobre el consumo de memoria. Un modelo de 9.000 millones de parámetros ocupa unos 4,5 GB solo en pesos si se cuantiza a 4 bits, algo habitual en Ollama. El autor no detalla la cuantización, así que es una cifra orientativa. En 16 GB cabe con holgura.

La documentación de Home Assistant sobre Ollama es prudente con estos usos. Recomienda el modelo llama3.1:8b y exponer menos de 25 entidades. Advierte además de que los modelos pequeños cometen más errores y de que solo los que admiten herramientas pueden controlar la casa.

También indica que Home Assistant usa por defecto una ventana de contexto de 8.000 tokens, frente a los 2.000 de Ollama. Es un detalle que conviene ajustar según el modelo.

Cuatro días al mando

De lunes a jueves, el modelo tuvo el control total. En ese periodo se ejecutó unas 190 veces. Falló en tres ocasiones, es decir, en torno al 1,6 % de los ciclos. El resto del tiempo decidió. Tado seguía con su horario normal, pero el modelo podía anularlo en modo manual.

El lunes reconoció que la manta eléctrica encendida indicaba que se acercaba la hora de dormir. Pero retrasó el calentamiento del dormitorio dos horas y luego lo movió todavía más tarde.

El martes por la mañana elaboró un plan perfecto. Media hora después lo olvidó, y la calefacción arrancó tarde. El autor tuvo que modificar la consigna para que considerase las decisiones anteriores.

El miércoles calentó una casa vacía. Un móvil antiguo seguía registrado en Home Assistant y figuraba como presente. Hasta las 13:00 mantuvo varias zonas entre 18 y 19 °C. Fue un error del autor, no del modelo.

La documentación de la integración Tado ayuda a entender este tipo de fallos. Explica que la integración solo maneja el estado “en casa” o “fuera”, sin ubicación precisa, y que presenta limitaciones de actualización.

Si la presencia es tan básica, un dato erróneo arrastra al modelo a una conclusión equivocada.

El ejemplo de los niños

El jueves llegó la prueba que más interesaba. El autor explicó, en un campo de texto, que los niños no tenían colegio. Estarían en un dormitorio, donde está la consola, o en el salón.

El modelo tuvo en cuenta la nota. Pero hizo lo contrario de lo esperado. Bajó el dormitorio ocupado a 12 °C y mantuvo caliente el otro. Entendió la instrucción y no supo aplicarla.

Ese fallo resume el problema. El modelo comprende la idea, pero no siempre actúa en consecuencia. Y esa fue, justamente, la parte que debía ser su ventaja sobre un termostato clásico.

Lo que sí funcionó

No todo fue negativo. El cálculo del tiempo de precalentamiento, basado en las tasas históricas de cada habitación, resultó bueno. Las estancias alcanzaron la temperatura deseada con poca desviación.

También tuvo en cuenta la humedad y el riesgo de moho al decidir si calentar habitaciones vacías. Es un criterio que un termostato sencillo no aplica.

El consumo de energía fue algo superior al normal para cuatro días, aunque sin diferencias grandes. El autor lo compara ajustando por el clima más suave de esos días. Dos mediciones le parecieron dudosas.

Reflexiones adicionales

El experimento no demuestra que la idea sea mala. Demuestra que un modelo de 9.000 millones de parámetros, en un equipo de 16 GB, no basta para gobernar una calefacción con autonomía total. Con modelos mayores y mejor hardware, el resultado podría cambiar.

Hay un enfoque más prudente. El autor sugiere pedir al modelo solo que ajuste de vez en cuando el horario predefinido, en lugar de dirigir todo. Con esa división, un error pesa menos.

También queda una lección sobre los datos. Un móvil olvidado bastó para calentar una casa vacía. En automatización doméstica, la calidad de los sensores importa tanto como la del modelo.

Por ahora, el termostato clásico gana. Es predecible y no necesita explicaciones. El modelo local tiene la ventaja de entender frases como “hoy no hay cole”, pero esa ventaja pierde valor si luego no sabe ejecutarlas. Habrá que repetir la prueba con otros modelos.