Se llama domótica a los sistemas capaces de automatizar una vivienda o edificación de cualquier tipo, aportando servicios de gestión energética, seguridad, bienestar y comunicación, y que pueden estar integrados por medio de redes interiores y exteriores de comunicación, cableadas o inalámbricas, y cuyo control goza de cierta ubicuidad, desde dentro y fuera del hogar. Se podría definir como la integración de la tecnología en el diseño inteligente de un recinto cerrado.
Si está buscando construir una red de dispositivos domésticos inteligentes, probablemente haya oído hablar de Z-Wave y ZigBee.
Son protocolos de conectividad inalámbrica, diseñados principalmente para domótica.
Ambos protocolos comparten cualidades, como la baja potencia y la alta fiabilidad, características esenciales para las aplicaciones de domotica.
Sin embargo, tienen algunas diferencias importantes que desarrollaremos en este articulo.
La mayoría de las personas están familiarizadas con las redes WiFi. Una red WiFi domiciliarias generalmente se estructura como una "RED EN ESTRELLA". En una red en estrella, cada dispositivo se comunica directamente con (y solo con) el HUB central (ó ROUTER). Si un dispositivo está fuera del alcance del router, ese dispositivo no formará parte de la red.
Tanto Z-Wave como ZigBee se consideran "REDES DE MALLA". En una red de malla, la señal se origina desde un HUB central al igual que la red estelar. Sin embargo, los dispositivos no necesitan comunicarse directamente con el router. Una red de malla permite que cada dispositivo en la red funcione como un repetidor y pase la señal a otro dispositivo. Esto permite que las redes de malla sean más versátiles. Pueden cubrir grandes distancias e incluso sortear obstáculos.
Para la gran mayoría de las aplicaciones residenciales, ni el límite de salto ni el límite total del dispositivo deben ser un factor limitante.
Tanto ZigBee como Z-Wave son de muy baja potencia. Usan una fracción de la potencia requerida por WiFi. Este es un beneficio importante que los convierte en una opción tan popular para dispositivos domésticos inteligentes. En una instalcion de domotica muchos de los dispositivos no tendrán acceso a la energía de linea (220v); estos dispositivos deberán funcionar con baterías.
Algunos dispositivos que usan Z-Wave o ZigBee pueden funcionar con una sola batería de botón por varios años. Un dispositivo como ese que intenta mantener una conexión WiFi estaría muerto en días.
Sin embargo, un dispositivo que actúa como repetidor requerirá más potencia. Por esa razón, los dispositivos que funcionan con baterías generalmente están programados para no actuar como repetidores. Es importante tener esto en cuenta al construir su red.
La casa inteligente de hoy se está expandiendo a su garaje e incluso a su patio. Un gran protocolo inalámbrico debe ser capaz de llegar a todos los rincones de su hogar. No es posible detalla el alcance efectivo de una señal inalámbrica en su hogar porque el alcance real dependerá de muchos factores del medio físicos y climáticos.
Lo que podemos decir es que para el mismo nivel de potencia, operar a una frecuencia más alta reducirá el rango de la señal. ZigBee opera a 2,4 GHz en comparación con los 908 MHz de Z-Wave. La frecuencia más alta permite que ZigBee transmita más datos pero reduce el rango de la señal.
El rango inferior se reduce aún más cuando hay obstáculos. Una señal de alta frecuencia viajará a través de obstrucciones, como paredes, con menos eficacia que una señal de baja frecuencia.
Una señal Z-Wave entre dos nodos puede viajar hasta 10 metros en un entorno exterior sin obstáculos.
Sin embargo, se reduce significativamente en el hogar.
Las paredes y otras obstrucciones se combinan con varias fuentes de interferencia eléctrica para reducir la distancia efectiva.
Una guía más precisa para la instalación en el hogar es de 30 metros sin obstrucciones y 15 metros con paredes en el medio.
El rango de espacio libre en el hogar de ZigBee es de aproximadamente 15 metros.
La automatización del hogar incluye sensores de puertas y ventanas, cerraduras eléctricas y vídeo vigilancia de nuestro hogar. La seguridad de nuestros datos inalámbricos es tan importante como siempre.
Tanto Z-Wave como ZigBee utilizan el estándar de cifrado AES 128. Esa es la misma encriptación utilizada por los bancos y el gobierno. Nadie obtendrá el control de su hogar inteligente pirateando el cifrado de la señal. Eso no quiere decir que algunos dispositivos no sean vulnerables. Es solo que la señal inalámbrica en sí misma no es la parte vulnerable.
Al principio de su historia, Z-wave tiene fama de ser inseguro.
Su reputación no estaba realmente justificada.
Las fallas de seguridad que ocurrieron fueron causadas por errores de implementación de las empresas.
Aunque el estándar de cifrado de alto nivel estaba disponible, algunas compañías optaron por no usarlo.
Ahora, la Z-Wave Alliance requiere AES 128 para que un dispositivo obtenga la certificación.
Además, Z-Wave Alliance requiere una implementación obligatoria de su nuevo marco de seguridad 2 (S2) en todos los dispositivos que reciben la certificación. Esta última actualización de seguridad prácticamente elimina las posibilidades de que un dispositivo se vea comprometido durante el proceso de inclusión. Reduce un proceso anterior de tres pasos a uno, lo que a su vez reduce el consumo de energía y la latencia. Y ayuda a evitar que sus dispositivos Z-Wave se usen en un ataque DDOS.
En MQTT se denomina Topic a una cadena de texto UTF-8, una longitud máxima de 65536 caracteres (aunque lo normal es que sea mucho menor) y distingue entre mayúsculas y minúsculas.
Los Topics están formados por uno o más "niveles" separados entre sí por una barra inclinada '/'. Cada nivel debe está formado por uno o más caracteres.
El funcionamiento de los Topcis en MQTT es sencillo y transparente. Por un lado el Broker acepta todos los Topics. No es necesario crearlo explícitamente antes de publicar o suscribirse al Broker.
Por su parte, los clientes pueden suscribirse a uno o varios Topic. Para ello, el cliente puede establecer varias suscripciones y/o emplear Wildcards, como veremos mas adelante.
Finalmente, los clientes publican mensajes indicando un único Topic. El Broker recibe el mensaje y, si encuentra alguna suscripción que cumpla con el filtro del Topic, transmite el mensaje a los clientes suscritos.
Cuando un cliente establece una suscripción puede suscribirse a un Topic específico, o usar Wildcards para suscribirse a múltiples Topic. Existen dos Wildcards que podemos emplear, de "NIVEL ÚNICO" O "NIVEL MÚLTIPLE"
El carácter + puede ser empleado para sustituir un único nivel en cualquier lugar del Topic.
| Topic | Aplica |
|---|---|
| casa/+/temperatura |
|
| casa/living/+ |
|
El carácter # puede ser empleado para sustituir cualquier número de niveles y puede usarse únicamente al final del Topic.
| Topic | Aplica |
|---|---|
| casa/living/# |
Recibirá todos los mensajes cuyo Topic empiece por: "casa/living/"
|
| casa/# |
Recibirá todos los mensajes cuyo Topic empiece por: "casa/"
|
Los Wildcards son únicamente para la suscripción. Los mensajes pueden publicarse únicamente contra un Topic.
El éxito de un sistema de IoT depende enormemente de la arquitectura que diseñemos para la mensajería. En el caso de MQTT es esencial planear y organizar los Topic que vamos a emplear en el proyecto. Hay varios consejos que podemos seguir.
El principal es diseñar el sistema de Topic para que sea ampliable y mantenible. Queremos poder añadir más dispositivos a nuestra red o nuevas funcionalidades, y evitar darnos cuenta en el futuro de que el sistema que elegimos es insuficiente.
Otro consejo es mantener los Topic lo más pequeños y claros posible. Asimismo, es recomendable usar Topics lo más específicos posibles, evitando enviar mensajes a varios dispositivos y discriminar por el contenido del mensaje.
Así, por ejemplo, si se tiene varios sensores /Habitacion/Humedad/1/, /Habitacion/Humedad/2/, /Habitacion/Temperatura/1/ en lugar de usar /Habitacion/ para todos los dispositivos
Finalmente, otro pequeño consejo es emplear únicamente caracteres ASCII estándar, evitando caracteres especiales e incluso espacios. Esto hará más sencillo la interpretación de Topics, y la interoperabilidad entre lenguajes de programación y dispositivos.
Así, por ejemplo, es preferible emplear /Habitacion/ frente a /Habitación/ y /Humedad/ frente a /Sensor humedad/.
Es un sistema orquestador inteligente que puede interconectarse con otros dispositivos inteligentes, recolectar información, gestionar sus estados y disparar acciones que hayas configurado en las circunstancias que hayas establecido.
"Home Assistant" te permite conectar todos los dispositivos inteligentes en tu red Wi-Fi local y te brinda una interfaz simple para que actúen como un "director". El cual dispara acciones en función de si se cumplen o no ciertas condiciones dadas.
Lo que hace que Home Assistant sea genial es que no está tratando de enfocarse en una sola marca de productos inteligentes. La mayoría de los dispositivos que ya tienes funcionarán y conectarse a servicios de tercero como IFTTT es sencillo y simple.
Hay que tener en cuenta que el "Home Assistant" es un servicio local, lo que significa que no enviará ningún dato a la nube, incluso si tiene que recuperar datos de Internet. Las rutinas y comandos que configuras son solo para tus ojos. También es "bastante" fácil configurar rutinas usando una interfaz web alojada localmente en la instancia de "Home Assistant".
Esta característica es importante porque un servicio como este puede ser extremadamente complicado si desea programar rutinas extensas, por lo que tener una interfaz agradable y simple hace que sea mucho más fácil.
Es importante recordar que Home Assistant no puede controlar nada por sí solo. Pensalo como un conector con ENTRADAS de sensores que proveen información, SALIDAS para controlar actuadores y TUS reglas que definen como las ENTRADAS afectan las SALIDAS.
Ej: si ENTRADA: "Cuarto del bebé - Temperatura" - CONDICION: "Supera los 25°C" - SALIDA: "Cuarto del bebé: Ventilador" - ACCION: "Encender".
Quizás no necesite un "smart hub". Si no tiene ningún dispositivo inteligente en tu casa, Home Assistant no te servirá para nada. Pero si ya tiene instalados o piensas implementar dispositivos inteligentes, es una excelente manera de ampliar las características y la funcionalidad que no costará mucho dinero.
A la hora de empezar a incursionar en el área de la domótica es muy fácil marearse con tanta información disponible. Un detalle a tener en cuenta todas las plataformas open source tiene una desventaja su comunidad puede o no ser muy activa y la documentación no es una prioridad y mas de una vez lo que encontramos en foros suele ser versiones obsoletas.
Lo que resulta sumamente importante es evaluar la actividad de su comunidad a la hora de optar por una plataforma u otra.
Esta excelente introducción a los tableros y sensores de prototipos le permitirá recopilar datos de Arduinos y Raspberry Pis en muy poco tiempo.
El Internet de las cosas es uno de los temas tecnológicos más importantes y prometedores de la actualidad. Algunos investigadores de mercado estiman que hay más de 20 mil millones de dispositivos conectados y contando. A nuestro alrededor, hay teléfonos inteligentes, dispositivos portátiles y otros dispositivos, todos los cuales usan sensores. Hoy en día, los sensores juegan un papel importante en nuestra vida cotidiana y en IoT. Los sensores monitorean nuestro estado de salud (por ejemplo, un latido cardíaco), la calidad del aire, la seguridad del hogar y se usan ampliamente en el Internet industrial de las cosas (IIoT) para monitorear los procesos de producción. Por estos motivos, es importante saber cómo funcionan y cómo podemos usarlos para obtener información.
En términos generales, un sensor es un dispositivo que puede detectar cambios en un entorno. Por sí solo, un sensor es inútil, pero cuando lo usamos en un sistema electrónico, juega un papel clave. Un sensor puede medir un fenómeno físico (como temperatura, presión, etc.) y transformarlo en una señal eléctrica.
Existe una amplia gama de sensores que podemos explotar para medir casi todas las propiedades físicas que nos rodean. Algunos sensores comunes que son ampliamente adoptados en la vida cotidiana incluyen termómetros, sensores de presión, sensores de luz, acelerómetros, giroscopios, sensores de movimiento, sensores de gas y muchos más.
Existen otras formas y métodos para agrupar sensores, pero las clasificaciones que se muestran arriba son las más fáciles.
El desarrollo de placas de creación de prototipos y el bajo precio de los sensores nos permiten usarlos fácilmente en proyectos de IoT. Existen varias placas de creación de prototipos en el mercado, adecuadas para diferentes proyectos según las características y especificaciones. En este contexto, consideraremos las dos placas más populares: Arduino Uno y Raspberry Pi 2.
Este artículo explorará cómo conectar diferentes sensores a estas placas y cómo interactuar con ellas.
Antes de sumergirse en los detalles sobre cómo usar los sensores con estas placas, es importante tener en cuenta que cada sensor tiene su propio rango de voltaje de funcionamiento. Este parámetro es muy importante porque el voltaje suministrado por la placa no debe ser más alto que el voltaje máximo permitido por el sensor. Por lo tanto, es importante leer la hoja de datos del sensor cuidadosamente antes de conectarla a la placa para evitar daños. El mismo principio es válido para la señal de salida, que debe ser inferior al voltaje máximo que la placa puede tolerar.
El primer y más popular tablero es el Arduino Uno. Es una placa de microcontrolador basada en un ATmega328P. Es muy fácil de usar y un buen punto de partida. Esta placa proporciona 6 pines analógicos y 14 pines digitales. Es perfecto para usar con sensores analógicos y digitales.
La forma más fácil de comenzar es conectar un sensor analógico al Arduino. Un sensor analógico, como se indicó anteriormente, es un sensor que proporciona una señal continua. Para nuestro primer ejemplo básico, conectaremos un sensor de temperatura simple, un TMP36. Para obtener más información, puede consultar la hoja de datos del sensor. En términos generales, el voltaje de salida de este sensor es directamente proporcional a la temperatura ambiental. Arduino proporciona varios pines de entrada analógica, etiquetados con una "A", que son adecuados para aceptar señales analógicas provenientes de un sensor. El siguiente esquema describe cómo conectar el sensor:
const int tempSensorPin = A1;
void setup() {
Serial.begin(9600);
}
void loop() {
int pinValue = analogRead(tempSensorPin);
Serial.println("Pin value: " + String(pinValue));
float voltage = (pinValue / 1024.0) * 5.0;
Serial.println("Voltage: " + String(voltage));
float temperature = (voltage - 0.5) * 100; // °C
Serial.println("Temperature: " + String(temperature));
delay(5000);
}
Ahora es el momento de conectar un sensor digital a un Arduino. Hay varios sensores digitales disponibles, pero en aras de la simplicidad, consideraremos un sensor digital común llamado DHT11. Este sensor mide la temperatura y la humedad. Es un sensor muy barato que proporciona una salida digital. En este escenario, el pin de datos del sensor debe estar conectado al pin Arduino digital, como se muestra a continuación:
El código es muy simple. Aunque podemos analizar la señal digital y leer la temperatura y la humedad, utilizaremos una biblioteca para simplificar el desarrollo. La biblioteca está disponible en el IDE de Arduino en el elemento del menú Bosquejo-> Incluir biblioteca.
#include "DHT.h"
#define PIN 8
#define DHTTYPE DHT11 // sensor type
DHT dht(PIN, DHTTYPE);
void setup() {
Serial.begin(9600);
}
void loop() {
int temp = dht.readTemperature();
int hum = dht.readHumidity();
Serial.println("Temperature: " + String(temp));
Serial.println("Humidity: " + String(hum));
delay(5000);
}
Al ejecutar el código anterior, Arduino registrará la temperatura y la humedad cada 5 segundos.
Un sensor I2C es un bus serie utilizado para conectar periféricos a microprocesadores. Es ampliamente utilizado y requiere cuatro pines diferentes:
Para experimentar con el sensor I2C con Arduino, analizaremos el sensor BMP280 / BME280. Este sensor mide, entre otras propiedades, la presión barométrica. El siguiente diagrama muestra cómo conectar un BMP280 a Arduino:
Como puede ver, hay cuatro conexiones diferentes. La misma conexión se puede usar con un BME280. No olvide conectar el pin CLK del sensor al Arduino CLK y el pin SDA (los datos) al Arduino SDA. Además, el pin SDO no puede dejarse flotando, por lo que debe conectarlo a tierra o a Vcc. El código fuente para leer la presión se muestra a continuación:
#include
#include
#include
//BMP280
Adafruit_BMP280 bmp;
void setup() {
Serial.begin(9600);
if (!bmp.begin()) {
Serial.println("Could not find a valid BMP280
sensor, check wiring!");
while (1);
}
}
void loop() {
float pressure = bmp.readPressure();
Serial.println("Pressure: " + String(pressure));
delay(5000);
}
Antes de ejecutar el código anterior, debe importar una biblioteca para manejar el sensor, como se describe en el ejemplo anterior.
Raspberry Pi es una computadora de placa única desarrollada por la Fundación Raspberry Pi. Hay varias versiones de Raspberry Pi con diferentes especificaciones, pero todas tienen su propio sistema operativo basado en Linux. Es similar a una PC porque admite salida de video, puertos USB y teclados. Es una placa muy poderosa, y los ejemplos a continuación muestran solo un poco de su poder.
Para controlar los movimientos, utilizaremos un sensor PIR, que significa infrarrojo pasivo. Utiliza un sensor infrarrojo para detectar la radiación de bajo nivel emitida por un cuerpo cálido. En pocas palabras, cuando el nivel de radiación cambia, significa que un cuerpo cálido se está moviendo hacia su área de detección. Este sensor utiliza un pin digital que se pone bajo (o alto) cuando se detecta movimiento. El siguiente esquema muestra cómo conectar el sensor a Raspberry Pi. La conexión puede cambiar si usa una versión PIR diferente o una placa Raspberry Pi diferente:
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM)
sensorPin = 7
GPIO.setup(sensorPin, GPIO.IN)
while True:
if GPIO.input(sensorPIN) == GPIO.LOW:
print "Motion detected"
else:
print "No motion"
time.sleep(0.5)
Cuando el PIR detecta un movimiento, esta sencilla aplicación registrará "Movimiento detectado".
Otro sensor interesante es el sensor MQ-4. El MQ-4 tiene una alta sensibilidad al gas natural. Puede responder rápidamente y es muy fácil de usar. Las conexiones entre el sensor y Raspberry Pi son las mismas que en el ejemplo PIR. Asegúrese de usar el pin digital del sensor y asegúrese de que el voltaje de salida, que debe ser inferior a 3V. Si el sensor tiene una salida superior a 3V, debe usar un convertidor de nivel lógico. El código para usar el MQ-4 es el mismo que el del ejemplo anterior.
Google Home Mini es el pequeño de la familia de altavoces inteligentes de Google. Una gama que completa el Google Home y Google Home Max (este último no disponible en España). Una fuerte apuesta de Google por tomar ventaja el campo de los asistentes personales domésticos.
Los dispositivos Google Home emplean Google Assistant como software para interpretar órdenes y vocalizar respuestas. Una aplicación que también podes utilizar desde tu celular con Android.
La calidad de sonido y potencia del Google Home Mini queda lejos del Google Home, y a mucha distancia del Google Home Max que es un altavoz multimedia de alta calidad.
Pese a su escasa potencia, el Google Home Mini funciona de forma notable para sonidos vocales donde consigue un audio claro y distinguible. Podemos enviar el audio de muchas aplicaciones al Google Home Mini a través de Wifi usando tecnología Miracast. Por otro lado, podemos conectarnos a través de Bluetooth y usarlo como altavoz inalámbrico si nuestro dispositivo móvil lo permite.
Dispone de dos micrófonos de largo alcance, que consiguen un reconocimiento de voz correcto desde cualquier sitio de una habitación, incluso aunque estemos a una distancia de varios metros.
El reconocimiento es afectado por el ruido ambiente, sobre todo si lo tenemos cerca de la televisión. Por su parte, la sintaxis de voz es correcta, y tanto el contenido como el tono de voz de las respuestas resultan amigables y muy naturales. Es perfectamente imaginable poder mantener una conversación fluida en un futuro no muy lejano.
Gracias a la funcionalidad "Voice Match", Google Home Mini puede reconocer la voz de quién le habla. Podemos configurar hasta 6 perfiles de usuarios, y Google Home dará respuestas personalizadas para cada usuario, como por ejemplo sus citas de calendario.
Podemos hacer una gran cantidad de acciones en el Google Home Mini. Por ejemplo, podemos preguntarle por la hora o el tiempo, preguntarle qué significa una palabra, pedirle que traduzca a otro idioma, o añadir recordatorios o leer nuestras citas de Google Calendar.
También podemos definir alarmas en una determinada hora o dentro de un cierto tiempo. Por ejemplo, podemos decirle "recuérdame apagar el horno dentro de 30 minutos".
Google Home también nos ayuda a hacer la lista de la compra. Podemos decir "añade comprar leche a la lista de la compra" y Google Home lo añadirá en la lista, que podremos consultar desde el celular.
Por supuesto, también puede ponernos música. Diciéndole "pon me algo de música" Google Home reproducirá música desde el servicio que tengamos configurado (Spotify o Google Music).
Cuando Google Home no entienda algo nos responderá que no entiende el comando. Estas funciones son las mismas que podemos tener en el móvil con Google Assistant.
Los productos Sonoff de Itead son equipos de IoT muy interesantes que forman una alternativa muy económica para darle inteligencia tu casa.
Disponen de integración con los principales asistentes de voz como Google Home o Alexa. Incluso podemos integrarlos con otros servicios en la nube a través de la popular aplicación IFTTT.
Para los makers mas avanzados, es posible reprogramar los dispositivos con uno de los firmware desarrollados por la comunidad, como el ESPurna desarrollado por Xose Perez, o Tasmota desarrollado por Theo Arends..
El producto principal y más conocido de la familia Sonoff es el relé controlado por Wifi. Su uso es muy sencillo, simplemente alimentamos el dispositivo por el primario, y en el secundario recibirá corriente cuando el relé este activado.
El relé también incorpora un pulsador para conmutar el relé de forma manual. Resulta imprescindible en casos de fallos de la conexion WiFi.
El intercambio de datos entre dispositivos IoT es el la piedra fundamental de este tipo de proyecto. Armamos una lista de los protocolos de comunicación existentes en el ámbito del IoT.
Un protocolo de comunicación es un conjunto de normas definidas como un standard para que dos o más dispositivos puedan comunicarse y entenderse.
Con el avance de las telecomunicaciones y el impulso que ha supuesto Internet, contamos con protocolos robustos como el WiFi ó el 3G la comunicación entre dispositivos no resulta ningún problema.
Sin embargo, en los proyectos de IoT tenemos ciertos requisitos especiales que hacen que los protocolos populares de comunicación no sean eficientes. ¿Cuáles son estos condicionantes?
Por su filosofía los proyectos IoT cuentan con una gran cantidad de dispositivos. Algunos de ellos de pequeños recursos (energía, potencia de RF, etc), como sensores o actuadores. Mientras que otros cuentan con mucho más recursos, como los servidores que recoge información, almacena datos, procesa estadísticas y/o aplican reglas de negocio.
Se debe contemplar que algunos de los dispositivos serán dispositivos embebidos, de bajo costo y escasa capacidad de cálculo. Por tanto, el protocolo deberá requerir poca capacidad de procesamiento.
Queremos que se puedan añadir o quitar dispositivos dinámicamente, sin que el comportamiento del sistema se modifique. Es importante mantener débil el acoplamiento entre dispositivos. Es decir, queremos que la dependencia entre los dispositivos sea la menor posible, y deseablemente nula.
Relacionado con la variedad y número de dispositivos, vamos a querer interoperabilidad. Nuestra solución debera ser capaz de soportar la mayor variedad de dispositivos, sistemas operativos y lenguajes de programación.
Se debe contemplar que un gran numero de sensores, actuadores y servidores, conlleva un gran número de comunicaciones simultáneas y, en general, se requiere una respuesta rápida.
Esto requiere que los mensajes transmitidos sean pequeños y, nuevamente, no requieran un gran procesamiento.
No importa de qué proyecto se trate la seguridad debe ser un elemento importante a tener en cuenta. En un proyecto IoT los dispositivos suelen estar expuestos a Internet y transmitir información privada e incluso controlan sistemas físicos.
Debemos poder acceder a los dispositivos fácilmente, por lo que tendremos que lidiar con direcciones de IP dinámicas y DHCP, posibles conexiones con mucha latencia o poco ancho de banda, dependencia con la infraestructura de la red, firewalls, etc.
¿Cómo conseguir que un número alto de dispositivos, distribuidos geograficamente usando redes desconocidas, se comuniquen entre sí?
Una solución posible, es externalizar la comunicación con un servicio de notificaciones centralizado. Esta solución consiste en disponer un servidor central o Broker, que se encarga de recibir los mensajes de todos los dispositivos emisores, y distribuirlos a los receptores.
El Broker tiene una dirección fija y es accesible por todos los dispositivos, con lo que se elimina el problema de visibilidad entre dispositivos. El servidor mantiene un registro de los dispositivos conectados, recibe los mensajes y los distribuye al resto dispositivos, filtrando los destinatarios según algún criterio.
Los dispositivos entre si, por lo que NO DEPENDEN del resto. Por tanto, esta infraestructura nos proporciona la escalabilidad.
La metodología Publicador/Suscriptor o PubSub es un arquitectura de mensajería donde un agente, el "Suscriptor", informa al "Broker" que quiere recibir mensajes de determinado tipo.
Otro miembro del sistema, el "Publicador" publica mensajes en la cola que le corresponde para que se distribuido por el "Broker" a los "Suscriptores" correspondientes.
El rRPC es un patrón de ejecución remota de procedimientos. Donde un miembro del sistema, llamado "Callee", comunica al "Broker" que proporciona un cierto procedimiento. Otro miembro, llamado "Caller", puede llamar a este procedimiento.
El Broker invoca el procedimiento en el "Callee", recoge el resultado del proceso, y lo comunica al "Caller" que lo ha invocado.
Existen varias topologias para realizar un patrón PubSub o rRPC. Describiremos dos de las principales. A efectos prácticos, podemos conseguir funcionalidades similares en ambos planteamientos, pero igual que en el caso anterior conviene ser consciente de la diferencia.
No obstante, también hay que destacar que existen soluciones que adoptan un comportamiento intermedio o híbrido entre ambos planteamientos.
En un servicio de mensajería de tipo "Message Queue" el "Broker" genera una cola de mensajes única para cada uno de los clientes que inician la subscripción.
El Broker discrimina los mensajes empleando el identificador del cliente, existen mecanismos para distribuir a múltiples clientes el mismo mensaje.
Las colas de mensajes de cliente mantienen los mensajes recibidos hasta que son entregados al cliente. De forma que si se recibe un mensaje cuando el cliente no está conectado, se mantienen en el Broker y son entregados cuando se conecta.
Ejemplo
Una aplicación de mensajería tipo Whastapp, donde el usuario recibe los mensajes que ha recibido mientras no estaba conectado.
Servicio de mensajería puro o Message Service. En este escenario, el Broker distribuye inmediatamente los mensajes a los clientes conectados.
Los mensajes se filtran por algún criterio, como el tema o el contenido del mensaje.
A diferencia de un "Message Queue", los mensajes entregados mientras el cliente está desconectado se pierden. No obstante, eso no significa que un servicio "Message Service" no pueda implementar algún tipo de persistencia de datos.
Ejemplo
Un chat, donde no podemos recuperar los mensajes emitidos cuando no estábamos en la sala. Otro ejemplo cotidiano es una conversación a viva voz. Si alguien dice algo mientras estamos en otra habitación, aunque entremos nos hemos perdido lo que se dijo antes.
| MQTT MQ Telemetry Transport |
Protocolo PubSub de Message Service que actúa sobre TCP. Destaca por ser ligero, sencillo de implementar.
Resulta apropiado para dispositivos de baja potencia como los que frecuentemente tenemos en IoT. Está optimizado para el routing activo de un gran número de clientes conectados de forma simultánea. |
|---|---|
| AMQP Advanced Message Queuing Protocol) |
Protocolo PubSub de Message Queue. AMQP está diseñado para asegurar la confiabilidad e interoperabilidad.
Está pensado para aplicaciones corporativas, con mayor rendimiento y redes de baja latencia. No resulta tan adecuado para aplicaciones de IoT con dispositivos de bajos recursos. |
| WAMP Web Application Messaging Protocol |
Protocolo abierto que se ejecuta sobre WebSockets, y provee tanto aplicaciones de PubSub como rRPC. |
| CoAP Constrained Application Protocol |
Protocolo pensado para emplearse en dispositivos de IoT de baja capacidad. Emplea el modelo REST de HTTP con cabeceras reducidas, añadiendo soporte UDP, multicast, y mecanismos de seguridad adicionales. |
| STOMP Streaming Text Oriented Messaging Protocol |
Protocolo sencillo que emplea HTTP y mensajes de texto para buscar el máximo de interoperabilidad. |
| XMPP Extensible Messaging and Presence Protocol |
Protocolo abierto basado en XML diseñado para aplicaciones de mensajería instantánea. |
| WMQ WebSphere MQ |
Protocolo de Message Queue desarrolado por IMB. |
Copyright © 2026 - Murky Robot - Todos los derechos reservados