Pourquoi pas une base classique

Jour 1 · Du broker à la base · 20 min

Vos relevés se perdent. Le broker les distribue puis les oublie — il ne stocke rien. Il faut donc une base, et le premier réflexe serait PostgreSQL ou MySQL. C'est jouable, mais mal adapté.

Ce qu'une série temporelle a de particulier

Une donnée de capteur a trois traits que les bases relationnelles ne prévoient pas :

• Elle arrive toujours en fin de série. On insère au présent, on ne modifie presque jamais le passé.
• Elle est massive et répétitive. Cent capteurs à une mesure par minute font 52 millions de lignes par an, dont la plupart se ressemblent.
• Elle perd de la valeur en vieillissant. La température d'il y a deux ans à la seconde près n'intéresse personne ; sa moyenne horaire, oui.

Le modèle de données d'InfluxDB

Jour 1 · Du broker à la base · 25 min

InfluxDB ne raisonne pas en tables et colonnes. Un point se compose de quatre éléments, et bien les distinguer conditionne les performances de tout le système.

thermeo,site=lyon,etage=etage1,capteur=capt-01 temperature=21.4,humidite=48 1723449600
└──┬───┘ └──────────────── tags ────────────────┘ └────── fields ──────┘ └── temps ──┘
 measurement

La distinction qui compte

Les tags sont indexés, les fields ne le sont pas. On filtre donc sur des tags, on calcule sur des fields.

Règle pratique

• Un tag répond à « d'où vient cette mesure ? » — il prend un nombre fini et stable de valeurs. Site, étage, identifiant de capteur, type d'appareil.
• Un field répond à « que vaut-elle ? » — il varie librement. Température, humidité, tension de pile, compteur.

Buckets et rétention

Les points vivent dans un bucket, qui porte une durée de conservation. Passé ce délai, InfluxDB supprime les points automatiquement — pas de tâche de ménage à écrire. Vous exploiterez cela au jour 2.

Quiz — Modèle de données

Jour 1 · Du broker à la base · 8 min

TP 1 — Monter la base

Jour 1 · Du broker à la base · 1 h

Démarrer InfluxDB, écrire des points à la main et les relire.

1. Démarrez InfluxDB en conteneur, avec sa configuration initiale :
   copier

   docker run -d --name influx-thermeo \
     -p 8086:8086 \
     -e DOCKER_INFLUXDB_INIT_MODE=setup \
     -e DOCKER_INFLUXDB_INIT_USERNAME=admin \
     -e DOCKER_INFLUXDB_INIT_PASSWORD=thermeo2026 \
     -e DOCKER_INFLUXDB_INIT_ORG=thermeo \
     -e DOCKER_INFLUXDB_INIT_BUCKET=releves \
     -e DOCKER_INFLUXDB_INIT_RETENTION=7d \
     influxdb:2.7

2. Ouvrez http://localhost:8086 et connectez-vous. Notez la rétention de 7 jours déclarée à la création du bucket.
3. Dans l'interface, allez dans Load Data → API Tokens et copiez le jeton administrateur. Vous en aurez besoin partout.
4. Écrivez un premier point en ligne de commande. Respectez la syntaxe : tags collés au measurement par des virgules, espace, puis fields :
   copier

   TOKEN="<votre-jeton>"
   
   curl -s -X POST "http://localhost:8086/api/v2/write?org=thermeo&bucket=releves&precision=s" \
     -H "Authorization: Token $TOKEN" \
     --data-binary 'thermeo,site=lyon,etage=etage1,capteur=capt-01 temperature=21.4'

5. Vérifiez dans Data Explorer que le point apparaît. Écrivez-en trois autres avec des capteurs et des sites différents.
6. Faites délibérément l'erreur de cardinalité : écrivez un point où la température est un tag, puis regardez le nombre de séries créées :
   copier

   # a NE PAS reproduire en production
   curl -s -X POST "http://localhost:8086/api/v2/write?org=thermeo&bucket=releves" \
     -H "Authorization: Token $TOKEN" \
     --data-binary 'mauvais,capteur=capt-01,temperature=21.4 valeur=1'

7. Répétez avec cinq températures différentes et comptez les séries dans Data Explorer. Cinq séries pour cinq mesures — extrapolez à un an de relevés et consignez le chiffre.

TP 2 — Brancher le broker sur la base

Jour 1 · Du broker à la base · 1 h 15

Faire couler les messages MQTT vers InfluxDB, automatiquement et en continu.

1. Il faut un pont entre le broker et la base. Telegraf fait cela sans une ligne de code : il s'abonne à MQTT et écrit dans InfluxDB.
2. Créez telegraf.conf. Notez le topic_parsing : c'est lui qui transforme le chemin du topic en tags — exactement la convention posée en M1 :
   copier

   [[inputs.mqtt_consumer]]
     servers = ["tcp://host.docker.internal:1883"]
     topics = ["thermeo/+/+/+/temperature", "thermeo/+/+/+/humidite"]
     data_format = "value"
     data_type = "float"
   
     [[inputs.mqtt_consumer.topic_parsing]]
       topic = "thermeo/+/+/+/+"
       measurement = "_/_/_/_/measurement"
       tags = "_/site/etage/capteur/_"
   
   [[outputs.influxdb_v2]]
     urls = ["http://host.docker.internal:8086"]
     token = "$INFLUX_TOKEN"
     organization = "thermeo"
     bucket = "releves"

3. Démarrez Telegraf :
   copier

   docker run -d --name telegraf-thermeo \
     -e INFLUX_TOKEN="<votre-jeton>" \
     -v "$(pwd)/telegraf.conf":/etc/telegraf/telegraf.conf:ro \
     --add-host=host.docker.internal:host-gateway \
     telegraf:1.30

4. Vérifiez les journaux — c'est là que se voient les erreurs de connexion :
   copier

   docker logs -f telegraf-thermeo

5. Relancez votre capteur.py de M1. Après quelques secondes, les points apparaissent dans Data Explorer, correctement étiquetés par site, étage et capteur.
6. Vérifiez le mapping : les tags doivent venir du topic, pas être écrits en dur. Lancez un second capteur sur un autre étage et confirmez que les deux séries se distinguent.
7. Coupez Telegraf trente secondes pendant que le capteur publie, puis relancez-le. Les messages émis pendant la coupure sont perdus — sauf si vous avez prévu quelque chose. Reliez ce constat à la session persistante vue en M1 et proposez une correction.

Point de contrôle — fin du jour 1

Jour 1 · Du broker à la base · 15 min

Interroger le temps

Jour 2 · Interroger et faire durer · 25 min

Une base de séries temporelles ne s'interroge pas comme une base relationnelle. On ne demande pas « les lignes où… », on demande « l'évolution de… sur… agrégée par… ».

La structure d'une requête Flux

Flux est le langage d'InfluxDB 2. Une requête est un tuyau : chaque étape reçoit le résultat de la précédente.

from(bucket: "releves")
  |> range(start: -1h)                                   // fenêtre de temps
  |> filter(fn: (r) => r._measurement == "temperature")   // quelle série
  |> filter(fn: (r) => r.site == "lyon")                  // filtre sur un tag
  |> aggregateWindow(every: 5m, fn: mean)                 // moyenne par tranche de 5 min
  |> yield(name: "moyennes")

Les fonctions d'agrégation

Comparer plusieurs capteurs

Par défaut, Flux garde les séries séparées : une courbe par combinaison de tags. Pour les regrouper, on redéfinit le groupement.

from(bucket: "releves")
  |> range(start: -24h)
  |> filter(fn: (r) => r._measurement == "temperature")
  |> group(columns: ["site"])            // une courbe par site, capteurs confondus
  |> aggregateWindow(every: 1h, fn: mean)

Quiz — Requêtes

Jour 2 · Interroger et faire durer · 7 min

TP 3 — Faire parler les données

Jour 2 · Interroger et faire durer · 1 h

Écrire les requêtes dont un exploitant a réellement besoin.

1. Écrivez la requête « température moyenne par tranche de 5 minutes sur la dernière heure, pour le site de Lyon », en repartant de l'exemple de la leçon.
2. Écrivez la requête « dernière valeur connue de chaque capteur ». Indice : last() après un group par capteur.
3. Écrivez la requête « amplitude de variation par capteur sur 24 h » avec spread. Quel capteur varie le plus ?
4. Écrivez la requête qui détecte un capteur muet : ceux dont le nombre de points sur les dix dernières minutes est nul ou anormalement bas. Ossature :
   copier

   from(bucket: "releves")
     |> range(start: -10m)
     |> filter(fn: (r) => r._measurement == "temperature")
     |> group(columns: ["capteur"])
     |> count()
     |> filter(fn: (r) => r._value < 5)     // seuil a ajuster selon votre cadence

5. Coupez un capteur et vérifiez que votre requête le fait bien remonter. Comparez cette approche au testament MQTT de M1 : les deux détectent une panne, mais pas de la même façon ni au même moment.
6. Écrivez enfin la requête « écart entre le capteur le plus chaud et le plus froid de chaque site ». Elle est plus difficile : cherchez du côté de pivot ou d'un double group.
7. Consignez les cinq requêtes commentées dans un fichier requetes.flux de votre dépôt.

Ne pas tout garder pour toujours

Jour 2 · Interroger et faire durer · 20 min

Cent capteurs à une mesure par minute, c'est 52 millions de points par an. À la seconde, c'est 3 milliards. Aucune base ne tient ce rythme indéfiniment — et surtout, personne n'en a besoin.

Le principe

On conserve le détail fin peu de temps, et des agrégats de plus en plus grossiers de plus en plus longtemps. Trois buckets, trois rétentions :

Les tâches d'agrégation

InfluxDB exécute des tâches périodiques qui lisent un bucket, agrègent et écrivent dans un autre. Une fois en place, tout se fait sans intervention.

option task = {name: "vers_5m", every: 5m}

from(bucket: "releves")
  |> range(start: -task.every)
  |> filter(fn: (r) => r._measurement == "temperature")
  |> aggregateWindow(every: 5m, fn: mean)
  |> to(bucket: "releves_5m", org: "thermeo")

Ce qu'on perd

Agréger, c'est choisir. Une moyenne horaire efface les pics : si un capteur monte à 45 °C pendant deux minutes, la moyenne de l'heure ne le montrera pas.

TP 4 — Rétention et agrégats

Jour 2 · Interroger et faire durer · 1 h 15

Mettre en place la cascade de buckets et automatiser l'agrégation.

1. Créez les deux buckets d'agrégats, avec leurs rétentions :
   copier

   docker exec influx-thermeo influx bucket create \
     --name releves_5m --org thermeo --retention 90d
   
   docker exec influx-thermeo influx bucket create \
     --name releves_1h --org thermeo --retention 1825d

2. Dans l'interface, allez dans Tasks → Create Task et créez la tâche vers_5m à partir du script de la leçon.
3. Laissez tourner quinze minutes avec vos capteurs actifs, puis vérifiez que releves_5m se remplit. Comparez le nombre de points des deux buckets.
4. Créez la seconde tâche, qui agrège les 5 minutes en heures. Notez qu'elle lit releves_5m, pas les données brutes — on cascade :
   copier

   option task = {name: "vers_1h", every: 1h}
   
   from(bucket: "releves_5m")
     |> range(start: -task.every)
     |> aggregateWindow(every: 1h, fn: mean)
     |> to(bucket: "releves_1h", org: "thermeo")

5. Enrichissez vers_5m pour conserver aussi le maximum et le minimum, comme le suggère la leçon. Vérifiez que les trois valeurs coexistent bien.
6. Provoquez la panne annoncée : désactivez la tâche vers_5m, laissez tourner, puis constatez que releves_5m a un trou. Réactivez et vérifiez que le trou ne se comble pas tout seul.
7. Rédigez la procédure de rattrapage : quelle requête permettrait de reconstruire les agrégats manquants tant que les données brutes existent encore ?
8. Calculez le volume : combien de points chaque bucket contiendra-t-il à plein régime pour cent capteurs ? Comparez au volume qu'aurait un stockage brut sur cinq ans.
   copier

   # a completer dans votre rendu
   # brut 7 j     : 100 capteurs x ... x ...
   # 5 min 90 j   : ...
   # 1 h 5 ans    : ...
   # total        : ... contre ... en tout-brut sur 5 ans

Point de contrôle — fin du jour 2

Jour 2 · Interroger et faire durer · 15 min

De la donnée à l'action

Jour 3 · Règles et plateformes · 20 min

Stocker ne sert à rien si personne n'agit. Il manque la brique qui transforme une mesure en décision : le moteur de règles.

Où placer la règle

Vous savez maintenant qu'une décision peut se prendre à trois endroits, et le choix n'est pas indifférent.

Node-RED

Node-RED assemble des traitements par blocs reliés graphiquement. C'est l'outil dominant dans l'IoT pour ce type de règles : on branche une entrée MQTT, un test, une sortie, et c'est en service.

TP 5 — Une règle qui déclenche

Jour 3 · Règles et plateformes · 1 h 15

Construire une alerte qui croise plusieurs sources et republie une décision.

1. Démarrez Node-RED :
   copier

   docker run -d --name nodered-thermeo \
     -p 1880:1880 \
     --add-host=host.docker.internal:host-gateway \
     nodered/node-red:3.1

2. Ouvrez http://localhost:1880. Installez le nœud InfluxDB par Menu → Manage palette → Install, module node-red-contrib-influxdb.
3. Construisez un premier flux : mqtt in sur thermeo/+/+/+/temperature → debug. Vérifiez que les messages défilent.
4. Ajoutez un nœud function qui extrait le capteur depuis le topic et convertit la charge utile :
   copier

   const p = msg.topic.split('/');
   msg.site = p[1];
   msg.etage = p[2];
   msg.capteur = p[3];
   msg.valeur = parseFloat(msg.payload);
   return msg;

5. Ajoutez un switch qui ne laisse passer que msg.valeur > 24, puis un mqtt out qui republie sur thermeo/alertes/temperature-haute.
6. Abonnez-vous à ce topic d'alerte depuis un terminal et faites monter la valeur d'un capteur. L'alerte doit apparaître.
7. Ajoutez maintenant l'hystérésis vue en M2 — le seuil nu produit une rafale. Utilisez le contexte de flux pour mémoriser l'état :
   copier

   const enAlarme = flow.get('alarme_' + msg.capteur) || false;
   if (!enAlarme && msg.valeur > 24.0) {
     flow.set('alarme_' + msg.capteur, true);
     msg.payload = 'ALARME ' + msg.capteur + ' : ' + msg.valeur;
     return msg;
   }
   if (enAlarme && msg.valeur < 23.0) {
     flow.set('alarme_' + msg.capteur, false);
     msg.payload = 'fin alarme ' + msg.capteur;
     return msg;
   }
   return null;   // rien a signaler

8. Faites osciller la valeur autour de 24 et vérifiez qu'une seule alarme part, comme au TP 4 de M2.
9. Construisez enfin la règle composée : alerter seulement si la température dépasse 24 °C et que l'humidité du même capteur est inférieure à 40 %. Il faut mémoriser la dernière humidité connue par capteur — c'est l'exercice difficile du TP.
10. Exportez votre flux en JSON et versionnez-le dans votre dépôt.

Les plateformes managées

Jour 3 · Règles et plateformes · 25 min

Vous venez de construire votre plateforme : broker, ingestion, base, règles. AWS IoT Core et Azure IoT Hub proposent la même chose, exploitée pour vous. Il faut savoir arbitrer.

Les quatre briques d'une plateforme managée

Le jumeau numérique — la brique qui manque

C'est le concept le plus intéressant, et celui que votre maquette ne couvre pas. Le jumeau — device shadow chez AWS — conserve deux états pour chaque objet :

• L'état constaté, ce que l'objet a rapporté en dernier.
• L'état désiré, ce qu'on voudrait qu'il soit.

Quand ils diffèrent, la plateforme envoie la consigne à l'objet dès qu'il se reconnecte. Cela résout exactement le problème posé au TP 6 de M2 : comment commander un objet qui dort ? On n'attend pas qu'il écoute — on écrit dans son jumeau, il se synchronise à son réveil.

Managé ou auto-hébergé

Quiz — Règles et plateformes

Jour 3 · Règles et plateformes · 7 min

TP 6 — La chaîne complète

Jour 3 · Règles et plateformes · 1 h 30

Assembler le pipeline de bout en bout et instruire le choix de plateforme.

1. Vous assemblez maintenant tout : nœud de M2 → broker sécurisé de M1 → Telegraf → InfluxDB → Node-RED. C'est le livrable du module.
2. Vérifiez que chaque maillon fonctionne isolément, puis lancez l'ensemble avec au moins trois capteurs sur deux sites.
3. Rédigez un docker-compose.yml qui démarre toute la pile en une commande. C'est ce qui rend votre maquette reproductible :
   copier

   # services attendus : mosquitto, influxdb, telegraf, nodered
   # volumes pour la configuration et la persistance
   # reseau commun, plus de host.docker.internal

4. Testez la reproductibilité : docker compose down -v puis docker compose up -d. Tout doit repartir, y compris les buckets et les tâches — sinon documentez ce qui manque.
5. Mettez en œuvre le motif du jumeau avec ce que vous avez : publiez une consigne en message retenu sur thermeo/lyon/etage1/capt-01/consigne, et faites en sorte que le capteur la lise à son réveil. Reliez cela au TP 6 de M2.
6. Rédigez une note de deux pages : le schéma de votre architecture, le volume de données attendu à trois ans, et une recommandation managé ou auto-hébergé pour Thermeo, argumentée sur au moins quatre critères dont la réversibilité.

Point de contrôle — fin du module M3

Jour 3 · Règles et plateformes · 20 min