Projet

Général

Profil

Thermo-Bibli (Attention: Ancienne version!)

Synopsis

Attention, cette version est une archive du développement, vous trouverez le projet mis à jour à cette adresse, lien vers le wiki mis à jour: Thermo-Bibli réarrangé

Projet de dispositifs de mesure DIY et communicants pour suivre l'évolution de la température et de l'hygrométrie dans les réserves de livres anciens de l'Université de Bordeaux.

Commanditaire: Romain Wenz, Responsable du service du patrimoine documentaire.
Responsable du projet: Pierre Grangé-Praderas

Participants:
Habib Belaribi, stagiaire adsillh du mi-septembre 2021 à fin janvier 2022.
Stage du 17 mai au 25 juin 2021, "Alexander Dales",Lucas Pallaro, Bastien Boineau, Loris Galland.

Versions:
2 versions co-existent avec des technos plus ou moins communes

Documentations utilisateur

Date Version Fichier
en cours 0.1

Sources Logiciel

Dépôt de code

Vue d'ensemble

Pour l'instant : solution GSM, peut-être plus tard réseau UB + solution hotspot.

Éléments physiques, sous-parties

DISPOSITIF DE MESURE (grappe de capteurs): RELAI-HOTSPOT: SERVEUR DE VISUALISATION: SERVEUR DE SAUVEGARDE:

Cahier des charges

Équiper les réserves des bibliothèques universitaires de l'UB de capteurs de température et hygrométrie autonomes et connectés, leur permettant de savoir en temps réel si les conditions de conservation sont bonnes.

  • FP: Le système permet au conservateur de surveiller la température et l'humidité des réserves de livres anciens, à distance et sans pouvoir accéder pour entretien pendant 2 mois.
  • FC1: Le système doit envoyer ces données sur un serveur extérieur à l'université, sans passer par son réseau et en canal chiffré (SSL).
  • FC2: Le système doit Créer une visualisation en ligne : tableaux, courbes...
  • FC3: Le système doit Redonder ces données sur un serveur distant pour conservation.
  • FC4: Le système (les grappes) doit doit tenir minimum 2 mois sur batterie.
  • FC5: Le système doit Envoyer une alerte lors des franchissements de seuils absolus et relatifs, ou en cas de défaillance du système.

Site test : Carreire

Description de la bibliothèque du site Carreire

Fonctions

FP Captation de la température et de l'humidité

  • précision Température recherchée: 0.5°c
  • précision Humidité Relative recherchée: 2%
  • échantillonnage temporel: 1 mesure par 10 minutes (à la demande du client, modifiable dans le temps)
  • échantillonnage spatial: 3 grappes de 5 capteurs (à la demande du client, modifiable dans le temps)

FC2 Interface de visualisation des données

InfluxDB + Grafana qui sont utilisés sur la VM
On utilise influxdb car il fait passerelle entre grafana et mqtt, grafana et influxdb sont compatibles entre eux et les deux sont compatibles avec raspberry PI, tout les deux sont open sources, pour plus de détails sur les avantages de ces derniers : comparatif grafana influxdb

FC4 Energie

Résumée : les grappes de capteurs doivent tenir 2 mois sur batterie. Les autres éléments sont sur secteur.

Détails sur cette page : Énergie

FC5 Alertes

18°c à 20°c (avec une marge de 0,5°c), 45% à 55% + 40% à 60%
Les seuils d'alertes doivent être réglables par les conservateurs dans l'interface de grafana.

Sécurité

3 comptes admin pour le Fablab
3 comptes admin pour le client
1 comptes utilisateur pour le client
Protégé par mdp

Seuils d'alerte

  • Absolu : 18°c à 20°c (avec une marge de 0,5°c), 45% à 55% + 40% à 60%, seuil urgence↷
  • Relatif : >5°c par semaine, +5%/semaine
  • Piles : 1 semaine avant décharge et à 50% de la batterie
  • Envoie d'un mail lors d'une erreur ou d'aucune valeur

Liste du matériel

  • 1 ESP 32 devkit lipo olimex
  • 5 "dht22"::https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf
  • tableau de câbles - à faire
  • 4 batteries 18650 - 3500mAh datasheet
  • Boîtier impression 3D
  • boîtier plastique (16cm*12cm*8cm)
  • une carte sim à demande du client (car le réseaux universitaire serait plus complique à en place pour lui)
  • hotspot - TPLINK-M5350

Capteurs à déterminer !
Par exemple : DHT 22, pas cher, possible à monter en grappes verticales, avec 5 volts, USB, sur boîtier de dérivation électrique.
Possibilité de change de capteur si besoins après les tests effectué dans la réserve.

Relai : il reçoit les données captées par les esp32 et les envoie vers le serveur.

Installations des outils logiciels nécessaires

  • installation des outils de visualisation graphique dynamique :
    • Grafana
      • avec une BDD Sqlite3 pour la gestion utilisateurs
    • Influxdb (pour linux) : grafana et influxb

> Travail sur le code source logiciel :

-- Programme côté micro-contrôleur :

Lien vers le dépôt officiel : https://git.cohabit.fr/thermo-bibli/code-grappe
  • Télécharger le code situé sur la branche "site carreire"
Recherches sur les modifications de code source :
  • disponibles sur le journal de bord d'Habib ( Habib_Belaribi, avec le mot-clé "thermo".

Évaluation du prix

Première grappe de test

4 DHT22 = 10€
1 esp32 par grappe = 5€
1 boîtier de dérivation = 10€
1 rtc = 0,5€
1 hotspot wifi
1 mat
chargeur de piles 18650
câbles
forfait GSM ( 2 euros/mois)
abonnement à la VM (5 euros/an)

1 devis routeur wifi / hotspot SIM
1 Devis micro serveur

Tableau de chiffrage

Tableau pour une grappe

désignation lien d'achat prix ttc datasheet
esp32 esp32-ali-express 5,17€(expédition : 2,06€) esp32-datasheet
DHT22 dht22-ali-express 3,08€(expédition : 0,88€) dht22-datasheet
batterie 18650 batterie-ali-express 3,07€(expédition : 7,07€) NCR18650B.pdf

Abonnement

désignation lien d'achat prix ttc
abonnement GSM abonnement 2€/mois + 10€ de carte sim(une fois)
VM abonnement 5€/an

Cartes ESP32 commandées

Prototype d'une grappe :

a. Ordre de connexion des capteurs au micro-contrôleur

Disposition sur l'étagère de la bibliothèque Fil électrique Programme ESP32
Haut jaune pin 35
v bleu pin 17
v vert pin 21
v violet pin 22
Bas blanc pin 23

(1) 3ème colonne Programme ESP32 : ligne 8 du fichier main.cpp dans https://git.cohabit.fr/thermo-bibli/code-grappe/src/commit/70e5ca43ad01b333ff80f9b1a0bcf444059ae1d3

b. Problèmes particuliers rencontrés

-- Changement du circuit d'alimentation

  • Les fils de la batterie initialement prévus pour les pins VCC et GND sont finalement soudés à la main directement sur le + et le - de la pile principale,
    afin d'éviter les pertes d'intensité (cause probable: résistivité, origine : quelquepart sur la carte ESP) constatées avec l'ampèremètre .
  • 3 piles sont ajoutées en parallèle afin d'augmenter la capacité ampérique (aka le stock électrique) sans modifier la tension du circuit (autour de 4V).

-- Abandon de 2 pins (capteur DHT)

En date du 30 novembre, après réparation du port USB physique de l'ESP32,
et le changement de plusieurs lignes de code pour ajouter de la verbose à la connexion au hotspot :
nous avons pu constater que lorsque les pins 2 et 13 sont connectés,aucune donnée n'est envoyée au serveur.
  • supposition : lien avec le SPI (pin 2) ? quid du pin 13 ?
  • C'est finalement le pin 35 qui est choisi comme remplacement du pin 2.

Prototype V2 :

Plusieurs modifications ont étaient apportées au Prototype.
Le projet se basais sur un ancien modèle d'ESP32 avant de passé au Olimex ESP32-Devkit-LiPo-EA ce qui entraîna différents soucis.

Mesure de la capacité de la batterie.

L'ESP étant différent du précédent, son architecture l'est aussi (disposition spatial des ports).
Sur l'ancien ESP il était possible de mesurer sa batterie sans lui apporter de modification physique. Le nouveau nécessite des soudures a plusieurs niveaux : BAT_SENS_E1, BAT_PWR_E1 et au PWR_SENS_E1.
Une fois ceci fait il était techniquement possible de mesurer la valeur de la tension aux borne du microcontrôleur.
Cependant le code calculant la capacité de la batterie était paramétré pour l'ancien ESP, j'ai donc du changer la variable contenant l'adresse du port de lecture avec 35, l'adresse virtuelle du GPIO35.

Position et intégrité des capteurs

Même problème, l'adresse des anciennes PIN de L'ESP n'était plus les bonnes et sont maintenant à jour.
Un des capteurs n'a pas été assez bien étalonné physiquement en usine, nous l'avons identifié et nous pourrons ajuster sa valeur dans le code.

Soucis de communication ESP/VM

Suite à des mises à jours, certaines dépéndances utilisés dans les script Pythons sont concidérés par la VM comme inutilisé puis supprimé, ce qui entraine un mauvais fonctionnement.
InfluxDB étant la partie stockage de donnée du serveur eu aussi un problème en lien avec celui des scrpit.
La solution trouver à été de mettre à jour InfluxDB et de modifier le script Python.

Cependant pour tester si l'ESP fonctionne bien nous utilisons Grafana qui ne marchais pas à cause de ces soucis.
La commmande suivante permet de récupérer sur le Broker MQTT ce qui est reçu, nous à permis de tester le fonctionnement de l'ESP sans Grafana:
mosquitto_sub -h cohabit-capteurs.aquilenet.fr -u capteurs -P Fablab -t test-alex