Capteur environnement
Consignes
Pour notre projet de BUT 3, qui se déroule tout au long de l'année, nous sommes chargés de développer un système de surveillance environnementale pour une pièce.
Ce système doit être capable de mesurer et de communiquer des informations sur différents paramètres environnementaux à un utilisateur via un système de communication. Le système doit être autonome, économique, et facile à installer et à maintenir. Il doit inclure des capteurs pour mesurer la température, le taux de CO2, ainsi que l'état de la lumière et des fenêtres dans la pièce. En outre, le système doit présenter un design attractif pour les utilisateurs
Analyse fonctionnelle
Diagramme pieuvre du système en fonctionnement nominal :
La première étape dans un projet est de réaliser une analyse fonctionnelle, elle nous sera très utile pour dans un premier temps la rédaction du cahier des charges. Puis pour la rédaction et la définition des matrices décisionnelles.
FP_A_01 : Transmettre les informations à l'utilisateur
Puis on produit ensuite 2 diagrammes pieuvres. Le premier sert à décrire le fonctionnement nominal du système. Le 2ème sert à décrire le système en mode de maintenance.
SSS_FUNC_FS1_01
Vérification : D,T Flexibilité : F0
Description de l’exigence : Transmettre les informations à l'utilisateur
Description de la performance attendue : Le système doit pouvoir transmettre l’information des différents capteurs à l’utilisateur. La transmission doit être sans fil. Une LED visuelle doit être installée sur le système pour informer l’utilisateur de l’état du système (éteint, connecté, déconnecté). Le système doit transmettre visuellement les informations à l’utilisateur (différents paramètres de la pièce).
SSS_FUNC_FS1_02
Vérification : D,T Flexibilité : F0
Description de l’exigence : Mesurer la température de l’environnement.
Description de la performance attendue : Le système doit pouvoir mesurer la température à 1° près. Le temps de réaction du capteur doit être de moins de 10 minutes.
SSS_FUNC_FS1_02
Vérification : D,T Flexibilité : F0
Description de l’exigence : Mesurer la température de l’environnement.
Description de la performance attendue : Le système doit pouvoir mesurer la température à 1° près. Le temps de réaction du capteur doit être de moins de 10 minutes.
SSS_FUNC_FS1_03
Vérification : D,T Flexibilité : F0
Description de l’exigence : Mesurer le taux de CO2 de l’environnement.
Description de la performance attendue : Le système doit pouvoir mesurer le taux de CO2 à 50% près. Le temps de réaction du capteur doit être de moins de 10 minutes.
SSS_FUNC_FS1_04
Vérification : D Flexibilité : F0
Description de l’exigence : Mesurer l’état logique de la lumière dans la pièce.
Description de la performance attendue : Le système doit pouvoir déterminer si la lumière est allumée ou éteinte dans la pièce on autorise un taux d’erreur à 1%. Le temps de réaction du capteur doit être de moins de 1 seconde.
SSS_FUNC_FS1_05
Vérification : D Flexibilité : F0
Description de l’exigence : Mesurer l’état logique des fenêtres de la pièce.
Description de la performance attendue : Le système doit pouvoir déterminer si les fenêtres présentes dans la pièce sont ouvertes ou non, on autorise un taux d’erreur à 1%. Le temps de réaction du capteur doit être de moins de 1 seconde.
SSS_FUNC_FS1_06
Vérification : D Flexibilité : F2
Description de l’exigence : S’intégrer physiquement dans l’environnement.
Description de la performance attendue : Le système doit pouvoir s’intégrer dans l’environnement, il faut prévoir un moyen de fixation de l’équipement. Les capteurs doivent pouvoir s’implanter dans l’environnement de la pièce.
SSS_FUNC_FS1_07
Vérification : A Flexibilité : F2
Description de l’exigence : Le système doit être peut coûteux
Description de la performance attendue : Afin d’avoir un maximum de donnée sur tout le bâtiment, il faut produire plusieurs fois ce système, pour cela il faut que le système soit peu coûteux, le système à l’unité doit coûter moins de 50€.
SSS_FUNC_FS1_08
Vérification : A Flexibilité : F2
Description de l’exigence : Le système doit respecter les normes Europe.
Description de la performance attendue : Afin de produire un système légal, il doit respecter les normes européenne (IP2X, fréquences d’utilisation légales, etc.…)
SSS_FUNC_FS1_09
Vérification : T Flexibilité : F0
Description de l’exigence : Le système doit être alimenté.
Description de la performance attendue : Le système peut être alimenté via des piles ou via une prise.
SSS_FUNC_FS1_10
Vérification : I Flexibilité : F0
Description de l’exigence : Le système doit être attractif
Description de la performance attendue : Le système doit plaire visuellement au client
SSS_FUNC_FS1_10
Vérification : I Flexibilité : F0
Description de l’exigence : Le système doit être attractif
Description de la performance attendue : Le système doit plaire visuellement au client
Diagramme pieuvre du système en fonctionnement maintenance
SSS_FUNC_FS2_01
Vérification : D Flexibilité : F2
Description de l’exigence : Être accessible au technicien.
Description de la performance attendue : Le technicien doit pouvoir ouvrir facilement le boîtier pour pouvoir effectuer une maintenance, un bouton et une led visuelle sera présente pour aider le technicien à la maintenance.
SSS_FUNC_FS2_02
Vérification : D,T Flexibilité : F2
Description de l’exigence : Point de mesure pour le capteur de CO2.
Description de la performance attendue : Afin d’aider à la maintenance, Il faut un accès facile aux points de mesure du capteur de CO2, ces points de mesures doivent être accessible seulement par un technicien.
SSS_FUNC_FS2_03
Vérification : D,T Flexibilité : F2
Description de l’exigence : Point de mesure pour le capteur de température.
Description de la performance attendue : Afin d’aider à la maintenance, Il faut un accès facile aux points de mesure du capteur de température, ces points de mesures doivent être accessible seulement par un technicien.
SSS_FUNC_FS2_04
Vérification : D,T Flexibilité : F2
Description de l’exigence : Point de mesure pour le capteur d’état de la lumière.
Description de la performance attendue : Afin d’aider à la maintenance, Il faut un accès facile aux points de mesure du capteur d’état de la lumière, ces points de mesures doivent être accessible seulement par un technicien.
SSS_FUNC_FS2_05
Vérification : D, T Flexibilité : F2
Description de l’exigence : Point de mesure pour le capteur d’état de fenêtre.
Description de la performance attendue : Afin d’aider à la maintenance, Il faut un accès facile aux points de mesure du capteur d’état de fenêtre, ces points de mesures doivent être accessible seulement par un technicien.
SSS_FUNC_FS2_06
Vérification : D, T Flexibilité : F2
Description de l’exigence : Point de mesure de l’alimentation.
Description de la performance attendue : Afin d’aider à la maintenance, Il faut un accès facile aux points de mesure de l’alimentation, ces points de mesures doivent être accessible seulement par un technicien.
Allocation organique des fonctions
Pour transmettre les données des différents capteurs à l'utilisateur, nous avons décidé d'utiliser la technologie de communication sans fil à basse consommation "LoRa", sur les recommandations de Mr DUVIELBOURG. Cette technologie est couramment utilisée dans les applications de l'Internet des Objets (IoT) et pourrait s'avérer particulièrement efficace pour notre système de surveillance de l'environnement.
Dans un premier temps on va étudier le fonctionnement d’un réseau LoRa. Pour cela on utilise le réseau « The Things Network », on se sert d’une Gateway de la même marque. Pour faire quelques tests, on nous a prêté un microcontrôleur Arduino MKR WAN 1310, avec un module MKR ENV, qui comprends des capteurs de pression, température, humidité, et de lumière.
On va essayer dans un premier temps d’envoyer un message via le réseau LoRa. La classe de communication sera de classe A, le système passera la plupart de son temps en attente, et communiquera ces informations toutes les 30 secondes.
Nous avons réussi assez facilement à envoyer et à lire dans le terminal de « The Things Network » les informations des capteurs de température et humidité. Cependant on rencontre un problème lors de l’envoie des données avec les interruptions, le microcontrôleur se bloque, et on ne reçoit aucune information sur « The Things Network ».
C’est pourquoi en plus du prix on ne pourra pas garder cette carte par la suite.
Recherche de solutions
Système de communication
Choix des composants
Tous les choix des composants sont décrits dans le document A_AF_SAE5. On utilise des matrices décisionnelles pour comparer plusieurs solutions à une exigence.
Pour le choix du microcontrôleur et de la communication LoRa, il a été d’abord choisi d’utiliser un microcontrôleur avec LoRa WAN intégré, car cela aura été plus efficace et rapide que d’implanter une puce LoRa sur un autre microcontrôleur. Cependant on s’est rendu compte qu’il est compliqué de trouver des microcontrôleurs avec puces LoRa intégré pour un prix raisonnable. Notre choix s’est donc tourné sur le microcontrôleur PIC16F et la seeeduino LoRa-E5-HF. Qui sont aussi le choix d’autres groupes.
La logique est la suivante : le PIC est la puce centrale, elle gère la communication entre la Seeeduino (sorties) et les capteur (entrées). La communication entre le PIC et la seeeduino se fera en UART (RX/TX). On résout ainsi la problématique de l’envoi d’information avec les interruptions. Le microcontrôleur PIC16F à un comparateur interne.
On a sélectionné le capteur de CO2 de chez Scio science qui est une entreprise qui construit des capteurs scientifiques, la datasheet est complète et la communication se fera en I2C.
Le capteur de température est un LMT887, il s’agit d’un capteur souvent utilisé, le stock est conséquent et le capteur est déjà linéarisé avec la formule pour avoir la température.
Le capteur de lumière sera un switch NO ou NF.
Pour le capteur d’état de la lampe, On utilisera une photodiode, qui nous donnera une tension en fonction de la lumière de la pièce. Il faut ensuite régler un seuil de déclenchement afin d’avoir un capteur Logique plutôt qu’analogique (besoin pour déclencher des interruptions par la suite). Pour cela on utilise un comparateur LM393 avec une résistance de tirage.
A partir de toutes ces choix, on va donc créer le fichier « Bill_Off_Materials » qui va contenir toutes les références des composants qui seront équipés dans le système.
Afin de dérisquer le choix de composants et par demande du client, on fait des tests du fonctionnement du système et du programme sur plaque d’essai.
On simule alors les capteurs logiques avec des boutons et les capteurs analogiques avec des potentiomètres afin de vérifier/dérisquer la logique de notre programme.
On rencontre un problème lors de l’envoie des données avec les interruptions, lorsque l’on utilise une interruption pour envoyer des informations le microcontrôleur se bloque, et on ne reçoit aucune information sur TheThingsNetwork.
Essais sur plaque d’essais
Changement de hardware
Il a été décidé de changer de carte, et d’utiliser le module LoRa de chez Seeeduino, piloté par un microcontrôleur PIC16F.
La logique est la suivante, le PIC est la puce centrale, elle gère la communication entre la Seeeduino (sorties) et les capteur (entrées).
La communication entre le PIC et la seeeduino se fera en UART (RX/TX).
On résout ainsi la problématique de l’envoie d’information avec les interruptions.
Le microcontrôleur PIC16F à un comparateur interne. D’après notre professeur le PIC16F à aussi un RTC interne. On s’est rendu compte par la suite qu’il s’agit d’un timer et non d’un RTC.
Avantages :
Gain de coûts (Pas de dédoublement de fonctions)
Inconvénients :
Plus compliqué à mettre en place (La fonction est plus compliquée à utiliser qu’un RTC externe)
La logique de fonctionnement du programme devra donc changer.
Consommation du système
L’objectif est maintenant de connaitre la consommation de la carte pour dimensionner la batterie. Lors du choix des composants on a minimisé la consommation au plus possible.
Après avoir fait le devis de consommation, on peut conclure qu’avec 2 piles AAA de 1500 mAh, et un mode de fonctionnement de 72 mesures dans la journée (nombre de mesures maximal). On peut tenir 7,4 ans en autonomie.
On a trouvé toutes nos solutions, on peut maintenant produire le PCB.
LA CAO du PCB sera réalisée sous le logiciel Altium designer. En premier lieu on fait la partie fonctionnelle du schéma. En mode « Schematic » on place les composants que l’on a sélectionnés. Ensuite, nous avons fait les liaisons entre les composants en s’aidant de la datasheet de chaque composant ainsi que les essais que nous avons réalisé sur plaque d’essais.
Conception du PCB
Lorsque le schéma est fini on peut enfin commencer la réalisation du pcb. Pour cela nous avons commencé par choisir des dimensions arbitraires afin de pouvoir commencer le placement des composants sur le pcb. Il s’agit d’un pcb double couche, dans notre cas nous avons positionné des composants seulement sur la couche top avec en botom juste un plan de masse. Nous avons créé une antenne patch dimensionné pour une antenne de 868MHz, la fréquence de communication du Lora. Nous avons aussi prévu des points de tests sur le pcb afin de pouvoir réaliser plus facilement les futures maintenances. Nous avons donc obtenu pcb qui se présente de la sorte :
Nous avons donc exporté ce fichier sous format gerber et commander chez JLCPCB 5 pcb afin de proposer un prototype fonctionnel.
J'ai produit une liste des composants à commander pour réaliser le projet
Bill of Material
En parallèle de la conception du PCB je vais réaliser la logique du programme.
L’objectif est de concevoir un algorithme facilement modifiable. On programme sur un pic16F, le langage utilisé sera du C.
Pour l’acquisition des valeurs, on utilisera les fonctions suivantes :
+ Int getTempérature()
+ Int getCO2()
+ Bool getLum()
+ Bool getFen()
Les horaires du mode jour est réglable en fonction du choix de l'utilisateur.
Conception du programme
Mode Jour
Mode nuit
Capteur de Température
Il mesure la température toutes les 30 minutes
Capteur de fenêtre
Inactif en mode jour
Capteur de lumière
Inactif en mode jour
Capteur de CO2
Il mesure le CO2 toutes les 30 minutes, s’il dépasse un certain seuil, on diminue le temps et on passe à 3 mesures espacées de 10 minutes, jusqu’à ce que la valeur soit inférieur au seuil.
Capteur de fenêtre
Dès changement en mode nuit, acquisition de l’état des fenêtres.
Puis dès qu’il y a changement d’état (interruption), acquisition de l’état des fenêtres.
Capteur de lumière
Dès changement en mode nuit, acquisition de l’état de la lumière
Puis dès qu’il y a changement d’état (interruption), acquisition de l’état de la lumière
Capteur de Température
Inactif en mode nuit
Capteur de CO2
Inactif en mode nuit
CAO du boîtier
La CAO du Boîtier sera réalisée sous le logiciel 3D Experience.
Je vais dans un premier temps importer le PCB en fichier 3D, ainsi je pourrait me rendre compte de la position des capteurs, des trous, et des fiches.
Impression du boîtier
Tests du PCB
On a commencé par souder le capteur de CO2 à l’aide du four. Ensuite on soude le reste des composants avec un fer à souder.
On a trouvé de meilleurs connecteurs que ceux initialement prévus. On a donc câblé les connecteurs et fait les câbles qui servent à relier le boitier principal et les capteurs annexes.
Une fois tous les composants soudés, Il faut faire clignoter la led de test, ainsi on vérifiera si le microcontrôleur se programme convenablement. Après quelques problèmes avec le programmateur, on arrive bien à faire clignoter la led.
Comme nous avons précédemment écrit un programme fonctionnel du comparateur qui fonctionne sur la plaque d’essais, nous avons décidé de tester en premier ce programme. Cependant ce dernier ne fonctionne pas comme prévu.
On s’est alors rendu compte d’une erreur de câblage du potentiomètre R7. Le GND et ref_lum sont inversés. Il faudra la modifier dans la prochaine version du PCB.
En attendant on couper la piste et mettre un câble à la place pour vérifier le fonctionnement du comparateur.
Cependant le système ne fonctionne toujours pas comme prévu, il y a un court-circuit sur le capteur de température ou le capteur de particules. Pour rectifier ce court-circuit, nous avons dû couper la piste d’alimentation des deux capteurs. Ce qui rend les rend inopérants.
Erreur du comparateur
Après avoir résolu les problèmes de câblage du PCB, nous avons réessayé de faire fonctionner le comparateur dans le but de générer une interruption. Nous avons réussi à refaire fonctionner le comparateur comme lors de nos essais précédents. À ce stade, nous avons tenté de mettre en place l’interruption.
Le programme est simple : lorsqu’un changement d’état se produit, cela déclenche l’interruption et change l’état de la LED. Cependant, cela ne fonctionne pas. Pour éclaircir cette situation, nous avons mesuré la sortie du comparateur et constaté qu’elle n’est pas numérique. Le comparateur oscille légèrement, ce qui empêche le déclenchement de l’interruption.
Étude de changement du système
On atteint à ce moment du projet un nouveau jalon. Il nous reste 2 semaines pour pouvoir faire fonctionner le système. Il nous reste encore toutes les parties suivantes à programmer et à tester :
Lecture d'une entrée logique
Envoie des informations via LoRa
Réception des informations via LoRa
Faire fonctionner le capteur de CO2
Faire fonctionner le capteur de température
Faire fonctionner le capteur d’état de lumière
Faire fonctionner le capteur d’état de fenêtre
Faire fonctionner les interruptions
Faire fonctionner le timer
Faire fonctionner le programme principal
Alimenter via pile
Programmer la fonction de maintenance
Programmer la base de données
On se pose alors la question de la faisabilité du projet dans les temps, sachant qu’il faudra aussi produire toute la documentation liée au projet.
Le retard pris est lié à plusieurs problèmes :
Microcontrôleur :
Le choix du pic16f est le mauvais, il s’agit d’un microcontrôleur peut accessible, très bas niveau. En effet le microcontrôleur respecte toutes les exigences et à toutes les fonctionnalités demandées d’après le cahier des charges, mais rien que l’allumage d’une LED est bien plus complexe que d’autres microcontrôleurs.
Actuellement on a réussi à allumer et éteindre une led, à faire fonctionner le comparateur. En 3 semaines je doute sérieusement d’arriver à faire fonctionner l’I2C et la liaison tx – rx avec la puce LoRa. Le changement du pic16f pour un microcontrôleur plus un système plus simple sera nécessaire pour respecter les délais.
LoRa WAN :
La solution du LoRa WAN au cours du projet semble de plus en plus être un mauvais choix. Il existe très peu de puce LoRa WAN sur le marché, ce qui augmente le prix de ces dernières, ce qui n’arrange en rien le prix de base d’une Gateway aux alentours des 130€. Les projets GitHub sont peu nombreux comparé à d’autres solutions.
Autre point problématique, pour communiquer les informations à l’utilisateur, on transmet les informations du système vers la Gateway, puis via « The Things Network », qui transmet les données à une base de données en ligne. Qu’il faut par la suite pouvoir afficher via Grafana. Et trouver un autre moyen pour envoyer les alertes sur le téléphone de l’utilisateur. Cela fait beaucoup de services différents, qui chacun peuvent fermer, ne plus fonctionner à la suite d’une mise à jour, ou être piraté.
Pour notre application, qui fonctionne seulement dans un seul bâtiment, pas sûr que rester avec une solution LoRa soit le meilleur choix.
Cela vaut le coup alors de chercher d’autre solution pour palier à tous ces problèmes.
On fera cette fois ci le système le plus simple possible, l’idée est avant tout de prototyper et de pouvoir proposer un système fonctionnel en moins de 3 semaines. L’utilisation de devkit sera à privilégier. (On cherche à vraiment éviter les problèmes du premier prototype).
Système de communication
Wifi
Le wifi consomme beaucoup trop pour une application de système embarqué, avec le réseau wifi déjà existant dans l’école cette solution peut néanmoins être correct.
Pour rendre le wifi viable il faudrait être connecté sur secteur, cependant un système de transformation de tension augmenterait le prix, et cela limiterait le choix de placement du système dans la pièce. Le wifi à les avantages d’être peux coûteux et d’être facile à utiliser.
Bluetooth
Le Bluetooth consomme beaucoup pour du système embarqué. Et la distance de communication est bien trop faible pour notre application. Néanmoins cette solution est peu couteuse, et facile à utiliser.
Zigbee
Zigbee est basé sur la norme IEEE 802.15.4, ce qui lui permet d'offrir une faible consommation d'énergie, une portée étendue et une fiabilité accrue.
La topologie de réseau maillé de Zigbee permet à chaque appareil de fonctionner comme un répéteur, ce qui étend la portée du réseau et améliore sa fiabilité. Zigbee prend en charge la communication bidirectionnelle, ce qui permet aux appareils de communiquer entre eux et d'envoyer des données vers et depuis un contrôleur central.
C’est une solution qui est déjà équipée sur certains microcontrôleurs. Cependant pour fonctionner cela nécessite un coordinateur Zigbee mais les prix sont abordables.
Matter
Matter est conçu pour être une norme unifiée pour la connectivité des appareils domestiques intelligents, ce qui devrait faciliter l'intégration de nouveaux appareils dans le réseau et améliorer l'interopérabilité entre les appareils de différents fabricants.
Matter est basé sur les protocoles Internet établis, ce qui devrait faciliter la mise en œuvre et la prise en charge par les fournisseurs de services et les fabricants d'appareils.
Matter prend en charge une topologie de réseau maillé similaire à Zigbee, ce qui permet d'étendre la portée du réseau et d'améliorer sa fiabilité.
Matter est conçu pour être sécurisé dès le départ, avec un chiffrement de bout en bout et une authentification des appareils, ce qui devrait améliorer la sécurité globale de l'IoT.
Version Zigbee
Après recherche des différents composants disponible sur le marché, la solution du Zigbee semble être la meilleure et semble être réalisable en 3 semaines.
Si cette solution ne fonctionne pas on pourra toujours passer sur une solution Matter. (Les microcontrôleurs Zigbee embarque généralement aussi Matter).
La grande question est de prouver que le réseau fonctionne correctement. Pour cela il me faut plusieurs systèmes pour prouver son bon fonctionnement.
On va commencer par créer 3 systèmes prototype.
Comme il s’agit de la même problématique on peut reprendre l’analyse fonctionnelle précédente et les matrices décisionnelles précédentes.
On va donc refaire les matrices décisionnelles en étendant la recherche aux systèmes autre que LoRa. Tous les choix des composants sont décrits dans le document B_AF_SAE5. Voici un résumé des solutions choisies :
Remplacement des composants
Microcontrôleur
Le microcontrôleur sera un ESP32 H2 ou un ESP32 C6, Ces microcontrôleurs ont déjà l’antenne implanté, leurs prix est seulement d’environ 2€, et ils sont très simples à programmer et à utiliser.
Notre choix se portera sur l’ESP32 C6 car pour un prix similaire propose plus de fonctionnalité (et donc de flexibilité) que l’ESP32 H2.
Capteurs CO2
Le capteur de CO2 précédent fonctionne en I2C, ce capteur nécessite un four pour être soudé, lors de cette première phase de prototypage je n’ai pas accès à un four, je vais faire plus simple et remplacer ce capteur par un autre capteur I2C.
Encore une fois l’idée est de montrer que c’est possible de communiquer avec un capteur I2C. pour cela je vais prendre le capteur AHT20 de chez adafruit. Capteur très simple à utiliser, coût : 4,87€
Capteur température
Bien que le capteur AHT20 mesure la température, Je vais garder le LMT87, on n’a pas pu le tester sur l’ancien prototype à cause du court-circuit, mais normalement le câblage est correct.
Capteur lumière
On a eu précédemment des problèmes avec le comparateur du capteur de lumière. Après réflexion pas sûr qu’une photodiode soit très efficace pour détecter l’allumage d’une lumière dans une pièce. Il vaut mieux mettre un LDR à la place qui a une sensibilité spectrale plus large ce qui aidera pour la détection. En plus de simplifier le câblage. Le capteur de lumière sera donc monté sur le PCB principal. Il faudra prévoir un trou dans le boîtier pour le capteur.
Capteur de fenêtre
Ce capteur sera toujours en dehors du boîtier principal.
LDO
Ajout d’un LDO (Low-dropout regulator) qui permet d’avoir une tension d’alimentation plus lisse et de meilleure qualité.
Coordinator
Afin de gérer le réseau zigbee, on a besoin d’coordinateur zigbee, on choisira le TI CC2652P. Qui est recommandé par home assistant.n dehors du boîtier principal.
Batterie
La batterie sera la même que précédemment.
On va ajouter un moyen de mesurer le niveau de batterie du système, pour cela il faut relier la borne positive de la batterie à une broche analogique de l'ESP32-H2 et la borne négative à la masse. Ensuite lire la tension de la batterie en utilisant la fonction le CAN de l’ESP32.
Tous les composants sélectionnés, sont retrouvable dans la BOM, avec leur référence.
Si on compare les prix de cette solution avec le LoRa. On se rend compte que cette solution et vraiment plus économique et flexible pour le même résultat. Si on prend l’exemple d’un réseau de 10 capteurs. On économise avec le Zigbee 138,2€.
Devis de consommation V2
On a refait un devis de consommation. En mode end device et en mode routeur. Vous pouvez retrouver ces calculs dans le document « Devis_consommation ».
On s’est rendu compte que le Zigbee en mode end device peux tenir jusqu’à 12,0 ans en autonomie.
Pour le mode routeur, il n’est pas écrit dans la datasheet du microcontrôleur la consommation. On estimera donc que le microcontrôleur consomme 10 fois plus et se réveille 10 fois en mode nuit. Avec ces calculs on arrive à une autonomie de 3,4 années.
Vu les économies qu’apporte la solution du Zigbee, cette solution est toujours intéressante. Une alternative avec des end devices reliés directement par secteur est envisageable.
Suite à l'étude des composants
Après recherche, il sera compliqué d’avoir un PCB fonctionnel pour la semaine du 13 au 17 mai.
On ne possède pas de four à disposition avant un certain temps, ce qui rend impossible le soudage de l’ESP 32 mini.
On peut commander des PCB déjà prés soudés, mais le coût sera beaucoup trop élevé (sachant qu’il me faut plusieurs prototypes pour faire un réseau). A la place, on va proposer un prototype sur « Protoboard » avec des devkits, qui eux ont pins traversants. Puis on va proposer une version finale avec un PCB.
Pour les premiers tests on va tout d’abord faire fonctionner les capteurs de températures AHT20 avec les ESP32 C6 M1 sur les protoboards.
Réalisation du prototype
On commence par tester les devkit ESP32 C6, pour cela on les programme avec vs code et l’extension ESP-IDF.
On test dans un premier temps un programme simple de blink. Puis On essaie de programmer le capteur de température et d’humidité AHT20. Avec la bibliothèque officielle du constructeur Adafruit.
La bibliothèque de AHT20 n’est pas compatible avec ESP IDF, en effet elle utilise les bibliothèques Arduino.h et Wire.h.
On se décide donc à utiliser l’IDE Arduino. Cependant la puce esp c6 étant trop récente, elle n’est pas programmable avec l’IDE Arduino.
Une autre solution est d’importer ces librairies avec l’extension vscode Plateform.io mais il y a de nombreuses erreurs lors du choix de la carte, surement lié au fait qu’elle soit trop récente. Il faut recréer la librairie du capteur AHT20 dans ESP IDF.
Je suis parti de la base de la libraire officielle de Adafruit, et après plusieurs heures de programmation je n’arrive pas à communiquer correctement avec le microcontrôleur. La lecture du controlWord du capteur n’est pas correcte. Je me demande alors si le capteur n’est pas HS. Je suis sûr que le câblage lui est correct.
Pour vérifier si le capteur fonctionne je récupère une arduino nano v3 sur laquelle sur laquelle je branche le capteur. J’importe la bibliothèque de Adafruit et je flash le programme par défaut, sur la liaison série j’ai alors des messages d’erreur m’indiquant que la communication a échoué.
J’essaye de télécharger une autre librairie trouvée sur GitHub et cette fois ci le capteur me rend les bonnes valeurs. Je change donc de base de librairie pour la programmation. Je remarque que cette librairie envoie des messages différents pour l’initialisation. J’arrive ensuite à faire fonctionner le controlword, le plus gros problème que j’ai rencontré est la définition de SCL et SDA qui s’effectue dans le menuconfig du projet. J’ai finalement créé les fonctions d’envoi de la requête et de réception des informations du capteur.
Après avoir vérifié que je reçoit bien les bonnes valeurs du capteur, je réorganise le programme pour qu’il soit plus clair et je créé une fonction GetTemperature() et GetHumidity(). Ces fonctions gère l’envoie de la requête, la réception et le décodage des informations.
Transmission Zigbee vers Home assistant
L’étape suivante est l’envoie des informations via Zigbee.
Je pars d’un programme existant qui transmet les informations d’un capteur de température, d’humidité, l’état d’un bouton et qui reçois l’état d’une led.
Le capteur de température et d’humidité du projet git n’est pas le même que celui que j’utilise. Je modifie donc la librairie du capteur et je remplace les fonctions du capteur du projet git par le mien.
Côté Raspberry pi et home assistant, le coordinateur Zigbee est détecté correctement et n’est pas compliqué à installer.
Après avoir corrigé 2-3 bugs transverses, l’ESP32 est reconnu par home assistant.
Il est possible que l'ESP 32 rencontre une erreur d'initialisation de la pile Zigbee. Dans ce cas, il est nécessaire d'effacer le flash de l'ESP 32 et de renvoyer le programme. Cette erreur est causée par des données résiduelles du programme précédent qui n'ont pas été correctement effacées lors du nouveau flash.
Cependant la valeur n’est pas mise à jour sur le panel home assistant, la valeur n’est envoyée qu’une seule fois lors de la première connexion ou lors d’un reboot de l’end device.
Sur le terminal de l’ESP 32 la valeur est bien envoyé toutes les 5 secondes. Le problème vient alors de la réception. Pourtant lorsque je regarde les logs de home assisant, je vois que les valeurs sont bien reçues par le coordinateur. C’est home assistant qui ne met pas à jour les valeurs des variables de température et humidité.
Pour rectifier cette erreur je vais dans un premier temps réinstaller une version vierge de home assistant car avec l’inexpérience j’ai peut-être modifié le paramètre de mise à jour des valeurs de capteur. Après avoir réinitialisé les paramètres d’home assistant, les valeurs ne se mettent toujours pas à jour.
Je décide alors d’installer l’extension zigbee2mqtt qui est une alternative à ZHA (Zigbee Home Automation) qui lui est installé nativement dans home assistant. Pour que zigbee2mqtt puisse fonctionner il faut installer un Broker, ici je vais utiliser le Broker Mosquitto.
On peut ensuite lancer zigbee2mqtt et lancer la recherche d’appareil. Cette fois ci notre système est bien détecté et se met à jour automatiquement.
On peut voir ici que les différents systèmes sont bel et bien détectés et connecté au coordinateur Zigbee.
Actuellement les systèmes fonctionnent tous en « end device », on a donc un réseau en étoile. Par la suite il faut créer un réseau maillé. Pour cela il faut changer les paramètres de certains systèmes pour qu’ils puissent être défini en routeur.
CAO du boîtier V2
Une 2 ème version du boîtier a été réalisée avec le logiciel 3D Expérience. Il reprend les dimensions du boîtier différent en s’adaptant aux nouveaux composants. Ce modèle respecte les règles de fabrication additive.
Cette fois ci les composants sont fixés sur une plaque, et un couvercle vient se rajouter dessus. On a donc les capteurs dans le sens des ouvertures (contrairement à l’ancien modèle qui avait le défaut d’avoir les capteurs enfermés).
PCB V2
Sur la base du premier PCB, Kylian a réalisé une deuxième version adaptée au ESP32 C6.
Toute la partie commande a été gardée, nous avons modifié l’erreur du premier PCB. Et nous avons placé un header pour pouvoir programmer cette carte.
Comme il n’y a pas d’antenne sur le PCB, on a pu miniaturiser cette deuxième version.
Nous avons commandé et soudé cette deuxième version.
Nous allons par la suite tester cette version avec le programme que l’on à précédemment conçu.
Avancement actuel du projet
Actuellement le système n’est pas complétement terminé, il reste les fonctionnalités suivantes à implanter :
Mode routeur
Il reste encore à faire les modifications pour que le système puisse fonctionner en mode routeur. Cela ne devrait pas être trop long à implémenter.
Corriger l’erreur d’envoi/réception d’informations binaire
L’information du switch du capteur de fenêtre ne remonte pas les informations jusqu’à home assistant. L’information du capteur est correctement affichée dans le terminal de l’ESP32. L’erreur doit venir du cluster logique qui doit être mal configuré.
NTP
Il faut ajouter un NTP (Network Time Protocol) afin d’acquérir l’heure du réseau pour se calibrer sur le temps réel.
Faire fonctionner le capteur de CO2
Le capteur de température et d’humidité que l’on a essayé fonctionne en I2C tout comme le capteur de CO2. Il faut adapter le programme en modifiant les adresses et les messages envoyés pour qu’il puisse communiquer en I2C avec le capteur de CO2.
Faire fonctionner le capteur de température
Le capteur de température ne fonctionne pas encore, il suffit juste de faire fonctionner l’ADC, de récupérer et de traiter la valeur.
Faire fonctionner le programme principal
Une fois toutes les fonctions manquantes programmés, il faut créer le programme principal que l’on a précédemment défini dans le document «logique».
Tests unitaires
Batterie de test du système
Une fois le système entièrement fonctionnel, il faut faire passer une batterie de test au système et s’assurer qu’il respecte bien chaque fonction.
Livrables
Voici les différents livrables produits pour le client à la fin du projet :