MQTT: en åben netværksprotokol og dens betydning i IoT

Husk navnet MQTT, da det er en netværkskommunikationsprotokol type M2M (Machine to Machine), der kommer til at lyde ganske lidt. Det bliver ganske populært takket være den nye æra af tingenes internet eller IoT (tingenes internet) for dets forkortelse på engelsk. Derudover er det en åben protokol, som giver mange fordele.

Faktisk er det blevet en af ​​de centrale søjler i IoT, da det er ret godt på enheder med nogle transmissionsbegrænsninger som disse. Forkortelsen MQTT kommer fra Meddelelseskø telemetri transport, en åben standard fra OASIS og ISO (ISO / IEC 20922) til netværkskommunikation, og som generelt kører på den berømte TCP / IP.

Netværksprotokoller

masse kommunikationsprotokoller De er regler, der tillader to eller flere enheder eller systemer at kommunikere med hinanden. Det vil sige, det er en protokol til at transmittere information på forskellige måder og med et defineret format, hvad enten det er implementeret af software og hardware (eller begge dele).

El standard i protokollen definerer en lang række kommunikationsegenskaber. Det kan gå fra reglerne for synkronisering, semantik, syntaks, pakkeformat osv. Og sandheden er, at de ikke er noget ubetydelige, da vi takket være disse protokoller i dag kan bruge internettet og andre kommunikationsnetværk ...

Og selvfølgelig er der ikke kun en protokol, men mange. For eksempel, den kendte DNS, FTP, MQTT, HTTP og HTTPS, IMAP, LDAP, NTP, DHCP, SSH, Telnet, SNMP, SMTP osv. Til applikationslaget. Mens du er i transportlaget kan du finde nogle så berømte som TCP, UDP osv. Såvel som dem fra internetlaget som IPv4 eller IPv6 (hvilket har muliggjort det største antal tilgængelige IP'er og ankomsten af ​​IoT ), IPSec osv. Og andre fra linklaget, såsom DSL, Ethernet, WiFi, ARP osv.

Om IoT-protokoller

Der er selvfølgelig specifikke kommunikationsprotokoller, eller som kan anvendes på IoT. Det vil sige i betragtning af det foregående afsnit ville de være en række definerede standarder, så to eller flere IoT-enheder kan kommunikere og forstå hinanden, og de er generelt M2M, det vil sige maskine til maskinkommunikation. mange IoT-enheder tilsluttet og deler information fra sensorer eller andre kilder.

På grund af det store antal IoT-enheder skal disse protokoller opfylde krav ud over begrænsningerne for båndbredde, hastighed osv. (bemærk, at mange enheder er indlejrede og billige), som normalt findes i nogle enheder. Og jeg mener det faktum skal være skalerbar, for at kunne tilføje flere tilsluttede enheder, hvis det er nødvendigt og uden at påvirke det globale system.

De skal også have en lav afhængighed kobling mellem enheder, så der ikke genereres problemer, hvis en enhed fjernes. Og selvfølgelig søges der høj interoperabilitet, så det fungerer med et stort antal meget forskellige enheder og systemer, da IoT-verdenen er ret heterogen.

Andre nyttige funktioner er nemme at implementere dem, sikkerhed, etc. Husk, at IoT skaber store udfordringer i sikkerhedsaspektet. Endnu mere, når mange af de tilsluttede enheder normalt er kritiske i visse tilfælde ... for eksempel legetøj til mindreårige.

Vigtige begreber

Når det er sagt, skal det siges, at løsninger til IoT bruger en central server til at modtage meddelelserne fra alle de tilsluttede enheder, der udsender, og distribuere dem til alle de tilsluttede IoT-enheder, der lytter. Denne server er det, der er kendt som router eller mægler. Noget der på nogle måder er langt fra det konventionelle klient-server-forhold.

Endvidere metoderne som du kan finde i disse kommunikationsprotokoller til IoT er:

• PubSub: Publish / Susbcribe er et meddelelsesmønster, hvor en enhed (Sub) informerer mægleren om, at den ønsker at modtage en besked, mens en anden enhed (Pub) offentliggør beskeder, som mægleren distribuerer til den / de andre enheder, der venter på dem.
• rRPC: Router Remoder Procedure Calls er et andet mønster for ekstern procesudførelse. I den informerer en enhed (Callee) mægleren om, at den vil udføre en bestemt procedure, og mægleren distribuerer den til en anden enhed (Caller), som processen udføres på.

Nu for at udføre disse metoder eller mønstre, a meddelelsesinfrastruktur. Og i denne forstand kan man skelne mellem to:

• Meddelelseskø: messaging-tjeneste, hvor der genereres en enkelt meddelelseskø til alle klienter, der starter et abonnement på mægleren. Sidstnævnte gemmer meddelelserne, indtil de leveres til klienten. Hvis klienten eller modtageren ikke er forbundet, opretholdes den, indtil den er tilsluttet. Disse typer tjenester er som dem, der bruges i instant messaging-apps som Telegra, WhatsApp, Messenger osv.
• Meddelelsestjeneste: det er en anden tjeneste, hvor mægleren sender beskederne til den tilsluttede modtagerklient, filtreret efter typen af ​​besked. Hvis klienten eller modtagerenheden er afbrudt, går beskederne tabt (selvom det muligvis har noget logningssystem).

IoT-protokoller

Efter at have set ovenstående, lad os nu se nærmere på det IoT-protokoller der er bedre kendt. Blandt de mest fremtrædende af M2M er:

• AMQP (Advanced Message Queuing Protocol): er en PubSub-protokol af Message Queue. Designet til at have god interoperabilitet og sikre pålidelighed. Specielt til virksomhedsapplikationer, høj ydeevne, netværk med høj latens, kritiske osv.
• WAMP (Web Application Messaging Protocol): er en anden åben PubSub-type protokol som rRPC, og den kører på WebSockets.
• CoAP (begrænset applikationsprotokol): er en protokol, der er specielt designet til applikationer med lav kapacitet.
• TOMP (Streaming Text Oriented Messaging Protocol): meget enkel protokol og for at opnå maksimal interoperabilitet. HTTP bruges til at overføre tekstbeskeder.
• XMPP (eXtensible Messaging and Presence Protocol): en anden protokol, der bruges i IoT til instant messaging-apps og baseret på XML. Jan denne sag er også åben.
• WMQ (WebSphere Message Queuing): protokol udviklet af IBM. Det er af typen Message Queue, som navnet antyder, og er beskedorienteret.
• MQTT: (se næste afsnit)

Alt om MQTT

El MQTT-protokol Det er en meddelelseskø kommunikationsprotokol, der følger et PubSub-mønster og af M2M-typen, som jeg allerede har nævnt. Det bruges i vid udstrækning i IoT og er baseret på TCP / IP-stakken, der bruges på Internettet.

I tilfælde af MQTT, enhver forbindelse holdes åben og det genbruges i al nødvendig kommunikation. Noget andet end hvad der sker i andre kendte protokoller, at hver kommunikation finder sted, kræver en ny forbindelse.

Advantage

Fordelene ved MQTT-protokollen er meget tydelige med hensyn til M2M-kommunikation til IoT. Ud over alt sagt ovenfor er det en protokol, der giver:

• Skalerbarhed for at forbinde flere og flere kunder.
• Afkobling mellem klienter for mindre afhængighed.
• Asynkronisme.
• Enkelhed.
• Let for ikke at forbruge for mange ressourcer (selvom det med TLS / SSL-sikkerhed går op).
• Energieffektivt til enheder, der er afhængige af batteri eller fungerer 24/7, det har ikke brug for stor båndbredde (ideel til langsomme forbindelser, som f.eks. Nogle trådløse).
• Sikkerhed og kvalitet for større pålidelighed og robusthed i kommunikationen.

historie

MQTT blev oprettet i 90'erne med en tidlig version af protokol i 1999. Det blev oprettet af Dr. Andy Stanford-Clark fra IBM og Arlen Nipper fra Cirrus Link (tidligere Eurotech).

La indledende idé var at oprette en protokol til overvågning af en rørledning, der rejste gennem ørkenen, med en effektiv kommunikationsprotokol (lav båndbreddeforbrug), lys og at et lavt energiforbrug. På det tidspunkt var det meget dyrt, men nu er det blevet en billig og åben protokol.

Den oprindelige protokol blev forbedret med udseendet af nye versioner, såsom MQTT v3.1 (2013) under OASIS-specifikationen (Organisation for fremme af strukturerede informationsstandarder) osv. Du burde vide, at det i starten var en proprietær IBM-protokol, men at den ville blive frigivet i 2010, og det endte med at blive en standard i OASIS ...

Sådan fungerer MQTT-forbindelsen

MQTT-protokollen bruger et filter, for de meddelelser, der sendes til hver klient, baseret på emner eller emner, der er organiseret hierarkisk. På denne måde kan en kunde sende en besked om et bestemt emne. På denne måde modtager alle de klienter eller tilsluttede enheder, der abonnerer på emnet, beskeder via mægleren.

Som det er MQ, meddelelser forbliver i køen og de går ikke tabt, før klienten har modtaget denne besked.

Forbindelserne, som jeg også antydede, er oprettet via TCP / IP, og serveren eller mægleren vil registrere de tilsluttede klienter. Enhederne bruger som standard kommunikationsporte nummer 1883, selvom du muligvis også støder på port 8883, hvis du bruger SSL / TLS for ekstra sikkerhed.

For at forbindelsen er mulig, er der ikke kun behov for klienter, servere og porte. Også andre pakker eller beskeder sendt for kommunikation at finde sted:

• Opret forbindelse: CONNECT besked / pakke sendt af klienten med alle de nødvendige oplysninger. Disse oplysninger inkluderer kunde-id, brugernavn, adgangskode osv. Mægleren eller serveren reagerer med en CONNACK-pakke, der informerer klienten om, at forbindelsen blev accepteret, afvist osv.
• Send og modtag beskeder: når forbindelsen er oprettet, bruges PUBLICER pakker eller meddelelser med emnet og nyttelasten af ​​meddelelsen sendt til mægleren. På den anden side bruger den eller de interesserede klienter SUBSCRIBE- og UNSUSCRIBE-pakker til at abonnere eller trække deres abonnement tilbage. Mægleren vil også svare med henholdsvis en SUBACK- og UNSUBACK-pakke for at rapportere om succesen af ​​den operation, som klienten har anmodet om.
• Vedligeholdelse af forbindelsen: for at garantere, at forbindelsen forbliver åben, kan klienter periodisk sende en PINGREQ-pakke, der matches med en PINGRESP-pakke fra serveren.
• Afslut forbindelse: når en klient afbryder forbindelsen, sender den en DISCONNECT-pakke for at rapportere hændelsen.

De der beskeder eller pakker Dem, jeg har talt om, har en struktur, der er den samme som andre pakker med andre netværksprotokoller:

• Header eller fast header: er en fast del, der optager mellem 2-5 byte. Den indeholder en kontrolkode, ID for den sendte beskedstype og dens længde. Mellem 1-4 bytes bruges til at kode længden ved hjælp af de første 7 bits i hver oktet som data for længden og en ekstra kontinuitetsbit for at bestemme, at der er mere end en byte, der udgør meddelelsens længde.
• Variabel overskrift: er ikke altid obligatorisk, men valgfri. Det er kun indeholdt i nogle pakker i visse situationer eller specifikke meddelelser.
• Indhold eller data: pakkedataene er det, der rent faktisk indeholder den besked, der skal sendes. Det kan være fra nogle få kB til en 256 MB grænse.

Hvis du er interesseret i at vide den tilsvarende kode i hexadecimal for de typer meddelelser, der sendes, er:

Kvalitet og sikkerhed for kommunikation

En anden vigtig detalje i meddelelserne fra MQTT er servicekvalitet eller QoSog sikkerhed. Kommunikationssystemets robusthed i tilfælde af fejl og dets sikkerhed afhænger af dette.

Med hensyn til kvaliteten kan det bestemmes 3 forskellige niveauer:

• QoS 0 (ikke-kendskab)- Meddelelsen sendes kun en gang, og i tilfælde af fejl vil den ikke blive leveret. Det bruges, når det ikke er kritisk.
• QoS 1 (anerkend): meddelelsen sendes så mange gange som nødvendigt for at garantere levering til kunden. Ulempen er, at klienten kunne modtage den samme besked flere gange.
• QoS 2 (sikret)- Svarende til ovenstående, men leveres kun én gang. Det bruges ofte til mere kritiske systemer, hvor der er behov for større pålidelighed.

På den anden side, hvad angår MQTT-sikkerhed, kan forskellige foranstaltninger anvendes til at sikre dets styrke i denne henseende. Som jeg allerede har kommenteret før, kan godkendelse af brugeren og adgangskoden, som mange andre protokoller, sikres ved hjælp af SSL / TLS. Selvom mange IoT-enheder med lav kapacitet eller ressourcer kan have problemer med overbelastning af arbejde, når de bruger denne type sikker kommunikation ...

Af denne grund bruger mange IoT-enheder, der bruger MQTT, adgangskoder og brugere i flytekst, hvilket kunne få nogen til at snuse netværkstrafik for at få dem meget let. Og hvis det ikke er nok, kan mægleren også konfigureres til at acceptere anonyme forbindelser, hvilket gør det muligt for enhver bruger at etablere kommunikation med større risiko.

Brug af MQTT med Arduino

Selvfølgelig kan du brug MQTT-protokollen med Arduino og andre udviklingskort såvel som Rapsberry Pi osv. For at gøre dette skal du give dit Arduino-kort forbindelse, hvis det ikke har det. Også biblioteket Arduino-klient til MQTT det vil hjælpe dig i disse opgaver. Dette bibliotek er kompatibelt med:

• ArduinoYUN
• Arduino WiFi (skjold)
• Arduino Ethernet (skjold)
• ESP8266-modul
• Intel Galileo / Edison
• Raspberry Pi
• ...

Så snart til koden for at bruge MQTT i en eller anden applikation er sandheden, at det er simpelt. På Fritzing-billedet kan du se en plak Arduino UNO til hvilken forbindelse via Arduino Ethernet er blevet tilføjet, og den er også blevet tilsluttet en DHT22 fugtigheds- og temperaturføler, selvom det kunne have været noget andet ...

Okay, når det er sagt, for den kode, du skal generere i Arduino IDE At arbejde med MQTT-protokollen på Arduino er det så simpelt:

• til sende beskeder MQTT

#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>
#include <DHT.h>

#define DHTPIN 2
#define DHTTYPE DHT22

// Direccion MAC del adaptador Ethernet
byte mac[] = { 0xCE, 0xAB, 0x0E, 0x3F, 0xFE, 0xD4 };

// IP del servidor (broker)
IPAddress mqtt_server(192, 168, 1, 4);

// Topic o tema con el que se trabaja
const char* topicName = "test";

DHT dht(DHTPIN, DHTTYPE);
EthernetClient ethClient;
PubSubClient client(ethClient);

void setup()
{
  Serial.begin(9600);
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Fallo en Ethernet usando DHCP");
  }
// Puerto 1883 de comunicación
  client.setServer(mqtt_server, 1883);
  dht.begin();
}

void loop()
{
  if (!client.connected()) {
    Serial.print("Conectando ...\n");
    client.connect("Cliente Arduino");
  }
  else {
    // Envío de informacion del sensor de temperatura y humedad
    float temp = dht.readTemperature();
    char buffer[10];
    dtostrf(temp,0, 0, buffer);
    client.publish(topicName, buffer);
  }
  // Tiempo entre envíos en ms (cada 10 segundos)
  delay(10000);
}

• til modtage beskeder af MQTT behøver du kun pladen Arduino UNO og forbindelse med Arduino Ethernet eller ethvert andet element. Med hensyn til koden vil et eksempel være:

#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>

// Direccion MAC del adaptador Ethernet
byte mac[] = { 0xCE, 0xAB, 0x0E, 0x3F, 0xFE, 0xD4 };

// IP del servidor (broker)
IPAddress mqtt_server(192, 168, 1, 4);

// Topic o tema con el que trabajr
const char* topicName = "test";

EthernetClient ethClient;
PubSubClient client(ethClient);

void callback(char* topic, byte* payload, unsigned int length) {
  Serial.print("El mensaje ha llegado [");
  Serial.print(topic);
  Serial.print("] ");
  int i=0;
  for (i=0;i<length;i++) {
    Serial.print((char)payload[i]);
  }
  Serial.println();
}

void setup()
{
  Serial.begin(9600);
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Fallo en Ethernet al usar configuración DHCP");
  }
  client.setServer(mqtt_server, 1883);
  client.setCallback(callback)
}

void loop()
{
  if (!client.connected()) {
      Serial.print("Conectando ...");
      if (client.connect("rece_arduino")) {
        Serial.println("conectado");
        client.subscribe(topicName);
      } else {
        delay(10000);
      }
  }
  // Cliente a la escucha
  client.loop();
}

For mere information kan du download gratis Nuestro PDF-vejledning med Arduino IDE-kurset for at starte programmeringen.