Controlar un robot con MQTT - [Parte 1]

La mayoría de los artículos del blog tratan sobre controles o regulaciones más simples que maneja un microcontrolador. Pero los dispositivos IoT, abreviatura de Internet de las cosas, pueden hacer mucho más. La base para ello la proporcionan los protocolos que garantizan la comunicación a los dispositivos individuales, como el MQTT utilizado aquí. Esta primera entrada de la serie de blogs sobre MQTT enseña los fundamentos. Al final de la serie de blogs, se controla un pequeño robot utilizando MQTT, de forma similar a un mando a distancia.

Requisito previo

Para esta entrada en el blog sólo se necesitan unos pocos componentes, ver Tabla 1.

Número	Componente
1	Raspberry Pi
1	Fuente de alimentación a juego

Tabla 1: Hardware necesario

Con la Pi, ten en cuenta que además del hardware mencionado anteriormente, también necesitarás una tarjeta microSD. Para ello deberás instalar Raspberry Pi OS (antes Raspbian) como imagen en la tarjeta.

Note en este punto

Este tutorial cubre MQTT y cómo configurar tu propio broker y clientes MQTT. Por lo tanto, sólo para esta parte se necesita una Raspberry Pi para seguir y copiar todos los pasos que se muestran aquí. En las siguientes partes de la serie del blog se integrarán más clientes, como la placa de microcontroladores compatible con Arduino Uno R3 y NodeMCU.

¿Qué es MQTT?

MQTT es la abreviatura de Message Queuing Telemetry Transport (transporte de telemetría por colas de mensajes) y también se conoce con el antiguo nombre de WebSphere MQTT, WSMQTT para abreviar. Se trata de un protocolo de red abierto para la comunicación entre máquinas, por ejemplo, para transmitir datos de sensores y/o controlar actuadores. El trasfondo de este protocolo es que se puede garantizar la transmisión de información incluso en las llamadas redes inestables. El término "redes inestables" tiene su origen en la época en que las redes eran todavía muy susceptibles a las interferencias.

MQTT, si está instalado por defecto, es accesible a través del puerto de red 1883. El segundo puerto, el 8883, es el puerto de red seguro, pero debe estar cifrado mediante el protocolo TLS. Para utilizar MQTT, se necesita un servidor MQTT, el llamado broker, así como los correspondientes dispositivos finales que envían o reciben los datos, también llamados clientes. Normalmente el broker se encuentra en un sistema operativo basado en Linux. Sin embargo, también es posible utilizar sistemas operativos Windows. Mientras tanto, MQTT se puede encontrar en la tecnología de automatización y en los proyectos de IoT, ya que es relativamente fácil configurar una red MQTT con pocos recursos.

La versión 3.1.1 del protocolo utilizada aquí, así como la versión 3.1 anterior, fueron publicadas en 2010 bajo una licencia libre, que fue especificada por el comité de estandarización de OASIS. Por lo tanto, esta versión del protocolo ya tiene más de 10 años en el momento de la publicación del blog. La última versión del protocolo 5.0 fue publicada en 2019 y al mismo tiempo especificada por el comité de estandarización OASIS.

¿Cómo funciona MQTT?

MQTT utiliza la arquitectura de publicación/suscripción basada en eventos. No existe una conexión de extremo a extremo, como por ejemplo en una página web, sino un servidor, el llamado broker, al que se conectan emisores y receptores, los llamados clientes. Para entender mejor estas conexiones, la figura 1 lo ilustra de forma simplificada.

Figura 1: Ilustración de la arquitectura MQTT

Un cliente, en este caso el sensor, el dispositivo móvil o el dispositivo IoT, siempre puede enviar y/o recibir datos; el broker simplemente sirve como un buffer de información que reenvía los datos a otros clientes. Para que el cliente reciba un mensaje correspondiente del corredor, debe suscribirse a los llamados temas cuando se establece la conexión o durante el funcionamiento en el corredor.

Puede pensar en un tema como una especie de URL (Localizador Uniforme de Recursos) que refleja el contenido deseado. Un tema para un sensor de temperatura en el salón podría publicar los valores medidos en Casa/Piso/Salón/Temperatura. Para que quede claro, no se trata de una dirección del sensor, sino que permite acceder a los últimos datos transmitidos del sensor. Cuando se actualiza la lectura, el broker comprueba qué cliente se ha suscrito para recibir esta información y la reenvía.

Intercambio de datos con el broker

Como se mencionó al principio, MQTT fue concebido para conexiones inestables, por lo que existen tres calidades de servicio diferentes, Calidad de Servicio o QoS. Con el nivel 1 o QoS = 0, el mensaje se envía exactamente una vez. Un acuse de recibo, como es el caso de la otra QoS, es completamente ignorado. Sólo la publicación, la llamada PUBLISH, es importante.

Con QoS = 1, también se habla de "entregado al menos una vez", lo que significa que el emisor espera un acuse de recibo del receptor. Este acuse de recibo se denomina PUBACK y es obligatorio para la estación remota; en caso contrario, el emisor transmite hasta que recibe un acuse de recibo. Esto hace que un mensaje se transmita varias veces al receptor.

QoS = 2 es la combinación de QoS = 0 y QoS = 1, por lo que también representa la transmisión más lenta. Aquí el mensaje se envía exactamente una sola vez. Para ello, es necesario un acuse de recibo en dos fases.

En primer lugar, el emisor envía (PUBLISH) su mensaje al destinatario, que acepta el mensaje y envía un mensaje de confirmación (PUBREC), con el contenido del emisor adjunto como copia. Si este mensaje de confirmación (PUBREC) es recibido por el emisor, éste guarda la información y responde también con un mensaje de confirmación (PUBREL).

Finalmente, cuando el destinatario ha recibido el PUBREL, este envía el último mensaje de confirmación (PUBCOMP). Al final de dicha transferencia de datos, se asegura que el mensaje ha llegado realmente. Para que sea más comprensible, muestra Figura 2 una vez más, de forma esquemática, cómo se ve el flujo de mensajes con las tres variantes de QoS.

Figura 2: Descripción general de QoS de MQTT

Suscribirse a los datos del broker

Ahora se plantea la cuestión de cómo puede un cliente consultar ahora los datos de los sensores. De nuevo hay varias variantes que pueden llevar al objetivo. En la primera variante, como ya se mostró anteriormente para la simple transferencia de datos del sensor, se puede especificar el tema completamente. Para ello, basta con introducir el tema Casa/Piso/Salón/Temperatura. Sin embargo, entonces sólo recibirá exactamente este valor.

Cuando se usa la variante dos, entra en juego el operador +. Por En casa / + / + / temperatura recibirá los datos de temperatura de todas las habitaciones de cada piso. Esto es útil si especifica una estructura de este tipo para todos los sensores de su casa y desea mostrarla de forma agrupada, por ejemplo.

La variante tres va un paso más allá con el operador #. Mediante Home / Planta Baja / # se obtiene toda la información disponible para cada habitación de la planta baja. Dependiendo de la cantidad de información, un montón puede venir juntos en este punto.

El cuarto y último caso es probablemente la suscripción a temas con mayor uso de datos, siempre que transmita grandes cantidades de datos. Con / # se suscribe al directorio raíz y se le enviarán todos los cambios. ¡Específicamente no recomiendo esta variante en este momento! Debe pensar de antemano cómo se verá y determinará de antemano su estructura o los datos de medición que desea registrar.

Por último, probablemente surja la pregunta: ¿qué ocurre si un transmisor deja de transmitir repentinamente? Para ello, existe el llamado mensaje retenido en MQTT, que contiene la última voluntad. Para poder utilizarlo, el emisor, en nuestro caso un sensor, debe proporcionar este mensaje retenido al conectarse al broker. Esto almacena lo que se enviará si el remitente ya no puede ser alcanzado. El broker puede entonces escribir un contenido individual para cada tema. Dado que MQTT ya proporciona monitorización por defecto, no hay que preocuparse por este punto. Ya que se profundiza demasiado en el asunto, puedo dar en este punto sin embargo con gusto la palabra clave mensaje LWT, con la que encontrará suficiente material de lectura en Internet.

La Raspberry Pi se convierte en broker

Como se menciona en la sección "¿Qué es MQTT?", Este protocolo es muy popular en la escena de IoT. Muchos evitan usar sus datos o datos personales para controlar su hogar en Internet, por ejemplo mqtt-dashboard.com/ salvar. Por lo tanto, tiene sentido configurar un pequeño corredor local con Raspberry Pi. Al principio, no importa qué versión de Raspberry Pi esté utilizando y si ya está asumiendo alguna tarea.

En primer lugar, abra el terminal de su Raspberry Pi, consulte figura 3 y luego emitir los comandos Codigo 1 a.

Figura 3: Terminal abierto en Pi

sudo apt upgrade

sudo apt dist-upgrade

Código 1: actualiza Raspbian

Con esto actualizas la Raspberry Pi y todos los paquetes instalados. A continuación, emite el comando Code 2 a. Esto cargará el popular broker mosquitto y la aplicación cliente en tu Raspberry Pi. Confirma la instalación en el terminal en el punto apropiado.

sudo apt install mosquitto mosquitto clients

Código 2: instalar el servidor y el cliente Mosquitto

Utilice el comando para que el intermediario también se inicie inmediatamente después de un reinicio Codigo 3.

sudo systemctl enable mosquitto.service

Código 3: inicia el servicio mosquitto cuando se reinicia el Pi

Dado que es posible que el demonio aún no se ejecute en la Pi, inícielo con el comando Codigo 4.

sudo mosquitto -d

Código 4: iniciar mosquitto

A partir de este punto has configurado un broker MQTT local y sin cifrar en tu red doméstica. Si no ha configurado el reenvío de puertos a la Raspberry Pi a través de su router, esto no puede ser alcanzado en Internet. Pero debería ser suficiente para el uso privado. Para que el broker siga siendo accesible desde la Pi después de un reinicio, debe asignar a la Raspberry Pi una dirección IP fija a través del router.

Envía y recibe datos al broker

Ahora es el momento de poner en práctica la teoría y enviar mensajes al broker y también recibir mensajes del broker. Para ello se necesitan los comandos de terminal "mosquitto_sub" para la función de suscripción y "mosquitto_pub" para la función de publicación de mensajes.

El comando de terminal "mosquitto_sub" se iniciará, y los comandos más importantes se explican a continuación. Si quieres ir más allá de los comandos mostrados aquí, recomiendo el manual de Linux suministrado internamente en este punto, que puedes llamar en el terminal con el comando "man mosquitto_sub", "man mosquitto_pub" o "man mosquitto". El comando de Linux "man" significa "manual", en alemán "manual" o "manual".

Use el comando para ver en detalle qué está procesando el suscriptor de mosquitto en segundo plano y también para recibir todos los mensajes Código 5.

mosquitto_sub -d -q 2 -t / #

Código 5: Deje que los suscriptores de Mosquitto escuchen los nodos raíz

El que se muestra aquí Código 5 usa las opciones Tabla 2.

Opción	Explicación
-re	Activa el modo de depuración y muestra toda la información útil.
-q	Especifica qué QoS debe comunicarse el suscriptor con el corredor. QoS 2 se usa en el Código 5.
-t	Especifica a qué tema se suscribirá el suscriptor. En Code 5, el suscriptor se suscribe a todos los temas.

Tabla 2: Opciones del suscriptor de mosquitto

Tengo el comando Código 5 se ingresa, la salida primero indicará la conexión exitosa con el corredor, consulte Figura 4 Marca 1.

Figura 4: Salida de terminal de moquitto_sub

En el marcador 1 de la Figura 4 se puede ver que se está estableciendo una conexión y que la estación remota, el broker, ha aceptado la conexión. Inmediatamente después, el suscriptor transmite a qué tema se va a suscribir, aquí "/ #", y qué QoS ha solicitado, aquí "QoS: 2". Por último, la solicitud de suscripción se realiza mediante SUBACK, el acuse de recibo de la suscripción, aceptado. Se establece la conexión con el broker y se suscribe el tema deseado. 

Marca 2 de Figura 4 aparecerá en su terminal después de un tiempo. Como se describe en "Cómo funciona MQTT", esta es la consulta de si el suscriptor todavía está en línea. El corredor pregunta si el suscriptor todavía está en línea, el llamado Silbido Reqinvitado. Normalmente, el cliente envía la respuesta correspondiente, la denominada Silbido Response, a la ruptura.

El siguiente paso, ahora que tenemos un suscriptor, es usar un editor para enviar datos al corredor. El primer mensaje debería ser, por supuesto, "Hello World". El editor envía esta pequeña oración al topic / test / testpub.

Para hacer esto, abra una segunda ventana de terminal y emita el comando en consecuencia Código 6 a . 

mosquitto_pub -d -q 2 -t / test / testpub -m "Hello world"

Código 6: mosquitto_pub "Hello World"

Las opciones utilizadas para Código 6 estan en Tabla 3 enumerados.

Opción	Explicación
-re	Activa el modo de depuración y muestra toda la información útil.
-q	Especifica qué QoS debe comunicarse el editor con el corredor. QoS 2 se usa en el Código 6.
-t	Especifica el tema al que se deben enviar los datos, aquí / test / testpub
-metro	Envía el siguiente mensaje, aquí "Hello World"

Tabla 3: Opciones de la editorial mosquitto

Echemos un vistazo a los datos que se transmiten, consulte Figura 5 Marque 1, enviado al corredor. Como antes, se seleccionó QoS 2 en las opciones, por lo que también puede ver el flujo de comunicación correspondiente.

Figura 5: Salida de terminal de moquitto_pub y mosquitto_sub

Inmediatamente después, el corredor envía el nuevo mensaje al suscriptor, véase la Figura 5 Marca 2, porque se ha suscrito a todos los temas. En el borde superior del marcador 2 de la Figura 5 se puede ver que se han recibido nuevos datos en el tema / test / testpub. El handshake de QoS 2 se muestra directamente detrás, con el mensaje "Hello world" recibido.

Ahora ha aprendido los conceptos básicos de MQTT y los antecedentes técnicos de MQTT. Siéntase libre de jugar con los comandos una vez y enviar datos al corredor y, si es necesario, abrir otros terminales que se suscriban a otros temas.

En la siguiente parte de la serie de blogs, conectará un microcontrolador Arduino o ESP32 al MQTT y enviará datos, y la estación remota reaccionará en consecuencia.

Este y otros proyectos se pueden encontrar en GitHub en https://github.com/M3taKn1ght/Blog-Repo