WikiPrépaLivrets

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

Pas encore noté

Téléchargements

  • Corrigé : pas encore disponible
  • Rapport du jury : pas encore publié

Description

Sujet officiel CAPET troisième concours en informatique, session 2026.

Ces sujets peuvent vous intéresser

Pas encore de corrigé pour ce sujet : voici des sujets proches corrigés.

Lecture du sujet en ligne

L'énoncé complet, avec les formules et les figures, sans ouvrir le PDF.
Afficher ou masquer la section
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.
corresMQ8 = [(1.0, 103), (1.2, 132), (1.4, 163), (1.6, 197), (1.8, 243), (2.0, 281), ..]
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.
adminene@naiobox:~/ssl$ pud
′home/adminene/ssl
adminene@naiobox:~/ssl$ instruction à déterminer
total 20
druxruxr-x 2 adminene adminene 4096 oct. 3 13:02
druxr-x--- 5 adminene adminene 4096 oct. 3 12:57
-rw-rw-r-- 1 adminene adminene 1147 oct. 3 13:02 certificate.pem
-rw-rw-r-- 1 adminene adminene 1001 oct. 3 13:01 csr.pem
-rw------- 1 adminene adminene 1704 oct. 3 12:58 privatekey.pem
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
  • -Outstanding long-term stability
  • -I2C interface with TVOC and CO2eq output signals
  • -Very small 6-pin DFN package: 2.45 × 2.45 × 0.9 mm^3
  • -Low power consumption: 48 mA at 1.8V

Air Quality Signals

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:
  1. 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.
  2. 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.

DOCUMENT TECHNIQUE DTC1 (questions C4 à C5)

Structure de la classe SGP30

SGP30
+TVOC : uint16_t -i2cdev : 12CDevice * attributs
+SGP30() +begin( *pWire : Tw oWire=&Wire, initSenor : bool=true ) : bool +1AQinit() : bool +|AQmeasure() : bool -readWordFromCommand( command[] : uint8t, cmdLen : uint8t, delay : uint16t, "readdata : uint16t=NULL, readlen : uint8_t=0 ) : bool +setHumidity( absoluteHumidity : uint32t ) : bool
1
1
I2CDevice
-Wire : TwoWire *
    opérations
+w rite( *buffer : const uint8_t, len : sizet, stop : bool=true, *prefix_buffer : const uint8_t=nullptr, prefixlen : sizet=0 ) : bool
+read( *buffer : uint8t, len : size_t, stop : bool=true ) : bool
+begin( addrdetect : bool=true ) : bool
1
1
TwoWire
    opérations
+begin()
+beginTransmission( uint8_t address)
+av ailable()
+requestFrom( adress : uint16_t, len : size_t ) : size_t
+w rite( data : uint16_t) : size_t
+endTransmission()
+read() : uint16_t
No. Time Source Destination Protocol Length Info
21.643484 192.168.8.1 192.168.8.4 TCP 7441646 → 502 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=2037001570 TSecr=0 WS=128
21.643895 192.168.8.4 192.168.8.1 TCP 74502 → 41646[ SYN, ACK ] Seq = 0 Ack = 1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM TSval=154180132 TSecr=2037001570
21.644498 192.168.8.1 192.168.8.4 TCP 6641646 → 502 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2037001571 TSecr=154180132
26.650606 192.168.8.1 192.168.8.4 Modbus/TCP 78 Query: Trans: 1; Unit: 1, Func:
26.655130 192.168.8.4 192.168.8.1 Modbus/TCP 79 Response: Trans: 1; Unit: 1, Func:
26.655631 192.168.8.1 192.168.8.4 TCP 6641646 → 502 [ACK] Seq=13 Ack=14 Win=64256 Len=0 TSval=2037006582 TSecr=154185143
31.654942 192.168.8.1 192.168.8.4 Modbus/TCP 78 Query: Trans: 2; Unit: 1, Func:
31.655846 192.168.8.4 192.168.8.1 Modbus/TCP 79 Response: Trans: 2; Unit: 1, Func:
31.656095 192.168.8.1 192.168.8.4 TCP 6641646 → 502 [ACK] Seq = 25 Ack=27 Win=64256 Len=0 TSval=2037011583 TSecr=154190143
33.121067 192.168.8.1 192.168.8.4 TCP 6641646 → 502 [FIN, ACK] Seq=25 Ack=27 Win=64256 Len=0 TSval=2037013048 TSecr=154190143
L 33.121486 192.168.8.4 192.168.8.1 TCP 66502 → 41646[ ACK ] Seq = 27 Ack= 26 Win=65280 Len=0 TSval=154191610 TSecr=2037013048
- Frame 152: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface \Device\NPF_{CDC89913-7404-40B Ethernet II, Src: RaspberryPiT_20:ed:de (dc:a6:32:20:ed:de), Dst: MicroStarINT_e7:dd:dc (00:d8:61:e7:dd:dc) Internet Protocol Version 4, Src: 192.168.8.1, Dst: 192.168.8.4 Transmission Control Modbus/TCP ✓ Modbus . 0000011 = Function Code: Read Holding Registers (3) Reference Number: 40098 Word Count: 2
0000 00 d8 61 e7 dd dc dc a6 32 20 ed de 08 00 45 00 ⋯ a 2⋯E
0010 00 40 84 07 40 00 40 06 25 5b c0 a8 08 01 c0 a8 .@...@. %[
0020 08 04 a2 ae 01 f6 ca 29 85 a8 45 8b e4 9c 80 18 .......) ⋯ E
0030 01 f6 a2 3e 00 00 01 01 08 0a 79 6a 54 7e 09 30 ...> ..yjT~. 0
0040 ad b7 00 02 00 00 00 06 01 03 9c a2 00 02 ........ .
No. Time Source Destination Protocol Length Info
85
86
21.643484 192.168.8.1 192.168.8.4 TCP 74 41646 → 502
21.643895 192.168.8.4 192.168.8.1 TCP 74 502 → 41646 ACK] Seq=0 Win=65535 Len=0 TSecr=2037001570
87 21.644498 192.168.8.1 192 TCP
66
41646 → 502
Seq = 1
Ack=1
Win=64256
Len=0
TSval
TSval
TSecr=154180132
78
Query: Trans:
1; Unit:
1, Func:
Read
Holding
Registers
26.650606 192.168.8.1 192.168.8.4 Modbus/TCP
108 26.655130 192.168.8.4 192 Mo
79
Response: Trans:
1; Unit:
1, Func:
3:
Read
Holding
Registers
109 26.655631 192.168.8.1 192 TCP 66
153 31.655846 192.168.8.4 192.168.8.1 Modbus/TCP 79 Response: Trans:
2; Unit:
Read Holding Registers
154 31.656095 192.168.8.1 192.168.8.4 TCP 66 41646 → 502 [ACK] Seq=25 Ack=27
33.121486 192.168.8.4 192.168.8.1
66
66
502 → 41646
502 → 41646
Seq = 27 Ack=26 Win=65280 Len=0
Seq=27 Ack=26
TSval=154191610 TSecr=2037013048
TSval=154191610 TSecr=2037013048
Détail trame nº108
Sequence Number (raw): 1166795919
[Next Sequence Number: 14 (relative sequence number)]
Acknowledgment Number: 13 (relative ack number)
Acknowledgment Number: 13 (relative ack number)
Acknowledgment number (raw): 3391718824
1000 = Header Length: 32 bytes (8)
✓ Flags: 0x018 (PSH, ACK)
000. = Reserved: Not set
... 0 = Accurate ECN: Not set
0 = Congestion Window Reduced: Not set
. 0 = ECN-Echo: Not set
.... ..0. = Urgent: Not set
.... ... 1 = Acknowledgment: Set
1 = Push: Set
.... . 0 Reset: Not set
.... ..0. Syn: Not set
.... .... 0 Fin: Not set
0000 dc a6 32 20 ed de 00 d8 61 e7 dd dc 08 00 45 00 - 2 a E
0010 00 41 76 30 40 00 80 06 f3 30 c0 a8 08 04 c0 a8 Av0@ 0
0020 08 01 01 f6 a2 ae 45 8b e4 8f ca 29 85 a8 80 18 E )
0030 00 ff 50 5f 00 00 01 01 08 0a 09 30 ad b7 79 6a P_ 0 yj
0040 40 f1 00 01 00 00 00 07 01 03 04 14 00 ff fe @ ⋯ .
No. Time Source Destination Protocol Length Info
85 21.643484 192.168.8.1 192.168.8.4 TCP Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=2037001570 TSecr=0 WS=128
86 21.643895 192.168.8.4 192.168.8.1 TCP ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM TSval=154180132 TSecr=2037001570
87 21.644498 192.168.8.1 192.168.8.4 TCP 6641646 → 502
107 26.650606 192.168.8.1 192.168.8.4 Modbus/TCP 78 Query: Trans:
108 26.655130 192.168.8.4 192.168.8.1 Modbus/TCP 79 Response: Trans:
109 26.655631 192.168.8.1 192.168.8.4 TCP 66 41646 → 502 [ACK]
152 31.654942 192.168.8.1 192.168.8.4 Modbus/TCP 78 Query: Trans:
153 31.655846 192.168.8.4 192.168.8.1 Modbus/TCP 79 Response: Trans:
154 31.656095 192.168.8.1 192.168.8.4 TCP 6641646 → 502
166 33.121067 192.168.8.1 192.168.8.4 TCP 6641646 → 502
L 167 33.121486 192.168.8.4 192.168.8.1 TCP 66502 → 41646
Length: 7 ✓ Modbus . 0000011 = Function Code: Read Holding Registers (3) [Request Frame: 107] [Time from request: 0.004524000 seconds] Byte Count: 4 > Register 40098 (INT16): 5120 > Register 40099 (INT16): -2
Transaction Identifier: 1 Protocol Identifier: 0 Unit Identifier: 1
0000 0010 0040 0041763040008006 080101 f6 a2 ae 45 8b e4 8f ca 2985 a8 8018 ……E. …)… 00 ff 50 5f 00000101080 a 0930 ad b7 79 6a ..P_…....0..y 40 f1 0001000000070103041400 ff fe @ @ . . . . . . . . . . . . @ @ . .

DOCUMENT TECHNIQUE DTD4

Inverter Model MODBUS Register Mappings

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
0000 d8 3a dd 93 95 da a0 dd 6c 69 d6 a8 08 00 45 00 : li E
0010 00 5a 00 3d 00 00 ff 06 2a 03 c0 a8 08 0c c0 a8 Z = *
0020 08 01 f4 a5 07 5b 05 f6 84 e2 7a 95 06 22 50 18 [ z ⋯ "P
0030 16 5a 87 ae 00 00 30 30 00 15 6c 6f 63 61 6c 42 -Z • - - 00 00 localB
0040 61 74 74 2f 74 65 6d 70 65 72 61 74 75 72 65 32 att/temperature 2
0050 34 2e 36 30 7c 32 30 32 35 2d 31 30 2d 30 34 20 4.60 202 5-10-04
0060 31 36 3a 31 35 3a 34 33 16:15:43

Pas de description pour le moment