CAPET informatique troisième concours 2026, épreuve écrite, option ingénierie informatiqueSujet
Troisième concours du Capet section sciences industrielles de l'ingénieur option ingénierie informatique - Sujet de l'épreuve écrite de la session 2026
CAPET
CONCOURS EXTERNE ET CAFEP CORRESPONDANT ET TROISIEME CONCOURS
Section : SCIENCES INDUSTRIELLES DE L'INGÉNIEUROption : INGÉNIERIE INFORMATIQUE
ÉPREUVE ÉCRITE DISCIPLINAIRE
L'épreuve, spécifique à l'option choisie, porte sur l'étude d'un système, d'un procédé ou d'une organisation. Elle a pour but de vérifier que le candidat est capable, à partir de l'exploitation d'un dossier technique remis par le jury, de conduire une analyse critique de solutions technologiques et de mobiliser ses connaissances scientifiques et technologiques pour élaborer et exploiter les modèles de comportement permettant de quantifier les performances d'un système ou d'un processus lié à la spécialité et définir des solutions technologiques
Durée : 5 heures
Calculatrice autorisée selon les modalités de la circulaire du 17 juin 2021 publiée au BOEN du 29 juillet 2021. L 'usage de tout ouvrage de référence, de tout dictionnaire et de tout autre matériel électronique est rigoureusement interdit.
Il appartient au candidat de vérifier qu'il a reçu un sujet complet et correspondant à l'épreuve à laquelle il se présente.
Si vous repérez ce qui vous semble être une erreur d'énoncé, vous devez le signaler très lisiblement sur votre copie, en proposer la correction et poursuivre l'épreuve en conséquence. De même, si cela vous conduit à formuler une ou plusieurs hypothèses, vous devez la (ou les) mentionner explicitement.
NB : Conformément au principe d'anonymat, votre copie ne doit comporter aucun signe distinctif, tel que nom, signature, origine, etc. Si le travail qui vous est demandé consiste notamment en la rédaction d'un projet ou d'une note, vous devrez impérativement vous abstenir de la signer ou de l'identifier. Le fait de rendre une copie blanche est éliminatoire.
INFORMATION AUX CANDIDATS
Vous trouverez ci-après les codes nécessaires vous permettant de compléter les rubriques figurant en en-tête de votre copie
Ces codes doivent être reportés sur chacune des copies que vous remettrez.
-Troisième concours externe du CAPET de l'enseignement public :
-Troisième concours externe du CAPET de l'enseignement privé :
Définition de l'épreuve
L'épreuve consiste en l'étude d'un système, d'un procédé ou d'une organisation.
Elle a pour objectif de vérifier la capacité du candidat à conduire une analyse critique de solutions technologiques et de mobiliser ses connaissances scientifiques et technologiques relevant de l'option du concours.
L'épreuve est constituée de plusieurs parties indépendantes, à traiter obligatoirement.
Conseils aux candidats
II est demandé aux candidats :
-de rédiger les réponses aux différentes parties sur des feuilles de copie séparées et clairement repérées ;
-de numéroter chaque feuille de copie et indiquer le numéro de la question traitée ;
-de rendre tous les documents réponses, même non complétés ;
-d'utiliser exclusivement les notations indiquées dans le sujet lors de la rédaction des réponses ;
-de justifier clairement les réponses ;
-d'encadrer ou souligner les résultats ;
-de présenter lisiblement les applications numériques, sans omettre les unités, après avoir explicité les expressions littérales des calculs ;
-de formuler les hypothèses nécessaires à la résolution des problèmes posés si celles-ci ne sont pas indiquées dans le sujet.
Sommaire
Page
Sommaire1
Contexte général2
Partie A3
Partie B5
Partie C8
Partie D10
Partie E12
Partie F14
DOCUMENTS RÉPONSES17
DOCUMENTS TECHNIQUES26
Système de supervision de microgrid
Contexte général
Afin de tendre vers la neutralité carbone, on observe la multiplication des installations de production d'énergie électrique, notamment solaires et le développement des dispositifs de stockage. Cela entraîne la création de microgrids, ou micro-réseaux, qui sont des réseaux électriques de petite taille, conçus pour fournir un approvisionnement électrique fiable à un petit nombre de consommateurs.
Ils agrègent de multiples installations de production locales et diffuses (panneaux photovoltaïques, mini-éoliennes, petite hydraulique...), des installations de consommation, des installations de stockage et des outils de supervision et de gestion de la demande.
Figure 1 : L'architecture d'un microgrid (Source : CRE)
Dans le cadre de ce sujet, l'étude porte sur la supervision d'un microgrid installé dans une entreprise du domaine des énergies renouvelables qui a pour objectif de rendre son siège français quasiment autonome en électricité.
Afin de contrôler les flux de puissances et s'assurer du bon fonctionnement des installations, la société Naiobee a mis en place un système de supervision du microgrid, articulé autour d'un composant central : la Naiobox.
Analyse structurelle et fonctionnelle du microgrid
Objectif : Etudier la structure du dispositif de supervision. Justifier l'utilité du microgrid mis en place.
D'un point de vue puissance, le microgrid étudié est constitué :
-de 230 m^2 de panneaux voltaïques sur les toits de la société pour une puissance
-de 8 bornes de recharge de véhicules électriques gérées par un système de gestion
-de batteries de stockage d'une capacité de 40 kW ⋅ h, permettant de stocker l'énergie
Afin de contrôler le fonctionnement de l'installation, la société NAloBEE a installé un système de supervision.
Le composant central de cette supervision est la Naiobox regroupant :
-une application SCADA (système de contrôle et d'acquisition de données) ;
-un programme de gestion centrale Node-RED (outil de développement low code) ;
-une base de données.
Le synoptique simplifié de l'installation de gestion de l'énergie est donné figure A1.
Figure A1 : Architecture simplifiée du Microgrid étudié
Un des objectifs de cette supervision est de permettre la visualisation et le stockage des données de puissance de chaque sous-installation. Le dispositif doit également surveiller les conditions de température, humidité et présence de gaz (composés organiques volatiles COVT et dihydrogène H_2 ) dans le local de batteries afin d'alerter en cas d'anomalie et d'activer la ventilation forcée.
Question A1 Compléter le diagramme des cas d'utilisation donné en DRA1.
Question A2 Indiquer quelle est la relation entre l'acteur utilisateur et administrateur dans ce diagramme. Donner les implications de cette relation.
Description des protocoles de communication utilisés
Les 2 onduleurs et le compteur ENEDIS envoient leurs données à la Naiobox via Ethernet en utilisant le protocole Modbus TCP/IP.
La puissance consommée et les informations issues des bornes de recharge sont obtenues via des requêtes API REST envoyées par le système de gestion de charge Evlink LMS.
Lorsque la production des panneaux solaires est plus importante que la consommation, du courant est réinjecté dans le réseau. Le compteur relié au réseau détecte alors cette injection de courant et commande alors la recharge des batteries de stockage en communiquant avec l'onduleur SI 4.4M par protocole Modbus TCP/IP.
La surveillance des conditions environnementales du local batterie est assurée par un module IOT M5Stack, basé sur le microcontrôleur d'architecture ESP32-S. Il envoie ces données à la Naiobox en utilisant le protocole MQTT par wifi. Des extraits de documents techniques du capteur SGP30 (COVT) et du capteur MQ8 (dihydrogène) sont données respectivement en DTA1 et DTA2.
Question A3 Compléter les liaisons en indiquant le protocole (ou type de liaison) utilisé puis les composants manquants du diagramme de déploiement simplifié fourni en DRA2.
Le dispositif vu précédemment permet d'obtenir les courbes de puissances données en DTA3.
Question A4 Donner la relation entre énergie et puissance. Puis, à partir de la courbe de la puissance de charge batterie, estimer l'énergie récupérée en kW ⋅ h sur ce jour particulier.
Question A5 Expliquer la chute brutale de puissance de charge batterie observée à partir de 9h15 alors que les panneaux solaires continuent à produire.
Le contrat d'électricité souscrit a une puissance de 150kV ⋅ A et correspondait au moment de la souscription à un tarif profil jaune. Dans cette tarification, le prix du MW ⋅ h, fixé sur le prix de marché, dépend de l'heure de consommation. On donne en annexe DTA4 les caractéristiques principales de cette tarification.
Question A6 En se basant sur les courbes de puissance consommée sur le site de l'entreprise et sur les tarifs de vente et rachat d'électricité, conclure sur l'intérêt de l'utilisation de batteries de stockage.
Partie B
Mesure du taux de dihydrogène par capteur analogique
En cas de défaillance de la batterie de stockage de l'énergie, celle peut entraîner un dégagement de différents gaz, dont du dihydrogène H_2. Par mesure de sécurité supplémentaire aux dispositifs de surveillance intégrés dans la batterie, une mesure du taux de dihydrogène est mise en place. Cette mesure est réalisée par un capteur MQ8 dont un extrait de documentation est donné en DTA2.
Objectif : Mettre en œuvre le capteur analogique MQ8 et vérifier si son association avec le M5 Stack permet bien de détecter un dégagement anormal de H_2.
On donne, en figure B1, les fonctionnalités disponibles sur les ports du M5Stack :
GPIO TYPE
Analog Function
M-BUS
Analog Function
GPIO TYPE
GND GND
GND
ADC
G35
ADC1_CH7
1
ADC
G36
ADC1_CH0
I
RST
EN
1/0/T
G23
MOSI
DAC/SPK
G25
ADC2_CH8
I/O/T
I/O/T
G19
MISO
DAC
G26
ADC2_CH9
I/O/T
1/0/T
G18
SCK
3.3V
I/0/T
G3
RXD1
TXD1
G1
1/0/T
1/0/T
G16
RXD2
TXD2
G17
I/O/T
1/0/T
G21
SDA
SCL
G22
I/O/T
I/O/T
ADC2_CH2/T2
G2
GPTO
GPIO
G5
I/O/T
1/0/T
ADC2_CH5
G12
IIS_SK
IIS WS
G13
ADC2_CH4/T4
I/O/T
1/0/T
ADC2_CH3/T3
G15
IIS_OUT
IIS.MK
G0
ADC2_CH1/T1
I/O/T
HPWR
IIS IN
G34
ADC1_CH6
1
Figure B1 : Ports M5Stack
Question B1
Proposer et justifier le choix d'un numéro de port du M5Stack pouvant être utilisé pour recueillir le signal issu du capteur MQ8.
Le capteur MQ8 est alimenté sous 5 V alors que le microcontrôleur ESP32 du M5Stack fonctionne sous une tension de 3,3 V. On doit donc insérer un montage permettant d'adapter le niveau de tension. On propose, ci-dessous, un circuit dans lequel on a choisi R2 = 10kΩ.
Figure B2 : Circuit d'adaptation de tension pour ESP32
Question B2
Calculer la valeur à imposer à R1 de manière à ce qu'une tension Vout de 5 V entraîne une tension Vesp de 3,3 V sur le port de l'ESP32.
Question B3 Donner le nom du montage entre la sortie du capteur MQ8 et Vout. En consultant le schéma de câblage du capteur MQ8 dans la documentation technique DTA2, indiquer son intérêt ici.
Le convertisseur analogique numérique (CAN) intégré dans l'ESP32 du M5Stack a une résolution de 12 bits et travaille sur la plage de tension d'entrée [0; 3, 3 V].
Question B4 Indiquer ce que représente la résolution d'un CAN. En déduire la valeur du quantum du CAN (la plus petite variation de tension détectable par le CAN ou tension correspondant à un incrément de 1 en sortie de CAN).
Dans les conditions d'utilisation du capteur, on a relevé, ci-dessous, la relation entre tension au niveau du CAN de l'ESP32 et concentration en dihydrogène en ppm (parties par million).
Figure B3 : Tension CAN ESP32 en fonction de la concentration en H2
Question B5 | Calculer le nombre N_(seuil) qui sera délivré par le CAN de l'ESP32 pour une concentration d'hydrogène de 300 ppm, seuil à partir duquel une alerte sera déclenchée et la ventilation mise en route.
Dans les questions suivantes, l'objectif est de coder en Python les fonctions qui permettront d'obtenir la valeur du taux de concentration en dihydrogène à partir de la valeur de sortie du CAN.
Question B6 Donner le code de la fonction convCAN qui prend l'argument valeurCAN, un entier correspondant à la valeur de sortie du CAN et renvoie la valeur de la tension appliquée sur le CAN correspondante.
Afin d'obtenir par programmation la correspondance entre la tension délivrée par le capteur MQ8 et la concentration en dihydrogène, on dispose d'une table représentant la courbe donnée en figure B3. On donne, ci-dessous, un extrait partiel de la déclaration de cette table simplifiée, sous la variable locale corresMQ8.
Question B7 Donner en python la fonction convTauxH2 qui pour une valeur de tension Vesp envoyé par le capteur MQ8, en argument de la fonction, renvoie le taux de dihydrogène correspondant.
La fonction devra renvoyer le taux de H_2 correspondant à la dernière tension de la table inférieure à Vesp si la valeur de la tension est bien comprise entre les valeurs extrêmes de la table.
Par exemple, avec la table corresMQ8, pour une tension Vesp de 1,5 V, la fonction doit renvoyer un taux de 163 ppm.
En fait, le CAN intégré dans l'ESP 32 comporte des non-linéarités entre la tension d'entrée et la valeur renvoyée par le CAN. On donne, figure B4, la relation entre tension et valeur renvoyée.
Figure B4 : Caractéristique CAN ESP32
Question B8
Conclure alors sur la capacité du dispositif et des fonctions étudiées précédemment à fournir une valeur correcte du taux de dihydrogène. Indiquer si la détection de seuil à 300 ppm est réalisable dans ces conditions.
Partie C
Mesure du taux de composants volatiles COVT
Une mesure complémentaire, moins spécifique que la mesure du taux de H_2 vu précédemment, pour mesurer d'éventuels dégagements gazeux dus à un dysfonctionnement des batteries, est d'utiliser un capteur mesurant le taux de composés organiques totaux (COVT).
Objectif : Etudier la programmation de l'ESP32 du M5stack (programmation objet en C++) afin de mesurer le taux de COVT.
On souhaite effectuer une mesure toutes les 10 secondes et on définit initialement 2 seuils pour la surveillance du taux de COVT :
-Message d'alerte si le taux de COVT est supérieur à 500 parties par milliard (ppb) ou si la croissance de ce taux est supérieure à 200 ppb par minute.
-Ventilation si le taux de COVT est supérieur à 1000 ppb.
La documentation technique partielle du SGP30 est fournie en DTA1.
Question C1 Justifier le choix du capteur SGP30 par rapport aux besoins définis précédemment.
Question C2 Compléter le diagramme de séquence simplifié fourni en DRC1 qui décrit les échanges entre ESP32 et SGP30
La gestion du capteur commence par l'instanciation d'un objet SGP30, que l'on nomme capteurCovt_Batt par l'instruction : SGP30 capteurCovt_Batt;
Question C3 Indiquer comment on appelle la méthode permettant d'instancier un objet d'une classe.
La classe SGP30 utilise les classes I2CDevice et TwoWire pour gérer la liaison I2C. On donne en DTC1 la structure simplifiée de la classe SGP30 dans un diagramme de classe.
Question C4 Donner les 2 instructions qui permettent d'initialiser l'objet capteurCovt_Batt avec les paramètres par défaut (méthodes begin et IAQinit).
Le lancement d'une mesure se fait en appelant la méthode IAQmeasure. Cette méthode stocke la valeur du taux de COVT dans l'attribut TVOC (la méthode renvoie true si la mesure a réussi, false sinon). On donne en DRC2 le code partiel qui s'exécute en boucle, permettant de relever le taux de COVT.
On souhaite stocker le taux de COVT dans une variable locale nommée tauxTvoc.
Question C5 Indiquer (et justifier) si l'attribut TVOC est public ou privé. En ligne 12 de DRC2, déclarer et réaliser l'affectation de tauxTvoc.
On veut stocker le taux de croissance du taux de COVT en ppb par minutes dans la variable slopeCOVT.
Question C6 Lignes 15 à 17 de DRC2, déclarer cette variable et donner les instructions qui permettent de réaliser le calcul.
On considérera que la ventilation forcée est activée par appel de la fonction triggerVentilation() et arrêtée par appel de la fonction stopVentilation(). Par ailleurs, le message d'alerte est lancé par la fonction alertCOVT().
Question C7 Compléter, dans DRC2 lignes 19 à 24, le code permettant de gérer le déclenchement de la ventilation et le lancement du message d'alerte en fonction des indications données en début de cette partie de sujet.
Question C8 Conclure quant à la capacité de déclencher l'alerte et de mettre en place une ventilation efficace en cas de taux élevé de COVT. Proposer éventuellement des pistes de modification.
Partie D
Analyse de la communication Naiobox - Onduleur de panneaux solaires
Toutes les 5 secondes, la Naiobox utilise un réseau informatique pour demander aux différents équipements du microgrid (onduleur des panneaux solaires, onduleur de batteries, LMS, compteur EDF…) des informations (tensions, intensités, puissances…) sur l'énergie électrique produite, stockée ou consommée.
Objectif : Analyser la communication entre la Naiobox et l'onduleur des panneaux solaires.
Afin d'identifier les paramètres réseau de la Naiobox, on saisit la commande décrite à la figure D1.
adminene@naiobox : ~
Fichier Edition Onglets Aide
adminene@naiobox : ~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether dc:a6:32:20:ed:de brd ff:ff:ff:ff:ff:ff
inet 192.168.8.1/28 brd 192.168.8.15 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fe80::481:d427:f7ea:395f/64 scope link noprefixroute
valid_lft forever preferred_lft forever
adminene@naiobox : ~ $ ip route
default via 192.168.8.14 dev eth0 proto static metric 100
192.168.8.0/28 dev eth0 proto kernel scope link src 192.168.8.1 metric 100
adminene@naiobox :~ $
Figure D1 : Console de la Naiobox
Question D1 Identifier la configuration réseau de la Naiobox puis compléter le tableau du document réponse DRD1. À ce stade, certaines cases de la colonne Naiobox ne peuvent être complétées.
On poursuit l'identification des composants en utilisant l'analyseur de paquets Wireshark afin de capturer les communications entre la Naiobox et l'onduleur. Les résultats sont présentés dans les documents techniques DTD1, DTD2, DTD3.
Question D2
Compléter le tableau du document réponse DRD1 à l'aide du document technique DTD1.
Question D3
Indiquer quels filtres ont été appliqués à la trace Wireshark pour obtenir la copie d'écran de documents techniques DTC1. La ligne de commande au format Wireshark n'est pas demandée.
Question D4
À l'aide du document technique DTD1, compléter le schéma du document de réponse DRD2. Citer les couches du modèle OSI, du modèle TCP/IP et les protocoles utilisés dans la communication Naiobox / onduleur des panneaux solaires pour chacune des couches.
Question D5
Modbus est à l'origine une communication série (Modbus RTU). Ici, dans le protocole Modbus TCP, les données Modbus sont encapsulées dans une trame TCP. Expliquer ce que cela signifie. Citer deux avantages à cette solution par rapport au Modbus série.
Question D6
Expliquer à quoi servent les trames 85 à 87 (documents techniques DTD1).
Question D7
À l'aide du document technique DTD4, indiquer l'utilité du flag PSH (push) présent dans le document technique DTD2 pour l'expéditeur puis pour le récepteur.
Question D8
À partir des documents techniques DTD1, DTD4, indiquer quelles sont les données demandées par le client dans la trame 152.
Question D9
À partir des documents techniques DTD3, DTD4, indiquer quelle est l'information et sa valeur du microgrid qui sont transmises à la Naiobox pour être stockées dans la base de données. Justifier votre réponse.
Question D10
Conclure en complétant le diagramme de séquence du document réponse DRD3 afin de modéliser le transfert de données entre la Naiobox et l'onduleur pour les traces Wireshark enregistrées.
Partie E
Conception des requêtes SQL
Une base de données SQLite est hébergée dans la Naiobox. Plusieurs flux Node Red sont exécutés sur la Naiobox pour collecter, formater puis enregistrer les données dans la base de données.
Objectif : Écrire une partie des requêtes SQL du système de gestion de bases de données.
La base de données est organisée suivant le schéma relationnel suivant :
Les types des différents attributs des tables Mesures, Appareils, Lieux et Grandeurs sont indiqués entre parenthèses. Les clés primaires de chacune des tables sont soulignées. On note les contraintes suivantes dans les données de la table:
-La table Mesures contient l'identifiant unique de l'appareil dont provient la mesure, la date et l'heure de la mesure, la valeur mesurée ainsi que l'identifiant de la grandeur physique mesurée.
-La table Appareils décrit chaque appareil du microgrid relié au réseau (onduleurs de panneaux solaires, onduleurs de batteries...) en spécifiant son index (ld_appareil) son nom, son numéro de série et un identifiant unique du lieu où se trouve l'équipement.
-La table Lieux répertorie le lieu où peuvent être placés les équipements ainsi qu'un identifiant unique.
-La table Grandeurs répertorie les grandeurs physiques qui peuvent être mesurées en indiquant un identifiant unique, le nom de la grandeur physique mesurée et son unité.
La base de données SQLite gère les dates au format DATETIME qui est un Texte (iso-8601). Les dates contiennent aussi I'heure sous la forme : AAAA-MM-JJ HH:MM:SS).
Exemples :
-Le 1^(er) janvier 2025 à 11h00 s'écrit : '2025-01-01 11:00:00'
-Le 14 juillet 2025 à 23h55 et 10 secondes s'écrit '2025-07-14 23:55:10'
Un rappel des mots clés et fonctions SQL usuels est fourni dans le document technique DTE1.
Question E1 Donner les requêtes SQL qui ont permis la création de la table Lieux suivante avec ses valeurs.
Id_lieu
nom
5
Toiture
4
Local Technique 3er étage
3
Local Technique 2er étage
2
Local Technique 1er étage
1
Local Technique rez-de-chaussée
Question E2 Indiquer les avantages de stocker le nom dans une table à part et de faire une jointure avec la table Appareils plutôt que d'écrire directement le nom du lieu dans la table Appareils.
Question E3 Créer la requête SQL permettant d'ajouter une mesure de 11245 W effectuée le 25/08/2025 à 12h00 par l'onduleur batterie (id_appareil = 2) dans la table Mesures. Pour cette requête, grandeur_id=5.
Question E4 Proposer une requête de sélection permettant de vérifier que l'ajout a bien été réalisé.
Question E5 Créer une requête qui liste les appareils situés au "Local Technique rezde-chaussée", avec leur nom et leur numéro de série.
Question E6 Créer une requête SQL permettant de rechercher toutes les mesures de puissance AC de l'onduleur de panneaux solaires (id_appareil = 3) pour la date du 7 septembre 2025. Les résultats devront être classés du plus ancien au plus récent et devront fournir l'id_mesure, la date et l'heure de mesure, la valeur de la puissance AC, la grandeur physique mesurée (grandeur_id=5) et l'unité de chaque enregistrement.
Question E7 Créer une requête qui calcule l'énergie totale produite par les panneaux solaires sur la journée du 7/9/2025 en kilowatt heure (kW•h). L'onduleur de panneaux solaires a pour index : (appareil_id=3) et la mesure a pour index de grandeur (grandeur_id=5). Une mesure est enregistrée toutes les 5 secondes. Expliquer le calcul.
Partie F
Paramétrage de Node-RED sur la Naiobox
La Naiobox est le composant central de la supervision du microgrid. Il permet de récupérer les informations envoyées par les différents constituants du microgrid et de stocker les données dans une base de données pour ensuite être consultées grâce à un logiciel SCADA implanté dans la Naiobox.
Comme les équipements communiquant avec la Naiobox utilisent des protocoles différents, le concepteur de la Naiobox a choisi de réaliser la collecte de ces données via l'utilisation du logiciel Node-RED : outil de programmation visuelle développé par IBM, principalement destiné à connecter des objets, services ou API entre eux via un système de flux de messages au format JSON (flows).
Objectif : Sécuriser le logiciel Node-RED sur environnement Linux, paramétrer la communication MQTT entre Node-RED et le M5 stack du local batterie.
La Naiobox contient un mini PC géré par un système d'exploitation Linux. Après installation du logiciel Node-RED, l'accès à l'interface de programmation de Node-RED, se fait par défaut en HTTP. Il est donc décidé de configurer le logiciel afin de n'autoriser que des connexions utilisant le protocole HTPPS.
Question F1 Expliquez ce qu'est le protocole HTTPS et en quoi il est plus sécurisé que le protocole HTTP.
Dans un premier temps, afin de générer et stocker des certificats privés, on exécute sur la Naiobox les instructions suivantes :
adminene@naiobox : ~ $ mkdir ssl
adminene@naiobox : ~ $ cd ssl
adminene@naiobox : ~/ssl $ openssl genrsa -out privatekey.pem 2048
adminene@naiobox : ~/ssl $ openssl req -new -sha256 -key privatekey.pem -out csr.pem
adminene@naiobox : ~/ssl $ openssl x509 -req -in csr.pem -signkey privatekey.pem -out certificate.pem
Question F2 Indiquer ce que réalisent les deux premières instructions : mkdir ssl et cd ssl.
Les 3 dernières instructions permettent de générer un certificat (fichier certificat.pem) et une clé privée (privatekey.pem). Après l'exécution de celles-ci, on veut s'assurer qu'ils sont bien présents.
Question F3 | En se basant sur la documentation technique DTF1, donner l'instruction permettant de visualiser tous les fichiers (même cachés) avec leurs droits, présents dans le dossier ssl et ainsi vérifier que la clé privée a bien été générée.
L'exécution de l'instruction précédente a permis d'obtenir le résultat ci-dessous.
Figure F1 : Affichage des fichiers dans le dossier ssl
Question F4 Résumer les droits en écriture et lecture affectés aux fichiers précédemment cités, les justifier par rapport à leur utilisation.
Pour activer et configurer la connexion en HTTPS dans Node-Red, il faut modifier un fichier nommé settings.js. Il s'agit d'un fichier javascript, comportant des propriétés d'objet JavaScript qu'il faut paramétrer.
On donne en DRF1 l'extrait du fichier settings.js relatif à la sécurité dans Node-RED. Dans cet extrait, une section permet de définir où Node-RED doit aller chercher la clé publique et le certificat, grâce à l'instruction : require("fs").readFileSync(chemin_fichier).
Question F5 À partir de l'image figure F1, compléter la partie HTTPS du fichier settings.js dans DRF1, afin de donner le chemin de la clé privé et du certificat.
Par défaut, l'accès à Node-RED ne nécessite aucune identification. Il faut donc paramétrer un utilisateur administrateur (admin) dans le fichier settings.js. On génère alors le hash du mot de passe que l'on veut associer au compte admin via l'instruction : Node-red admin hash-pw.
On copie ensuite ce mot de passe dans la section adminAuth du fichier settings.js dans la propriété password (cf. DRF1).
Question F6 Donner la propriété principale d'un hash qui justifie son utilisation ici.
Le système à microcontrôleur M5Stack permet la mesure des conditions environnementales du local batterie. Il transmet ces informations à la NAIOBOX en utilisant le protocole MQTT. Ce protocole est présenté brièvement en DTF2. Le broker (serveur) MQTT est installé sur la Naiobox.
Par exemple, toutes les 10 secondes, le M5stack transmet à la Naiobox le taux de composants organiques volatiles (TVOC en anglais), qui peut permettre de détecter un début de défaillance des batteries. Cette communication est gérée en C++ dans le M5stack notamment via l'instruction : client.publish("localBatt/TVOC", payload, true). La variable payload contient l'information du taux de TVOC et l'horodatage de la mesure.
On souhaite paramétrer un nœud Node-RED permettant de collecter cette information.
Question F7 Proposer un niveau de QOS en justifiant votre choix, puis compléter en DRF2 les champs sujet et QoS.
Une capture de trames a été effectuée au niveau de la Naiobox, puis on a appliqué un filtre de manière à ne conserver que les trames concernant le protocole MQTT. Une capture d'écran du logiciel Wireshark est donnée en DTF3.
Question F8 Identifier les adresses IP de la carte M5Stack et de la Naiobox. Compléter alors le champ serveur du bloc de configuration du nœud MQTT de Node-Red en DRF2 avec l'adresse complète du broker (IP + port).
Les règles de sécurité du broker MQTT sont définies dans son fichier de configuration. On peut notamment y paramétrer le port utilisé, l'autorisation de connexions non authentifiées, l'emplacement des éventuels mots de passe, les clés et certificats... On donne en figure F2 la copie du fichier de configuration utilisé lors des captures de trames.
# Place your local configuration in /etc/mosquitto/conf.d/
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
pid_file /run/mosquitto/mosquitto.pid
allow_anonymous true
password_file /etc/mosquitto/passwd
listener 1883
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
Figure F2 : Fichier de configuration du broker MQTT
Question F9 Au vu de la figure F2 et du détail de trame MQTT, conclure sur les éventuelles failles dans la sécurité de la communication par MQTT.
NE RIEN ECRIRE DANS CE CADRE
Diagramme de cas d'utilisation du système de supervision
Diagramme de déploiement du système de supervision
NE RIEN ECRIRE DANS CE CADRE
DOCUMENT RÉPONSE DRC1 (Question C2)
Diagramme de séquence mesure COVT avec SGP 30
DOCUMENT RÉPONSE DRC2 (Questions C5 à C7)
Code de mesure du taux de COVT
Ligne Code C++
// Variables
uint16_t lastTvoc = 0; // dernière mesure de taux de COVT
unsigned long lastMeas = millis();
While (true) { //boucle de mesure
unsigned long now = millis();
if (now - lastMeas >= 10000) { //mesure toutes les 10 s
lastMeas = now;
if (sgp.IAQmeasure()) { // lancement de la mesure
// stockage du taux actuel mesuré dans la variable tauxTvoc
..........................................................................................
// calcul du taux croissance par minute du taux de COVT
.........................................................................................
.............................................................................................
.........................................................................................
//déclenchement de la ventilation et de l'alerte
if
{alerteCOVT();}
if
{ triggerVentilation();}
.........................................................................................
(-........................................................................................
else
{M5.Lcd.println("Erreur mesure !");}
}
NE RIEN ECRIRE DANS CE CADRE
Nom
Onduleur panneaux solaires
Naiobox
Rôle (client ou serveur) :
Adresse IPv4 :
Masque de sous-réseau :
Passerelle :
Port :
DOCUMENT RÉPONSE DRD2 (Question D4)
NE RIEN ECRIRE DANS CE CADRE
DOCUMENT RÉPONSE DRD3 (Question D10)
DOCUMENT RÉPONSE DRF1 (Questions F5 et F6)
Fichier de configuration Node-RED settings.js
/****************************************************************************
*Security
* - adminAuth
* - https
* - httpsRefreshInterval
* - requireHttps
* - httpNodeAuth
* - httpStaticAuth
***************************************************************************/
/** To password protect the Node-RED editor and admin API, the following
* property can be used. See https://nodered.org/docs/security.html for details.*/
adminAuth: {
type: "credentials",
users: [{
username: "admin",
password:"$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tI8sJogENOMcxWV9DN.",
permissions: "*"
}]
},
/** The following property can be used to enable HTTPS
* This property can be either an object, containing both a (private) key
* and a (public) certificate, or a function that returns such an object.
* See http://nodejs.org/api/https.html#https_https_createserver_options_requestlistener
* for details of its contents. */
/** Option 1: static object */
https: {
key: require("fs").readFileSync(_____.................................................), // à compléter
cert: require("fs").readFileSync(_..................................................) // à compléter
},
/** If the ˋhttpsˋ setting is a function, the following setting can be used
* to set how often, in hours, the function will be called. That can be used
* to refresh any certificates. */
httpsRefreshInterval : 12,
/** The following property can be used to cause insecure HTTP connections to
* be redirected to HTTPS. */
requireHttps: true,
NE RIEN ECRIRE DANS CE CADRE
DOCUMENT RÉPONSE DRF2 (Questions F7 et F8)
Configuration nœud MQTT sur Node-RED
Supprimer
Annuler
Terminer
* Propriétés
□
() Serveur
□
□
Action
□
Sujet
□
** QoS
□
→ Sortie
□
- Nom
□
DOCUMENT TECHNIQUE DTA1 (questions A3, C1 et C2)
Documentation partielle capteur SGP30
Datasheet SGP30
Sensirion Gas Platform
-Multi-pixel gas sensor for indoor air quality applications
Air quality signals TVOC and CO_(2eq) are calculated from Ethanol and H_2 measurements using internal conversion and baseline compensation algorithms.
Parameter
Signal
Values
Comments
Output range
TVOC signal
0 ppb to 60000 ppb
Maximum possible output range. The gas sensing performance is specified for the measurement range as defined in Table 1
CO2eq signal
400 ppm to 60000 ppm
1
Range
Resolution
0ppb − 2008ppb
1 ppb
TVOC signal
2008 ppb - 11110 ppb
6 ppb
11110ppb − 60000ppb
32 ppb
CO_(2eq) signal
400ppm − 1479ppm
1 ppm
1479ppm − 5144ppm
3 ppm
5144 ppm - 17597 ppm
9 ppm
17597ppm − 60000ppm
31 ppm
Sampling rate
TVOC signal
1 Hz
The on-chip baseline compensation algorithm has been optimized for this sampling rate. The sensor shows best performance when used with this sampling rate.
CO2eq signal
1 Hz
Table 2 Air quality signal specifications.
Measurement Communication Sequence:
The typical communication sequence between the I2C master (e.g., a microcontroller in a host device) and the sensor is described as follows:
The sensor is powered up, communication is initialized. The I2C master sends the commands sgp30_get_feature_set (begin method) and then sgp30_iaq_init.
The I2C master periodically requests measurement and reads data, in the following sequence:
a.I2C master sends a measurement command (sgp30_measure_iaq).
b.The sensor sends back a message containing the CO2eq concentration rates (in ppm) and TVOC (in ppb).
c.I2C master reads out the measurement result.
Command codes
All SGP30 commands and data are mapped to a 16-bit address space. Additionally, data and commands are protected with a CRC checksum to increase the communication reliability. The 16-bit commands that are sent to the sensor already include a 3-bit CRC checksum (Data sent from and received by the sensor is always succeeded by an 8-bit CRC).
Command
Hex. Code
Parameter length including CRC [bytes]
Response length including CRC [bytes]
Measurement duration [ms]
Typ.
Max.
sgp30_iaq_init
0x2003
-
-
2
10
sgp30_measure_iaq
0x2008
-
6
10
12
sgp30_get_iaq_baseline
0x2015
-
6
1
10
sgp30_set_iaq_baseline
0x201e
6
-
1
10
sgp30_set_absolute_humidity
0 × 2061
3
-
1
10
sgp30_measure_test ^(10)
0 × 2032
-
3
200
220
sgp30_get_feature_set
0x202f
-
3
1
10
sgp30_measure_raw
0x2050
-
6
20
25
sgp30_get_tvoc_inceptive_baseline
0x20b3
-
3
1
10
sgp30_set_tvoc_baseline
0x2077
3
-
1
10
Table 3 command codes
Documentation capteur MQ8
MQ-8 Hydrogen Gas Sensor
Features
It has good sensitivity to hydrogen gas in wide range,and has advantages such as long lifespan,low cost and simple drive circuit&etc.
Main Applications
It is widely used in domestic gas leakage alarm,industrial flammable gas alarm and portable gas detector.
Basic Circuit
Fig2.MQ-8 Test Circuit
Instructions:The above fig is the basic test circuit of MQ-8.The sensor requires two voltage inputs:heater voltage (V_H) and circuit voltage (V_C).V_H is used to supply standard working temperature to the sensor and it can adopt DC or AC power,while V_(RL) is the voltage of load resistance R_L which is in series with sensor.Vc supplies the detect voltage to load resistance R_L and it should adopts DC power.
Technical Parameters
Stable. 1
Model
MQ-8
Sensor Type
Semiconductor
Standard Encapsulation
Bakelite,Metal cap
Target Gas
Hydrogen
Detection range
100 ∼ 1000ppm(H_2 gas)
Sensor character under standard test conditions
Heater Resistance
R_H
30Ω ± 3Ω(room tem.)
Heater consumption
P_H
≤ 950 mW
Sensitivity
S
Rs(in air)/Rs(in 1000ppmH_2) ≥ 5
Output Voltage
V_(RL)
2.5 V ∼ 4.0 V(in 1000ppmH_2 )
Concentration Slope
α
≤ 0.6(R_(1000ppm)/R_(400ppm)H_2)
Fig3.Typical Sensitivity Curve
Calculation formula:
Resistance of Sensitive materials (Rs)=(Vc/VRL-1)×RL
Relevés de puissance sur le site
DOCUMENT TECHNIQUE DTA4 (question A6)
Caractéristiques tarification électrique
a)Tarif de vente d'électricité aux entreprises
Les entreprises ayant une puissance électrique souscrite supérieure à 36kV ⋅ A sont obligées de souscrire à un contrat d'électricité au prix de marché. Elles peuvent alors souscrire à une offre à prix fixe ou à prix indexé sur le marché de gros de l'électricité.
On donne ci-dessous une estimation de tarif à prix indexé pour le mois d'octobre 2024 pour une tarification profil jaune, tarifs calculés à partir du prix de référence HT. Les tarifs réellement appliqués varient en fonction du fournisseur et du contrat signé.
Prix de référence HT
Abonnement en €/kVA (ou €/kW)
Parts variables en €/MWh
Pointe
Heures Pleines Hiver
Heures Creuses Hiver
Heures Pleines Été
Heures Creuses Été
"Profil Jaune" Client base moyen
45
--
242
186
132
115
"Profil Jaune" Client base saisonnalisé
41
--
251
195
134
118
Tarifs octobre 2024, source SELECTRA
Les plages horaires des heures creuses et heures pleines sont définies localement par Enedis et dépendent de la gestion du réseau électrique dans cette zone. En général, les heures creuses couvrent une période de 8 heures par jour. Elles sont souvent concentrées sur la nuit entre 22h00 et 6h00 ou réparties entre des créneaux comme 12h00 à 17h00 et 20h00 à 8h00. Les plages spécifiques peuvent varier selon le contrat.
a)Tarif de rachat
On donne ci-dessous les tarifs de rachat par EDF de l'électricité d'origine photovoltaïque correspondant au même instant que dans le tableau ci-dessus.
Puissance de l'installation
Tarif d'achat du kW ⋅ h en vente au surplus
≤ 9kWc
0,1276 €
≤ 100kWc
0,0765 €
Remarque : Actuellement le prix de rachat en surplus a évolué , il est de 0,04 € par kW•h pour une puissance inférieure à 9 kWc et 0,0731 € sinon.
The following table lists the supported MODBUS register values. Unsupported values are indicated by the NOT_IMPLEMENTED value. The base register of the Device Specific block is set to 40070 (MODBUS PLC address [base 1]), or 40069 (MODBUS Protocol Address [base 0]).
-acc32 is a uint32 accumulator that should always increase. Its value is in the range of 0...4294967295.
-Scale Factors. As an alternative to floating point format, values are represented by Integer values with a signed scale factor applied. The scale factor explicitly shifts the decimal point to left (negative value) or to the right (positive value).
For example, a value "Value" may have an associated value "Value_SF"
Value = "Value" * 10^ Value_SF for example:
-For "Value" = 2071 and "Value_SF" = -2 Value = 2071^∗ 10^∧ − 2 = 20.71
-For "Value" = 2071 and "Value_SF" = 2 Value = 2071^∗ 10^∧2 = 20710
Address
Size
Name
Type
Units
Description
(base 0)
(base 1)
40091
40092
1
I_AC_PF ^1
int16
%
Power Factor
40092
40093
1
I_AC_PF_SF ^1
int16
Scale factor
40093
40094
2
I_AC_Energy_WH
acc32
WattHours
AC Lifetime Energy production
40095
40096
1
I_AC_Energy_WH_SF
uint16
Scale factor
40096
40097
1
I_DC_Current
uint16
Amps
DC Current value
40097
40098
1
I_DC_Current_SF
int16
Scale factor
40098
40099
1
I_DC_Voltage
uint16
Volts
DC Voltage value
40099
40100
1
I_DC_Voltage_SF
int16
Scale factor
40100
40101
1
I_DC_Power
int16
Watts
DC Power value
40101
40102
1
I_DC_Power_SF
int16
Scale factor
40103
40104
1
I_Temp_Sink
int16
Degrees C
Heat Sink Temperature
40106
40107
1
I_Temp_SF
int16
Scale factor
40107
40108
1
I_Status
uint16
Operating State
40108
40109
1
I_Status_Vendor
uint16
Vendor-defined operating state and error codes. For error description, meaning and troubleshooting, refer to the SolarEdge Installation Guide.
Fiche résumée des fonctions et mots clés SQL usuels
Description
Syntaxe SQL
Créer une base de données
CREATE DATABASE nom de la_base;
Créer une table dans une base de données
CREATE TABLE nomTable ( id INT NOT NULL AUTO_INCREMENT, champ1 DOUBLE, champ2 VARCHAR(255), champ3 TIMESTAMP DEFAULT NOW(), PRIMARY KEY(id));
Écrire une nouvelle entrée dans une table de BDD
INSERT INTO nomTable(champ1, champ2, champ3) VALUES('valeur1', 'valeur2', NOW());
Modifier les informations de l'entrée dont le champ id = 51
UPDATE nomTable SET nomChamp1=10, nomChamp2=32 WHERE id=51;
Sélectionner toutes les informations de la table
SELECT * FROM nomTable;
Sélectionner seulement les informations d'un champ
SELECT nomChamp FROM nomTable;
Sélectionner tous les champs de la table correspondant à deux critères
SELECT * FROM nomTable WHERE nomChamp1 = 'poste' AND nomChamp3 < 12;
Sélectionner sur plusieurs tables (jointure)
SELECT * FROM nomTable1 JOIN nomTable2 ON nomTable1.nomChamp1 = nomTable2.nomChamp4;
Appliquer une fonction d'agrégation (MIN, MAX, COUNT, AVG) sur des valeurs d'un champ regroupées
SELECT MAX(nomChamp1) FROM nomTable GROUP BY nomChamp2;
Utiliser DATE() pour extraire la partie date
SELECT DATE(nomChamp3) FROM nomTable;
Utiliser NOW() pour insérer la date et l'heure actuelles
INSERT INTO nomTable(champ1, champ2, champ3) VALUES('valeur1', 'valeur2', NOW());
Utiliser CASE pour des conditions personnalisées
SELECT nomChamp1, CASE WHEN nomChamp1 > 100 THEN 'Élevé' ELSE 'Faible' END AS categorie FROM nomTable;
Ordonner les résultats d'une requête par ordre croissant ou décroissant
SELECT * FROM nomTable ORDER BY nomChamp1 ASC;
Filtrer par intervalle de dates
SELECT * FROM nomTable WHERE champ3 BETWEEN '2025-01-01' AND NOW();
Les mots en gras dans la colonne de droite sont des mots réservés par le langage SQL.
DOCUMENT TECHNIQUE DTF1 (questions F3 et F4)
Droits des fichiers sous Linux
Commande Is:
La commande ls sert à lister les fichiers et répertoires dans un dossier.
Syntaxe de base : Is [options] [chemin]
Par défaut, Is affiche les fichiers du dossier courant (dans l'ordre alphabétique, sans détails, sans afficher les fichiers cachés).
Option
Signification
Exemple
-l
Affichage long (détails : droits, taille, date)
Is -I
-a
Affiche tous les fichiers, y compris les fichiers cachés
Is -a
-h
Affiche les tailles dans un format lisible (Ko, Mo...) - à utiliser
Is -lh
-t
Trie par date de modification (plus récent en premier)
Is -It
-r
Inverse l'ordre d'affichage (alphabétique ou temporel)
Is -Ir
-S
Trie par taille (du plus gros au plus petit)
Is -IS
-R
Affiche le contenu des sous-répertoires (récursif)
Is -R
-d
Affiche le nom d'un dossier sans lister son contenu
Is -ld dossier
-1
Affiche un fichier par ligne
Is -1
Affichage des droits sur les fichiers (permissions) :
Les droits sous Linux déterminent qui peut lire, écrire ou exécuter des fichiers et des répertoires. Ils sont essentiels pour la sécurité et la gestion des accès dans le système.
Voici le format de sortie de l'instruction ls avec l'option permettant d'afficher les droits sur les fichiers (exemple pour un fichier) :
Les 10 premiers caractères représentent donc les droits affectés au fichier :
-1^(er) caractère : type de fichier :
-: fichier régulier
d: dossier
-Caractères 2 à 4 : droits du propriétaire :
r: lecture , w : écriture , x : exécution
-Caractères 5 à 7 : droit du groupe
-Caractères 8 à 10 : droit des autres utilisateurs
DOCUMENT TECHNIQUE DTF2 (question F7)
Protocole MQTT
MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie léger s'appuyant sur la suite de protocoles TCP/IP. Il est particulièrement utile pour les applications loT (Internet des Objets). Il est conçu pour être fiable, simple, léger en bande passante.
Fonctionnement
Un client va publier des données sur un sujet (topic) et envoyer ces données au broker (serveur). Le broker, va renvoyer ces données aux clients abonnés (subscribers) ayant préalablement fait la demande d'abonnement pour ce sujet (topic) au broker .
Un topic est une chaîne de caractère. Les topics peuvent avoir une hiérarchie qui permet de sélectionner finement les informations que l'on désire en séparant les niveaux de sujets par un « / ».
Exemple de structuration des topics : contexte/emplacement/capteur ou action/type… evlink/borne1/energie evlink/borne1/cmd evlink/borne1/# ( le # signifie tous les topics du sous niveau considéré )
Qualité de Service
Le protocole MQTT offre trois niveaux de Qualité de Service (QoS) pour garantir la fiabilité de la livraison des messages.
-Qos 0 ( Au plus une fois) : Le message est envoyé une seule fois sans confirmation. Pas de garantie.
-QoS 1 ( Au moins une fois) : Le message est ré-envoyé jusqu'à accusé de réception. Risque de doublons.
-QoS 2 (Exactement une fois) : Le message est livré une seule fois et garanti sans doublon grâce à un échange en quatre étapes. Plus coûteux en temps.
Le paramétrage de ce QoS s'effectue à l'envoi d'un message lors d'une commande publish et lors de l'abonnement (subscribe). Le QoS effectif sera le minimum entre le QoS demandé par le client à l'abonnement et celui utilisé lors de la publication.
DTF3 (Questions F8 et F9)
Listing des trames MQTT
No.
Time
Source
Destination
Protocol
Length
Info
1
0.000000
192.168.8.12
192.168.8.1
MQTT
93
Publish Message [localBatt/TVOC]
3
0.347017
192.168.8.12
192.168.8.1
MQTT
95
Publish Message [localBatt/eCO2]
5
6.208854
192.168.8.12
192.168.8.1
MQTT
56
Ping Request
7
6.209112
192.168.8.1
192.168.8.12
MQTT
56
Ping Response
9
10.078543
192.168.8.12
192.168.8.1
MQTT
93
Publish Message [localBatt/TVOC]
11
10.345032
192.168.8.12
192.168.8.1
MQTT
95
Publish Message [localBatt/eCO2]
13
18.922619
192.168.8.12
192.168.8.1
MQTT
101
Publish Message [localBatt/humidite]
15
19.323261
192.168.8.12
192.168.8.1
MQTT
104
Publish Message [localBatt/temperature]
17
19.846324
192.168.8.12
192.168.8.1
MQTT
93
Publish Message [localBatt/TVOC]
19
20.353539
192.168.8.12
192.168.8.1
MQTT
95
Publish Message [localBatt/eCO2]
21
21.218737
192.168.8.12
192.168.8.1
MQTT
56
Ping Request
23
21.219185
192.168.8.1
192.168.8.12
MQTT
56
Ping Response
25
29.850236
192.168.8.12
192.168.8.1
MQTT
93
Publish Message [localBatt/TVOC]
27
30.353109
192.168.8.12
192.168.8.1
MQTT
95
Publish Message [localBatt/eCO2]
29
36.226733
192.168.8.12
192.168.8.1
MQTT
56
Ping Request
31
36.226984
192.168.8.1
192.168.8.12
MQTT
56
Ping Response
33
39.848689
192.168.8.12
192.168.8.1
MQTT
93
Publish Message [localBatt/TVOC]
35
40.351027
192.168.8.12
192.168.8.1
MQTT
95
Publish Message [localBatt/eCO2]
37
48.904532
192.168.8.12
192.168.8.1
MQTT
101
Publish Message [localBatt/humidite]
39
49.324926
192.168.8.12
192.168.8.1
MQTT
104
Publish Message [localBatt/temperature]
41
49.851230
192.168.8.12
192.168.8.1
MQTT
93
Publish Message [localBatt/TVOC]
43
50.350288
192.168.8.12
192.168.8.1
MQTT
95
Publish Message [localBatt/eCO2]
45
51.242186
192.168.8.12
192.168.8.1
MQTT
56
Ping Request
47
51.242321
192.168.8.1
192.168.8.12
MQTT
56
Ping Response
49
59.961886
192.168.8.12
192.168.8.1
MQTT
94
Publish Message [localBatt/TVOC]
51
60.369761
192.168.8.12
192.168.8.1
MQTT
95
Publish Message [localBatt/eC02]
53
66.312573
192.168.8.12
192.168.8.1
MQTT
56
Ping Request
55
66.312823
192.168.8.1
192.168.8.12
MQTT
56
Ping Response
Détail de la trame n° 39
> Frame 39: 104 bytes on wire (832 bits), 104 bytes captured (832 bits)
> Ethernet II, Src: Espressif_69:d6:a8 (a0:dd:6c:69:d6:a8), Dst: RaspberryPiT_93:95:da (d8:3a:dd:93:95:da)
> Internet Protocol Version 4, Src: 192.168.8.12, Dst: 192.168.8.1
> Transmission Control Protocol, Src Port: 62629, Dst Port: 1883, Seq: 551, Ack: 7, Len: 50
v MQ Telemetry Transport Protocol, Publish Message
> [Expert Info (Note/Protocol): Unknown version (missing the CONNECT packet?)]
> Header Flags: 0x30, Message Type: Publish Message, QoS Level: At most once delivery (Fire and Forget)
Msg Len: 48
Topic Length: 21
Topic: localBatt/temperature
Message: 32342e36307c323032352d31302d30342031363a31353a3433