Réflecteur solaire automatisé

Projet réflecteur solaire automatisé

 

LUCAS Miguel                        KIEFFER Maxime                      NESTELHUT Alexandre

 

 

SOMMAIRE

 

     I.Préparation

              Contexte et principe

              Choix des techniques et du matériel

              Montage du réflecteur

              Recherche des coordonnées solaires

 

     II.Création du support

            Pied et rotation

             Cadre et pivotement

             Montage final (à compléter)

 

     III.Programmation

             Branchements et configuration

             Tests des servomoteurs avec des valeurs données

             Amélioration à l’aide de la carte SD

             Modifications complémentaires

 

     IV.Conclusion et remerciements

 

 

 I.Préparation

 

 1.Contexte et principe

Dans le cadre d’étude et réalisation du troisième semestre du DUT GEII (Génie Électrique et Informatique Industrielle), un projet nous a été confié par notre professeur référent, M. OULD ABDESLAM Djafar, consistant à étudier la mise en place d’un réflecteur solaire et ainsi dans un deuxième temps le réaliser dans le but de faire converger les rayons du soleil vers un point donné (par exemple une maison pour pouvoir chauffer celle-ci) d’une manière autonome.Ce type de réflecteur n’étant pas commercialisé en France, la conception et la programmation se créera de toutes pièces par notre groupe, et pourra aboutir à une présentation pour des entreprises intéressées et ainsi effectuer une potentielle mise sur le marché.

 

 

 

 

Ce réflecteur est composé d’une base solide afin de maintenir la structure stable en cas d’intempéries ou de temps indésirable. Sur celui-ci seront situés un servomoteur et un moteur pas à pas contrôlés par une carte Arduino permettant d’effectuer les rotations nécessaires, à savoir une horizontalement et l’autre verticalement pour que le miroir fixé à la structure puisse se mouvoir dans plusieurs positions et angles possible nécessaires à réflexion des rayons du soleil, ceux-ci devant incider sur un point précis, en l’occurrence ici les fenêtres du bâtiment afin de le chauffer ou d’améliorer sa luminosité de manière écologique.

 

 

2.Choix des techniques et du matériel

 

Nous avons utilisé un moteur pas à pas pour sa rotation continue permettant de faire plusieurs tours pour descendre et remonter le panneau, et inversement le servomoteur qui reste bloqué à son dernier angle lorsque l’on coupe l’alimentation pour pouvoir tourner et rester dans l’orientation voulue.

 

Nous avons utilisé une carte Arduino Uno étant donné que cette dernière est pratique dû à sa simplicité de fonctionnement et sa faible consommation. Pour alimenter le servomoteur ainsi que la carte Arduino, nous avons choisis un adaptateur USB 4 ports étant donné que la puissance délivrée par l’Arduino n’est pas suffisante pour le servomoteur. Une alimentation externe plus puissante est prévue pour le moteur pas à pas.

 

 

3.Montage du réflecteur solaire

 

 

Lors du montage, nous avons constaté que la fixation de base du panneau risquait de subir les aléas de la météo et ainsi fragiliser le réflecteur. Pour régler ce souci, nous avons eu l’idée de renforcer la structure avec des plaques reliées aux coins supérieurs et ainsi de remplacer l’ancien support.

 

 

 

4.Recherches pour les coordonnées solaires

 

Afin de réaliser notre projet, nous avons dû faire des recherches concernant les positions et trajectoires du soleil pour calculer les angles de rotation des servomoteurs, un par rapport au Zénith du Soleil et un par rapport à l’Azimut.

 

Azimut et Zénith (ici hauteur) :

 

 

 

Pour cela, nous avons utilisé de nombreux sites afin de nous renseigner au maximum tels que http://www.solartopo.com ou encore www.sunearthtools.com que nous allons utiliser pour récupérer les données.

 

Au préalable, nous avons calculé la hauteur (Zénith) grâce à une formule trouvée sur le site www.buzzcasonits.blogspot.com pour vérifier que les valeurs soient cohérentes.

 

 

Le meilleur moyen d’avoir les données étant de les récupérer directement sur le site web, nous avons téléchargé le fichier csv pour l’année 2019.

 

 

Par la suite nous avons testé nos hypothèses en vrai, grâce à notre réflecteur et à un Fluke Thermal Imager, muni d’un laser.

 

 

II. Création du support

 

1.Pied et rotation

 

Pour créer le support, nous avons récupéré un bon nombre de pièces. Tout d’abord, pour la base nous avons utilisé un tube rectangulaire muni d’un pied. Nous avons alors mesuré les dimensions du servomoteur puis découper le haut du support aux bonnes dimensions. Pour soutenir le servomoteur, la partie découpée a été pliée. Pour finaliser cette partie nous avons limé les bords afin d’éviter les rayures.

 

 

Ensuite nous avons tracé le schéma pour les parties supérieures du support. Nous avons découpé le tout dans du bois (medium). Ce système sera composé de 2 disques en bois, l’un posé sur l’autre grâce à des billes en verre calées dans un rainure afin d’éviter de mettre tout le poids de la partie supérieure sur le servomoteur

 

 

Après avoir tracé le schéma sur papier nous avons fait une modélisation 3D grâce au logiciel de CAO FreeCAD (logiciel libre totalement gratuit) dans le but de les réaliser grâce à la fraiseuse CNC 3 axes à l’IUTlab ; voici les figures représenter en 3D dans le logiciel :

 

 

 

Malheureusement nous n’avons pas pu réaliser les cylindres à la fraiseuse 3 axes ; nous les avons donc faits « à la main » : pour créer le cylindre ainsi que la gouttière nous avons utilisé la fraiseuse manuelle, pour les parties qui durent être creusée nous avons dégrossi le travail grâce à la perceuse à colonne puis affiné aux ciseaux à bois. Voici le résultat :

 

 

 

 

Pour pouvoir fixer le tout nous avons vissé (temporairement pour avoir un pied stable) une plaque bien plus grande en bois (medium de 5 cm d’épaisseur). Le tout monté donne ce résultat :

 

 

2.Cadre et pivotement

 

Une fois les deux cylindres fixés sur le pied nous sommes passés au second axe qui lui est en deux parties : le support du miroir et l’entraînement du servomoteur :

 

– le support en miroir est entouré d’un cadre en aluminium qui fait le pourtour du miroir, lui étant coincé entre une barre en bois et le cadre justement pour éviter de devoir le percer

 

 

 

-l’entrainement est fait par le servomoteur qui agit sur deux barres reliées entre elles et au miroir, mais le servomoteur manquant de puissance pour soulever le miroir nous allons devoir améliorer ce mécanisme.

 

 

3.Montage final

 

Après de multiples tests, nous avons constaté que le moteur n’était pas assez puissant pour pouvoir faire remonter le panneau. C’est pourquoi nous avons changé notre deuxième axe en utilisant une tige filetée avec un moteur pas à pas.

Contrairement au servomoteur, le moteur pas à pas va fonctionner en nombre de tours et va faire tourner la tige filetée ce qui va provoquer l’inclinaison du miroir.

 

 

Après avoir modifié cet axe, nous avons assemblé les deux parties entre elles grâce à trois vis et deux tiges filetés avec écrous.

 

 

 

III.Programmation

 

1.Branchements du système

 

A savoir : l’Arduino est alimentée grâce au port Vin connecté à l’un des servomoteurs directement branché sur le secteur

 

Configuration carte Arduino Uno

2.Test des servomoteurs avec des valeurs données

 

3.Amélioration à l’aide de la carte SD

 

Une fois que les moteurs tournent nous devons cette fois-ci obtenir les valeurs à leur envoyer à partir d’un fichier texte. Pour ce faire nous avons choisi l’option d’utiliser une carte SD car l’accès à celle-ci est plus simple que si nous devions accéder à la mémoire de l’Arduino. Nous avons donc commandé une extension SD pour notre carte Arduino UNO et branché soigneusement sur celle-ci.

4.Modifications complémentaires

 

 

Suite à l’avancement du projet, nous avons remarqués que notre programme initial ne convenait plus à nos besoins. Nous avons fait des modifications : une par rapport à la récupération de données et l’autre par rapport à une modification faite dans le montage.

 

– Modification pour la récupération de données sur un an : Dans ce cas , nous avons remplacé le fichier sur la carte SD par un fichier ayant les valeurs pour toute l’année, puis nous avons modifié le programme car la lecture sur un an n’est pas pareil que celle sur un jour.

 

 

-Modification pour le fonctionnement du moteur pas à pas

 

Dans ce cas, nous avons remplacé notre servomoteur par un moteur pas à pas donc nous avons changé la formule pour ce dernier. Pour cela nous calculons le nombre de pas de que le moteur doit faire pour obtenir le nombre de tours, ce qui diminuera ou augmentera la distance entre le moteur et le bout de la tige filetée et donc incliner le panneau d’un certain angle

 

 

 

IV.Conclusion et remerciements

 

Nous voulons tout d’abord remercier Mr OULD ABDESLAM Djafar de nous avoir guidé et aidé tout au long du projet. Nous voulons aussi remercier Mr DE SABBATA pour nous avoir donné de nombreux conseils et aussi pour nous avoir autorisé à utiliser l’IUT Lab pour nos besoins. Nous aimerions également remercier Mr WIRA pour son aide concernant la gestion de la carte SD et la lecture du fichier.

Pour conclure, ce projet a été pour nous une expérience importante pour notre cursus car nous avons pu travailler en groupe tout au long de l’année. Nous avons appris à nous partager les tâches, à faire des compromis entre nous pour pouvoir satisfaire au mieux les besoins du projet. De plus cette expérience fut d’autant plus enrichissante car nous avions un projet concret avec une réalisation à la clé qui s’est concrétisée.

Nous pouvons également ajouter à ce projet divers points d’amélioration, que ce soit remplacer les pièces en bois par de l’aluminium pour augmenter sa robustesse, un anémomètre permettant de coucher le panneau en cas de vent fort détecté, une cale pour éviter le redressement quelque peu brusque du retour en position initiale du panneau. Un capteur serait également à prévoir sous le miroir pour l’éviter de descendre trop loin et causer des dégâts.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Mallette qualité de l’énergie

Quentin JACQUEY

Anas BOUHSSINE

Emre TEKIN

Mise en œuvre d’un module WAGO

Rapport de Projet

Introduction

 

Dans le cadre de notre DUT GEII, il nous fallait réaliser un projet pendant notre troisième semestre. Ce projet reposait sur un automate programmable WAGO, celui-ci nous permettrait de réaliser des mesures et une récupération des données de consommations électriques d’une installation.

Nous avons alors dû programmer une interface graphique pour faciliter la prise en main de l’utilisateur.

Finalement, la récupération et affichage des données de l’automate se feront au travers d’un Janitza, un appareil de mesure couplé au WAGO.

 

Afin de mener à bien ce projet, nous avions à notre disposition une mallette, composée de l’automate auquel nous avons ajouté un appareil, tenant le rôle de transformateur 230/24 V afin d’alimenter l’automate. Nous avons également utilisé un Janitza, dont le rôle sera détaillé plus loin.

Sommaire

A. Objectifs

B. Ressources

  1. Avancement

  2. Installation

  3. Mesures

  4. Banque de données

  5. Reprise de toutes les étapes

C. Reprise de la banque de données

D. Difficultés rencontrées

E. Conclusion

F. Annexes

 

A. Objectif

Notre projet WAGO permet de mesurer et analyser une ou plusieurs installations électriques, ce qui permet à l’utilisateur de contrôler ou optimiser sa consommation électrique.

Nous avons comme projet également de transférer les données vers l’automate depuis un Janitza, afin de créer une banque de données qui va permettre de récupérer et stocker les données instantanées dans l’automate venant du Janitza.

B. Ressources

 

Pour notre projet, nous avions à disposition :

  • Automate WAGO (Référence 6028-2186)(Centrale Fastlogger 3G)

  • Module 750-494 Module de mesure

  • Module 750-495 Module de mesure

  • Module 750-600 Module d’extrémité

  • 3 sondes de courants 60V/1A
  • 4 boucles de Rogowski

 

 

 

Nous avons intégré un transformateur 230/24V qui est utilisé comme alimentation.

Nous utilisons comme câbles un câble d’ordinateur recyclé et dénudé. Nous branchons ce câble à la prise de la mallette.

Nous avons également utilisé plusieurs logiciels :

 

  • WAGO Ethernet settings

  • WAGO-IO Check

 

  • Fastlogger

Nous avions envisagé d’utiliser le logiciel Codesys et éventuellement un Raspberry PI afin de créer une base de données où stocker les données.

Nous avons finalement opté pour la solution du Janitza.

Le Janitza est un appareil de mesure  que nous avons utilisé afin de projeter les données récoltées par le Janitza vers notre automate.  Son installation et branchement sont détaillés ci-dessous.

 

C. Avancement

Le schéma ci-dessous démontre le but de notre projet et les différentes étapes de notre projet.

 

Notre projet ce sépare en plusieurs étapes :

  1. L’installation
  2. Les mesures
  3. Programmation envoi des données
  4. Reprise des étapes

Le contenu de chacune de ces étapes ainsi que l’avancement actuel sont développées ci-dessous.

 

1.L’installation

Nous avons dû, en premier lieu, nous approprier le matériel à disposition, et comprendre le fonctionnement de celui-ci en lisant les documentations techniques.

Les branchements de l’automate ont été préalablement effectués, il nous fallait cependant connecter l’automate à une alimentation. Là où les étudiants de l’année précédente avaient utilisé un transformateur externe, nous avons opté pour un transformateur interne à la mallette.  Pour cela, nous avons utilisé un transformateur 230/24V fourni par le professeur. Il nous fallait donc intégrer le transformateur dans la mallette qui nous était fourni. Pour cela, nous avons utilisé un câble d’ordinateur que nous avons dénudé afin de servir de câble d’alimentation reliant la prise de la mallette au transformateur.

Après avoir testé le bon fonctionnement du transformateur et de l’automate, il nous fallait maintenant s’occuper de l’adresse IP de l’automate.

Une adresse nous avait été fournie : 10.95.11.33, préalablement configuré grâce à WAGO Ethernet Settings cette adresse correspond à l’adresse de l’automate dans le réseau UHA.  Pour tester la concordance de l’adresse, nous avons configuré un ordinateur portable sur le même sous-réseau que l’automate à l’adresse : 10.95.11.32.

Après vérification, l’automate a la bonne adresse.

Nous avons également installé FASTLOGGER dans l’automate grâce aux étapes décrites en Annexe 1.

 

2.Mesures

Une fois l’automate correctement configuré, nous avons effectué des mesures grâces à des lampes halogènes.

Nous avons utilisé IO-CHECK pour voir les mesures.

Pour mesurer, nous avons utilisé les sondes de courants sur une seule phase.

Voici les mesures obtenues :

D’abord, avec les lampes à mi-puissance :

Puis avec les lampes à leur puissance maximale:

Grâce à ces mesures, nous nous sommes assurés du bon fonctionnement et du logiciel, et de l’automate.

En effet, nous constatons qu’à leur puissance maximale, les lampes produisent des harmoniques plus importantes et plus nombreuses, ce qui démontre le bon fonctionnement des mesures de notre automate.

 

 

3.Banque de Donnée

 

Pour créer une banque de données, nous envisagions d’utiliser CODESYS ainsi qu’un Raspberry PI. Cependant, nous avons  eu des problèmes vis-à-vis des logiciels. Nous possédions CODESYS 2.3, mais les automates WAGO ne sont pas reconnus comme des cibles du logiciel. Pour résoudre ce problème, nous avons communiqué avec Mr. MARTIN, qui travaille chez WAGO. Mr. MARTIN a répondu à notre demande et nous a donné accès au logiciel avec la référence de notre automate.

Nous avons trouvé la référence correspondante du logiciel qui allait avec notre automate. Nous pouvions désormais nous consacrer à la programmation de la banque de données. Quant au Raspberry PI, nous avions décidé d’abandonner l’idée de l’utiliser. En effet, le logiciel qui nous permettrait d’utiliser le Raspberry PI était payant.  De plus, CODESYS remplissait déjà toutes les fonctions nécessaires à notre projet.

Nous avions besoin d’accéder à la fonction ‘‘root’’ du logiciel Putty afin de pouvoir modifier, supprimer ou ajouter des fonctions dans l’automate. Pour y accéder, il nous fallait un identifiant et un mot de passe, malheureusement aucun des deux ne nous a été donné par les anciens étudiants en charge de ce projet. Nous étions donc obligés de reboot l’automate et refaire alors toutes les étapes décrites précédemment.

 

4.Reprise de étapes

 

Après avoir fait un « reset » de l’automate grâce à ces  étapes (Annexe 2), nous avons perdu toutes les données que contenait l’automate. Nous voulions donc reprendre toutes les étapes. Malheureusement l’adresse IP initiale qui nous a été donnée est fausse. Nous avions donc activement recherché l’adresse IP actuelle de l’automate. Nous avons trouvé comment faire (Annexe 2). L’adresse IP de l’automate est donc désormais 192.168.1.17.

Nous avons également reset les identifiants et mot de passe pour le site Web-Base Management, ce que l’on recherchait. Nous avons défini les mots de passe tel quels:

Identifiant :                  1.user                           2.admin

Mot de passe :            1.wago                         2.user

Nous avions donc dû refaire toutes les étapes précédentes, une fois l’adresse IP de l’automate reconfiguré sur 10.95.11.33.

 

Après que notre automate ait été reconfiguré correctement, nous pouvions reprendre la programmation de la banque de données grâce à Codesys.

Nous avions pour cela configuré le logiciel pour qu’il reconnaisse l’adresse de l’automate.

 

Afin de compiler et charger le programme dans l’automate, nous avions besoin d’un mot de passe qui était :

Mot de passe : user

Ainsi, nous avons réussi à transférer le programme dans l’automate, nous pouvions alors récupérer les données de la consommation électrique des installations.

Le résultat est montré ci-dessous.

Après de nombreux tests, nous avions compris qu’il nous fallait utiliser Fastlogger après avoir discuté au téléphone avec notre contact WAGO.

 

Après avoir eu accès aux pleins pouvoirs sur l’automate grâce à Putty (Annexe 3), nous avons pu accéder à Fastlogger, que nous avions installé précédemment. Ce logiciel nous permet d’accéder directement aux données récoltées dans l’automate.

 

Le logiciel Fastlogger se présente sous cette forme :

 

Après avoir vu un aperçu de ce que donnait la récolte des données.

Fastlogger va nous permettre d’archiver ces données sur un fichier .csv contenu dans la carte mémoire.

Nous allons alors transférer ces données archivées et récoltées sur un serveur FTP donné par l’IUT.

Malheureusement, le serveur FTP était inutilisable, en effet,  la complexité du réseau empêchait d’établir une liaison avec notre automate. Nous avons donc dû abandonner l’idée du serveur.

Nous devions également nous servir d’un module de mesure, le Janitza 96 RM-E. Il s’agit d’un équivalent du Wago que nous utilisons comme centre de mesure. Pour cela, nous avons connecté le Janitza avec l’automate en Modbus TCP/IP afin de récupérer les valeurs mesurées par le Janitza. Le Wago sert alors de centre de collecte des données du Janitza que l’on enregistre sous CSV grâce à un adressage spécifique.  (ANNEXE 4)

 

D. Difficulté rencontré

 

Lors de notre projet, nous avons rencontré certaines difficultés. En effet, la première difficulté fut de trouver le logiciel adapté pour nous permettre de coder notre banque de données. Après avoir trouvé Codesys, la difficulté a été de nous le procurer. La version WAGO n’étant pas disponible sur leur site, nous avons envoyé des mails à notre contact MR. Martin, il nous a envoyé un lien pour le télécharger mais qui ne contenait pas la référence de notre automate. Il nous a alors fallu attendre qu’il nous renvoie le lien contenant le logiciel avec notre référence.

  • Nous avons rencontré des difficultés afin de transférer le programme depuis le logiciel vers l’automate. Nous avons donc essayé plusieurs méthodes. D’abord avec un câble ETHERNET, cela ne marchait pas. Nous avons alors essayé avec un câble RS232, cela ne marchait pas non plus. Enfin nous avons branché l’automate sur le réseau, et nous avons pu nous connecter à lui depuis le logiciel grâce à son adresse IP.
  • Le problème majeur que nous avons rencontré a été l’accès au noyau de l’automate Wago. En effet l’installation du fastlogger doit se faire dans le noyau par le logiciel « Putty ». Ce logiciel comporte 3 utilisateurs. Le premier ne servant à rien est « User » utiliser pour voir les fichiers installé dans le noyau. Le second est « admin » qui peut être utilisé pour accéder au noyau et y transférer certains fichiers. Enfin il y a le super admin « root » qui donne libre accès à toute manipulation du noyau. C’est celui-ci qui était la cause du problème car le mot de passe défaut a été modifier.

La solution est donc de réinstaller le firmware du wago (Annexe 5…) et d’utiliser le mot de passe par défaut.

  • Nous avons eu également l’idée d’utiliser un serveur FTP afin d’y stocker les données. Malheureusement, la connexion de l’automate avec le serveur était impossible, dû à la complexité du réseau UHA (sécurité).
  • Nous avons donc dû utiliser un Janitza 96 Rm-E. La complexité de son utilisation ainsi que celle de la connexion avec notre automate nous a apporté des difficultés sur la compréhension de ceux-ci. Grâce à des recherches fructueuses, nous avons compris son utilisation et nous avons donc pu utiliser le Janitza tel que nous en avions besoin.

 

E. Conclusion

 

Si on devait résumer notre projet, nous pourrions dire que nous avons apporté :

  • Un transformateur interne, afin d’alimenter de manière autonome l’automate
  • Modification des mots de passe des différents logiciels que nous avons dû réinitialiser
  • Installation du Fastlogger dans l’automate, ainsi que son codage et son utilisation
  • Après de nombreux problèmes, l’utilisation du Janitza comme module de mesure et utilisation de notre Wago comme centre de collecte de ces données

Cependant, nous sommes conscients que notre projet aurait pu être amélioré :

En effet, si l’utilisation du serveur FTP, la récolte des données aurait pu être plus ludique et attractive.

Nous aurions pu également créer une interface graphique pour mieux représenter les données récoltées à partir du Janitza.

 

F. Annexes

 

Annexe 1 : Installer FASTLOGGER

  • Copier-coller le fichier .ipk dans le dossier tmp du FTP du contrôleur
  • Ouvrir une connexion SSH sur le contrôleur grâce à Putty [se connecter avec les identifiants suivant : root (utilisateur) et wago (mot de passe)]
  • Sous Putty, ouvrir le dossier tmp (grâce à la commande « cd /tmp »).
    Il faut respecter l’espace entre le ‘d’ et le ‘/’
  • Lancer la commande d’installation :« ipkg install install-fastlogger_1.2.10_arm.ipk ».

Il faut respecter tous les espaces et bien renseigner le nom du fichier y compris l’extension. FASTLOGGER se lance donc.

Annexe 2 : Reset et trouver l’adresse IP

Reset :

  • Appui sur Bouton « RST » pendant 8 secondes, jusqu’à ce que la led « SYS » clignote en orange.
  • Mettre le Switch en mode « Reset ».
  • Attendre 3 secondes le temps que la Led « Sys » soit rouge.

Trouver adresse IP :

  • Mettre le Switch en mode « STOP »
  • Appui sur Bouton « RST » pendant 8 secondes, jusqu’à ce que la led « SYS » clignote en orange
  • L’adresse IP de l’automate est alors : 192.168.1.17

Source : Data sheet 750-8207

 

Annexe 3 : Avoir les pleins droits sur l’automate

 

Sur Putty, rentrer les informations telles quelle :

Un message d’information va s’afficher, cliquer sur « Oui ».

Une boite de dialogue va alors s’afficher :

S’identifier en tant que « root », le mot de passe correspondant est : « user ».

Vous aurez dès lors un accès total sur l’automate, c’est-à-dire que vous pourrez avoir accès aux programmes installés sur l’automate, les modifier, en supprimer, ou en créer.

 

Annexe 4 : Configuration Janitza

 

Configuration de l’adresse IP du Janitza :

Appuyer pendant 5 secondes sur la touche 1 et 2 du janitza pour entrer dans le mode de paramétrage du janitza.

La navigation dans le menu est possible grâce à la touche sur laquelle se trouve une flèche vers la droite et la validation la touche vers le haut.

En navigant dans ce menu, on peut changer l’adresse IP du Janitza dans la sous-section addr où l’adressage ce fait en 4 étapes.

Suite à cela on rentre cette adresse dans la case dédié dans le fastlogger dans l’onglet configuration modbus TCP/IP

Dans l’onglet requête, on ajoute l’adressage spécifique à la valeur que l’on veut.

Dans l’onglet donné on peut visualiser les données et aussi archiver les valeurs que l’on souhaite.

Attention à l’ état !!

Etat 150: Sans réponse

Etat 129: Problème Communication

Etat 0: En fonctionnement

Visualisation des données avec possibilité d’archivage.

 

Attention à l’adressage ! L’adressage fournit dans le noyau du wago est incorrecte et il faut ajouter un par un les adressages de registre que l’on souhaite récupérer retrouvable dans la datasheets du Janitza.

Annexe 5 : Réinstallation Firmware

1.Télécharger ce fichier

http://www.wago.com/public-download/Support/FW/0750-8xxx/WAGO_FW_0750-8xxx_I.ZIP

2.3.4.

5. Insérer la carte SD dans le PFC200 ou la microSD dans le PFC100, puis le redémarrer électriquement. Le lecteur de cartes SD ou microSD clignote orange pendant plusieurs secondes. L’image du noyau est automatiquement chargée dans la mémoire RAM.

Après la séquence d’initialisation, les LEDS SYS et I/O sont vertes fixes. La LED RUN est rouge fixe, le lecteur de cartes SD ne clignote plus.

A ce stade, l’image du noyau est simplement présente en mémoire RAM, il est nécessaire de la copier sur la mémoire Flash interne.

6. Une fois tous cela fait connecter vous à Web-Based Management.

7. Retirer la carte SD ou microSD, puis redémarrer le PFC. Le PFC a été mis à jour. Retourner sur le Web-Based Management afin de vérifier la version du firmware.

8.La carte SD n’est pas utilisable en stockage. Il faut donc la formater.

 

 


Supervision Efficacité Energétique

HEGE Simon

MINERY Loïc

Rapport Efficace Energie

Projet 2018/2019

 

 

 


Sommaire

  1. Remerciements

  2. Introduction

  3. Cahier des Charges

    1. Bêtes à corne
    2. Diagramme pieuvre
    3. Partage des tâches
    4. Schéma de fonctionnement
    5. Environnement logiciel
    6. Environnement matériel
    7. Capteurs utilisés
    8. Comparaison capteurs
      1. Première partie
      2. Deuxième partie
  4. Recensement capteurs

    1. Création d’une interface VBA sur Excel
  5. Logiciel EfficaceEnergie

    1. Prise en main
    2. Création plan IUT
    3. Enregistrement nouveaux capteurs
    4. Compte admin et utilisateur
    5. Analyse de résultats
  6. Conclusion

  7. Annexes

    1. Captures d’écrans Comparaison
    2. Novembre
    3. Septembre
    4. Octobre

Remerciements

Nous tenons à remercier notre professeur référent, M. Ould qui nous a proposé ce projet et nous a guidé tout au long de ses semaines de recherches et de supervision. Nous souhaitons également remercier M.Marco SANGWA qui nous a permis d’utiliser son rapport de stage.

Introduction

Le but principal de ce projet était d’analyser les données de capteurs de la société Distrame afin d’avoir une meilleure efficacité énergétique au sein de l’IUT de Mulhouse. Notre projet Efficacenergie a donc consister en l’installation de capteurs dans l’établissement, puis en leur enregistrement dans le logiciel Efficacenergie afin de relever leurs courbes de consommation ou leurs courbes de température. Nous avons recenser les capteurs existants et nous avons analyser les données des capteurs déjà installés. Nous avons également utilisé le rapport de stage de M. Marco SANGWA, étudiant de l’année passée, qui nous as permis de comprendre le fonctionnement des différents logiciels afin d’installer les capteurs plus facilement et plus rapidement.


Cahier des Charges

Bêtes à corne

 

Diagramme pieuvre

Contraintes majeurs

  • Plan interactif : Le plan devait être clair et intuitif afin de pouvoir effectuer le suivi de la consommation pour chaque capteur.
  • Déclaration des capteurs : Chaque capteur devait être déclaré sur le logiciel wavenet, on lui a attribué ensuite un répéteur si cela était nécessaire.
  • Cohérence des valeurs : Trouver l’origine d’un décalage de ± 9 % entre les relevés des capteurs Distrame et UHA.

Contraintes mineurs

  • Esthétique : L’interface doit être esthétique dans la mesure du possible.
  • Fiabilité : L’interface doit fonctionner correctement ainsi que la déclaration des capteurs dans l’architecture.
  • Simplicité : Elle doit être simple d’utilisation.
  • Sécurité : Mise en place de comptes utilisateur et administrateur.

Partage des tâches

MINERY Loïc :

  • Création plan IUT interactif avec courbes et mesures pour chaque capteur de chaque bâtiment.
  • Comparaison capteurs UHA et Distrame
  • Recensement des capteurs
  • Installation des nouveaux capteurs
  • Powerpoint

HEGE Simon :

  • Création de l’interface pour le recensement des capteurs
  • Recensement des capteurs
  • Comparaison capteurs UHA et Distrame
  • Installation des nouveaux capteurs
  • Rapport

Schéma de fonctionnement

Environnement logiciel

  • Interface Distrame Efficacenergie
  • Logiciel Wavenet monitor
  • Logiciel Diris Digiware

Environnement matériel

  • Capteurs
  • Ordinateurs

Capteurs utilisés

Comparaison capteurs

Première partie

Notre enseignant référent, M. OULD nous a demandé de comparer sur plusieurs mois les valeurs de consommation électriques mesurées par les capteurs de la société DISTRAME et ceux de l’UHA. Nous avons utilisé le logiciel EfficaceEnergie ainsi que le logiciel Diris Digiware de l’UHA, auquel nous avons eu accès grâce au compte utilisateur de M. OULD. Nous avons ainsi comparé les données des capteurs installés dans différents bâtiments.

 

Tableau de la consommation des bâtiments selon le mois
Tableau de la consommation des bâtiments par semaines

 

Nous avons alors remarqué que les capteurs UHA ont toujours des valeurs plus élevées que ceux de DISTRAME sauf au mois de Juillet (valeurs en rouges) où nous constatons que les capteurs UHA du bâtiment A et Générale sont plus élevées que ceux de Distrame.

Nous avons calculé les pourcentages de différences entre les capteurs et il semble qu’en générale, sur trois mois, la différence soit d’environ 9 %.

Conclusion première partie

Nous avons remarqué une différence d’environ 9 % entre les capteurs des deux sociétés. Nous avons alors contacté, par mail et téléphone, M. LALLEMANT, un agent de DISTRAME, pour lui demander s’il avait une explication à cette différence entre les capteurs. Il ne pouvait malheureusement pas nous répondre. Nous avons ensuite contacté par téléphone M. SCHMIDT qui nous a redirigé vers le support de Distrame. Un agent nous a demandé les références de nos capteurs ainsi que celles des compteurs. Il souhaitait aussi connaitre les valeurs de nos boucles de courants, mais nous n’y avons pas accès seul.  Nous lui avons envoyé toutes les informations par mail par deux fois, sans réponse de sa part.


Deuxième partie

Notre enseignant référent nous a demandé, dans un second temps, de comparer les valeurs de consommation électriques des capteurs DISTRAME et UHA mais cette fois sur une période de 6 mois. Ainsi , nous avons comparé les données du mois de juillet 2018 au mois de décembre de la même année afin de vérifier si la différence de 9 % persistait sur une longue période.

Rapport de consommation sur la période juillet-décembre 2018

Consommation bâtiment A

 

La valeur du capteur Distrame de consommation du bâtiment A est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 3.94%.

Nous observons un pic de consommation à environ 200 kWh pour le capteur UHA, à la date du 10 décembre 2018, qui n’est pas présent sur le relevé du capteur Distrame.

Consommation bâtiment B

 

La valeur du capteur Distrame de consommation du bâtiment B est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 3.59%, ce qui est assez proche de la valeur obtenue pour le bâtiment A.

A la date du 10 décembre 2018, nous observons à nouveau un pic de consommation à environ 440 kWh pour le capteur UHA, qui n’est pas présent sur le relevé du capteur Distrame.

Consommation bâtiment C

 

La valeur du capteur Distrame de consommation du bâtiment C est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 2.52%.

 

Nous observons encore un pic de consommation à environ 700 kWh pour le capteur UHA, à la date du 10 décembre 2018, qui n’est pas présent sur le relevé du capteur Distrame. Les relevés sont cohérents.

Consommation bâtiment E

 

La valeur du capteur Distrame de consommation du bâtiment E est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 1.99%, ce qui est beaucoup moins élevé que les valeurs obtenues pour les bâtiments A et B.

 

A la date du 10 décembre 2018, nous observons de nouveau un pic de consommation à environ 760 kWh pour le capteur UHA, qui n’est pas présent sur le relevé du capteur Distrame. Les relevés sont cohérents.

Consommation bâtiments DFGH

 

La valeur du capteur Distrame de consommation des bâtiments D, F, G et H est cette fois-ci moins élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons donc un point de pourcentage négatif de -2.04%.

A la date du 10 décembre 2018, nous observons un pic de consommation à environ 1300 kWh pour le capteur UHA qui n’est pas présent sur le relevé du capteur Distrame.

Consommation logements de fonctions

 

La valeur du capteur Distrame de consommation des logements de fonctions est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 1.14%, ce qui qui représente l’écart le plus faible entre les capteurs de l’UHA et ceux de Distrame.

On n’observe pas de pic de consommation au 10 décembre, les deux graphiques semblent équivalents.

Consommation générale de l’IUT

 

La valeur du capteur Distrame de consommation générale est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous observons un plus grand écart avec un point de pourcentage de 4.74%.

On observe un pic de consommation le 10 décembre 2018 pour environ 3500 kWh.

 

Nous avons remarqué une différence entre les valeurs générales mesurées par les capteurs et celles obtenues en additionnant les valeurs obtenues précédemment. Ainsi, la valeur mesurée par le capteur UHA est plus petite que celle obtenue par la somme alors que la valeur mesurée par le capteur Distrame est plus élevé. Les valeurs obtenues par la somme sont plus cohérentes car plus rapprochées l’une de l’autre.

Conclusion deuxième partie

Nous avons remarqué que les relevés des capteurs UHA et Distrame sont cohérents entre eux. Les valeurs des capteurs Distrame sont généralement plus élevées que celles des capteurs UHA sauf pour les bâtiments D-F-G-H.

Nous avons également remarqué un pic de consommation au 10 décembre 2018, uniquement présent sur les relevés des capteurs UHA. Ce pic n’est pas présent sur le relevé de la consommation des logements de fonctions ni sur les relevés des capteurs Distrame. Il s’est donc produit quelque chose au niveau des capteurs UHA ce jour-là.

Enfin, la moyenne de la différence des pourcentages entre les valeurs obtenues sur 6 mois par les capteurs UHA et Distrame est de 1.99%, en comptant le pourcentage négatif des bâtiments D-F-G-H. On remarque donc que la différence de 9% sur une semaine diminue à 2 % sur 6 mois ce qui est une très bonne chose. Les différents capteurs ne donnent donc pas des valeurs trop différentes.


Recensement capteurs

Tout d’abord, nous avons recensé tous les capteurs non-installés physiquement, car il y en avait des nouveaux et des anciens, puis nous avons vérifiés lesquels étaient déjà enregistrés dans EfficacEnergie. Nous en avons également profité pour vérifier les noms de tous les capteurs sur le logiciel et repérer les doublons, les capteurs obsolètes ou bien tout simplement les capteurs mal déclarés.

Ainsi, nous avons comptés 14 capteurs-émetteurs et 5 répéteurs non-installés physiquement. Sur ces 14 capteurs, 10 sont des capteurs waveflows, 3 sont des nouveaux capteurs et 1 seul est un capteur wavesense. Sur les 3 nouveaux capteurs, nous avons 2 capteurs wavetherms et 1 capteur LEM.

Nous avons également recensé 5 répéteurs dont 2 sont des wavetalks.

Certains capteurs non-installés physiquement étaient déjà enregistrés sur le logiciel EfficacEnergie, nous n’aurons donc pas besoin de les enregistrer mais juste les installer sur un compteur. Ils étaient enregistrés sous le collecteur Ethernet qu’il faudra changer pour le collecteur Webdyn. C’était le cas des WFL3 à 9.

Ensuite, nous avons recensés les capteurs physiquement installés dans l’enceinte de l’IUT. Certains capteurs étaient enregistrés sous le collecteur Ethernet dans le logiciel EfficacEnergie, ils ne donnaient donc aucun relevé sur le logiciel. Ainsi le capteur WFL de la salle B010 n’envoyait aucun résultat depuis avril, date à laquelle il a été mis sur le mauvais collecteur. Afin de les faire fonctionner, nous les avons enregistrés sous le collecteur Webdyn qui reçoit toutes les données et les envois au serveur.

Mise en place du capteur sur le collecteur webdyn

Nous avons aussi remarqué que certain capteur enregistré ne correspondait en réalité à aucun capteur réel, il faudra donc les supprimer.

Capteurs ne relevant aucunes données car n’existant pas physiquement

D’autres capteurs étaient utilisés en double sous deux noms différents, nous allons donc en supprimer un des deux.

Capteurs existants en double

Création d’une interface VBA sur Excel

Cette interface permet de rechercher rapidement l’adresse radio, la localisation ainsi que le type de capteur associés au nom d’un capteur ou répéteur. Elle permet également d’ajouter à tout moment un capteur ou un répéteur en plus.

Tableau Excel recensant les capteurs + Interface

Logiciel EfficaceEnergie

Prise en main

Pour débuter, nous avons créé un fichier à notre nom, dans lequel nous avons créé tous les graphiques et tableau. Afin d’obtenir ces fameux graphiques, nous nous sommes aidés du rapport de projet de l’année dernière ainsi que de l’aide présente sur le logiciel.  Nous avons ainsi créé notre premier graphique.

 

Paramétrages permettant la création d’un graphique
Comparaison de la consommation entre les bâtiments de l’IUT (RGB) et la courbe de consommation générale (Noir)

 

Nous remarquons sur ce graphique que la consommation générale n’est pas l’addition de toutes les consommations mais plutôt leur moyenne.

Après la création d’un graphique nous avons voulu créer un tableau.

Graphique et tableau montrant la consommation du bâtiment B sur une journée (Les graphiques barres ont été remplacés par des graphiques linéaires depuis)

Création plan IUT

Après avoir pris en main le site EfficacEnergie, nous avons été capable de créer une carte de l’IUT avec la position des capteurs et ce qu’ils mesurent. Pour cela, nous nous sommes aidés  du rapport de projet de l’année dernière dans lequel toutes les positions des capteurs étaient précisées. Après vérification, certains capteurs avaient malheureusement été changés de place comme le capteur de température WTH salle B016 qui à été déplacé dans l’amphithéâtre nord et que nous avons donc renommé. Nous avons également nous-mêmes rajouté certains capteurs, comme le capteur de température de la cave A ou bien encore celui du bureau de M.Ould.

Plan interactif de l’IUT

Chaque capteur est ainsi représenté par un point avec son nom sur lequel on peut cliquer afin d’avoir le détail de ses mesures. S’il s’agit d’un capteur de température, il est représenté par un point rouge tandis qu’un capteur de consommation est lui représenté par un point vert. Lorsqu’il s’agit de la consommation de plusieurs bâtiments, le capteur est représenté par une maison.

Détail des mesures du capteur de température du bâtiment A

Enregistrement nouveaux capteurs

Le cahier des charges du projet impliquait d’installer de nouveaux capteurs aussi bien physiquement que sur le logiciel. Ainsi, nous avons installé deux capteurs de température Wavethermes que nous avons appelés respectivement WTH15 et WTH16. Le capteur-transmetteur WTH15 a été installé dans le bureau de M. Ould tandis que le WTH16 à lui été installé dans la cave du bâtiment A par un technicien de l’IUT. Avant de les installer physiquement, nous les avons d’abord configurés dans le logiciel wavenet monitor, permettant de vérifier qu’ils fonctionnent correctement et de créer l’architecture réseau.

Ajout d’un capteur à l’aide de son adresse radio
Capteur assigné par défaut. Mauvaise architecture.
Capteur assigné au waveport. Bonne architecture.
Test du signal du capteur concluant

Puis nous avons rentrés les capteurs dans le logiciel Efficaceenergie grâce à leurs codes. Nous avons ensuite pu effectuer toute sortes de tests comme le test RSSI, qui permet de vérifier le pourcentage de signal qui arrive au collecteur, le test de batteries, qui permet de voir le pourcentage de batteries restantes dans chaque capteurs et transmetteurs, ainsi qu’un test de rapatriement, qui permet d’enregistrer la valeur que le capteur lit à l’instant présent.

Activation du collecteur WebdynRF obligatoire pour ajouter des capteurs

 

Ajout du capteur avec sa période d’échantillonnage

 

Test signal du capteur

 

Test du niveau de batterie

 

Test des valeurs rapatriées depuis le capteur

Compte admin et utilisateur

Nous avons créé un compte admin dans lequel nous pouvons ajouter des capteurs et créer des tableaux et courbes. Le compte utilisateur ne permet pas de créer de courbes mais uniquement de visualiser les relevés dont l’admin a donné les droits de visualisation. Nous ne pouvons malheureusement pas créer de compte où l’on pourrait créer des graphiques mais ne pas avoir accès aux configurations.

Fichiers et paramètres auxquels l’admin à accès

Seul le fichier avec le plan et le paramètre de déconnexion sont accessibles au compte utilisateur

Analyse de résultats

Le capteur WFL salle B010 donnait des courbes inadéquates. En effet, les courbes étaient sous formes de pulsions complètement irréalistes pour une valeur de consommation. Nous avons vérifier son branchement au compteur et cela ne changeant rien, nous avons décidé de l’enlever car il ne servait à rien.

Consommation en janvier 2019
Consommation en avril 2018

Le capteur de température de la cave A marche correctement et on remarque que la température reste bien constante à 16 degrés Celsius.

Température de la cave par jour durant une semaine

Le capteur de température du bureau de M. Ould marche lui aussi correctement et on remarque que la température baisse jusqu’à 18 degrés Celsius le week-end, notamment le dimanche. En effet, l’IUT pour baisser sa consommation ne chauffe pas les salles le week-end. Le dimanche 3 mars, la température dans le bureau reste à 20 degrés Celsius car il y avait les portes ouvertes ce week-end là.

Température du bureau de M.Ould tous les jours sur un mois

Conclusion

Notre projet abouti permet la visualisation et l’analyse des données des capteurs de la société Distrame afin d’avoir une meilleure efficacité énergétique au sein de l’IUT de Mulhouse. La surveillance de la consommation par les intervenants de l’IUT sera aussi plus efficace et rapide grâce à la carte interactive. Cette carte devrait être mise sur grand écran au sein même de l’IUT afin que le public puisse y accéder à tous moment grâce au compte utilisateur. La justesse des données pourrait être améliorée si l’on découvre d’où vient la légère différence entre les capteurs UHA et Distrame. Notre projet a également permis la surveillance de la température de la cave A afin que la bière du projet micro-brasserie automatisée soit toujours à bonne température. Il permettrait également la surveillance de la production énergétique du projet Centrale d’autoconsommation solaire.


Annexes

Septembre

Relevé du capteur de consommation Distrame du bâtiment A
Relevé du capteur de consommation UHA du bâtiment A

Octobre

 

Novembre

 

 

 


Micro-Brasserie solaire automatisée

Sommaire:

Remerciement

Introduction

  1. La passionnante histoire de la bière
    1. Chronologie de la bière
    2. Fabrication
  2. Réalisation des bières de GEII
    1. Première bière: apprentissage de brassage
    2. Deuxième Bière: consommation d’énergie
  3. Automatisation
    1. liste du matériel nécessaire
    2. Motorisation du moulin
    3. motorisation du malaxeur
    4. Asservissement de température
  4. Amélioration possible
  5. Conclusion

Remerciements:

Ce projet n’aurait pu être réalisé sans l’aide d’une multitude de personnes que nous tenons à remercier ici. Parmi elles :

– M. Ould-Abdeslam pour la proposition et le suivi complet de ce projet ainsi que pour les commandes de matériel,

– les techniciens de l’IUT qui nous ont permis d’automatiser le moulin à l’aide d’une simple pièce qui nous manquait,

– M. De Sabatta pour sa patience et ses nombreux conseils,

– M. Hiebel, du lycée Charles de Gaulle à PULVERSHEIM, section “chaudronnerie”, pour la tôle en inox qui nous manquait afin de réaliser notre malaxeur.

Nous tenons également à remercier M. Drouaz qui nous a apporté des conseils pour la fabrication de la bière et qui était présent à chacun de nos brassages ainsi que pour les stérilisations du matériel, ainsi que toutes les personnes qui se sont démenées pour nous trouver des bouteilles de bières refermables ou qui peuvent être encapsulées.

Pour finir, nous remercions l’IUT qui nous a donné le financement pour aboutir et surtout commencer ce magnifique projet.  

Introduction:

Nous sommes deux étudiantes de deuxième année en GEII: Toussaint Raphaëlle et Dusausay Laura.

Dans le cadre de notre scolarité, nous avons choisi, dans notre projet, de créer une microbrasserie, dont l’automatisation exploite l’énergie solaire.

Mais dans un premier temps, laissez-nous vous faire découvrir cet art ancestral à travers son histoire, sa fabrication ainsi que son automatisation.

1.La passionnante histoire de la bière :

    1. Chronologie de la bière

Le principe de la bière est de réaliser une fermentation de céréales. La première a vu le jour à Jericho (à côté de Jérusalem)  en 12 000 avant J.C.

Celui-ci s’est développé partout dans le monde en faisant évoluer sa recette de siècle en siècle.

En 4 000 av JC, en Egypte, la bière était une boisson divine. Plus tard elle gagnera l’Europe en devenant une boisson remplie de vertus médicinales. En 1435 ce sont les prêtres qui ont l’exclusivité de la fabrication de ce breuvage. Puis durant l’ère industrielle Pasteur va faire la découverte de la levure ce qui va révolutionner le mode de préparation. Finalement ce n’est qu’en 1950 que la bière va commencer à être industrialisée.

    1.2 Fabrication

1.2.1 Matières premières

Eau Il faut 6L à 8L pour 1L de bière
malt Orge germé et caramélisé, froment, ou seigle
houblon Pour l’amertume, l’arôme, aseptisation, digestibilité
levure Pour la fermentation alcoolique

Tab 1: Les matières premières de la bière

1.2.2 Les 5 grandes étapes

maltage Le malt crée les enzymes nécessaires à la  création d’alcool lors de la fermentation (déjà fait lors de la commande du malt)
Le brassage On hydrate et chauffe le malt permettant l’activation des enzymes ainsi que l’obtention des sucres
cuisson du moût On filtre la fermentation. Le liquide qui en ressort est chauffé à plusieurs températures avec du houblon et d’autres épices. Cette étape permet de donner du goût à la bière
fermentation Cela désigne la réaction chimique qui transforme le sucre en alcool. L’ajout de levure permet de gérer ce procédé.Celui-ci est fait en 2 temps de repos avec des températures différentes.
la garde Procédé de la gazéification

  Tab 2: Explication des procédés de fabrication

2.Réalisation des bières de GEII

    2.1 Première Bière: apprentissage de brassage

Pour notre projet nous avons commandé une microbrasserie afin de l’automatiser. Mais avant toute chose il fallait que l’on se familiarise avec les différents procédés pour connaître les étapes essentielles à automatiser.

Nous voilà donc parties dans la création de notre Première bière.

2.1.1 Matériel et matières premières

Pour 20L de bière:

Kit Brewferm; Une balance; Un minuteur; Récipient pour le malt concassé; Rallonge électrique; Cotons tiges pour stériliser le robinet des cuves

4,4 kg de malt du kit Brewferm; Houblon du kit Brewferm; Eau (suffisamment pour les différentes phases de cuisson et le refroidissement); Sucre Candy du kit Brewferm; Levure du kit Brewferm

2.1.2 Recette de fabrication

Pour commencer, moudre le malt à l’aide du moulin.

Faire chauffer 20 L d’eau jusqu’à atteindre 52°C. Puis ajouter le malt. Après 15 minutes de cuisson, augmenter la température à 62°C puis attendre 45 minutes. Augmenter la température jusqu’à 72°C puis laisser cuire 15 minutes. Enfin, augmenter la température jusqu’à 78°C et attendre 5 minutes. La phase d’empâtage est terminée, on peut passer à la filtration.

Mettre le contenu de la cuve dans une cuve de filtration puis récupérer le liquide sortant du robinet qu’on remet à nouveau dans la cuve de filtration jusqu’à ce que le liquide devienne plus clair.

Vider le contenu de la cuve par le robinet dans la cuve chauffante jusqu’à atteindre 24 L. Pour cela, ajouter de l’eau à la température de 75°C dans la cuve de filtration et patienter. Une fois la valeur de 24L atteinte, faire chauffer jusqu’à atteindre l’ébullition. Une fois le mélange porté à ébullition mettre la chaussette contenant le houblon et patienter pendant 80 minutes.

Commencer à stériliser le refroidisseur, la cuillère ainsi que la cuve de fermentation.

ATTENTION : une fois stérilisé, il ne faut plus mettre ce matériel en contact avec autre chose que la future bière.

A la fin des 80 minutes de cuisson, enlever la chaussette et passer à la phase de refroidissement.

Brancher un tuyau entre le robinet de la cuve chauffante et le refroidisseur, un tuyau entre le refroidisseur et la cuve de fermentation, brancher un tuyau entre le refroidisseur et le robinet d’eau froide et le dernier tuyau entre le refroidisseur et l’évier dans lequel ressortira l’eau qui sera chaude. Activer l’eau froide avec un gros flux puis ouvrir le robinet de la cuve chauffante pour libérer la bière. Attendre que le processus soit terminé.

Pour terminer, ajouter la levure dans de l’eau suivant les indications de la levure. Ajouter cette levure dans la bière et mélanger sans faire de bulle.

Enfin fermer la cuve de fermentation et ajouter le barboteur, dans celui-ci, mettre un peu d’eau.

ATTENTION : l’eau ne doit pas entrer en contact avec la bière.

Mettre la cuve de fermentation dans une salle à 20°C pendant 2 semainesAprès 2 semaines de fermentation, mettre la cuve dans une salle/cave à 15°C pendant 2 semaines.

Stériliser les bouteilles qui vont contenir la bière 48h avant la mise en bouteille à l’aide de chemipro dilué dans de l’eau. Le jour de la mise en bouteille, faire fondre avec de l’eau 7g/L de sucre puis l’ajouter dans la cuve de fermentation (après avoir stérilisé la cuillère).

Stériliser le robinet de la cuve de fermentation. Mettre les bouteilles stérilisées 10 minutes dans de l’eau bouillante puis mettre la bière dans les bouteilles. Stériliser les capsules et capsuler les bouteilles.

Laisser la bière minimum 2 semaines en bouteilles à température ambiante avant dégustation.

 

2.2 Deuxième Bière : consommation d’énergie

Début juin 2018 l’IUT de Mulhouse a investi dans 2 panneaux solaires. Ils peuvent produire jusqu’à 2,2 kWh.

Fonctionnement d’un panneau solaire:

Un panneau solaire est constitué de cellules dites photovoltaïque. Une cellule est constituée de 2 couches de silicium dopées respectivement P et N. Initialement, cette jonction PN est électriquement neutre. Un photon d’énergie suffisante va créer un trou par arrachement d’un l’électron. Par l’agitation des électrons voisins, ce trou va être comblé en piégeant un électron. À l’échelle de la cellule, le comportement est équivalent à une force électromotrice. Si la jonction est insérée dans un circuit fermé, un courant va circuler. Pour augmenter la puissance disponible, il faut placer plusieurs cellules pour former un panneau solaire. La tension est continue. L’énergie peut alors être stockée dans une batterie, qui joue le rôle de récepteur quand elle se charge, puis de générateur lorsqu’elle débite vers un utilisateur. Si l’utilisateur exploite une tension sinusoïdale, il faut alors intercaler un onduleur.

Lors de l’installation il faut veiller qu’aucun objet faisant de l’ombre soit à proximité du panneau. En effet contre toute attente, lorsqu’une cellule est ombragée, c’est la totalité du panneau qui cesse de produire.  Ainsi, à l’IUT, un arbre cache une partie du panneau et fait perdre 30% de la production.

Lors de la première bière nous n’avons pas pu mesurer la consommation d’énergie dont nous avons besoin lors de la fabrication. C’est lors de la fabrication d’une seconde bière, dont la recette est en annexes 2 et 3, que nous avons mesuré la consommation d’énergie nécessaire. Toute les données de production des panneaux solaire de l’IUT sont envoyées sur la plateforme.

Ainsi nous avons pu voir notre consommation d’énergie.

Lors de la fabrication de cette bière, nous avons mesuré la consommation électrique de tout le processus en utilisant les batteries (stock maximal de 4,8 kWh). Ces batteries conservent l’énergie récupérée grâce au panneau solaire installé à l’extérieur du bâtiment. Nous nous baserons sur la consommation des batteries pour ultérieurement faire une analyse de la consommation d’énergie totale d’un brassage.

Au début du processus les batteries étaient chargées à 89% de la charge maximale. On a fait chauffer de l’eau jusqu’à 80°C avant de la laisser refroidir à 67°C. Une fois à 80°C les batteries étaient à 72% de leur charge maximale. Juste avant la phase de filtration les batteries étaient à 68%. Puis on fait chauffer de l’eau de rinçage, une fois l’eau à 78°C les batteries étaient à 60%. Puis on porte l’eau à ébullition. Au début des 80 minutes de cuisson les batteries étaient à 43% puis à la fin de la cuisson elles étaient à 26%.

Remarque: Lors de cette journée les batteries ont pu se recharger légèrement.

Nous voyons sur la courbe de production des batteries ci-dessus, que de 10 h à 11 h 30 le panneau a produit une puissance jusqu’à 600 W et de 15 h 30 à 16 h la consommation était moindre (cf les encadrés noirs de la Fig 8)

Au bilan, pour faire tout le processus (sans compter la mise en bouteille) on a utilisé 89 % – 26 % = 63 % des batteries. Soit 0,63 x 4,8 kWh = 3 kWh. En toute rigueur, on a remarqué que lors de cette journée, les batteries ont pu se recharger légèrement, ce qui signifie que l’énergie réelle consommée est légèrement supérieure.

Cet essai a montré la faisabilité d’alimenter notre installation par le réseau issu des panneaux solaire.

3. Automatisation :

3.1 Liste du matériel nécessaire :

pour le malaxeur et le moulin Pour le PID de la cuve
Une perceuse 900W/230V Une carte Raspberry Pi avec son écran tactile, son alimentation et une carte SD
Des boulot M6 et M8 en inox Un clavier, souris

Une tige filetée M6 en inox d’une longueure d’un mètre

Une tige filetée M8 en inox d’une longueure d’un mètre

Une LED de roue libre 1N4002
Un fer plat en inox une sonde PT100

Pour la sécurité:

Un transformateur 12V 500mA

Un relais de puissance 12V 300mA

Un relais 5V

Une multiprise et une prise terre

Une carte Arduino Uno avec son câble et une résistance 100 Ohm

3.2 Motorisation du moulin :

Lors de la fabrication de la deuxième bière, nous avons motorisé la rotation du moulin à malt. Pour cela les techniciens de l’IUT nous ont usiné une pièce s’adaptant directement au moulinet du moulin pour ainsi utiliser une perceuse. 

La motorisation du moulin est terminée.

3.3 Motorisation du malaxeur :

Nous avons décidé de créer une pièce totalement en inox pour mélanger la bière de façon autonome.

Le choix de l’inox n’est pas anodin: c’est le seul métal inoxydable, adapté à l’alimentaire, et sans influence sur la saveur de la bière.

De ce fait nous avons réalisé un carré avec un fer plat d’un mètre où nous avons inséré des tiges filetées.

De ce fait lors de la rotation fait par la perceuse le liquide dans la cuve est mélangé de façon homogène.

 

 

3.4 Asservissement de la température :

Afin d’asservir la température, nous avons utilisé une sonde PT100, une carte Arduino Uno, une carte Raspberry Pi, un écran, un relais 5V, un relais 12V, un transformateur, une prise avec terre et la cuve chauffante Brewferm.

Le but est de commander la sonde PT100 à l’aide d’un Raspberry Pi afin que la température soit affichée sur un écran et qu’elle se régule seule suivant le programme de cuisson demandé. La sonde PT100 envoie un signal analogique et le Raspberry Pi ne reçoit que des signaux numériques, c’est pourquoi on ajoute une carte Arduino Uno qui fait office de convertisseur analogique/numérique. La carte Raspberry Pi sera donc reliée à un écran qui affichera le programme de cuisson et la température.

Elle sera aussi reliée à un relais 5V qui sera relié à un relais de puissance 12V. Les deux relais servent de protection à notre matériel. Ce relais de puissance sera relié d’un côté par la cuve chauffante Brewferm, et d’un autre côté par un transformateur qui sera branché au 230V de la prise secteur. 

Nous avons choisi la sonde PT100 grâce à ses caractéristiques :

– une précision d’un dixième de degré : largement suffisant pour notre application,

– gamme de température allant de 0 °C à 100 °C : adaptée à notre température de cuisson qui est de 90 °C,

– temps de réponse inférieure à 1 s : parfaitement cohérent avec notre projet. En effet, la montée en température de notre cuve est environ de 30 minutes pour une élévation de 20 °C. Le temps de réponse du capteur seul est donc négligeable.

3.4.1 Connectique Raspberry Pi → Cuve

 cuve relais de puissance relais 5V Raspy

Pour s’assurer de la sécurité de la cuve ainsi que de l’interface, nous utilisons des relais. 

On va utiliser une triplette avec un arrêt ON/OFF de plus de 3000W pour s’assurer qu’elle supporte les 2000W de la cuve, la perceuse du malaxeur ainsi que les relais. 

Par loi de Joule, 2kW, 230 V aboutit à un courant de 8,7 A. Ce qui nécessite un câble de section 1 mm2. Une fois le branchement réalisé nous pouvons passer à la programmation.

3.4.2 Programmation de la sonde:

Objectif : à travers une interface l’utilisateur choisira les 3 temps de cuisson et les températures associées ainsi que le temps de houblon. De cette façon l’utilisateur peut vaquer à ses occupations en recevant un email à chaque changement de cuisson, pour chaque houblon et fin de cuisson.

Nous avons donc commencé cette partie de l’automatisation par la programmation de la carte Raspberry Pi et de la carte Arduino Uno. La particularité de la sonde PT100, c’est qu’à 0 degrés Celsius celle-ci agit comme une résistance de 100 ohms. Celle-ci est reliée à la carte Arduino à l’aide d’un pont diviseur de tension avec une résistance 100 Ohm afin de faire la conversion analogique/numérique et de sortir une valeur de la température. (Fig 13) Cette valeur de température sera ensuite envoyée au Raspberry Pi. Le Raspberry Pi sera programmé pour recevoir les informations de la sonde dans un premier temps.

Pour l’arduino nous avons fait un programme nous permet de récupérer les valeurs de la sonde qui arrivent sur le port analogique de l’Arduino. Nous recevons les valeurs en millivolts que nous convertissons en degrés Celsius.

Pour ce faire, nous utilisons la fonction map qui permet de faire cette conversion. Pour calibrer la sonde, nous la mettons à 0°C et récupérons la valeur en millivolt. Nous ferons de même pour 100°C. Pour finir nous affichons le résultat en degrés sur la console. 

3.4.3 Programmation du contrôle de la cuve

Nous allons utiliser le  logiciel python pour programmer la cuve. Le principe de fonctionnement est le suivant :

  • Nous contrôlons constamment la température, si elle est trop froide on active le GPIO 12 (pin sur lequel est branché la cuve) donc on allume la cuve, sinon on le désactive pour l’éteindre.
  • Nous avons créé des paliers de température et de houblons
  • Nous utilisons des minuteurs pour savoir si le temps des paliers sont écoulés pour passer au suivant
  • Nous pilotons également 5 autres GPIO qui vont servir à envoyer des mails de suivi à l’utilisateur

Initialisation :

En début de programme toutes les variables, mettrons les GPIO sur FALSE (éteint), nous enregistrons les temps de cuisson et des houblons saisis

Chronomètre:

Nous utilisons le temps instantané sur lequel nous allons ajouter la durée saisie par l’utilisateur. 

Cependant l’utilisateur rentre dans l’interface une durée en minute uniquement, telle que 90 minutes. Ainsi, nous avons créé 2 fonctions permettant de transformer et d’ajouter la saisie des minutes de l’utilisateur, en heure et minute d’arrivée.

ex: il est 13h30, nous saisissons 70 min →  70 minutes c’est 1h et 10 minutes.–> la fonction renvoie heure prévu= 1h, Minute prévu=40

Régulation de la température:

Pour cela, nous avons créé une fonction qui va piloter le GPIO relié à la cuve pour l’activer ou non. Le principe est le suivant : si la température reçue par la sonde est inférieure à la température désirée, on allume la cuve sinon on l’éteint.

Architecture du programme:

Le programme est essentiellement constitué de “while” et de condition ”if”. Pour la première cuisson nous attendons que l’utilisateur lance le programme en appuyant sur le bouton de l’interface. Le programme est fait en deux parties : première cuisson et deuxième cuisson. A chaque fois nous devons attendre que l’utilisateur active la cuisson pour lancer l’algorithme. 

Dès lors, pour la première cuisson, nous allons créer des boucles qui vont s’exécuter tant que la cuisson avec ses paliers ne sont pas arrivées à termes.  A l’intérieur nous y plaçons la condition suivante :

Si la température relevé par la sonde est inférieure ou supérieure à 5°C de la température voulue pour le palier, nous la régulons comme nous avons vu précédemment.

Sinon nous lançons le chronomètre adéquat au palier. Et rentrons dans une boucle “tant que  l’heure instantanée est inférieure à l’heure de fin du chronomètre” , nous relevons la température de la sonde, nous ajustons en conséquence la température et nous relevons l’heure instantanée. Dès qu’on sort du “tant que” nous activons le GPIO adapté pour envoyer un mail puis nous le remettons en état OFF.

Cette condition va être répétée 3 fois soit le nombre de paliers maximum dans la première cuisson.

Lorsque les 3 paliers ont été exécutés, nous envoyons un mail de fin de première cuisson, sortons de tous les “tant que”, et coupons la cuve. 

Pour la deuxième cuisson le principe est similaire mais simplifié car la température reste constante à 90°C.

Ainsi nous allons faire une série de chronomètre avec comme consigne tant que le chronomètre précédent n’est pas écoulé on ne passe pas au suivant. Dès qu’un chronomètre est écoulé nous envoyons un mail, indiquant qu’il faut rajouter un houblon.

3.4.4 Programmation de NodeRed

L’application Node Red se fait en trois étapes distinctes, nous commençons par détecter un changement de front sur l’un des pins du Raspberry Pi (boite bleue). Ce changement de front nous indiquera à quel moment de la cuisson nous nous situons. Ensuite, suivant le pin détecté, on fait une fonction dans laquelle on affiche le message voulu (boite orange). Pour finir, ce message est envoyé par email afin de prévenir l’utilisateur du changement de température dans une cuisson ou alors pour prévenir qu’il faut mettre le houblon (boite verte).

3.4.5 Programmation de l’interface

Voici l’interface utilisée:

La programmation de l’interface se fait plutôt facilement. Il suffit de connaître les lignes de codes qui permettent de faire apparaître un bouton, une liste ou encore un texte et le tour est joué.

Voici des extraits de codes expliqués:

Nous avons choisi d’afficher l’heure  sur l’interface afin de nous éviter d’avoir une montre à côté de nous. Pour cela, nous avons créé une fonction qui permet de récupérer l’heure instantanée du Raspberry Pi. Puis on sélectionne l’endroit où l’on veut l’affiche à l’aide de la fonction “.grid”. On choisit la colonne et la ligne dans lesquelles on veut que l’heure s’affiche. 

Ensuite nous avons différentes zones de textes, ce sont les zones dans lesquelles on a déjà un texte comme “Palier 1”.  Pour cela, nous utilisons un “Label”, nous lui donnons un nom et le plaçons dans l’interface toujours à l’aide de la fonction “.grid”.

Nous avons également créé des “Spinbox” qui représentent les cases dans lesquelles nous choisissons une valeur. Nous décidons de pouvoir avoir des valeurs entre 0 et 150 “from_=0, to=150”, sauf pour la température que nous décidons d’avoir comme minimum 30 (from_=30, to=150). Les trois quarts du programme sont constitués de ces quatre lignes. 

Pour terminer, nous avons ajouté deux boutons : un qui lancera le chronomètre de la première cuisson, et un qui lancera le chronomètre de la deuxième cuisson.

On utilise donc la fonction “Button” dans laquelle nous entrons un texte, qui figurera sur le bouton, ainsi qu’une commande à lancer et sa position dans l’interface. Cette commande se trouve dans le programme qui contrôle la cuve. Ainsi, lors de l’appui sur le bouton de l’interface, le chronomètre ainsi que les fonctions de chauffe se mettent en route grâce à la liaison entre les deux programmes.

Le petit plus de notre interface est d’avoir une barre de menu dans lequel nous avons un seul menu, “Fichier”.

Dans ce menu “Fichier” nous avons créé un sous-menu “Bière blonde” et un sous-menu “Bière Ambrée”. En cliquant sur ces sous-menus, la recette de la bière s’affiche dans la console grâce à la fonction “command=”. Les fonctions “Recette_biere_blonde” et “Recette_biere_ambree” nous permettent tout simplement d’écrire dans la console le texte voulu qui est entre guillemets. Nous avons également ajouté un sous-menu “Quitter” qui permet de fermer l’interface.

4.Améliorations possibles :

 

Pour améliorer ce projet nous pouvons y apporter certaines modifications au niveau de la programmation, du malaxeur ou encore de la sonde.

4.1 La programmation:

Faute de temps, nous n’avons pas pu rassembler les programmes de l’interface et du programme principal. Pour les rassembler il y a 2 solutions. La première c’est de les rassembler tout en gardant 2 programmes différents, un pour le programme principal et un pour le programme de l’interface. La deuxième solution est de mettre les 2 programmes dans un seul et même programme qui lancera tout en même temps, cependant cette solution donnera un programme très long et assez complexe.

4.2 Le malaxeur:

Le malaxeur est prêt mais il n’est pas en place. Pour cela, il faudrait faire un trou dans le couvercle de la cuve afin d’y faire passer la tige filetée qui se logera dans le mandrin de la perceuse. Mais pour tenir la perceuse il faudrait aussi pouvoir

 

4.3 La sonde:

La sonde est programmée mais pour l’instant elle est juste posée dans la cuve. Pour la fixer, il faudrait faire un trou dans le couvercle de la cuve afin d’y faire passer la sonde, mais attention, il faudrait trouver une solution afin qu’elle ne soit pas emportée par le remous du malaxeur.

5. Conclusion

Ce projet fut très enrichissant que ce soit d‘un point de vue technique  que d’un point de vue humain. En effet à travers ce projet nous avons pu rencontrer plusieurs personnes qui nous ont soutenu et partagé leurs savoirs.

Sur le côté technique, l’automatisation de la micro brasserie fut très complet. Nous avons vu la programmation sur 3 supports différents (Raspberry Pi, Node Red, Arduino). Pour la mécanique nous avons pensé, découpé, plié, assemblé différentes pièces. Côté électronique, nous nous sommes occupées des commandes et de l’assemblage des éléments.

La partie énergie nous a sensibilisé au fonctionnement et à la lecture des graphiques fournis par le panneau solaire.

Finalement, ce projet est bien plus qu’un simple projet brassage. C’est un assemblage de savoir faire que nous avons mené à bien grâce à nos connaissances et au partage des savoir-faire. Pour le mener à terme, nous n’avons pas hésité à prendre de notre temps personnel.

Malgré les difficultés rencontrées nous avons réussi à obtenir un système qui fonctionne convenablement.