Multi-capteurs pour qualité de l'air intérieur

De Wiki LOGre
Aller à : navigation, rechercher

Par Philippe. (projet en cours, embryon de rédaction)

Objectifs du projet

Contexte et interrogations

L'objectif initial de ce projet est de pouvoir faire un suivi de qualité de l'air dans les locaux de type Fablab. On utilise des technologies et des matériaux variés qui peuvent émettre divers gaz et particules fines, dont on ne connaît pas grand chose.

Quels sont réellement les niveaux d'émissions si on imprime du PLA ou de l'ABS ou du TPE, si l'on fait de la soudure électronique, ou si on découpe du PMMA du contreplaqué ou du Medium au laser ? Certains matériaux, certaines couleurs, ceux de certaines marques sont-ils plus "émissifs" que d'autres ? Dans l'idéal, peut-on déterminer quels sont ces "gaz et particules" dont on parle ? Les filtres que l'on place sur ces machines sont-ils efficaces ? Pourrait-on détecter qu'ils sont encrassés et qu'il faut les changer si l'on faisait un suivi régulier de la qualité de l'air dans le local concerné ?

Voici quelques-unes des questions auxquelles ce projet pourrait apporter à termes des éléments de réponses.

Les grandes lignes

Il n'est pas simple de trouver, à coût raisonnable, un capteur de qualité de l'air adapté à un contexte tel que celui-ci. On trouve en grande surface des capteurs de CO2 ou des capteurs de fumée, pour la sécurité de la maison. Mais leur seule fonction est de déclencher une alarme au delà d'un seuil prédéfini. Quelques-uns affichent une valeur sur un écran, et une LED verte ou rouge, comme les capteurs de CO2 qui se sont diffusés pendant la pandémie de Covid 19 et qui sont alors utilisés comme "indice de confinement" de la pièce concernée.

On trouve par contre dans le domaine de l'électronique de plus en plus de capteurs "low cost" nus, qu'il faut alors connecter à un microcontrôleur. C'est l'option que je vais choisir, afin de pouvoir sélectionner à terme les éléments que je souhaite mesurer selon le contexte.

Afin d'obtenir un système suffisamment versatile, je choisis de créer une petite station de mesure, configurable car acceptant plusieurs types de capteurs, et que je pourrai déplacer d'un lieu à un autre sans trop de difficultés. De plus je ne souhaite pas seulement afficher des valeurs sur un écran, mais aussi enregistrer les mesures effectuées afin de pouvoir analyser des tendances, des évolutions jour-nuit, observer les évolutions de concentrations lorsque les fenêtres sont fermées/ouvertes, ou en fonction du nombre d'occupant, des machines utilisées, donc dépendant des activités menées dans le fablab, voire analyser ce qui s'est passé sur une semaine par exemple. Pour cela je vais transmettre les mesures sur un "dashboard" que nous pourrons analyser à volonté.

Hardware

Les capteurs

Pour le choix des capteurs, j'ai pris conseil auprès d'un laboratoire spécialisé, Solan Développement à Grenoble, que je remercie au passage pour leurs conseils avisés ! Evidemment je ne vais pas comparer les mesures effectuées par des capteurs à quelques euros cités ci-dessous et les analyses que peut faire un laboratoire professionnel muni de moyens lourds comme Solan Développement. Mais je ferai appel à leurs services dès que j'aurai besoin de définir ou de quantifier avec précision quels éléments chimiques sont présents dans le fablab et sont détectés par mes "petits" capteurs.

Noter que l'on choisit lorsque disponible des cartes munies d'interface I2C afin de faciliter la communication avec le capteur, mais aussi de reconnaître automatiquement (par les adresses I2C) quels capteurs sont connectés, ce qui va dans le sens de la versatilité souhaitée.

Pour les particules fines :

Pour le CO2 :

Pour les COV (composés organiques volatils) et autres gaz :

Il est important de comprendre que chacun de ces capteurs utilise une technologie qui répond principalement à un composé organique volatil particulier, mais peut répondre aussi de manière plus ou moins sensible, à d'autres COV. Par exemple, si le capteur d'éthanol du Multichannel ci-dessus affiche "5ppm", il est possible qu'il réagisse en fait à la présence de 20ppm d'acétone... Attention donc dans l'interprétation des mesures !

A ces capteurs "I2C", nous ajoutons quelques capteurs "analogiques", dont la sortie est un niveau tension dépendant de la concentration de gaz mesuré. Comme les précédents, chacun est sensible à une certaine gamme de gaz différents. Les capteurs "analogiques" sont pris pour l'instant dans cette liste :

Enfin, pour faciliter la gestion de la fréquence de mesure en fonction du contexte, j'ajoute un capteur de luminosité qui permettra de réduire la fréquence de mesures dans les périodes nocturnes, ainsi qu'une horloge RTC pour faire de même en tenant compte de l'horaire ou même du jour de la semaine (ralentir pendant le WE par exemple).

Il est envisagé d'intégrer par la suite

  • un capteur de niveau sonore (lequel ?),
  • un capteur de taux d'oxygène (peut-être parmi ceci ou cela)
  • un capteur HCHO
  • un capteur d'alcool (peut-être celui-ci)
  • ...

transmettre et récolter les mesures

Quelques discussions au LOG autour des outils pour stocker et présenter les mesures, m'ont conduit à regarder vers InfluxDB, Home Assistant, Grafana et quelques autres... Mais par ailleurs, le souhait de ne pas passer trop de temps à programmer/configurer puis gérer un serveur m'ont finalement amené à choisir un service relativement intégré pour le stockage et la mise en forme des données mesurées. Parmi la jungle d'outils disponibles, je me suis finalement orienté vers tago.io, ... pourquoi ? Peut-être parce que je ne savais vraiment pas où j'allais, et que Tago offre un mode "free" suffisamment performant pour débuter en découvrant les concepts et les outils sans s'engager financièrement avec un abonnement quelconque.

Pour la transmission des données, "par les ondes" en sortant du capteur pour assurer une mise en œuvre sans fil réseau au sein du bâtiment, plusieurs solutions possibles, parmi lesquelles Wifi, Bluetooth, LoRa... Bluetooth me semblait trop limité, avec nécessité de mise en place d'une passerelle (Raspberry par exemple ?) nécessaire à proximité du ou des capteurs. Pour mon usage, il est probable qu'une communication WiFi aurait été la plus simple à implémenter, le réseau sans fil étant généralement disponible dans un fablab. D'ailleurs mes premiers essais de communication vers tago.io ont été effectués via WiFi et le protocole HTTP, qui fonctionnait très bien. Mais mes tests à la maison m'ont démontré qu'à travers les murs de pierre, le réseau WiFi est vite limité et que si je mettais un capteur dans mon garage, la communication était parfois défectueuse. De plus, je souhaitais profiter de ce projet pour découvrir LoRa, et enfin, notre ami Oliv' du LOG étant spécialiste de cette solution, c'était vraiment l'occasion de s'y mettre. Grand merci à Oliv' donc, sans qui je ne serais pas allé bien loin dans e déploiement de LoRaWAN ! Je ne m'étendrai pas ici sur LoRa, LoRaWAN, et autres acronymes car je risquerais encore d'écrire des âneries...

Autre aspect intéressant sur LoRaWAN, le réseau communautaire TheThingsNetwork (maintenant TheThingsStack), qui permet un accès ouvert à des antennes partagées avec une couverture plutôt très bonne sur l'agglomération grenobloise, et par chance une gateway apparemment mise en place par un voisin amateur de LoRa dans mon village. Afin de mieux comprendre les principes de ce réseau, Oliv' m'a prêté une gateway, j'aurais probablement pu m'en passer, mais elle m'a bien rendu service néanmoins quand celle du voisin semble inactive.

Le micro-controleur

Après quelques échanges avec le spécialiste LoRa du LOG nous avons passé commande de quelques cartes "LILYGO TTGO T3 V1.6 V2.1.6". Oui, je sais le codage de version n'est pas super clair... Pourquoi cette carte ? Elle est basée sur un ESP32, avec suffisamment de mémoire pour ne pas s'inquiéter d'optimiser le code, et surtout elle dispose d'un module LoRa intégré et son antenne, et un nombre d'E/S qui semblait compatible avec le projet. Elle dispose en outre de quelques éléments potentiellement utiles, WiFi, chargeur de batterie LiPo intégré, lecteur de carte SD, etc. L'ESP32 peut se programmer en mode "Arduino", ce qui me simplifiera le développement. Une de ses faiblesses est peut-être la consommation énergétique, mais pour l'ensemble de capteurs dont j'aurai besoin, il n'est de toute façon pas envisageable de fonctionner sur batterie. Donc la conso du processeur est secondaire pour moi. ATTENTION de commander la version 868MHz pour un fonctionnement en Europe.

ATTENTION aussi, on trouve presque partout un schéma "pinout" erroné. Par exemple ici. J'ai corrigé ci-dessous les bugs que j'ai trouvés, je vous laisse retrouver les différences avec vos enfants ;-) ...

J'ai ajouté sur ce schéma la liaison entre l'alimentation 5V de l'USB et la pin 5V, via l'interrupteur, qui permet de confirmer que l'on peut alimenter d'un côté ou de l'autre, tant que l'on reste compatible en courant avec les pistes cuivrées du circuit. J'indique aussi par des petites flèches les spécificités des "GPIO" de l'ESP32, qui ne sont pas toutes d'usage général et pas toutes "In/out" comme on pourrait le croire. Les pins 0, 2 et 12 sont en orange, elles doivent être à 0 pendant le boot, ce qui limite leur usage potentiel. Les pins 34, 35, 36, 39 ne sont qu'en entrée et ne disposent pas de pullup/pulldown interne. La pin 35 reçoit (et permet de mesurer) la tension de la batterie si une batterie brachée sur le connecteur situé en face inférieure.

Schéma de câblage et circuit imprimé

Le schéma de cablage du prototype est fourni ci-dessous. N'étant pas spécialiste d'électronique et ne maîtrisant pas suffisamment les outils d'ECAD et les librairies associées, je me suis permis de le dessiner à ma manière. Désolé pour les puristes qui préféreraient lire un vrai schéma KiCAD ;-)

Voici un descriptif et quelques commentaires associés :

  • la fonction principale est le bus I2C, alimenté en 5V (tous les capteurs que j'ai utilisés acceptent cette tension, certains la nécessitent). J'ai prévu 10 prises I2C sur ce bus... et elles sont toutes utilisées sur le proto.
  • 4 prises Grove "analogiques" pour des "Analog Sensors" : VCC et GND pour l'alimentation, et sortie vers un diviseur de tension. L'une de ces prises est munie d'une connexion sur le 4e fil car certains capteurs de ce type nécessitent une alimentation complémentaire (résistance de chauffe avec Mosfet par exemple). Je ne l'ai pas encore vraiment utilisée.
  • J'ajoute une prise pour le DHT22 qui permet d'obtenir une mesure de T° et H% indépendante des autres capteurs (qui sont souvent à T° plus élevée que l'ambiance)
  • compte tenu de la forte consommation cumulées des capteurs, l'alimentation est prévue pour être utilisable soit directement via la prise micro-USB de la carte TTGO, soit par une prise d'alim micro-USB externe, soit par les deux. Les "jumpers alim" permettent de relier à volonté les circuits 5V et GND du TTGO et des capteurs, et le "bornier alim" permet d'alimenter le TTGO en récupérant le 5V externe tout en passant quand même par l'interrupteur du TTGO. Tout cela est un peu overkill, mais au moins on a le choix :-)
  • sur les conseils avisés de mon ami Marco, quelques condensateurs ont permis de solutionner le comportement parfois erratique des capteurs analogiques. Une paire de capas sur la ligne principale d'alimentation, une autre sur la ligne des capteurs analogiques. Est-ce suffisant, sont-ils bien placés ? EN tout cas ça marche mieux qu'avant.
  • La pin 34 reçoit la présence de l'alimentation 5V, afin de détecter une coupure d'alimentation lorsque l'on est par ailleurs alimenté par la batterie. Finalement, n'utilisant pas la batterie sur le proto, on pourrait virer ces résistances et affecter la pin 34 pour un autre usage, ainsi que la pin 35 d'ailleurs.
  • Enfin, le "jumper dev" permet de sélectionner manuellement une fonction supplémentaire dans le soft. Je l'ai utilisé pour forcer une fréquence de mesure assez élevée (sleep de 20s en l'occurrence) lorsque l'on est en phase de développement, mais toute autre fonction pourrait être définie dans le logiciel évidemment.


Pour la fabrication du PCB, mon schéma ne suffisait pas, évidemment  ;-)
Grand merci donc à Germain, du FabMSTIC, qui a effectué le transfert sous KiCAD, fait le routage, dessiné le PCB, et fabriqué avec sa graveuse laser "et un poil de chimie pour finir". Je fais chauffer mon fer à souder, et la dernière image de la galerie ci-dessous présente le PCB prêt à recevoir les capteurs.


Montage du système physique complet

Je souhaitais obtenir

  • un système modulaire, sur lequel on puisse choisir de monter une variété de capteurs,
  • sur lequel les capteurs seraient aussi "aérés" que possible, donc éviter un boîtier fermé,
  • qui permette de séparer physiquement des capteurs qui risqueraient de souffler sur d'autres, ou de "chauffer" (certains sont régulés en T°, il serait dommage de les placer par exemple à côté de celui qui devrait indiquer la T° ambiante).

J'ai finalement opté pour une structure purement interne, sans capotage externe. Modèle en plexiglas, muni d'une grille de perçages permettant d'accueillir aisément tous les capteurs dont l'empreinte est compatible avec les modèles Seeed (la majorité dont je dispose), et quelques trous supplémentaires lorsque nécessaire pour d'autres modèles. Le capteur SPS30 est fixé à l'adhésif double face. La structure permet de séparer l'espace en 4 zones et 8 surfaces, et des rainures permettent le passage des connectiques. Une petite paroi supplémentaire permet de séparer les flux d'air en entrée et sortie du SPS30 (particules) selon recommandations du fabricant Sensirion.

Afin d'être sûr d'aller dans les bonnes dimensions, un modèle Onshape. La carte électronique assemblée, et les quatre quadrans du système complet, monté avec un set de capteurs personnalisable.

Et finalement la maquette physique prête à l'emploi :

Software

Le code

Le développement a été effectué sous PlatformIO/VisualStudioCode, en langage Arduino, avec les librairies Arduino des différents capteurs.

La partie logicielle a été structurée par l'utilisation d'un soft existant de communication LoRaWAN, le même que j'ai utilisé pour le détecteur de panne de courant en version 1, basé sur "MCCI LoRaWAN LMIC library", et "Cayenne LPP" pour le formatage des messages de payload.

La deuxième fonction structurante est relative au choix des capteurs dialoguant en grande majorité sous interface I2C. J'ai donc initialisé le système par une procédure de balayage des adresses I2C connues, et la constitution d'une liste des capteurs connectés. Ensuite, la boucle principale lit les mesures fournies par chaque capteur et les insère dans la pile LoRaWAN jusqu'à ce que celle-ci soit pleine (51 octets maxi), on transmet les données vers TTN, on attend un peu, puis on poursuit la lecture des mesures si il restait des capteurs non traités, etc.

Détail technique, la librairie fournie pour l'écran OLED du TTGO (constructeur SSD1306Wire) initialisait le bus I2C à une fréquence de 700kHz, alors que certains capteurs tel que le SPS30 ne supportent que 100kHZ. Il a donc fallu modifier ce constructeur.

Ensuite il a fallu intégrer une à une les librairies de chaque capteur. N'ayant utilisé que des capteurs dont la librairie était disponible dans l'environnement Arduino, je n'ai pas eu à traiter "en dur" le dialogue avec les interfaces I2C. Les capteurs analogiques consistent seulement à lire une valeur entre 0 et 3.3V sur la GPIO correspondante. C'est ensuite l'utilisateur qui doit savoir quel capteur il a branché sur chaque prise Grove et en tirer les analyses qu'il souhaite.

Une horloge RTC et un capteur de luminosité permettent enfin d'adapter automatiquement la fréquence de mesure, en évitant de charger le réseau LoRa et la base de données au milieu de la nuit ou le week-end dans un local inoccupé.

.../...

Le dashboard

Tago.io ...