Thermostat d'ambiance : progression et évolution...

Mise en situation : il y a un an je découvrais les nouvelles versions des 'petits' processeurs Atmel, et plus particulièrement l'ATmega168pb grâce à un kit de développement à très bas coût, le kit ATmega168 X PLAINED. Ces petits processeurs me semblaient assez puissants pour tenter de développer un thermostat d'ambiance un peu plus convivial que ceux que l'on rencontre partout de façon standard. Je ne parlerai pas ici des objets de ce type dont l'objectif n'est certainement pas de répondre de façon simple à un besoin simple :

J'ai déjà eu l'occasion de 'disserter' sur le sujet dans un billet précédent. Or donc, après avoir décidé la mise en chantier d'un thermostat personnel, vint la réalisation et les premiers tests en juillet 2015 :

En compagnie d'une précédente réalisation pour comparaison.

J'ai continué quelque peu à développer ce prototype, mais au fur et à mesure de son développement, je me rendais compte que mes choix technologiques n'étaient pas les bons, et ce, sur deux points.

- D'un point de vue ergonomique tout d'abord, l'utilisation de boutons physiques, même si elle peut présenter certains avantages, ne permet pas une ergonomie 'soignée' en cas d'utilisation de plusieurs affichages différents.

- D'un point de vue technique, même si le processeur utilisé est assez puissant pour gérer l'affichage graphique, la taille de cet afficheur s'est avérée bien trop petite pour y afficher les informations de façon claire. La multiplicité des objets graphiques à gérer complexifient très fortement le code processeur, générant une application complexe et lourde.

J'ai donc cherché une autre solution d'affichage susceptible de servir aussi de surface de contrôle. J'ai déjà eu l'occasion de tester un tel afficheur lors de la mise en pratique d'une solution d'automatisme :

Ce système fonctionne très bien mais l'afficheur ne peut être utilisé vraiment correctement que dans l'environnement technique de cet automate, aidé du logiciel de développement fourni avec la solution.

Je me suis donc mis en quête de quelque chose qui ressemblerait physiquement à ce petit afficheur, mais un peu plus grand quand même, disposant aussi d'une interface tactile et d'un logiciel de développement.

Il y a pléthore de solutions de ce type, mais il me fût assez difficile de trouver une offre fiable, bien intégrée et fonctionnelle, pas 'trop' propriétaire et pas trop complexe à mettre en œuvre.

Et j'ai fini par trouver un système qui me semble assez pertinent. En une petit image, voici ce qu'il est possible de réaliser assez facilement avec l'outil de développement proposé avec l'afficheur :

Et en plus, le rendu est plus agréable que sur le prototype d'origine.

Les affichages ne sont pas pertinents puisque configurés par défaut dans l'outil de création graphique. Tous les objets présents ont néanmoins diverses caractéristiques modifiables directement par des instructions envoyées sur le port série de l'afficheur, comme les valeurs chiffrées, les textes etc etc...

Les premiers tests de modification dynamique de l'afficheur à l'aide d'un émulateur de terminal sur PC ont montré l'efficacité du système. Pour avancer sur le sujet, je compte me servir de mon premier prototype de thermostat pour envoyer les informations des capteurs sur ce nouvel afficheur.

13 janvier 2016. J'ai connecté cet afficheur à ma carte de développement à base de processeur Z8F Zilog. J'apprécie bien ce type de processeur assez rapide, fourni en périphériques et faciles à programmer et à 'debugger' avec le logiciel de développement fourni gratuitement. Voici le montage de base :

Avec un circuit d'interface 3,3V vers 5V.

J'ai donc écrit quelques lignes de 'C' pour envoyer par l'intermédiaire de ce processeur, les données sur la liaison série nécessaires à la configuration des indicateurs et de certains textes, ainsi qu'à l'apparition de certaines icônes à l'écran. Notez bien qu'il s'agit d'une démo. me permettant de valider le principe. Il n'y a aucune pertinence des informations affichées...

11 février 2016 : J'ai aussi connecté cet afficheur à un nouveau type d'automate que je me suis procuré. La particularité de ce PLC est d'être Open-Source de type Arduino, donc de programmation très aisée en C standard grâce à l'IDE Arduino. En un rien de temps, j'ai pu retranscrire le programme 'C' écrit pour le micro-contrôleur Z8F sur ce petit automate et constater le fonctionnement parfait de cet afficheur ainsi piloté :

L'afficheur est relié directement en 'TTL' sur les broches adéquates de l'automate.

15 janvier 2016 : Petite digression... A l'origine, j'avais développé mon premier prototype de thermostat sur une base de processeur 8 bits d'Atmel. Comme c'était mon premier 'vrai' emploi de ce type de processeur, je n'avais pas remarqué que la fréquence maximale de ces circuit était limitée à 8Mhz en cas d'utilisation de l'oscillateur interne.

Force fût alors de constater que la gestion de l'afficheur était lente, empêchant tout affichage dynamique de grande envergure. Même en doublant la fréquence de fonctionnement du processeur, il n'était pas certain que cela aurait grandement arrangé la situation. A considérer donc avec la complexité du code devant gérer totalement l'affichage. Raison pour laquelle je me suis engagé sur une autre voie.

Je viens de tester la nouvelle version de l'interpréteur basic du MAXIMITE, la V5. L'intérêt de cette nouvelle version est de proposer nativement l'utilisation et la gestion du même type d'afficheur que celui utilisé sur mon prototype de thermostat.

Un processeur 32 bits à 40Mhz, même s'il tourne sous Basic offre quand même d'autres performances :

Carte de développement personnelle.

Je pense poster un petit billet sur ce sujet prochainement.

 
A suivre...

Thermostat d'ambiance : ATmega168pb devient ATmega328...

Hum, quel lien entre la version 168 et 328 de l'ATmega et un thermostat?

Rappel des épisodes précédents :

• Tout commença par l'utilisation d'un kit de découverte de l'ATmega168pb vendu quelques Euros.
• Puis, vint l'idée de réaliser quelque chose de sympa avec cette petite bête. Pourquoi pas un petit thermostat?
• Les bases de l'application jetées il était temps de passer à la réalisation d'un premier prototype.
• Puis celui de son montage avec le relevé de quelques erreurs de conceptions sans conséquences pour un prototype.
• Le sujet de ce billet? Les premiers signes de vie de l'objet...

Restons modestes, pas question ici de concurrencer ce type d'appareils fabriqués par exemple par Momit. 

Publicité gratuite ;-)

Ici, pas de wifi, pas de réglage avec sa tablette (quoi-que le système étant ouvert, tout reste possible), par contre, une commande par deux fils uniquement, vers un récepteur placé à proximité de la chaudière, donc simple d'installation. Une commande par boutons dédiés qui 'devrait' permettre une utilisation sans besoin de notice à proximité...

Comme je l'ai évoqué dans un des articles précédents, le processeur ATmega168 est très bien, sauf qu'il ne possède quand même pas énormément de mémoire programme. Je me suis rendu compte lors des différents tests avant prototype que la librairie graphique occupait une place assez importante, susceptible de me poser des problèmes par la suite. Je suis donc passé au processeur au dessus, le 328. La compatibilité entre ces différentes versions de processeur est telle qu'il m'a suffit d'en changer le type dans le logiciel Studio 6 puis de re-compiler mes tests originaux pour en valider le fonctionnement sur la carte prototype.

Par contre, pour développer sans la carte 168pb Xplained mini, il est nécessaire de disposer d'un programmateur matériel permettant de charger le programme dans le processeur.

En ce qui me concerne, je n'ai rien acheté de spécial. Je disposais déjà d'un petit programmateur "mySmartUSB light" de myAVR disponible au prix exorbitant de 15,95€TTC (hors frais de port).

Encore de la publicité gratuite!

Ce type d'appareil ne peut pas prétendre fournir les mêmes fonctionnalités que les programmateurs fabriqués par Atmel. En particulier il n'est pas possible d'effectuer de session de débogage. La compatibilité STK500 ne permet pas non plus de 'remonter' la tension de fonctionnement du processeur. 

Ces petits inconvénients ne gênent 'pratiquement' pas le développement. En effet, la plupart des routines potentiellement gênantes ont déjà été programmée et déboguées avec la carte de découverte Atmel, notamment la gestion du bus I2C. Concernant l'absence de remontée de la tension du processeur, l'annulation du message fourni par la partie logicielle permet de continuer normalement l'upload du fichier exécutable dans le processeur.

Tout au plus le développement global est un peu moins pratique qu'avec un vrai débogueur matériel mais cela n'empêche absolument pas d'avancer, et d'autres moyens existent pour 'fliquer' ce qui se passe dans un programme....

Concernant les 'aides' matérielles dont il est 'relativement facile' de disposer pour mettre au point les parties logicielles, et notamment ce qui concerne le bus I2C, j'ai utilisé 'un oscilloscope de marque Rigol DS2072 disposant de la gestion du décodage I2C pour les tests préliminaires. Appareil pas très cher à l'achat et apte à rendre de bons services : 

Oui, je sais, encore de la publicité gratuite!

Il m'a permi non seulement de valider l'exactitude des informations envoyées et reçues, mais aussi l'état des signaux. Par la suite, j'ai utilisé un analyseur logique 'Logic Cube' de Zeroplus, lui aussi disponible à un prix 'amateur' qui, bien que ne travaillant que sur des signaux logiques, et donc incapable de visualiser la vraie forme des signaux, permet cependant de décoder un nombre sensiblement plus important de protocoles : 

Et ça recommence, je vais finir par demander des indemnités....

Cet appareil permet un affichage très pratique des échanges véhiculés sur le bus I2C. 

En voici un exemple : 

Conversation avec le capteur de température/hygrométrie avec un octet de trop demandé, pour voir...

En voilà terminé avec la partie matérielle qui m'a permis d'effectuer mes différents tests.

Concernant la partie logicielle, je dois citer le travail fourni par Adafruit Industrie concernant le portage de la bibliothèque graphique sur le circuit utilisé par le petit afficheur graphique. Il ne m'a fallu que quelques adaptations d'écriture pour coller au mieux avec la structure employée dans le développement de l'application générale.

Tout ceci pour un premier résultat des plus encourageant : 

En compagnie d'une précédente réalisation pour comparaison.

Deux remarques : 

• Sur le montage de droite, il a été utilisé des composants de grande précision. Les différences de valeurs mesurées sont uniquement dues au fait que le capteur du thermostat ne se situe pas au même endroit que sur le montage de droite.
• Le capteur utilisé sur le thermostat est de marque Honeywell et de type HIH6000. La particularité de ce capteur est une grande réactivité, notamment en ce qui concerne l'hygrométrie. Il s'avère bien plus réactif que le circuit de type SHT11 de Sensirion, pour une précision qui me semble assez identique et un prix bien moindre.

Il reste encore du travail de programmation à effectuer, notamment l'intégration du capteur de CO², la communication série et enfin l'application générale de contrôle...