Anatomie d'un système IoT

Jour 1 · Comprendre et faire parler les objets · 25 min

Avant de brancher quoi que ce soit, il faut savoir où l'on met les mains. Un système IoT, quelle que soit sa taille, s'organise toujours en quatre couches. Un capteur de température dans un bureau ou un réseau de mille sondes industrielles : même découpage.

Ce que fait chaque couche

Le cas qui va nous servir de fil rouge

Thermeo supervise le chauffage de bâtiments tertiaires. Une centaine de capteurs de température et d'humidité, répartis sur plusieurs sites. Aujourd'hui, chaque capteur interroge un serveur HTTP toutes les trente secondes.

Trois problèmes en découlent, et ils sont typiques :

• Les batteries se vident. Ouvrir une connexion HTTP coûte cher en énergie, et le capteur le fait 2 880 fois par jour.
• Le serveur travaille pour rien. La température d'un bureau ne change pas toutes les trente secondes ; l'essentiel des requêtes ne rapporte aucune information nouvelle.
• Une panne passe inaperçue. Si un capteur cesse d'émettre, personne ne le sait — le serveur attend simplement une requête qui n'arrive jamais.

Ces trois problèmes ont la même origine : le capteur demande au lieu de signaler. C'est ce que la leçon suivante va renverser.

Pourquoi MQTT plutôt que HTTP

Jour 1 · Comprendre et faire parler les objets · 25 min

HTTP fonctionne sur un principe simple : un client demande, un serveur répond. C'est parfait pour consulter une page web. Pour un capteur sur batterie, c'est un contresens.

Le renversement : publication et abonnement

MQTT inverse la logique. Le capteur ne demande rien : il publie quand il a quelque chose à dire. Les applications intéressées s'abonnent. Entre les deux, un broker fait le tri et la distribution.

Le point important, et il est structurant : le capteur ne sait pas qui l'écoute, et l'application ne sait pas qui publie. On appelle cela le découplage. Ajouter un second tableau de bord ne demande aucune modification côté capteurs — on branche un abonné de plus.

Ce que cela change concrètement

Et CoAP ?

Il existe un troisième larron, CoAP, qui transpose le modèle REST sur UDP pour des équipements encore plus contraints. Nous le manipulerons au chapitre 3. Retenez pour l'instant que MQTT maintient une connexion vers un broker, là où CoAP interroge une ressource sans intermédiaire.

Topics : nommer pour retrouver

Jour 1 · Comprendre et faire parler les objets · 20 min

Un topic est l'adresse d'un message. Le publieur y dépose, l'abonné y puise. C'est une simple chaîne de caractères découpée par des barres obliques, du plus général au plus précis :

thermeo/lyon/etage1/capt-01/temperature
└──┬───┘ └─┬─┘ └──┬──┘ └──┬──┘ └────┬────┘
  parc    site   étage  capteur   grandeur

Rien n'impose cette structure : le broker accepte n'importe quel nom. Mais une convention cohérente est ce qui rendra le système exploitable dans six mois, quand il y aura cent capteurs et trois personnes différentes pour les administrer.

Les deux jokers

Bien concevoir sa convention

Trois principes suffisent :

• Du général au précis. C'est ce qui rend les jokers utiles : on peut s'abonner à un site entier, puis affiner.
• Pas d'accent, pas d'espace, pas de majuscule. Les topics circulent entre des systèmes hétérogènes ; restez en minuscules et tirets.
• La grandeur en dernier. Si vous placez temperature avant le site, vous ne pourrez plus vous abonner à « tout ce qui concerne le capteur 01 ».

Quiz — MQTT et les topics

Jour 1 · Comprendre et faire parler les objets · 10 min

TP 1 — Démarrer votre broker

Jour 1 · Comprendre et faire parler les objets · 45 min

Faire tourner un broker MQTT en local et vérifier qu'il accepte les connexions.

1. Créez un dossier de travail tp-iot-mqtt et placez-vous dedans. Tout le module s'y déroulera.
2. Créez mosquitto.conf. Sans ce fichier, le broker n'écoute que sur la boucle interne du conteneur et vous ne pourrez pas l'atteindre :
   copier

   listener 1883
   allow_anonymous true
   
   # Journalisation détaillée : indispensable pour comprendre ce qui se passe
   log_type all
   connection_messages true

3. Démarrez le broker en montant votre configuration :
   copier

   docker run -it --name broker-thermeo \
     -p 1883:1883 \
     -v "$(pwd)/mosquitto.conf":/mosquitto/config/mosquitto.conf \
     eclipse-mosquitto:2

4. Lisez les journaux : vous devez voir Opening ipv4 listen socket on port 1883. Laissez ce terminal ouvert — il sera votre console de supervision tout au long du module.
5. Dans un second terminal, vérifiez que le port répond :
   copier

   docker exec broker-thermeo mosquitto_sub -h localhost -t 'test' -C 1 -W 3

6. La commande attend trois secondes puis rend la main sans erreur : le broker écoute. Un Connection refused signifie que la configuration n'a pas été montée — reprenez l'étape b et vérifiez le chemin.

TP 2 — Publier, souscrire, filtrer

Jour 1 · Comprendre et faire parler les objets · 1 h 15

Mettre en œuvre la convention de nommage de Thermeo et la manipuler avec les jokers.

1. Abonnez-vous à toutes les températures du site de Lyon :
   copier

   docker exec broker-thermeo mosquitto_sub -h localhost -v \
     -t 'thermeo/lyon/+/+/temperature'

2. Dans un troisième terminal, publiez trois relevés :
   copier

   docker exec broker-thermeo mosquitto_pub -h localhost \
     -t 'thermeo/lyon/etage1/capt-01/temperature' -m '21.4'
   docker exec broker-thermeo mosquitto_pub -h localhost \
     -t 'thermeo/lyon/etage2/capt-07/temperature' -m '22.9'
   docker exec broker-thermeo mosquitto_pub -h localhost \
     -t 'thermeo/paris/etage1/capt-12/temperature' -m '19.8'

3. L'abonné n'a reçu que deux messages sur trois. Identifiez lequel manque et pourquoi avant de continuer — la réponse tient au deuxième niveau du topic.
4. Relancez avec le joker multi-niveaux :
   copier

   docker exec broker-thermeo mosquitto_sub -h localhost -v -t 'thermeo/#'

5. Republiez les trois relevés : tout arrive cette fois. Ajoutez une publication d'humidité et vérifiez qu'elle est également captée.
6. Écrivez capteur.py, qui simule un capteur émettant toutes les deux secondes :
   copier

   import time, random, json
   import paho.mqtt.client as mqtt
   
   SITE, ETAGE, CAPTEUR = "lyon", "etage1", "capt-01"
   TOPIC = f"thermeo/{SITE}/{ETAGE}/{CAPTEUR}/temperature"
   
   c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
   c.connect("localhost", 1883, 60)
   c.loop_start()
   
   try:
       while True:
           valeur = round(random.uniform(19.0, 24.0), 1)
           charge = json.dumps({"valeur": valeur, "unite": "C"})
           c.publish(TOPIC, charge)
           print("publie", charge)
           time.sleep(2)
   except KeyboardInterrupt:
       c.loop_stop(); c.disconnect()

7. Lancez python capteur.py et vérifiez dans l'abonné thermeo/# que les relevés arrivent bien toutes les deux secondes.

Qualité de service : que garantit-on ?

Jour 1 · Comprendre et faire parler les objets · 20 min

Un message peut se perdre. Le réseau coupe, le capteur redémarre, l'abonné plante. MQTT propose trois niveaux de garantie, appelés QoS, et le choix n'est pas anodin : chaque niveau supplémentaire coûte des échanges réseau, donc de l'énergie.

Comment choisir

• QoS 0 — une mesure périodique, vite remplacée par la suivante. Perdre un relevé de température sur cent n'a aucune conséquence.
• QoS 1 — une alerte, un événement. Mieux vaut la recevoir deux fois que pas du tout. Il faut alors gérer les doublons côté application.
• QoS 2 — un ordre, une commande, une transaction. Arrêter deux fois une chaudière n'est pas neutre.

La session persistante

Un abonné déconnecté ne reçoit rien — sauf s'il a demandé une session persistante. Le broker met alors ses messages en file d'attente et les lui livre à la reconnexion. Cela suppose deux choses : un identifiant client stable, et un QoS d'au moins 1. Vous le vérifierez dans le TP qui suit.

Quiz — Qualité de service

Jour 1 · Comprendre et faire parler les objets · 8 min

TP 3 — Éprouver les trois niveaux

Jour 1 · Comprendre et faire parler les objets · 1 h

Constater par vous-même ce que chaque niveau garantit, et ce qu'il coûte.

1. Abonnez-vous en QoS 0, puis coupez l'abonné pendant que le capteur publie. Relancez-le : les messages émis pendant la coupure sont définitivement perdus.
   copier

   docker exec broker-thermeo mosquitto_sub -h localhost -v -t 'thermeo/#' -q 0

2. Recommencez avec une session persistante et QoS 1. L'identifiant fixe et l'option -c demandent au broker de conserver la file :
   copier

   docker exec broker-thermeo mosquitto_sub -h localhost -v \
     -t 'thermeo/#' -q 1 -c -i 'superviseur-thermeo'

3. Coupez l'abonné, laissez publier une dizaine de messages, relancez exactement la même commande. Les messages manqués sont livrés : c'est toute la différence.
4. Passez le publieur en QoS 2 et observez les journaux du broker :
   copier

   c.publish(TOPIC, charge, qos=2)

5. Comptez les échanges réseau visibles dans les journaux pour un seul message en QoS 2, puis en QoS 0. Consignez l'écart : c'est le prix de la garantie.
6. Remplissez le tableau comparatif dans votre compte rendu : pour chaque niveau, le nombre d'échanges observés, ce qui est garanti, et un cas d'usage Thermeo qui le justifie.

Connaître l'état du parc à tout instant

Jour 1 · Comprendre et faire parler les objets · 20 min

Reste le troisième problème de Thermeo : une panne de capteur passe inaperçue. MQTT y répond par deux mécanismes complémentaires, qu'on confond souvent.

Le message retenu

Un message publié avec le drapeau retain est conservé par le broker comme « dernière valeur connue » du topic. Tout nouvel abonné le reçoit immédiatement, sans attendre la prochaine publication.

C'est ce qui permet à un tableau de bord de s'afficher rempli dès son ouverture, au lieu de montrer des cases vides pendant dix minutes. Un seul message retenu par topic : chaque nouveau remplace le précédent. Pour l'effacer, on publie une charge utile vide.

Le testament

Le Last Will — le testament — est un message que le client confie au broker au moment de se connecter, avec cette consigne : « si je disparais sans prévenir, publie ceci à ma place ».

Le broker le déclenche lorsque le client cesse de donner signe de vie, à l'expiration du délai de keep-alive. Le capteur signale donc sa propre panne, sans que personne ait à le surveiller.

Les deux ensemble

Un capteur bien conçu publie en-ligne en retenu à sa connexion, et confie un testament hors-ligne, retenu lui aussi. Résultat : le topic de statut porte en permanence l'état réel du capteur, disponible instantanément pour qui s'y abonne. C'est exactement ce qui manquait à Thermeo, et vous allez le mettre en place maintenant.

TP 4 — Détecter un capteur muet

Jour 1 · Comprendre et faire parler les objets · 1 h

Mettre en place les deux mécanismes qui donnent l'état du parc en temps réel.

1. Publiez une valeur en message retenu :
   copier

   docker exec broker-thermeo mosquitto_pub -h localhost -r \
     -t 'thermeo/lyon/etage1/capt-01/temperature' -m '21.4'

2. Abonnez-vous ensuite à ce topic : vous recevez la valeur immédiatement, sans attendre de nouvelle publication.
3. Vérifiez qu'un retenu écrase le précédent : publiez 22.0, réabonnez-vous, constatez que seule la dernière valeur revient. Puis effacez-le avec une charge vide :
   copier

   docker exec broker-thermeo mosquitto_pub -h localhost -r \
     -t 'thermeo/lyon/etage1/capt-01/temperature' -m ''

4. Mettez en place le testament. Il se déclare avant la connexion :
   copier

   STATUT = f"thermeo/{SITE}/{ETAGE}/{CAPTEUR}/statut"
   
   c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
   c.will_set(STATUT, "hors-ligne", qos=1, retain=True)
   c.connect("localhost", 1883, 60)
   c.publish(STATUT, "en-ligne", qos=1, retain=True)

5. Surveillez les statuts du parc dans un terminal :
   copier

   docker exec broker-thermeo mosquitto_sub -h localhost -v -t 'thermeo/+/+/+/statut'

6. Lancez le capteur : en-ligne apparaît. Interrompez-le brutalement par Ctrl+C — le broker publie hors-ligne à sa place. C'est la détection de panne qui manquait à Thermeo.
7. Testez la déconnexion propre : publiez hors-ligne avant disconnect() et vérifiez que le testament n'est alors pas déclenché.

Point de contrôle — fin du jour 1

Jour 1 · Comprendre et faire parler les objets · 15 min

Ce qu'un broker ouvert laisse passer

Jour 2 · Sécuriser les échanges · 20 min

La maquette du jour 1 fonctionne, mais elle est ouverte à tous vents. N'importe qui sur le réseau peut lire les relevés — et surtout en injecter de faux.

Trois questions, trois réponses distinctes

On confond souvent ces trois notions. Elles répondent pourtant à des questions différentes, et chacune appelle son propre mécanisme.

Ce que le responsable sécurité exige

Trois conditions avant tout déploiement, que vous allez remplir aujourd'hui :

1. Plus aucun accès anonyme.
2. Tout le trafic chiffré.
3. Chaque capteur limité à ses propres topics — celui de Lyon ne doit pas pouvoir écrire sur ceux de Paris.

Certificats X.509 et chaîne de confiance

Jour 2 · Sécuriser les échanges · 25 min

Le mot de passe règle la question « qui es-tu ? », mais il circule en clair tant que la connexion ne l'est pas. Pour chiffrer, il faut des certificats — et pour des certificats, il faut une autorité.

Le principe

Une autorité de certification (CA) est simplement une paire de clés dont on décide qu'elle fait foi. Elle signe les certificats du broker et des capteurs. Chacun d'eux, possédant le certificat de l'autorité, peut alors vérifier que l'autre a bien été signé par elle.

Pour un réseau interne, vous êtes votre propre autorité : c'est ce qu'on appelle une CA privée. Aucun organisme extérieur n'intervient, et c'est parfaitement légitime tant que les certificats ne servent qu'entre vos machines.

Deux usages du certificat client

Un capteur peut présenter son propre certificat. Cela apporte deux choses d'un coup :

• Il prouve son identité sans mot de passe, donc sans secret à stocker en clair dans le firmware.
• Son CN peut servir directement d'identifiant — c'est l'option use_identity_as_username, qui relie le certificat aux ACL.

Quiz — Authentification et chiffrement

Jour 2 · Sécuriser les échanges · 8 min

TP 1 — Fermer la porte

Jour 2 · Sécuriser les échanges · 40 min

Supprimer l'accès anonyme et imposer une authentification.

1. Créez le fichier de mots de passe avec un premier compte. La commande demande le mot de passe deux fois :
   copier

   docker exec -it broker-thermeo \
     mosquitto_passwd -c /mosquitto/config/passwd capt-01

2. Ajoutez deux comptes de plus. Attention : sans -c, sinon vous écrasez le fichier :
   copier

   docker exec -it broker-thermeo \
     mosquitto_passwd /mosquitto/config/passwd capt-07
   docker exec -it broker-thermeo \
     mosquitto_passwd /mosquitto/config/passwd superviseur

3. Modifiez mosquitto.conf :
   copier

   listener 1883
   allow_anonymous false
   password_file /mosquitto/config/passwd
   
   log_type all
   connection_messages true

4. Redémarrez avec docker restart broker-thermeo, puis tentez une publication sans identifiants. Elle échoue — c'est le résultat attendu. Notez le code d'erreur exact, il vous servira à diagnostiquer plus tard.
5. Republiez avec les identifiants :
   copier

   docker exec broker-thermeo mosquitto_pub -h localhost \
     -u capt-01 -P '<votre-mot-de-passe>' \
     -t 'thermeo/lyon/etage1/capt-01/temperature' -m '21.4'

6. Adaptez capteur.py, avant l'appel à connect :
   copier

   c.username_pw_set("capt-01", "<votre-mot-de-passe>")

TP 2 — Devenir sa propre autorité

Jour 2 · Sécuriser les échanges · 50 min

Produire la chaîne de confiance dont le broker et les capteurs auront besoin.

1. Créez un dossier certs dans votre répertoire de travail.
2. Générez la clé et le certificat de votre autorité, valable dix ans :
   copier

   openssl genrsa -out certs/ca.key 2048
   
   openssl req -new -x509 -days 3650 -key certs/ca.key \
     -out certs/ca.crt \
     -subj "/C=FR/O=Thermeo/CN=Thermeo Root CA"

3. Générez la clé et la demande de signature du broker. Le CN doit être le nom par lequel les clients le joindront :
   copier

   openssl genrsa -out certs/broker.key 2048
   
   openssl req -new -key certs/broker.key -out certs/broker.csr \
     -subj "/C=FR/O=Thermeo/CN=localhost"

4. Faites signer le certificat du broker par votre autorité :
   copier

   openssl x509 -req -in certs/broker.csr -CA certs/ca.crt \
     -CAkey certs/ca.key -CAcreateserial \
     -out certs/broker.crt -days 825 -sha256

5. Faites de même pour le capteur — il servira au TP 4 :
   copier

   openssl genrsa -out certs/capt-01.key 2048
   
   openssl req -new -key certs/capt-01.key -out certs/capt-01.csr \
     -subj "/C=FR/O=Thermeo/CN=capt-01"
   
   openssl x509 -req -in certs/capt-01.csr -CA certs/ca.crt \
     -CAkey certs/ca.key -CAcreateserial \
     -out certs/capt-01.crt -days 825 -sha256

6. Inspectez le résultat et relevez l'émetteur, le sujet et les dates de validité :
   copier

   openssl x509 -in certs/broker.crt -noout -text | head -20

TP 3 — Chiffrer le trafic

Jour 2 · Sécuriser les échanges · 1 h

Passer le broker en TLS et vérifier de vos yeux que le chiffrement est effectif.

1. Ouvrez un écouteur TLS sur le port 8883, en gardant provisoirement le 1883 pour comparer :
   copier

   listener 1883
   allow_anonymous false
   password_file /mosquitto/config/passwd
   
   listener 8883
   allow_anonymous false
   password_file /mosquitto/config/passwd
   cafile /mosquitto/config/certs/ca.crt
   certfile /mosquitto/config/certs/broker.crt
   keyfile /mosquitto/config/certs/broker.key
   tls_version tlsv1.2
   
   log_type all

2. Recréez le conteneur en montant aussi les certificats :
   copier

   docker rm -f broker-thermeo
   
   docker run -it --name broker-thermeo \
     -p 1883:1883 -p 8883:8883 \
     -v "$(pwd)/mosquitto.conf":/mosquitto/config/mosquitto.conf \
     -v "$(pwd)/certs":/mosquitto/config/certs \
     -v "$(pwd)/passwd":/mosquitto/config/passwd \
     eclipse-mosquitto:2

3. Si le broker refuse de démarrer, lisez le message : une erreur de permission sur les clés est le cas le plus fréquent. Consignez le message et sa résolution — c'est un livrable.
4. Publiez en TLS en fournissant le certificat de l'autorité, pour que le client puisse vérifier le broker :
   copier

   mosquitto_pub -h localhost -p 8883 \
     --cafile certs/ca.crt \
     -u capt-01 -P '<mot-de-passe>' \
     -t 'thermeo/lyon/etage1/capt-01/temperature' -m '21.4'

5. Retentez sans --cafile : la connexion échoue, le client refusant un certificat qu'il ne peut pas valider. C'est le comportement attendu.
6. Adaptez capteur.py :
   copier

   import ssl
   
   c.username_pw_set("capt-01", "<mot-de-passe>")
   c.tls_set(ca_certs="certs/ca.crt", tls_version=ssl.PROTOCOL_TLSv1_2)
   c.connect("localhost", 8883, 60)

7. Si vous avez Wireshark, capturez sur la boucle locale et comparez 1883 et 8883 : sur le premier, la valeur 21.4 se lit en clair ; sur le second, non. C'est la démonstration que le chiffrement fonctionne.
8. Une fois la vérification faite, supprimez l'écouteur 1883 et redémarrez : plus aucun trafic en clair.

Autoriser : les listes de contrôle d'accès

Jour 2 · Sécuriser les échanges · 15 min

Il reste la troisième exigence : qu'un capteur ne puisse écrire que sur ses propres topics. C'est le rôle des ACL, déclarées dans un fichier que Mosquitto relit à chaque connexion.

La syntaxe

Une ACL se lit comme une suite de blocs : un utilisateur, puis ses droits.

user superviseur
topic read thermeo/#

user capt-01
topic write thermeo/lyon/etage1/capt-01/#
topic read thermeo/lyon/etage1/capt-01/consigne

Trois verbes existent : read, write, et readwrite. Les jokers + et # fonctionnent comme dans les abonnements.

Ce que cela implique

Notez la conséquence du dernier point : dans cette configuration, le superviseur ne peut pas publier de consigne. Si Thermeo veut plus tard piloter les chaudières depuis la supervision, il faudra un compte distinct, avec des droits d'écriture explicites et limités aux topics de consigne. C'est une décision d'architecture, pas un détail de configuration.

Quiz — Autorisation

Jour 2 · Sécuriser les échanges · 6 min

TP 4 — Identité par certificat et cloisonnement

Jour 2 · Sécuriser les échanges · 1 h

Donner à chaque capteur une identité propre et le restreindre à son périmètre.

1. Exigez un certificat client et utilisez son CN comme identité :
   copier

   require_certificate true
   use_identity_as_username true

2. Le capteur présente désormais son certificat, sans mot de passe :
   copier

   c.tls_set(ca_certs="certs/ca.crt",
             certfile="certs/capt-01.crt",
             keyfile="certs/capt-01.key",
             tls_version=ssl.PROTOCOL_TLSv1_2)

3. Vérifiez dans les journaux que le client est identifié comme capt-01 : c'est le CN du certificat qui fait foi.
4. Créez le fichier acl :
   copier

   # Le superviseur lit l'ensemble du parc
   user superviseur
   topic read thermeo/#
   
   # Chaque capteur n'écrit que sur sa propre branche
   user capt-01
   topic write thermeo/lyon/etage1/capt-01/#
   topic read thermeo/lyon/etage1/capt-01/consigne
   
   user capt-07
   topic write thermeo/lyon/etage2/capt-07/#
   topic read thermeo/lyon/etage2/capt-07/consigne

5. Déclarez-le et redémarrez :
   copier

   acl_file /mosquitto/config/acl

6. Depuis capt-01, tentez de publier sur le topic de capt-07. La publication est rejetée — c'est précisément l'exigence du responsable sécurité.
7. Vérifiez le pendant : le superviseur lit tout le parc, mais sa tentative de publier une consigne est refusée.

Point de contrôle — fin du jour 2

Jour 2 · Sécuriser les échanges · 15 min

CoAP : l'autre voie

Jour 3 · Élargir et assembler · 20 min

MQTT n'est pas la seule réponse. CoAP transpose le modèle REST sur UDP, pour des équipements encore plus contraints que ceux que nous avons manipulés.

Deux philosophies

L'observation

CoAP propose un mécanisme d'observe : le client s'inscrit sur une ressource et le serveur le notifie des changements. C'est un rapprochement du modèle MQTT, mais sans broker — donc sans point de collecte central, ce qui complique la supervision de cent capteurs.

Les réseaux LPWAN

Jour 3 · Élargir et assembler · 25 min

Reste la question radio. Pour les sept bâtiments de Thermeo sans connexion exploitable, il faut un réseau longue portée et basse consommation — c'est ce que désigne LPWAN.

Les trois candidats

Trois critères qu'on oublie souvent

• Le cycle d'utilisation. Sur les bandes libres, la réglementation limite le temps d'émission — typiquement 1 % du temps. Cela contraint la conception applicative bien plus que le débit théorique.
• Qui exploite l'infrastructure. LoRaWAN vous rend indépendant d'un opérateur, mais vous devenez responsable des passerelles, de leur alimentation et de leur maintenance.
• La pérennité. Un opérateur peut cesser son service — c'est déjà arrivé. Sur un choix qui engage dix ans, ce risque pèse autant que les caractéristiques techniques.

Quiz — CoAP et LPWAN

Jour 3 · Élargir et assembler · 8 min

TP 1 — Mettre CoAP en œuvre

Jour 3 · Élargir et assembler · 50 min

Faire fonctionner un échange CoAP et mesurer ce qui le distingue de MQTT.

1. Écrivez le serveur serveur_coap.py :
   copier

   import asyncio, random
   import aiocoap.resource as resource
   import aiocoap
   
   class Temperature(resource.Resource):
       async def render_get(self, request):
           valeur = round(random.uniform(19.0, 24.0), 1)
           return aiocoap.Message(payload=str(valeur).encode())
   
   async def main():
       racine = resource.Site()
       racine.add_resource(['temperature'], Temperature())
       await aiocoap.Context.create_server_context(racine, bind=('127.0.0.1', 5683))
       await asyncio.get_running_loop().create_future()
   
   asyncio.run(main())

2. Écrivez le client client_coap.py :
   copier

   import asyncio
   from aiocoap import Context, Message, GET
   
   async def main():
       ctx = await Context.create_client_context()
       req = Message(code=GET, uri='coap://127.0.0.1/temperature')
       rep = await ctx.request(req).response
       print('reponse :', rep.payload.decode())
   
   asyncio.run(main())

3. Lancez le serveur puis le client. Notez la différence de posture avec MQTT : ici c'est le client qui demande, le capteur ne pousse rien de lui-même.
4. Ajoutez une seconde ressource /humidite et vérifiez que le même serveur les expose toutes les deux.
5. Comparez la taille d'un échange CoAP et d'un échange MQTT, et consignez ce que cela change pour un capteur sur pile.

TP 2 — Un ESP32 sans ESP32

Jour 3 · Élargir et assembler · 1 h

Exécuter du vrai firmware embarqué, sans aucune carte physique.

1. Ouvrez wokwi.com et créez un projet ESP32. Le simulateur exécute réellement le firmware et dispose d'une pile réseau.
2. Ajoutez un capteur DHT22 par le bouton +. Reliez sa broche de données à la GPIO 15, son alimentation au 3V3 et sa masse au GND.
3. Saisissez le firmware dans sketch.ino. Le SSID Wokwi-GUEST est le réseau du simulateur, sans mot de passe :
   copier

   #include <WiFi.h>
   #include <PubSubClient.h>
   #include "DHTesp.h"
   
   const char* SSID = "Wokwi-GUEST";
   const char* BROKER = "test.mosquitto.org";
   const char* TOPIC = "thermeo/demo/etage1/esp32-01/temperature";
   
   WiFiClient net;
   PubSubClient mqtt(net);
   DHTesp dht;
   
   void setup() {
     Serial.begin(115200);
     dht.setup(15, DHTesp::DHT22);
     WiFi.begin(SSID, "");
     while (WiFi.status() != WL_CONNECTED) { delay(250); Serial.print("."); }
     Serial.println(" wifi ok");
     mqtt.setServer(BROKER, 1883);
   }
   
   void loop() {
     if (!mqtt.connected()) mqtt.connect("esp32-thermeo-01");
     TempAndHumidity d = dht.getTempAndHumidity();
     char buf[16];
     dtostrf(d.temperature, 4, 1, buf);
     mqtt.publish(TOPIC, buf);
     Serial.printf("publie %s\n", buf);
     delay(5000);
   }

4. Déclarez les bibliothèques dans libraries.txt :
   copier

   PubSubClient
   DHT sensor library for ESPx

5. Démarrez la simulation. Le moniteur série affiche la connexion puis les publications. Cliquez sur le DHT22 pour faire varier la température : la valeur publiée suit.
6. Depuis votre poste, recevez ce que publie l'ESP32 simulé :
   copier

   mosquitto_sub -h test.mosquitto.org -v \
     -t 'thermeo/demo/etage1/esp32-01/#'

7. Vous recevez les relevés d'un microcontrôleur qui n'existe pas physiquement. Mesurez le délai entre l'affichage sur le moniteur série et la réception.
8. Ajoutez un testament au firmware, comme au jour 1, en utilisant la signature complète de mqtt.connect. Coupez la simulation et vérifiez la bascule du statut.

TP 3 — Instruire le choix radio

Jour 3 · Élargir et assembler · 1 h 15

Recommander une technologie LPWAN pour les sept bâtiments isolés, sur critères.

1. Documentez-vous sur LoRaWAN, Sigfox et NB-IoT. Sources attendues : LoRa Alliance, documentation The Things Network, spécifications 3GPP.
2. Construisez un tableau comparatif portant sur : portée urbaine et rurale, débit utile, taille et nombre de messages autorisés par jour, consommation et autonomie estimée, coût annuel par objet, nécessité de passerelles, couverture en France.
3. Renseignez chaque case avec sa source.
4. Appliquez les contraintes de Thermeo : un relevé toutes les quinze minutes, 12 octets de charge utile, cinq ans d'autonomie visée, sept bâtiments dont trois en zone rurale, 15 € par objet et par an.
5. Calculez le nombre de messages quotidiens qu'impose ce rythme et confrontez-le aux quotas. Une technologie est éliminée par ce seul calcul : identifiez-la et démontrez-le.
6. Rédigez une recommandation d'une page : la technologie retenue, les deux raisons principales, et ce qui vous ferait changer d'avis si une contrainte évoluait.

TP 4 — Assembler le tout

Jour 3 · Élargir et assembler · 1 h 30

Réunir les acquis des trois jours en une maquette qui tient debout seule.

1. Repartez du broker sécurisé du jour 2 : TLS, certificats clients, ACL actives.
2. Générez des certificats pour trois capteurs supplémentaires avec votre script generer-certs.sh, et étendez le fichier ACL en conséquence.
3. Généralisez capteur.py pour qu'il prenne son identité en paramètre :
   copier

   import sys
   SITE, ETAGE, CAPTEUR = sys.argv[1], sys.argv[2], sys.argv[3]
   # le reste du code reprend ces trois variables
   # lancement : python capteur.py lyon etage1 capt-01

4. Lancez quatre capteurs simultanément, sur deux sites et deux étages différents.
5. Écrivez superviseur.py, qui s'abonne à tout le parc, tient à jour le dernier relevé de chacun et signale tout capteur muet depuis plus de dix secondes :
   copier

   # Ossature attendue — a completer
   # 1. connexion TLS avec le certificat du superviseur
   # 2. abonnement a thermeo/# en QoS 1, session persistante
   # 3. dictionnaire {topic: (valeur, horodatage)}
   # 4. boucle d'affichage toutes les 5 s : etat du parc
   # 5. alerte si horodatage plus vieux que 10 s

6. Coupez brutalement un capteur : le superviseur doit le signaler, à la fois par son horodatage et par le testament reçu sur le topic de statut.
7. Vérifiez enfin que l'ACL tient : tentez depuis un capteur de publier sur la branche d'un autre, et confirmez le refus dans les journaux.

Point de contrôle — fin du module M1

Jour 3 · Élargir et assembler · 20 min