Guía completa de integración de ocupación en Home Assistant

Es viernes a las 19:40. La tercera planta lleva vacía desde las 17:00, pero la climatización sigue funcionando a plena carga porque el sensor PIR del pasillo se disparó cuando pasó el equipo de limpieza. El lunes, el gestor del edificio revisa el consumo y ve tres horas de HVAC alimentando una planta sin nadie. Este es el problema que una integración de ocupación en Home Assistant bien diseñada resuelve, y también el motivo por el que muchas instalaciones fracasan: confunden detección de movimiento con conteo de ocupación.

Movimiento no es ocupación: el error de partida

Un PIR responde a una pregunta binaria: ¿algo se ha movido en los últimos X segundos? Un sistema de conteo responde a otra completamente distinta: ¿cuántas personas hay ahora mismo en esta zona? Para automatizar iluminación en un trastero, la primera pregunta basta. Para modular HVAC, gestionar salas de reuniones, activar alertas cuando se supera un límite predefinido de aforo o alimentar un análisis de utilización de espacios, necesita la segunda. Los sensores de conteo con IA que utilizan sistemas como los de Vemco alcanzan un mínimo contractual del 96% de precisión, y típicamente entre el 98% y el 99% cuando la iluminación, la disposición del espacio y el comportamiento de los visitantes lo permiten. Esa diferencia de datos de entrada cambia por completo qué automatizaciones son viables en Home Assistant.

Tres vías de integración y cuándo usar cada una

Existen tres arquitecturas habituales para llevar datos de conteo a Home Assistant, y la elección correcta depende de la latencia que necesite y de quién mantiene el sistema después de la entrega.

• MQTT: la opción preferida para tiempo real. El sensor o la plataforma de conteo publica en un topic por zona (por ejemplo, edificio/planta3/sala_a/ocupacion) y Home Assistant se suscribe mediante sensores MQTT. Latencia de segundos, carga mínima, y funciona bien con decenas de zonas.
• API REST con sondeo: útil cuando la plataforma de conteo solo expone una API. Configure el intervalo de sondeo con criterio: cada 30-60 segundos suele bastar para HVAC; sondear cada 5 segundos solo genera ruido y carga innecesaria.
• Webhooks entrantes: la plataforma empuja eventos a Home Assistant cuando cambia el conteo o se cruza un umbral. Ideal para alertas de aforo, menos adecuado como fuente única porque un evento perdido deja el estado desactualizado hasta el siguiente cambio.

En proyectos comerciales serios, la combinación ganadora suele ser MQTT para el estado continuo más un sondeo REST cada pocos minutos como verificación de coherencia. Si ambas fuentes divergen, algo falla y conviene saberlo antes de que la automatización tome decisiones erróneas.

Diseño de entidades: numérico primero, binario después

Modele siempre la ocupación como un sensor numérico (número de personas por zona) y derive los estados binarios mediante sensores de plantilla. Un binary_sensor de "zona ocupada" con histéresis — ocupada cuando el conteo supera 0, desocupada solo tras 10 minutos en 0 — evita que la climatización oscile cada vez que alguien sale a por café. Otro binary_sensor de "aforo excedido" se activa al superar el límite predefinido y dispara la notificación al equipo de seguridad o facilities. Conservar el dato numérico crudo tiene además un beneficio que muchos integradores descubren tarde: el historial de Home Assistant, exportado a InfluxDB o similar, se convierte en una base de análisis de utilización que justifica decisiones de espacio, la misma lógica que plataformas como VemSpace aplican a escala de portfolio.

Automatizaciones que justifican el presupuesto

• Setback de HVAC por zona: cuando una zona lleva 15 minutos con conteo cero, suba o baje la consigna 2-3 °C en lugar de apagar. La recuperación térmica de un apagado total suele costar más que el ahorro, especialmente en edificios con reocupación impredecible.
• Salas de reuniones fantasma: sala reservada en el calendario pero con conteo cero durante los primeros 10 minutos: libere la reserva automáticamente. En oficinas y universidades, este solo caso de uso recupera un porcentaje sorprendente de capacidad de salas.
• Alertas de aforo: notificación inmediata al superar el límite predefinido, con un segundo umbral de preaviso al 85% para que la respuesta sea preventiva y no reactiva.
• Iluminación y ventilación de zonas comunes: modulación proporcional al conteo real, no al movimiento, lo que en edificios públicos elimina el desperdicio clásico de sistemas siempre encendidos.

Lo que un implementador aprende en el segundo proyecto

Una observación de campo que rara vez aparece en la documentación: si usa MQTT, publique los conteos con la bandera retained activada. Cuando Home Assistant se reinicia — y se reiniciará, en cada actualización — un sensor sin mensaje retenido arranca en estado unknown, y una automatización de HVAC mal escrita puede interpretar ese estado como "vacío" y apagar la climatización de una planta llena. Añada siempre una condición que excluya unknown y unavailable en cualquier automatización que actúe sobre climatización o seguridad. El segundo aprendizaje: la exclusión de personal en el propio sensor importa más de lo que parece. Si el personal de limpieza y mantenimiento cuenta como ocupación, sus setbacks nocturnos nunca se activan y el ahorro proyectado se evapora. Los sensores con IA que distinguen y excluyen al personal resuelven esto en origen, antes de que el dato llegue a Home Assistant.

Cuándo Home Assistant se queda corto

Home Assistant es excelente como capa de orquestación en edificios pequeños y medianos, en pilotos, y como puente entre sensores y sistemas que de otro modo no hablarían entre sí. Pero un portfolio de edificios con BMS corporativo, requisitos de seguridad y acuerdos de nivel de servicio exige una capa de integración diseñada para ello. Ahí es donde una plataforma como VemFusion conecta directamente los datos de ocupación con HVAC, BMS y sistemas de seguridad sin depender de una instancia de Home Assistant que alguien tiene que mantener y actualizar. Un patrón habitual y sensato: validar los casos de uso y las lógicas de automatización con Home Assistant en una planta piloto, y escalar después con integración nativa al BMS. Lo aprendido en el piloto — umbrales, tiempos de histéresis, zonas problemáticas — se traslada directamente.

Errores frecuentes que conviene evitar

• Definir zonas de conteo que no coinciden con las zonas de climatización: el dato es correcto pero inservible para actuar.
• Automatizar sobre el conteo instantáneo en lugar de sobre medias móviles o estados con histéresis.
• No registrar los datos históricos desde el primer día, perdiendo la línea base que después justificaría la inversión.
• Asumir precisión perfecta: incluso al 98-99%, diseñe umbrales con margen y no automatizaciones que dependan de distinguir entre 0 y 1 persona en zonas grandes.

¿Está planificando una integración de ocupación en Home Assistant o evaluando el salto de un piloto a una integración completa con su BMS? El equipo de Vemco puede ayudarle a definir la arquitectura de zonas, los requisitos de precisión y la vía de integración adecuada para su edificio. Hable con nosotros aquí y cuéntenos qué sistemas quiere conectar.