Last month, we took a brief look at MQTT.
Le mois dernier, nous avons jeté un bref coup d'œil sur MQTT.
This month, we'll continue our discussion of MQTT, especially how MQTT can support quality of service and then we'll modify our original program from Full Circle issue #109 to support MQTT.
Ce mois-ci, nous poursuivrons notre discussion sur MQTT, en particulier sur la façon dont MQTT peut assurer la bonne qualité d'un service, puis nous modifierons notre programme original du numéro 109 du Full Circle pour supporter MQTT.
QoS QoS stands for Quality of Service. MQTT supports three levels, numbered 0, 1 and 2. If you don't have to be sure that those who are subscribed to your topic messages, then you simply use a QoS of 0. Here is a breakdown of the levels: 0 - At most once 1 - At Least once 2 - Exactly once
QoS
QoS signifie Qualité de service. MQTT supporte trois niveaux, numérotés 0, 1 et 2. Si vous ne devez pas être certain de savoir ceux qui sont abonnés à vos messages thématiques, alors vous utilisez simplement une QoS de 0. Voici une description des niveaux :
0 - Au plus une fois. 1 - Au moins une fois. 2 - Exactement une fois.
When the broker transfers a message to a subscribing client, it uses the QoS of the subscription made by the receiving client
Lorsque l'intermédiaire/serveur (le « broker ») transfère un message à un client abonné, il utilise la QoS de l'abonnement effectué par le client destinataire.
Level 0 Level 0 guarantees a best effort delivery. The message won't be acknowledged by the receiver (broker or client), nor will it be stored and re-delivered by the sender. Level 1 Using Level 1 is guaranteed that a message will be delivered at least once to the receiver (publisher to broker or broker to subscriber). The sender stores the message until it receives a PUBACK message from the receiver. Note that the message can be sent multiple times to the receiver until the PUBACK is sent back to the sender. Level 2 As you can see from the diagram, the client sends a publish message to the broker and the broker sends back a PUBREC. The sender then stores a reference to the packet identifier, which is then stored and then sends out a PUBREL message. If the receiver responds with a PUBCOMP message, the sender then knows it can safely discard the message and reference. If a message gets lost somewhere along the way, the sender (either the publishing client or the broker) is responsible for re-sending the last message.
Niveau 0
Le niveau 0 fournit la meilleure garantie de livraison. Le message ne fera pas l'objet d'un accusé de réception par le destinataire (l'intermédiaire ou le client), et il ne sera pas non plus stocké et renvoyé par l'expéditeur.
Niveau 1
L'utilisation du niveau 1 garantit qu'un message sera livré au moins une fois au destinataire (de l'éditeur à l'intermédiaire et de l'intermédiaire à l'abonné). L'expéditeur stocke le message jusqu'à ce qu'il reçoive un message PUBACK du destinataire. Notez que le message peut être envoyé plusieurs fois au destinataire jusqu'à ce que le PUBACK soit renvoyé à l'expéditeur.
Niveau 2
Comme vous pouvez le voir sur le diagramme, le client envoie un message de publication à l'intermédiaire et l'intermédiaire renvoie un PUBREC. L'expéditeur stocke ensuite une référence à l'identificateur de paquet, qui est alors stocké, et envoie un message PUBREL. Si le destinataire répond avec un message PUBCOMP, l'expéditeur sait alors qu'il peut jeter le message et la référence en toute sécurité. Si un message se perd quelque part en cours de route, l'expéditeur (le client qui publie le message ou l'intermédiaire) est responsable de la réexpédition du dernier message.
Of course, QoS Level 1 is faster than Level 2, since there are only two messages to deal with where Level 2 has four and QoS Level 0 is faster than Level 1. When the broker sends a message to a subscribing client, the QoS used is what the client used when subscribing to the topic. Therefore, the QoS can be downgraded from what the publishing client intends. When should you use one level over another? Basically if your publishing client doesn't need to worry if there might be a missed transmission or two, and your connection to the broker is reliable 24/7, you could pretty much feel safe to use Qos Level 0. If you need to have a guarantee that the published message will get to (or from) the broker with somewhere near complete assurance that the messages will make it through, then use Level 1. If a message absolutely positively must get through, then use Level 2, but remember, nothing in life is 100% perfect, especially when relying on connecting to a broker (on either end) via an external connection to the internet.
Bien sûr, le niveau 1 de QoS est plus rapide que le niveau 2, puisqu'il n'y a que deux messages à traiter quand le niveau 2 en a quatre, et le niveau 0 de QoS est encore plus rapide que le niveau 1.
Lorsque l'intermédiaire envoie un message à un client abonné, la QoS utilisée est celle utilisée par le client lorsqu'il s'abonne au sujet. Par conséquent, la QoS peut être déclassée par rapport à l'intention du client expéditeur.
A quel moment doit-on utiliser un niveau plutôt qu'un autre ? Fondamentalement, si votre client expéditeur n'a pas à s'inquiéter d'une ou deux transmissions manquées, et que votre connexion à l'intermédiaire est fiable 24 heures sur 24 et 7 jours sur 7, vous pourriez vous sentir en sécurité en utilisant le niveau 0 de Qos. Si vous avez besoin de garantir que le message publié parviendra à l'intermédiaire (ou en provenance de celui-ci), avec l'assurance presque totale que les messages passeront, utilisez le niveau 1. Si un message doit passer sans faute, alors utilisez le niveau 2, mais rappelez-vous que rien dans la vie n'est parfait à 100 %, surtout si vous comptez vous connecter à un intermédiaire (de part et d'autre) via une connexion externe vers l'Internet.
We will be using a Qos Level 1 for our communications in our demo, just for practice.
Nous utiliserons le niveau 1 de Qos pour les communications dans notre démo d'entraînement.
The Hardware If you remember the original project we did back in FCM 109, we used a DHT11 connected to our Raspberry Pi. We used the Adafruit DHT22 python library and slightly modified their sample code. I’ve recreated the Fritzing diagram showing the hardware connections… Once you have the hardware all set up, now we have to download and install the library. If you don’t currently have the library, you can find it on GitHub at https://github.com/adafruit/Adafruit_Python_DHT.git . Remember, you have to install the library on the Raspberry Pi. Here are the steps to clone the library from github.
Le matériel
Si vous vous souvenez du projet original réalisé dans le FCM n° 109, nous avons utilisé un DHT11 connecté à notre Raspberry Pi. Nous avons utilisé la bibliothèque DHT22 python d'Adafruit et avons légèrement modifié leur code échantillon.
J'ai recréé le diagramme de Fritzing en montrant les connexions matérielles :
Une fois tout le matériel installé, nous devons télécharger et installer la bibliothèque. Si vous n'avez pas la bibliothèque, vous pouvez la trouver sur GitHub à l'adresse https://github.com/adafruit/Adafruit_Python_DHT.git . Rappelez-vous que vous devez installer la bibliothèque sur le Raspberry Pi. Voici les étapes pour cloner la bibliothèque de github :
- cd /home/pi
- cd Adafruit_Python_DHT
- sudo apt-get update
- sudo apt-get install build-essential python-dev python-openssl
- sudo python setup.py install
The sample code is in the /examples folder, called simpletest.py. Be sure to change the line that defines which pin your sensor is on to match your setup. The original code assumes your are putting the data pin of the sensor on GPIO 23 (line 35). In the setup I present, use GPIO 4. Also be sure to comment out line 31 if you are using a Raspberry Pi instead of a Beaglebone board. Here is our updated code (right, and continuing on to the next page). You can try modifying the original code, or just start over. It’s not that long.
Le code d'exemple se trouve dans le dossier « /examples », appelé simpletest.py. Assurez-vous de changer la ligne qui définit la broche de votre capteur pour qu'elle corresponde à votre configuration. Le code original suppose que vous mettez la broche de données du capteur sur le GPIO 23 (ligne 35). Dans la configuration que je présente, utilisez GPIO 4. Assurez-vous également de commenter la ligne 31 si vous utilisez un Raspberry Pi au lieu d'une carte Beaglebone.
Voici notre code mis à jour (à droite, puis il continue à la page suivante). Vous pouvez essayer de modifier le code original ou simplement recommencer à zéro. Ce n'est pas si long.
In those last lines (next page), we check to make sure that we got data from the sensor, and if so, we create two messages, one containing the humidity value and one containing the temperature value. In the next two lines, we actually publish the messages. Notice that we are using a QoS value of 1 with a retain value of True. This should ensure delivery if the broker is there and if there are any clients listening for our data. Finally, we sleep for 5 seconds and repeat the loop. Feel free to change the sleep value to whatever you wish over 5. The DHT11/22 doesn’t like to be accessed more than about once every 5 seconds. A realistic value would be somewhere between 30 and 60 seconds.
Dans ces dernières lignes (page suivante), nous vérifions que nous avons bien reçu les données du capteur et, si c'est le cas, nous créons deux messages, l'un contenant la valeur d'humidité et l'autre la valeur de température. Dans les deux lignes suivantes, nous publions les messages. Notez que nous utilisons une valeur de QoS de 1 avec une valeur de rétention de type « True ». Cela devrait assurer la livraison si l'intermédiaire est là et s'il y a des clients qui écoutent nos données. Enfin, nous dormons pendant 5 secondes et répétons la boucle. N'hésitez pas à changer la valeur de sommeil si vous souhaitez plus de 5 secondes. Le DHT11/22 n'aime pas qu'on y accède plus d'une fois toutes les 5 secondes environ. Une valeur réaliste se situe entre 30 et 60 secondes.
client.publish(MQTT_PATH1,hmsg,qos=1,retain=True)
client.publish(MQTT_PATH2,tmsg,qos=1,retain=True)
else:
print('Failed to get reading. Try again!')
sleep(5)
Of course, I’m assuming that your broker is running on the same Raspberry Pi. If not, be sure the change the IP address that MQTT_SERVER pointing to. Now you can run your program (be sure the broker is running BEFORE you start the program). Next, run mosquitto_sub on the RPi subscribing to one or both of the topics we set up in our program. You should see a message each time the loop runs.
Bien sûr, je suppose que votre intermédiaire utilise le même Raspberry Pi. Si ce n'est pas le cas, assurez-vous de changer l'adresse IP vers laquelle MQTT_SERVER pointe.
Vous pouvez maintenant exécuter votre programme (assurez-vous que l'intermédiaire est en cours d'exécution AVANT de démarrer le programme). Ensuite, lancez mosquitto_sub sur le RPi en souscrivant à l'un ou aux deux sujets que nous avons mis en place dans notre programme. Vous devriez voir un message à chaque fois que la boucle s'exécute.
I’ve put our new program on Pastebin at https://pastebin.com/gqPLNsiw, just in case you don’t want to do all the typing. Next month, our project will be a GUI subscriber client to monitor our sensors. This client can be either on the RPi or on another computer on your network. In fact, if you use a public broker, you can monitor it from anywhere in the world. Until then, have a great month.
J'ai mis notre nouveau programme sur Pastebin à https://pastebin.com/gqPLNsiw, juste au cas où vous ne voudriez pas faire toute la dactylographie.
Le mois prochain, notre projet sera un client abonné GUI pour surveiller nos capteurs. Ce client peut être sur le RPi ou sur un autre ordinateur de votre réseau. En fait, si vous utilisez un intermédiaire public, vous pouvez le surveiller de n'importe où dans le monde.
D'ici là, passez un bon mois.