D'abord quelques photos pour présenter le système.
Je travaille dessus depuis six mois, entre l'attente des écrans, apprendre plein de choses, résoudre les problèmes, faire le modèle 3D du boîtier et l'imprimer... Alors je vais prendre mon temps aussi pour décrire le fonctionnement...
Et bientôt une petite vidéo... C'est mieux en dynamique !
Comme vous voyez, le système est constitué de 2 écrans e-paper et d'un boîtier imprimé en 3D. Mais il y a plein de choses dedans :
et une connexion Wi-Fi. En fait 3 réseaux sont déclarés, le système les teste un par un jusqu'à réussir à se connecter. On peut en ajouter ou en ôter, c'est codé en dur dans le code.
L'idée c'est d'afficher diverses informations sur les deux écrans selon l'orientation du boîtier. Le boîtier est en forme de boîte parallélépipédique, un pavé quoi, avec une sorte de ceinture qui tient lieu de pied. Je posterai une vue 3D du boîtier bientôt.
L'accéléromètre détecte les mouvements et l'orientation et déclenche les affichages.
Pour économiser l'énergie, j'ai choisi les écrans e-paper (voir les références plus bas) qui conservent l'affichage même s'ils ne sont plus alimentés. De même pour l'ESP32, j'ai choisi le module Lolin32 (réputé pour sa frugalité) et j'ai dû apprendre la gestion du deep sleep,et le réveil sur interruption générée par l'accéléromètre.
Les écrans sont en SPI, j'ai ramé pas mal avant de trouver les bonnes pins pour les brancher sur l'ESP32, sachant que j'ai aussi besoin d'un I2C pour l'accéléromètre, d'une broche pour lire le DHT22 et de 2 autres pour la mesure de tension batterie. L'ESP32 est presque chargé à fond ! Sachant que certaines broches sont en lecture seule (utilisées pour le DHT), d'autres ne peuvent pas être utilisées avec le Wifi, ça a été un peu compliqué de trouver la bonne configuration.
La boîte peut être orientée dans 4 directions, plus posée à plat. En tout ça fait 4*2+2 = 10 types d'information possibles à afficher. Ça permet donc de faire pas mal de choses :
Ça fait pas mal de choses à aller chercher sur internet, et comme le dit al1fch : le WiFi c'est l'ennemi de l'économie d'énergie...
Donc il a fallu gérer la connexion, afin d'afficher des infos à jour mais sans passer trop de temps à se connecter. Un autre problème un peu complexe : conserver une heure assez précise.
Je n'ai pas besoin de RTC puisque je peux trouver l'heure sur internet, mais l'horloge interne de l' ESP32 dérive pas mal surtout pendant les périodes de sommeil. Il a fallu trouver un moyen de rester assez précis, en attendant de remettre l'horloge à l'heure par internet. Je le resynchronise sur internet toutes les heures.
Donc il y a un compromis à trouver entre l'autonomie (la fréquence des connexions internet) et la précision des informations affichées.
Autre problème a régler : la mémoire. Lorsque l'ESP32 est en sommeil profond, la mémoire est perdue, à l'exception de ce qui est appelé RTC RAM. Cette mémoire fait 4Mo, dont seulement 2 sont accessibles pour le programme. Dans cette mémoire, je dois stocker les diverses variables du programme qui doivent être conservées d'une exécution à l'autre, après une phase de sommeil : les prévisions météo, l'heure et la date, les noms des fichiers des icônes, les citations, etc. Il a fallu apprendre à gérer ça.
Parlant d'icônes, elles sont stockées dans la SPIFFS, le système de fichiers de l'ESP32. Suite à la fermeture de l'API météo gratuite de Wunderground, j'ai du chercher d'autres fournisseurs gratuits de données météo. J'en ai sélectionné deux, un pour la météo du jour, avec des prévisions à 12 heures, et un autre pour les prévisions à plusieurs jours. Les icônes n'étant pas les mêmes, ça m'a posé deux nouveaux problèmes.
Cette correspondance à été stockée aussi dans la RTC RAM afin de ne pas avoir à la recharger chaque fois.
Dernier problème avec les icônes. Impossible de toutes les stocker dans la SPIFFS. L'espace est trop petit pour tous mes fichiers. Il a fallu faire de la compression d'image. J'ai écrit un script en python qui lit mes fichiers d'icônes et les comprime en RLE, pour ensuite stocker les fichiers comprimés dans la SPIFFS. Là ça tenait.
Mais la bibliothèque d'affichage e-paper ne prend que des fichiers genre BMP, pas les images compressées. J'ai donc dû écrire une fonction supplémentaire pour pouvoir afficher mes icônes à partir de ces fichiers compressés.
Les données lues sur internet sont souvent au format json : données météo, Saint du jour. J'utilise la bibliothèque arduinoJson pour cela. Mais les citations ne sont pas comme ça. Je vais les chercher sur un site dédié, et il faut les lire en cherchant directement dans le contenu de la page Web. Il a fallu écrire un code spécifique pour ça. Chaque jour, vers minuit, le programme va sur ce site et lit une dizaine de citations prises au hasard, et les stocke dans la RTC RAM. On en affiche une au hasard parmi elles lorsque le boîtier est orienté grand écran vers le haut.
Je vous passe le problème de l'affichage des caractères accentués...
Lorsque c'est le petit écran qui est vers le haut, on affiche la tension de la batterie, avec un dessin pour mieux voir le niveau restant. Il a fallu faire un montage électronique pour lire la tension batterie. La mesure ne devant pas décharger la batterie, j'ai utilisé un schéma trouvé sur internet, qui utilise un transistor MOSFET comme interrupteur afin de ne consommer de courant que lorsque la mesure est faite.
C'est pour pouvoir faire ce circuit et tout rentrer dans le boîtier, que je voulais le plus petit possible, que j'ai donc dû faire un PCB pour connecter l'ensemble des composants du système. C'est mon premier PCB, formé avec une plaque à trous. J'ai eu de la chance car tout a bien fonctionné du premier coup de ce côté là...
Prévision d'implantation des composants sur le PCB : ça rentre tout juste...
Dernier point : les polices de caractères. De différentes tailles, bold ou pas, il a fallu les créer et les stocker. La bibliothèque Adafruit GFX s'occupe de ça très bien, une fois qu'on a installé les fichiers des polices dans le bon répertoire. Pour créer les fichiers, j'ai utilisé le site Font Converter, très pratique !
Donc pour résumer : gros projet, qui m'a permis d'apprendre beaucoup de choses.
Une de plus ..... mais pas comme les autres !!! beaucoup de créativité dans cette réalisation
en particulier l'utilisation délicate d'afficheurs ePaper, la compression des images.......
Merci !! 
La vidéo ici
On voit bien sur la vidéo l'inconvénient principal de ces écrans : la mise à jour de l'affichage prend une ou deux secondes et se fait par un clignotement (affichage alternatif des versions normales et inversées des deux écrans). C'est acceptable pour les infos de météo parce que je ne les mets pas à jour très souvent (toutes les heures sauf changement d'orientation du boitier). Mais pas pour l'heure. C'est d'ailleurs pour ça (et pour limiter la consommation) que j'en reste à l'affichage HH:MM (pas les secondes).
Il a donc fallu chercher une autre manière de mettre à jour l'affichage. Ces écrans (enfin certains) supportent une mise à jour partielle (appliquée soit à une zone de l'écran, soit à l'écran entier...) mais ce n'était pas bon pour moi car mon grand écran (qui affiche l'heure) conserve des fantômes des pixels remplacés. Par exemple, au passage de 10h12 à 10h13, le '2' est un peu visible dans le '3', et ça devient encore plus visible après le '4', le '5', etc.
Je précise que c'est le cas pour mon écran : j'en ai discuté avec l'auteur de la bibliothèque d'affichage e-paper GxEPD2 qui m'a dit qu'il n'observait pas ce phénomène avec ses écrans. On a cherché à modifier les paramètres sans réussir à chasser les fantômes.
Donc il a fallu trouver une autre solution : j'ai proposé de faire un double rafraîchissement partiel, ce qui a résolu le problème (en tout cas c'est satisfaisant pour moi). Le passage des heures se fait sans clignotement de l'écran et il n'y a pas de fantômes. Par contre, le passage n'est pas immédiat : il faut compter un peu plus d'une seconde pour le changement d'heure.
Bientôt : les fichiers (code et fichiers 3D du boitier), des explications techniques plus précises sur le fonctionnement...
Bonjour,
Jolie réalisation
Voici les vues 3D du boitier :
Et les fichiers FreeCAD et STL (pour impression 3D) sont attachés.
A suivre...
Boite ecrans.zip (1.28 MB)
Bonjour je voulais connaitre la reference de l'ecran e paper
Ce sont des écrans fournis par Good Display :
[2.9 pouces, 296X128 pixels](https://fr.aliexpress.com/item/8-epaper-display-panel-1024 x 768/32812931535.html?spm=a2g0s.9042311.0.0.27426c37Cc6d2W)
Ecrans SPI noir et blanc (les tricolores mettent encore plus de temps à afficher), achetés avec les adaptateurs
Bonjour,
belle réalisation !!
sur quel site allez-vous chercher le saint du jour et les citation (en JSON) ? J'aimerai les utiliser pour du Rasbperry par contre.
Merci
Merci
Le saint du jour : ici
Les citations, je réponds bientôt... avec le code
EDIT :
Le site est celui-ci
En PJ le code pour ESP32 qui analyse le site, fournit le nombre de citations, en choisit 20 au hasard (maxNbCitations), et enlève les accents (pour le cas où on veut les afficher sur un écran). Il trouve les citations en cherchant les balises et les noms d'auteurs en cherchant "right">"
Citations_v3.ino (5.33 KB)
Un peu plus haut tu indiques que l'auteur de la librairie GxEPD2 n'a pas rencontré les même défauts que toi pour le raffraîchissement. Utilise e-t-il les mêmes références d'afficheurs GoodDisplay que toi ou d'autres afficheurs ?
Dans ce dernier cas connais tu les références supportées par cette librairie et présentant un meilleur raffraichissement ?
De mémoire, il utilise les mêmes références. Le petit c'est moi qui lui ai offert, le grand il en avait déjà un...
Bonjour à tous,
Je suis sans voix mais je dis bravo pour cette belle réalisation.
hello le sept
j'étais passé à coté.
BRAVO pour cette réalisation
Merci... D'autres infos à venir...
Bonjour
Voici les codes, je ferai quelques messages pour expliquer certaines difficultés. L'archive data.zip contient le répertoire 'data' nécessaire à l'upload des fichiers (icônes, etc) dans la SPIFFS.
Meteo_ESP32_DeepSleep_epaper_LOLIN32.ino (1.47 KB)
Accelero.h (4.67 KB)
Bonus.h (7.44 KB)
Displays.h (16.1 KB)
Internet.h (3.17 KB)
Sleep.h (5.49 KB)
Variables.h (8.13 KB)
Weather.h (9.61 KB)
data.zip (58.1 KB)
Je profite de la recharge de la batterie pour prendre quelques photos de l'intérieur ;
Pour que rien ne bouge à l'intérieur lorsque l'orientation change, les différents composants (écrans, modules électroniques, PCB, batterie) sont collés au pistolet à colle. Pour faire passer les fils sous le PCB, j'ai installé ce dernier sur des pieds faits avec des entretoises, idem pour la batterie.
Bientôt j'installerai un connecteur micro USB externe pour ne pas avoir à ouvrir le boîtier pour recharger la batterie.
Peut-être que je m'intéresserai aussi à la mise à jour OTA pour parfaire le tout...
Bonjour,
lesept:
Voici les codes, je ferai quelques messages pour expliquer certaines difficultés. L'archive data.zip contient le répertoire 'data' nécessaire à l'upload des fichiers (icônes, etc) dans la SPIFFS.
J'ai juste survolé le fichier Met...N32.ino pour voir ton remarquable travail, et la question est :
Pourquoi le loop() est vide ?
Merci
La loop est vide parce le code n'y rentre jamais. C'est le principe du deep sleep : l'esp se réveille, exécute le setup, fait ce qu'il a à faire et part en sommeil ensuite.
Bonjour 6+1
Merci pour ta réponse.
Effectivement cela s'explique dans ce contexte. Je n'ai aucune expérience du mode mise en sommeil (qu'il soit profond ou non ;)) et il va falloir m'y intéressé un jour.
Pour l'instant, d'une manière général, je pense que c'est une perte de temps 
