La cuestión device shadow vs gemelo digital surge en casi todos los proyectos IoT, porque ambos mantienen en la nube una copia del estado de un dispositivo. Este artículo explica exactamente en qué se diferencian en alcance, datos y finalidad, muestra cuándo un shadow es todo lo que necesitas y cuándo necesitas un gemelo completo, y recorre un patrón de device shadow portable construido sobre topics MQTT retenidos.
Para profundizar en el lado del gemelo, consulta la guía de tecnología de gemelo digital.
¿Qué es un device shadow?
Un device shadow es un documento de estado persistente para un único dispositivo, guardado en la nube. Normalmente tiene tres partes:
- Reported: el último estado que informó el dispositivo.
- Desired: el estado que una aplicación quiere que tenga el dispositivo.
- Delta: la diferencia, sobre la que debe actuar el dispositivo.
Las plataformas IoT en la nube introdujeron los shadows (llamados device twins en algunas plataformas) para resolver un problema concreto: las aplicaciones necesitan leer y cambiar el estado de un dispositivo incluso cuando está dormido o desconectado. El shadow siempre está disponible; el dispositivo se sincroniza con él cuando se conecta.
Un shadow es deliberadamente sencillo. Conoce un único dispositivo, guarda el estado actual y un número de versión, y poco más.
¿Qué es un gemelo digital?
Un gemelo digital es un concepto más amplio: una representación virtual en vivo de un activo, proceso o sistema físico que combina el estado actual con contexto y comportamiento. Sobre el estado que guarda un shadow, un gemelo suele añadir:
- Un modelo: qué es el activo, sus propiedades, unidades y semántica, expresados a menudo en DTDL o como Asset Administration Shell.
- Relaciones: esta bomba pertenece a esa estación, que alimenta ese depósito.
- Histórico: series temporales usadas para tendencias, diagnóstico y predicción.
- Analítica o simulación: valores derivados, detección de anomalías, escenarios what-if.
- Visualización: dashboards o escenas 3D que muestran muchos activos juntos.
Un gemelo puede representar cosas que ni siquiera son un único dispositivo: una línea de producción, una planta de un edificio, una fábrica entera.
Device shadow vs gemelo digital: comparativa
| Aspecto | Device shadow | Gemelo digital |
|---|---|---|
| Alcance | Un dispositivo | Activo, sistema o proceso, a menudo con muchos dispositivos |
| Datos principales | Estado reportado y deseado actual | Estado más histórico, modelo y contexto |
| Modelo | JSON libre | Esquema explícito, semántica y unidades |
| Relaciones | Ninguna | Jerarquías y enlaces entre activos |
| Tiempo | Solo el último valor | Actual e histórico |
| Lógica | Cálculo del delta | Analítica, simulación, predicción |
| Consumidores típicos | Apps móviles, gestión de dispositivos | Ingenieros, operarios, planificadores |
| Visualización | Normalmente ninguna | Dashboards y vistas 3D habituales |
| Esfuerzo de construcción | Bajo | Medio a alto |
La relación es acumulativa: la mayoría de los gemelos digitales contienen algo parecido a un shadow para cada dispositivo, mientras que un shadow por sí solo no es un gemelo completo. Nuestro artículo sobre gemelo digital vs sombra digital trata una distinción relacionada pero distinta de la literatura científica, en la que una sombra digital significa un flujo de datos unidireccional del activo al modelo.
Cuándo basta con un device shadow
Elige un shadow cuando:
- Gestionas muchos dispositivos similares, como enchufes inteligentes, localizadores o contadores.
- La necesidad principal es "muéstrame el estado actual y déjame cambiar la configuración".
- Los dispositivos duermen o se conectan de forma intermitente y deben ponerse al día con la configuración.
- No necesitas relaciones entre dispositivos ni analítica por encima.
El IoT de consumo, la configuración de flotas y los ajustes remotos son el terreno clásico de los shadows.
Cuándo necesitas un gemelo digital completo
Elige un gemelo cuando:
- El valor viene de ver los activos en contexto: una línea, un edificio, una red.
- Necesitas correlacionar el estado con el histórico para diagnosticar problemas.
- Varias fuentes de datos describen un mismo activo (PLC, sensor de vibración, MES).
- Los usuarios quieren vistas espaciales o un gemelo digital 3D de la planta o del edificio.
- Planeas mantenimiento predictivo o simulación.
Las plantas industriales, los sistemas energéticos y los edificios casi siempre acaban aquí. El artículo de arquitectura de gemelo digital muestra las capas adicionales que vas a necesitar.
Construir un device shadow portable con topics MQTT retenidos
Los servicios de shadow en la nube están atados a su plataforma. Puedes obtener el mismo comportamiento en cualquier broker MQTT que cumpla el estándar usando retained messages, lo que mantiene el diseño portable. La estructura de topics:
connectmq/demo/<id>/shadows/<device>/reported retained, device writes
connectmq/demo/<id>/shadows/<device>/desired retained, apps write
connectmq/demo/<id>/shadows/<device>/delta not retained, computed by a shadow service
connectmq/demo/<id>/shadows/<device>/status retained, last will
Los retained messages te dan gratis la propiedad más importante de un shadow: quien se suscriba, cuando se suscriba, recibe los últimos documentos reportado y deseado. Un pequeño servicio calcula los deltas:
import json
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/4d2a/shadows"
shadows = {}
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/+/reported", qos=1)
client.subscribe(f"{BASE}/+/desired", qos=1)
def on_message(client, userdata, msg):
_, _, _, _, device, kind = msg.topic.split("/")
doc = json.loads(msg.payload) if msg.payload else {}
shadow = shadows.setdefault(device, {"reported": {}, "desired": {}})
shadow[kind] = doc
delta = {
key: value
for key, value in shadow["desired"].items()
if key not in ("version", "ts") and shadow["reported"].get(key) != value
}
if delta:
client.publish(f"{BASE}/{device}/delta", json.dumps(delta), qos=1)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="shadow-service-4d2a")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
Pruébalo con el servidor MQTT público gratuito, solo con datos de prueba:
mosquitto_pub -h broker.connectmq.com -p 1883 -i lamp1-4d2a -q 1 -r \
-t "connectmq/demo/4d2a/shadows/lamp1/reported" -m '{"on": false, "brightness": 40}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i app-4d2a -q 1 -r \
-t "connectmq/demo/4d2a/shadows/lamp1/desired" -m '{"version": 1, "on": true, "brightness": 80}'
mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-4d2a \
-t "connectmq/demo/4d2a/shadows/lamp1/#" -v
El servicio publica {"on": true, "brightness": 80} en el topic delta. Un dispositivo también puede prescindir por completo del servicio: se suscribe a su topic deseado retenido y calcula el delta localmente, lo que a menudo es más sencillo en flotas pequeñas. Las reglas de reconexión y versionado de sincronización de estado del gemelo digital se aplican sin cambios.
Límites del shadow con topics retenidos
Sé honesto sobre lo que este patrón no te da. No hay API de consultas ("encuentra todas las lámparas encendidas"), no hay control de acceso por documento más allá de lo que permitan las credenciales de tu broker, y los retained messages viven en el broker y no en una base de datos. Si necesitas esas cosas, añade un servicio de gemelos o un suscriptor con base de datos junto al broker. Aun así, para muchas flotas los topics retenidos bastan y evitan toda una capa de servicios.
Errores habituales al elegir entre ambos
Los equipos suelen cometer uno de dos errores opuestos. El primero es llamar gemelo a un shadow y luego sorprenderse cuando los interesados esperan histórico, contexto y analítica que un único documento de estado no puede ofrecer. Si el director de planta pregunta "¿por qué se ralentizó la línea 3 el martes pasado?", un shadow no tiene respuesta.
El segundo error es empezar con una plataforma de gemelos pesada cuando el requisito real es "que la app móvil cambie la consigna del termostato mientras el dispositivo duerme". Ese proyecto necesita un shadow, y añadir modelado, bases de datos de grafos y escenas 3D solo retrasa la entrega.
Una prueba útil es escribir las tres preguntas que más quieren responder los usuarios. Si las tres tratan del estado actual o de la configuración de un dispositivo, construye un shadow. Si alguna implica el tiempo, relaciones entre activos o la comparación entre el comportamiento esperado y el real, planifica un gemelo, pero empieza igualmente con los topics de estado al estilo shadow descritos arriba, porque el gemelo se construirá sobre ellos.
Del shadow al gemelo: un camino práctico
- Empieza con un topic reportado y uno deseado retenidos por dispositivo.
- Añade un topic de estado con Last Will para la presencia.
- Añade un suscriptor de histórico que escriba en una base de datos de series temporales.
- Introduce un modelo de activos con jerarquía y unidades.
- Añade un dashboard o una vista 3D que se suscriba a ramas completas.
- Superpón analítica sobre el histórico y el estado en vivo.
Cada paso reutiliza los mismos topics, así que los dispositivos nunca tienen que cambiar.
Construye shadows y gemelos en ConnectMQ
ConnectMQ te da la base de mensajería para ambos: un broker MQTT gestionado con retained messages, Last Will, MQTT 3.1.1 y 5.0, TLS en el 8883 y WSS en el 8084 para dashboards en el navegador. Tu lógica de shadow y tus servicios de gemelos se conectan como clientes MQTT normales, así que nada queda atado a una nube concreta. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y lleva a él tu primer device shadow.
Preguntas frecuentes
¿Un device shadow es un gemelo digital?
Un device shadow es una forma sencilla de estado similar a un gemelo para un único dispositivo. Un gemelo digital añade un modelo, relaciones, histórico y analítica, a menudo sobre muchos dispositivos.
¿Puedo construir un device shadow sin una plataforma IoT en la nube?
Sí. Los topics MQTT retenidos para el estado reportado y el deseado, junto con un servicio de delta opcional, reproducen el comportamiento de un shadow en cualquier broker MQTT que cumpla el estándar.
¿Qué diferencia hay entre un device twin y un device shadow?
Son esencialmente el mismo concepto con nombres distintos según la plataforma: un documento en la nube con propiedades reportadas y deseadas para un dispositivo.
¿Necesito una base de datos para un device shadow?
No necesariamente. Los retained messages guardan el último estado. Añade una base de datos cuando necesites consultas entre dispositivos, histórico o registros de auditoría.
