protocole

protocole.md

@@ -0,0 +1,94 @@
+# Protocoles de communication industriels et IoT**
+
+Dans l’industrie comme dans l’IoT, on doit faire communiquer des capteurs, automates, serveurs, tableaux de bord, etc.
+Plusieurs protocoles existent, chacun optimisé pour un usage : faible bande passante, fiabilité élevée, déploiement dans le cloud, compatibilité historique…
+
+
+## MQTT – Message Queuing Telemetry Transport
+
+Protocole **pub/sub (publish/subscribe)** ultra-léger, conçu pour les capteurs IoT et les réseaux à faible débit.
+
+### Fonctionnement
+
+* Un **broker** (Mosquitto, EMQX, HiveMQ…) centralise la communication.
+* Les **clients publient** des messages sur un *topic*.
+* D’autres clients **s’abonnent** à ces topics.
+
+Exemple :
+
+* Un capteur publie `temperature = 26°` sur `salle1/temp`.
+* Une interface Node-RED ou un automate s’abonne → reçoit en temps réel.
+
+### Avantages
+
+* Très léger, faible consommation réseau.
+* Temps réel simple.
+* QoS (Quality of Service) :
+
+  * **0** : au mieux
+  * **1** : exactement un message reçu
+  * **2** : sans doublon
+
+### Limites
+
+* Modèle simple → pas de files persistantes complexes.
+* Moins adapté aux transactions ou aux règles métier avancées.
+
+### Domaine typique
+
+* IoT
+* Domotique
+* Télémetrie en réseau contraint
+
+
+## AMQP – Advanced Message Queuing Protocol
+
+Protocole orienté **file de messages** utilisé dans les systèmes distribués, cloud, microservices.
+
+Implémentation la plus connue : **RabbitMQ**.
+
+### Modèle de communication
+
+Plus complet que MQTT :
+
+* **Queues** (files d’attente)
+* **Exchanges** (direct, topic, fanout, headers)
+* **Routes** des messages selon des règles
+* Messages **persistants**, **accusés de réception**, **dead-letter queues**…
+
+### Avantages
+
+* Fiabilité élevée (transactions, ack).
+* Routage intelligent.
+* Très adapté aux architectures microservices.
+
+### Limites
+
+* Protocole plus lourd que MQTT.
+* Moins adapté aux réseaux IoT très contraints.
+
+### Domaines
+
+* Backends cloud
+* Intégration applicative
+* Flux de commandes industrielles complexes
+* Chaînes de traitement log d'entreprise
+
+
+# Modbus/TCP
+
+Protocole historique utilisé en automatisme.
+
+### Fonctionnement
+
+* Client/serveur
+* Lecture/écriture de registres
+* Pas de sécurité native
+* Simple, minimaliste
+
+### Domaines
+
+* Automates
+* Variateurs
+* Capteurs industriels
+* Bancs de test

tp3.md

@@ -71,6 +71,7 @@ Ajouter la bibliothèque MQTT
 #include "mqtt/async_client.h"
 
 #include <nlohmann/json.hpp>
+using json = nlohmann::json;
 ```
 
 Déclarer les constantes
@@ -97,6 +98,8 @@ public:
 };
 ```
 
+Intialiser le client et se connecter
+
 ```c
 mqtt::async_client client(ADDRESS, CLIENTID);
   callback cb;
@@ -116,6 +119,19 @@ mqtt::async_client client(ADDRESS, CLIENTID);
   }
 ```
 
+
+Après la boucle principale déconnecter MQTT.
+
+```c
+try {
+  client.unsubscribe(TOPIC)->wait();
+  client.stop_consuming();
+  client.disconnect()->wait();
+} catch(const mqtt::exception &exc){
+  std::cerr << "Erreur déconnexion MQTT: " << exc.what() << "\n";
+}
+```
+
 Dans la fonction ProcessMQTT créer un objet JSON avec les valeurs des différents capteurs.
 
 ```c
@@ -134,16 +150,10 @@ msg->set_qos(1);
 client->publish(msg);
 ```
 
-Après la boucle principale déconnecter MQTT.
+Appeler la fonction ProcessMQTT dans la boucle principale
 
 ```c
-try {
+ProcessMQTT(&client);
-  client.unsubscribe(TOPIC)->wait();
-  client.stop_consuming();
-  client.disconnect()->wait();
-} catch(const mqtt::exception &exc){
-  std::cerr << "Erreur déconnexion MQTT: " << exc.what() << "\n";
-}
 ```
 
 ## Énoncé