Introducción a los Protocolos para IoT

• MQTT (Message Queuing Telemetry Transport): Es un protocolo de mensajería ligero diseñado para dispositivos con recursos limitados y conexiones inestables. Es ampliamente utilizado en aplicaciones IoT para la comunicación entre dispositivos y servidores.

• HTTP (Hypertext Transfer Protocol): Aunque es un protocolo de uso general en la web, también se utiliza en el IoT para la comunicación entre dispositivos y servidores a través de solicitudes y respuestas.

• CoAP (Constrained Application Protocol): Es un protocolo diseñado específicamente para dispositivos con recursos limitados, como sensores y actuadores en el IoT. Ofrece una comunicación eficiente y bajo consumo de energía.

• AMQP (Advanced Message Queuing Protocol): Es un protocolo de mensajería que facilita la comunicación entre aplicaciones y dispositivos IoT, proporcionando una forma robusta de enviar mensajes en tiempo real.

• DDS (Data Distribution Service): Es un estándar de comunicación para sistemas distribuidos en tiempo real, utilizado en aplicaciones donde se requiere un intercambio de datos rápido y confiable, como en entornos industriales.

Estos son solo algunos ejemplos de protocolos utilizados en el IoT, y la elección del protocolo adecuado depende de los requisitos específicos de cada aplicación, como la seguridad, la eficiencia energética, la escalabilidad y la confiabilidad de la comunicación.

------------------------------------------- Otras fuentes -----------------------------------------------------------------------------------

Protocolos para IoT

Algunos de los muchos protocolos M2M disponibles.

• MQTT (MQ Telemetry Transport) es un 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) es un 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) es un protocolo abierto que se ejecuta sobre WebSockets, y provee tanto aplicaciones de PubSub como rRPC.
• CoAP (Constrained Application Protocol) es un 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, es un protocolo sencillo que emplea HTTP y mensajes de texto para buscar el máximo de interoperabilidad.
• XMPP (Extensible Messaging and Presence Protocol) es un protocolo abierto basado en XML diseñado para aplicaciones de mensajería instantánea.
• WMQ (WebSphere MQ) es un protocolo de Message Queue desarrolado por IMB.

Hasta aquí esta entrada sobre protocolos de comunicación M2M en IoT. Hemos visto las necesidades especiales de estos protocolos y cómo resolverlo con una externalización en un servicio de mensajería.

Resumen de los Mensajes del Protocolo MQTT

El protocolo MQTT (Message Queuing Telemetry Transport) es un estándar de mensajería ligero diseñado para dispositivos con recursos limitados y redes de ancho de banda reducido. Funciona sobre el protocolo TCP/IP y sigue un modelo de publicación/suscripción, donde los clientes se comunican a través de un broker que gestiona los mensajes.

Tipos de Mensajes en MQTT

MQTT define varios tipos de mensajes para facilitar la comunicación entre clientes y el broker. A continuación, se describen los principales:

1. CONNECT:

   • Propósito: Iniciar una conexión entre el cliente y el broker.

   • Contenido: Incluye el identificador del cliente, credenciales de autenticación (si se requieren), y parámetros como el tiempo de espera (keep-alive).

2. CONNACK:

   • Propósito: Confirmar la aceptación o rechazo de la solicitud de conexión por parte del broker.

   • Contenido: Contiene un código de retorno que indica el estado de la conexión (éxito o tipo de error).

3. PUBLISH:

   • Propósito: Enviar un mensaje desde un cliente a un tema específico en el broker.

   • Contenido: Incluye el tema (topic), el nivel de calidad de servicio (QoS), y la carga útil (payload) del mensaje.

4. PUBACK:

   • Propósito: Confirmar la recepción de un mensaje PUBLISH cuando se utiliza QoS 1.

   • Contenido: Contiene el identificador del mensaje para correlacionar la confirmación con el mensaje original.

5. PUBREC:

   • Propósito: Confirmar la recepción de un mensaje PUBLISH cuando se utiliza QoS 2.

   • Contenido: Similar a PUBACK, pero forma parte del proceso de entrega garantizada en QoS 2.

6. PUBREL:

   • Propósito: Indicar que el mensaje PUBLISH ha sido recibido y que el emisor puede liberar los recursos asociados.

   • Contenido: Incluye el identificador del mensaje correspondiente.

7. PUBCOMP:

   • Propósito: Confirmar que el proceso de entrega de un mensaje PUBLISH con QoS 2 se ha completado.

   • Contenido: Contiene el identificador del mensaje, cerrando el ciclo de confirmaciones en QoS 2.

8. SUBSCRIBE:

   • Propósito: Solicitar la suscripción a uno o más temas en el broker.

   • Contenido: Lista de temas y los niveles de QoS deseados para cada uno.

9. SUBACK:

   • Propósito: Confirmar la aceptación de una solicitud de suscripción.

   • Contenido: Lista de niveles de QoS otorgados para cada tema solicitado.

10. UNSUBSCRIBE:

    • Propósito: Solicitar la cancelación de la suscripción a uno o más temas.

    • Contenido: Lista de temas de los que el cliente desea darse de baja.

11. UNSUBACK:

    • Propósito: Confirmar la aceptación de una solicitud de desuscripción.

    • Contenido: Identificador del mensaje correspondiente a la solicitud de desuscripción.

12. PINGREQ:

    • Propósito: Verificar que la conexión entre el cliente y el broker sigue activa.

    • Contenido: No contiene carga útil; es simplemente una señal de "ping".

13. PINGRESP:

    • Propósito: Responder a un mensaje PINGREQ, indicando que la conexión está activa.

    • Contenido: Similar a PINGREQ, sin carga útil.

14. DISCONNECT:

    • Propósito: Indicar que el cliente desea cerrar la conexión de manera ordenada.

    • Contenido: No contiene carga útil; simplemente notifica al broker del cierre de la conexión.

Calidad de Servicio (QoS) en MQTT

MQTT ofrece tres niveles de QoS para garantizar la entrega de mensajes:

• QoS 0 (Entrega al menos una vez): El mensaje se envía sin garantía de entrega. No se realizan reintentos ni se espera confirmación.

• QoS 1 (Entrega al menos una vez): Se garantiza que el mensaje se entregará al menos una vez, pero es posible que se entregue más de una vez en casos de reintentos.

• QoS 2 (Entrega exactamente una vez): Se garantiza que el mensaje se entregará una sola vez. Este nivel implica un proceso de confirmación más complejo para evitar duplicados.

Conclusión

El protocolo MQTT utiliza una variedad de mensajes para gestionar la conexión, publicación, suscripción y mantenimiento de la comunicación entre clientes y el broker. Comprender estos mensajes es esencial para implementar soluciones eficientes en entornos con recursos limitados y necesidades de comunicación confiable.

Retención de Mensajes

El indicador de retención en un mensaje PUBLISH determina si el broker debe almacenar el último mensaje publicado en un tema específico. Cuando un nuevo suscriptor se une a ese tema, recibirá inmediatamente el mensaje retenido, lo que es útil para proporcionar el estado actual sin esperar a la próxima publicación.

Keep Alive y Mensajes de Ping

El parámetro Keep Alive es un intervalo de tiempo, en segundos, que el cliente establece al conectarse al broker. Si no se envían mensajes dentro de este intervalo, el cliente debe enviar un PINGREQ para mantener viva la conexión. El broker responde con un PINGRESP. Esto ayuda a detectar conexiones interrumpidas y a mantener la sesión activa.

Este resumen proporciona una visión general de los mensajes y funcionalidades clave del protocolo MQTT. Para obtener información más detallada y ejemplos prácticos, te recomiendo visitar el artículo original en Steve's Internet Guide.

Si tienes alguna pregunta específica o necesitas más detalles sobre algún aspecto de MQTT, no dudes en consultarme.

Comunicación entre un Dispositivo WiFi y un Servidor MQTT Mosquitto en Internet

En este escenario, un dispositivo IoT con WiFi (como un ESP32, Raspberry Pi o cualquier otro cliente MQTT) se conecta a un servidor Mosquitto MQTT en Internet para enviar y recibir mensajes.

1️⃣ Pasos de Comunicación

📡 Paso 1: Conexión del Dispositivo a la Red WiFi

El dispositivo debe conectarse a una red WiFi para tener acceso a Internet.

• El dispositivo IoT escanea las redes WiFi disponibles.

• Se conecta a una red con SSID y contraseña usando un protocolo como WPA2.

• Una vez conectado, obtiene una dirección IP mediante DHCP asignado por el router.

// Código en ESP32 para conectarse a WiFi
WiFi.begin("SSID", "PASSWORD");
while (WiFi.status() != WL_CONNECTED) { delay(500); }

🌍 Paso 2: Resolución de la Dirección IP del Servidor MQTT

El servidor Mosquitto en Internet tiene un nombre de dominio (ej: mqtt.example.com). El dispositivo usa DNS para obtener la dirección IP del servidor.

IPAddress serverIP;
WiFi.hostByName("mqtt.example.com", serverIP);

🔌 Paso 3: Establecimiento de la Conexión MQTT (HandShake TCP + TLS si es seguro)

• El dispositivo abre una conexión TCP con el puerto 1883 (sin TLS) o 8883 (con TLS/SSL).

• Si el servidor requiere autenticación, el cliente envía su usuario y contraseña.

• Se negocia la versión del protocolo MQTT y otros parámetros como el "Keep Alive" (mantiene la conexión activa).

// Código para conectarse a Mosquitto desde ESP32
client.setServer("mqtt.example.com", 1883);
client.connect("DeviceID", "user", "password");

📢 Paso 4: Publicación y Suscripción a un Tópico

Una vez conectado, el dispositivo puede publicar mensajes o suscribirse a temas para recibir información.

• Publicación: Enviar datos al servidor.

• Suscripción: Escuchar mensajes de un tópico específico.

// Publicar datos (ejemplo: temperatura)
client.publish("sensors/temp", "25.4");

// Suscribirse a un tópico
client.subscribe("commands/device1");

📨 Paso 5: Transferencia de Datos a Través de MQTT

📌 Ejemplo de flujo de comunicación:

1️⃣ El dispositivo IoT publica un mensaje:

• Tópico: sensors/temp

• Payload: "25.4"

2️⃣ El servidor Mosquitto recibe y reenvía el mensaje a todos los clientes suscritos a sensors/temp.

3️⃣ Otro dispositivo, como un dashboard en la nube, recibe la temperatura y la muestra en tiempo real.

🔄 Paso 6: Mantenimiento y Cierre de la Conexión

• Keep Alive: Si no hay tráfico, el cliente envía un PINGREQ al servidor cada cierto tiempo para evitar desconexión.

• Desconexión: Cuando el dispositivo deja de transmitir, envía un mensaje DISCONNECT al servidor.

client.disconnect();

2️⃣ Ejemplo Real de Mensajes MQTT en Mosquitto

🔹 El cliente publica un mensaje:

PUBLISH sensors/temp 25.4

🔹 Mosquitto lo reenvía a suscriptores:

Message received in sensors/temp: 25.4

🔹 El servidor envía un comando de respuesta:

PUBLISH commands/device1 LED_ON

🔹 El dispositivo IoT recibe la orden y enciende un LED.

3️⃣ Seguridad en la Comunicación MQTT

• TLS/SSL (MQTTS): Usar el puerto 8883 para cifrado.

• Autenticación: Usuario y contraseña en el cliente.

• Certificados: Validación de identidad del servidor y del cliente.

client.setServer("mqtt.example.com", 8883);
client.setCACert(root_ca);  // Certificado SSL

4️⃣ Diagrama Resumen

📡 Dispositivo IoT (WiFi) → Internet → Servidor Mosquitto MQTT → Cliente Suscrito (App, Dashboard, etc.)

CoAP son las siglas de Constrained Application Protocol, que en español se traduce como Protocolo de Aplicación para Entornos Restringidos.

¿Qué es CoAP?

CoAP es un protocolo diseñado específicamente para dispositivos con recursos limitados, como sensores, actuadores y nodos IoT. Fue estandarizado por el grupo de trabajo CoRE (Constrained RESTful Environments) del IETF.

Características principales:

• 🧠 Ligero y simple: Ideal para dispositivos con poca memoria y bajo consumo de energía.

• 🌐 Basado en REST: Su funcionamiento es similar a HTTP (usa métodos como GET, POST, PUT y DELETE), pero está adaptado para redes más restringidas.

• 📦 Usa UDP: A diferencia de HTTP y MQTT que usan TCP, CoAP usa UDP, lo que lo hace más rápido pero menos confiable (aunque incorpora mecanismos propios de confiabilidad).

• 🧩 Multicast nativo: Permite enviar un mensaje a múltiples dispositivos a la vez, algo que no es tan natural en otros protocolos como MQTT.

• 🔐 Seguridad: Puede utilizar DTLS (Datagram Transport Layer Security) para cifrar y autenticar mensajes.

¿Dónde se usa?

CoAP se utiliza principalmente en sistemas embebidos y aplicaciones de IoT industrial y doméstico, donde los recursos de red y de hardware son muy limitados. Por ejemplo:

• Sensores de temperatura que informan valores cada cierto tiempo.

• Interruptores inteligentes que responden a comandos.

• Sistemas de riego automatizados.

Comparado con MQTT:

Vamos a desglosar bien los comandos mosquitto_pub y mosquitto_sub, que son las herramientas de línea de comandos para publicar y suscribirse a mensajes MQTT usando Mosquitto. Te servirán muchísimo para pruebas rápidas en tu Raspberry Pi o en cualquier máquina que tenga instalado Mosquitto.

🧭 mosquitto_pub – Publicar mensajes a un broker MQTT

📌 Sintaxis básica:

mosquitto_pub -h <host> -t <topic> -m <mensaje>

🛠️ Opciones comunes:

🧪 Ejemplo:

mosquitto_pub -h localhost -t sensores/temperatura -m "25.3"

📡 mosquitto_sub – Escuchar mensajes desde un broker MQTT

📌 Sintaxis básica:

mosquitto_sub -h <host> -t <topic>

🛠️ Opciones comunes:

🧪 Ejemplo:

mosquitto_sub -h localhost -t sensores/temperatura -v

🌟 Características interesantes

• Podés usar comodines:

  • +: un solo nivel (ej. sensores/+)

  • #: múltiples niveles (ej. sensores/#)

• Se puede publicar JSON, binarios o cualquier string.

• Muy útil para testear dispositivos IoT, como el ESP32 o scripts en Python.

Un script en Python que:

1. Se conecta a una red Wi-Fi (esto lo gestiona el sistema operativo si estás en una PC o Raspberry Pi).

2. Se conecta al servidor Mosquitto (local o remoto).

3. Publica un mensaje a un tópico.

4. Se suscribe a ese mismo u otro tópico y muestra los mensajes recibidos.

✅ Requisitos:

• Python 3

• Biblioteca paho-mqtt: se instala con

  pip install paho-mqtt

🐍 Script completo (publicar y suscribirse en MQTT)

import paho.mqtt.client as mqtt
import time

# Parámetros del broker
MQTT_BROKER = "localhost"       # O la IP del servidor Mosquitto
MQTT_PORT = 1883
MQTT_TOPIC_PUB = "test/sensor"
MQTT_TOPIC_SUB = "test/#"
MQTT_CLIENT_ID = "cliente_mqtt_python"

# Función callback cuando se conecta
def on_connect(client, userdata, flags, rc):
    if rc == 0:
        print("Conectado al broker MQTT")
        client.subscribe(MQTT_TOPIC_SUB)
    else:
        print("Falló la conexión. Código:", rc)

# Función callback cuando llega un mensaje
def on_message(client, userdata, msg):
    print("mensaje recibido en {msg.topic}: {msg.payload.decode()}")

# Crear cliente
client = mqtt.Client(MQTT_CLIENT_ID)
client.on_connect = on_connect
client.on_message = on_message

# Conectar al broker
client.connect(MQTT_BROKER, MQTT_PORT, 60)

# Iniciar bucle en segundo plano
client.loop_start()

# Publicar algunos mensajes de prueba
for i in range(5):
    mensaje = f"Lectura #{i+1}: {20 + i}°C"
    print("Publicando: {mensaje}")
    client.publish(MQTT_TOPIC_PUB, mensaje)
    time.sleep(2)

# Esperar antes de salir
print("Esperando mensajes por 10 segundos...")
time.sleep(10)

# Detener cliente MQTT
client.loop_stop()
client.disconnect()
print("Desconectado del broker MQTT")

🔧 Opcional: cambiar por IP de tu Raspberry Pi

MQTT_BROKER = "192.168.1.100"  # Cambiá esto por la IP de tu Raspberry si es el servidor

Desarrollo un contenido detallado sobre cómo dimensionar una red IoT que utiliza MQTT, considerando aspectos como capacidad del broker, conexiones simultáneas, tráfico de datos, latencia y uso del ancho de banda.

📐 Dimensionamiento de una red IoT basada en MQTT

1. 🧠 Factores clave a considerar

Al planificar una red MQTT para IoT, es esencial tener en cuenta:

• Número de dispositivos/nodos que se conectarán al broker.

• Frecuencia de publicación de datos por cada nodo.

• Tamaño promedio del mensaje MQTT (en bytes).

• Tipo de red de comunicación (WiFi, LoRa, Ethernet, LTE, etc.).

• Capacidad del broker MQTT (hardware y software).

• Escalabilidad y tolerancia a fallos.

2. 🔗 Límites generales de brokers MQTT populares

Nota: En Raspberry Pi, Mosquitto puede manejar entre 200 y 1000 conexiones dependiendo de configuración y carga de trabajo.

3. 📦 Cálculo del ancho de banda

Fórmula básica:

Ancho de banda = Nº de dispositivos × Tamaño de mensaje × Frecuencia

Ejemplo:

• 100 nodos publicando cada 10 segundos

• Tamaño medio de mensaje: 100 bytes

👉

Ancho de banda ≈ (100 × 100 bytes × 0.1 mensajes/seg) = 1000 bytes/seg = ~8 kbps

Este número se multiplica por 2 si también considerás la recepción desde el broker (por ejemplo, para dashboards).

4. 🧪 Pruebas de carga (load testing)

Herramientas útiles:

• mqtt-benchmark

• artillery

• locust

• Simuladores de nodos como MQTT.fx, Node-RED, ESP32.

5. 🧰 Estrategias para escalar

• Usar QoS 0 (sin acuse de recibo) para sensores frecuentes y no críticos.

• Limitar el tamaño de los mensajes a menos de 256 bytes si es posible.

• Agrupar datos en JSON o batch.

• Desplegar brokers en contenedores (Docker) o usar brokers distribuidos.

• Usar brigde MQTT para separar regiones o segmentos.

• Configurar adecuadamente max_connections, message_size_limit, keep_alive, etc.

6. 🛡️ Seguridad y estabilidad

• Habilitar autenticación TLS.

• Usar credenciales por dispositivo.

• Monitorear con herramientas como Grafana + Telegraf + InfluxDB.

• Logs del broker + watchdogs automáticos.

La seguridad de los datos en MQTT (especialmente con TLS/SSL) sí afecta el rendimiento del broker Mosquitto, aunque cuánto disminuye depende del hardware, del número de conexiones, y de la configuración.

🔐 ¿Cómo impacta la seguridad en el rendimiento del broker Mosquitto?

1. Encriptación TLS/SSL

Cuando habilitás TLS en Mosquitto (usando cafile, certfile, keyfile en la configuración), se introduce una sobrecarga computacional por:

• Establecer conexiones seguras (handshake TLS).

• Encriptar y desencriptar cada mensaje.

2. Impacto en la tasa de datos (rendimiento)

Ejemplo: Si sin TLS Mosquitto puede manejar 1000 mensajes por segundo, con TLS puede bajar a 600–800 según el hardware.

3. 🔧 ¿Qué factores influyen más?

• Tipo de cifrado TLS: Algunos algoritmos como AES128-GCM son más rápidos que otros.

• Frecuencia de publicación: Más mensajes → más cifrado → más carga.

• Cantidad de conexiones simultáneas: Cada conexión segura consume CPU/RAM.

• Tamaño del mensaje: Cuanto mayor el payload, más procesamiento de cifrado.

4. 📌 Recomendaciones para reducir el impacto

• Usar certificados válidos pero con claves pequeñas (2048 bits).

• Activar TLS solo en puertos donde realmente se necesita.

• Usar TLS de forma selectiva (por ejemplo, solo para datos sensibles).

• Utilizar Mosquitto con soporte de hardware acelerado (Raspberry Pi 4 o mejor, o servidores con soporte de OpenSSL rápido).

• Configurar max_inflight_messages y message_size_limit con cuidado.

5. 🧪 ¿Cómo medir el impacto real?

Podés hacer pruebas comparativas con herramientas como:

# Sin TLS
mosquitto_pub -h 192.168.1.100 -t test -m "hola" -c -q 0

# Con TLS
mosquitto_pub -h 192.168.1.100 --cafile ca.crt --cert client.crt --key client.key -p 8883 -t test -m "hola" -c -q 0

Y luego usar htop o mosquitto -v para medir consumo de CPU y latencia.

Con esa base te propongo una implementación de ejemplo para una red IoT híbrida (física + simulada) utilizando:

🧩 Arquitectura Propuesta

🔧 Componentes

🔁 Flujo General

1. Broker MQTT local recibe datos de:

   • ESP32 conectados por WiFi.

   • Notebooks simulando nodos.

2. El broker reenvía los datos a:

   • ThingsBoard Cloud (via MQTT).

   • ThingSpeak (via HTTP POST).

3. Las plataformas visualizan los datos y gestionan alertas.

🧪 Ejemplo de práctica por partes

📘 Parte 1: Nodos Simulados en Notebooks

• Instalar paho-mqtt:

  pip install paho-mqtt

• Script Python (nodo virtual):

  import paho.mqtt.client as mqtt
  import time, random
  
  broker = "192.168.0.100"  # IP del Mosquitto
  client = mqtt.Client("NodoVirtual1")
  client.connect(broker)
  
  while True:
      temp = round(random.uniform(20, 30), 2)
      hum = round(random.uniform(30, 60), 2)
      payload = f'{{"temperature": {temp}, "humidity": {hum}}}'
      client.publish("iot/sensor1", payload)
      time.sleep(10)
  

📗 Parte 2: ESP32 con sensores reales

• Usar MicroPython o Arduino IDE.

• Publicar en el mismo broker Mosquitto local.

• Enviar payload JSON como en el nodo simulado.

• Sensores:

  • DHT11 → temperatura y humedad.

  • BMP280 → temperatura, presión.

📙 Parte 3: Integrar con ThingsBoard

• Crear dispositivo en ThingsBoard Cloud.

• Obtener token de acceso.

• Conectar desde ESP32 o Python al host MQTT:

  mqtt.thingsboard.cloud
  

• Publicar en tópico:

  v1/devices/me/telemetry

• Payload:

  {"temperature":25.6,"humidity":58}

📒 Parte 4: Integrar con ThingSpeak

• Crear canal, obtener API Key.

• Enviar datos vía HTTP GET o POST desde Python:

  import requests
  
  API_KEY = "TU_API_KEY"
  url = f"https://api.thingspeak.com/update?api_key={API_KEY}&field1=25.6&field2=58"
  requests.get(url)
  

✅ Objetivos para la clase

1. Simular una red con nodos físicos y virtuales.

2. Visualizar datos en dos plataformas (ThingsBoard + ThingSpeak).

3. Configurar una alerta en ThingsBoard (ej.: temperatura > 28 °C).

4. Analizar rendimiento de Mosquitto (cantidad de conexiones, frecuencia, tamaño de mensajes).