Guía de automatización con IoT: automatiza hogares, edificios, granjas y energía con MQTT

La automatización IoT consiste en dejar que sensores, reglas y actuadores se encarguen de las decisiones rutinarias de un espacio físico, desde apagar las luces de una oficina vacía hasta abrir una válvula de riego cuando el suelo está seco. Esta guía te ofrece una única arquitectura que sirve para hogares, edificios, granjas y sistemas energéticos, muestra automatizaciones funcionales con Home Assistant y Python sobre MQTT y explica cómo mantener todo el conjunto fiable y seguro.

Qué es la automatización IoT y por qué MQTT está en el centro

Toda automatización, por compleja que sea, sigue el mismo ciclo: medir, decidir, actuar, confirmar. Un sensor mide algo, una regla decide si hace falta actuar, un actuador hace el trabajo y un informe de estado confirma que ha ocurrido.

Los sistemas de automatización tradicionales construían este ciclo dentro del controlador de un único fabricante. Funciona hasta que quieres que un sensor de movimiento Zigbee controle un relé Wi-Fi, o que la producción de un inversor solar decida cuándo se enciende un termo eléctrico. La automatización IoT divide el ciclo en partes independientes que se comunican a través de una capa de mensajería común, y esa capa es casi siempre MQTT.

MQTT encaja porque:

• La publicación/suscripción desacopla los dispositivos de la lógica. Un sensor publica una vez; cualquier número de reglas, dashboards y registradores puede suscribirse.
• Es lo bastante ligero para microcontroladores como el ESP32 y el ESP8266, y lo admiten de forma nativa Tasmota, ESPHome, Zigbee2MQTT, los dispositivos Shelly y Home Assistant.
• Los retained messages permiten que un motor de reglas que se reinicia conozca de inmediato el estado actual de cada dispositivo.
• Los mensajes de Last Will anuncian cuándo un dispositivo se desconecta, para que las automatizaciones puedan pasar a un estado seguro.

Si el broker es nuevo para ti, empieza por qué hace un broker MQTT y luego vuelve aquí.

La arquitectura de automatización IoT en cuatro capas

La misma estructura sirve tanto si automatizas un piso como un edificio de oficinas de 20 plantas o un invernadero.

Mantener estas capas separadas es lo que hace el sistema mantenible. Puedes sustituir un sensor Zigbee por uno Wi-Fi, o trasladar las reglas de Home Assistant a Node-RED, sin recablear el resto, siempre que los topics sigan siendo los mismos.

¿Broker local, broker en la nube o ambos?

Un broker en una Raspberry Pi local mantiene las automatizaciones funcionando cuando cae internet, lo que importa para la iluminación y la calefacción. Un broker en la nube hace que los dispositivos sean accesibles desde cualquier lugar, conecta ubicaciones que no están en la misma red (una granja con varios campos, una empresa con varios edificios) y te quita el trabajo de parchear y hacer copias de seguridad de un broker. Muchas instalaciones combinan ambos: las reglas críticas en tiempo se ejecutan en local, mientras que la monitorización, el control remoto y la coordinación entre ubicaciones pasan por un broker MQTT en la nube. El tutorial de Home Assistant con un broker MQTT externo explica esa configuración paso a paso.

Diseño de topics para la automatización

Unos nombres de topic claros hacen que las reglas sean legibles y evitan interferencias accidentales entre dispositivos. Una estructura práctica:

<site>/<area>/<device>/<channel>
<site>/<area>/<device>/<channel>/set      (commands)

home/livingroom/thermostat/temperature
home/livingroom/thermostat/setpoint/set
office/floor3/zone-b/occupancy
farm/greenhouse1/soil/moisture
farm/greenhouse1/valve/state
energy/house/solar/power

Reglas prácticas que ahorran horas de depuración:

1. Separa los topics de estado (lo que informa el dispositivo) de los topics de comando (lo que le pides que haga), normalmente con el sufijo /set.
2. Publica el estado como retenido para que los dashboards y los motores de reglas lo vean al instante tras un reinicio.
3. Usa payloads JSON con unidades y marcas de tiempo cuando un dispositivo informe de varios valores.
4. Da a cada dispositivo un topic status con un Last Will de offline.

La guía sobre estructura de topics MQTT para el hogar inteligente profundiza más, incluido cómo gestionar grupos y escenas.

Automatización IoT por entorno

La arquitectura se mantiene, pero cada entorno tiene sus propias prioridades.

Hogares

La domótica es el ámbito más maduro. Home Assistant es la capa de lógica habitual, con MQTT conectando dispositivos de muchos ecosistemas: sensores Zigbee mediante Zigbee2MQTT, enchufes Wi-Fi flasheados con Tasmota y placas ESP32 a medida construidas con ESPHome. Las automatizaciones típicas son la iluminación según presencia, los horarios de calefacción, las alertas de fugas y las notificaciones. Un error frecuente es depender de la nube para cosas que deben funcionar sin conexión, como un interruptor de luz; mantenlas en local.

Edificios comerciales

La automatización de edificios se centra en la climatización, la iluminación, la ocupación y la calidad del aire, normalmente en muchas zonas. Los sistemas existentes hablan BACnet, KNX o Modbus, y los gateways los traducen a MQTT para que las aplicaciones más nuevas puedan usar los datos sin tocar el sistema de gestión del edificio. Lee automatización de edificios con MQTT para la arquitectura y BACnet a MQTT para el paso del gateway. La climatización y la iluminación en función de la ocupación son las victorias rápidas clásicas, porque las salas vacías son fáciles de detectar. En edificios grandes, como una torre de oficinas en Ciudad de México o un campus en Barcelona, visualizar las zonas en un gemelo digital 3D alimentado por los mismos topics ayuda a los operadores a localizar problemas de un vistazo.

Granjas e invernaderos

La automatización agrícola se enfrenta a largas distancias, condiciones duras y sensores alimentados por batería. La humedad del suelo, la temperatura del aire, la humedad ambiental y los niveles de agua controlan el riego, la ventilación y el sombreado. LoRaWAN es habitual en el campo, con servidores de red como The Things Network reenviando los uplinks por MQTT, como se explica en The Things Network y MQTT. Un broker en la nube resulta especialmente útil aquí porque los campos y los invernaderos rara vez comparten una red local. La guía de IoT para la agricultura inteligente y el tutorial de automatización de invernaderos cubren los detalles.

Energía

La automatización energética equilibra generación, almacenamiento y consumo: encender un termo cuando la producción solar es alta, cargar un vehículo eléctrico en horas valle o desconectar cargas no críticas. Los inversores, las baterías y los contadores inteligentes suelen exponer Modbus o APIs locales que pequeños puentes publican en MQTT. Consulta monitorización energética del hogar con MQTT y monitorización de inversores solares para montajes concretos.

Práctica: una automatización de riego por humedad del suelo

Construyamos un ciclo completo de medir, decidir y actuar. Un dispositivo publica la humedad del suelo, Home Assistant decide cuándo regar y una válvula informa de su estado. Puedes probarlo todo con el servidor MQTT público gratuito broker.connectmq.com antes de conectar hardware real. Elige un prefijo único como connectmq/demo/k7x2p9 y úsalo en todo lo que sigue; cualquiera puede leer el área pública, así que ahí solo deben ir datos de prueba.

Paso 1: simula el sensor y la válvula desde la línea de comandos

Publica una lectura de humedad retenida:

mosquitto_pub -h broker.connectmq.com -p 1883 -i soil-k7x2p9 \
  -t "connectmq/demo/k7x2p9/greenhouse1/soil" -r \
  -m '{"moisture": 42.5, "tempC": 19.8}'

Observa todo lo que cuelga del prefijo en un segundo terminal:

mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-k7x2p9 \
  -t "connectmq/demo/k7x2p9/#" -v

Paso 2: define las entidades en Home Assistant

Añade la integración MQTT en Home Assistant (Ajustes, Dispositivos y servicios, Añadir integración, MQTT) con el broker broker.connectmq.com, el puerto 1883 y un client ID único para las pruebas. Después declara el sensor y la válvula en configuration.yaml:

mqtt:
  sensor:
    - name: "Greenhouse Soil Moisture"
      unique_id: greenhouse1_soil_moisture
      state_topic: "connectmq/demo/k7x2p9/greenhouse1/soil"
      unit_of_measurement: "%"
      value_template: "{{ value_json.moisture }}"
  switch:
    - name: "Greenhouse Valve"
      unique_id: greenhouse1_valve
      command_topic: "connectmq/demo/k7x2p9/greenhouse1/valve/set"
      state_topic: "connectmq/demo/k7x2p9/greenhouse1/valve/state"
      payload_on: "ON"
      payload_off: "OFF"
      retain: false

Paso 3: escribe la regla de automatización

automation:
  - alias: "Irrigate greenhouse when soil is dry"
    mode: single
    triggers:
      - trigger: numeric_state
        entity_id: sensor.greenhouse_soil_moisture
        below: 30
        for: "00:05:00"
    conditions:
      - condition: time
        after: "06:00:00"
        before: "20:00:00"
    actions:
      - action: switch.turn_on
        target:
          entity_id: switch.greenhouse_valve
      - delay: "00:10:00"
      - action: switch.turn_off
        target:
          entity_id: switch.greenhouse_valve

La cláusula for ignora las bajadas breves causadas por el ruido del sensor, la condición horaria evita regar de noche y el retardo fijo garantiza que la válvula se cierre aunque dejen de llegar lecturas de humedad. Publica un valor de humedad de 25 y mantenlo durante cinco minutos; verás aparecer ON en el topic valve/set en tu ventana de mosquitto_sub, seguido de OFF diez minutos después. Un controlador de válvula real se suscribiría a valve/set y publicaría su posición real en valve/state.

La misma regla sin Home Assistant

No todas las instalaciones usan Home Assistant. Node-RED (consulta el tutorial de Node-RED y MQTT) o un pequeño servicio en Python pueden alojar la misma lógica. Esta versión usa paho-mqtt 2.x y añade histéresis para que la válvula no oscile alrededor del umbral:

import json
import threading
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/k7x2p9/greenhouse1"
DRY, WET, MAX_RUN_S = 30.0, 45.0, 600
valve_on = False
timer = None


def set_valve(client, on):
    global valve_on, timer
    valve_on = on
    client.publish(f"{PREFIX}/valve/set", "ON" if on else "OFF", qos=1)
    if timer:
        timer.cancel()
    if on:  # seguridad: nunca funcionar más de MAX_RUN_S
        timer = threading.Timer(MAX_RUN_S, set_valve, args=(client, False))
        timer.start()
    print("valve", "ON" if on else "OFF")


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/soil", qos=1)


def on_message(client, userdata, msg):
    moisture = json.loads(msg.payload)["moisture"]
    if not valve_on and moisture < DRY:
        set_valve(client, True)
    elif valve_on and moisture > WET:
        set_valve(client, False)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"irrigation-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Lista de comprobación para diseñar la automatización IoT

Usa esta lista antes de confiar a una automatización algo que importe:

1. Fallo seguro. Decide qué debe hacer cada actuador si desaparecen el motor de reglas, el broker o el sensor. Las válvulas se cierran, los calefactores se apagan, las puertas permanecen cerradas.
2. Antirrebote e histéresis. Usa ventanas de tiempo o umbrales distintos de encendido y apagado para que el ruido no provoque conmutaciones rápidas.
3. Confirma el estado. Envía órdenes al dispositivo por /set, pero alimenta los dashboards y las reglas posteriores con su state reportado.
4. Gestiona los dispositivos desconectados. Suscríbete a los topics status con Last Will y lanza una alerta cuando un sensor crítico deje de informar.
5. Mantén la intervención manual. Las personas deben poder anular la automatización en local, y las reglas deben respetarlo.
6. Elige la QoS a conciencia. QoS 1 para comandos y alarmas, QoS 0 para lecturas frecuentes. El artículo sobre niveles de QoS en MQTT explica por qué.
7. Protégelo. Usa TLS, credenciales únicas por dispositivo o gateway, y nunca expongas un broker sin autenticación. La checklist de buenas prácticas de seguridad en MQTT se aplica directamente.
8. Registra las decisiones. Publica en un topic de log qué hizo la regla y por qué, para poder depurar "¿por qué se encendió el calefactor a las 3 de la madrugada?".

Probar y mantener las automatizaciones a lo largo del tiempo

Una automatización que funciona el primer día puede romperse en silencio meses después: se agota la batería de un sensor, una actualización de firmware cambia el nombre de una entidad o un dispositivo obtiene una nueva dirección IP y no vuelve a conectarse. Trata las automatizaciones como cualquier otro software del que dependes.

Empieza probando las reglas con mensajes simulados antes de que toquen actuadores reales. Publicar desde la línea de comandos un valor de humedad bajo falso o un evento de ocupación falso es la forma más rápida de ver si una regla se dispara, y no cuesta nada. Guarda una breve lista de estos mensajes de prueba para cada regla importante, para poder repetirlos después de las actualizaciones.

Después, vigila la salud de las entradas, no solo de las salidas. Una regla de calefacción que depende de un sensor de temperatura es tan buena como el último informe de ese sensor. Controla el tiempo transcurrido desde la última publicación de cada dispositivo crítico y lanza una alerta cuando supere unos cuantos intervalos de envío. Los topics status retenidos con un Last Will lo facilitan, porque un dispositivo caído se anuncia a sí mismo.

Por último, revisa las automatizaciones unas cuantas veces al año. Elimina las reglas que nadie recuerda haber creado, comprueba que los umbrales siguen ajustándose a la estación o al cultivo y confirma que las intervenciones manuales siguen funcionando. Un conjunto pequeño y bien entendido de reglas vale más que uno grande en el que nadie confía.

Errores habituales

• Reglas repartidas entre muchas herramientas. Si parte de la lógica vive en el firmware de un enchufe, parte en Home Assistant y parte en Node-RED, nadie puede predecir el comportamiento. Elige un motor de reglas principal.
• Comandos retenidos. Un ON retenido en un topic de comando volverá a encender el dispositivo cada vez que se reconecte. Retén el estado, no los comandos.
• Client IDs compartidos. Dos clientes con el mismo ID se expulsan mutuamente del broker en bucle. Haz que cada ID sea único.
• Rutas críticas solo en la nube. Mantén en local las reglas relevantes para la seguridad y el confort, y usa la nube para la monitorización y el acceso remoto.
• Ignorar la elección del protocolo. Matter, Zigbee y Wi-Fi tienen cada uno sus ventajas e inconvenientes; Matter vs MQTT explica cómo pueden coexistir.

Escalar la automatización IoT a varias ubicaciones con ConnectMQ

En cuanto tienes más de una ubicación, o necesitas acceso remoto sin abrir puertos en tu router, un broker MQTT gestionado se convierte en el centro más sencillo. ConnectMQ da a cada ubicación el mismo endpoint por TLS en el puerto 8883, o por WebSocket seguro en el puerto 8084 para dashboards en el navegador, de modo que las instancias de Home Assistant, los flujos de Node-RED, los gateways y los dispositivos de distintos lugares se encuentran en un mismo broker. El explorador de topics en tiempo real del portal te ayuda a comprobar qué publican realmente los dispositivos, y las reglas de alerta por umbral con registro de alertas pueden avisarte cuando una lectura supera un límite. La lógica de automatización en sí se queda en Home Assistant, Node-RED o tu propio servicio, conectados como clientes MQTT normales.

El plan Serverless gratuito admite hasta 25 conexiones, lo que cubre con holgura un hogar típico o un invernadero pequeño. Los edificios más grandes y los despliegues en varias ubicaciones pueden pasar al plan Serverless de pago con hasta 1.000 conexiones, o a un clúster dedicado. Compara las opciones en la presentación del broker MQTT gestionado.

Empieza con ConnectMQ

Haz el prototipo de tus automatizaciones en el servidor MQTT público gratuito, pensado para pruebas y no para producción, y pasa a un broker privado cuando entren en servicio dispositivos reales. Regístrate en app.connectmq.com con el plan Serverless gratuito, sin tarjeta de crédito, crea un broker y copia el nombre de usuario, la contraseña y el client ID generados en Home Assistant, Node-RED o tus dispositivos. Cambia el puerto a 8883 con TLS y tus reglas seguirán funcionando sin cambios.

Preguntas frecuentes

¿Necesito Home Assistant para la automatización IoT?

No. Home Assistant es la capa de lógica más habitual en los hogares, pero Node-RED, openHAB o un pequeño servicio en Python o Node.js conectado al mismo broker MQTT pueden ejecutar reglas idénticas. El broker y los topics siguen siendo los mismos elijas lo que elijas.

¿El broker de mi automatización debe ser local o estar en la nube?

Ejecuta en local las reglas críticas en tiempo y relevantes para la seguridad, para que funcionen durante los cortes de internet. Usa un broker en la nube para el acceso remoto, las instalaciones en varias ubicaciones y la monitorización, o combina ambos con reglas locales y visibilidad en la nube.

¿ConnectMQ ejecuta mis reglas de automatización?

No. ConnectMQ es el centro de mensajería y ofrece reglas de alerta por umbral para la monitorización, pero la lógica de automatización se ejecuta en herramientas como Home Assistant, Node-RED o tus propios servicios, que se conectan al broker como clientes MQTT.

¿Por qué mi dispositivo se enciende cada vez que se reconecta?

Probablemente publicaste el comando con el flag de retención. El broker guarda los retained messages y los entrega a cada nuevo suscriptor, así que retén los topics de estado, pero nunca los de comando.

¿Puedo probar la automatización IoT sin hardware?

Sí. Simula sensores con mosquitto_pub contra broker.connectmq.com, usando un client ID y un prefijo de topic únicos, y observa los comandos resultantes con mosquitto_sub antes de conectar dispositivos reales.