Anthias
mail

nextion

Domotique Arduino

Nextion

Introduction
Cahier des charges
Déroulement du programme
Conception hardware
Consommations électriques
Principe de gestion de la base de données
Choix des 360 points par jour
Buffer tournant
Stockage de données
Données aberrantes
L’erreur de conception

Concept d'exploitation des données
Signal blackout
Inclusion hardware
Conclusion


Domotique Nextion nextion

Retour page principale Nextion arduino

Maj : 24/06/19

Abstract :
This page describe my data acquisition system wich record a lot of sensors and displaying curves on la 480*320 graphical lcd.
It is running perfectly since 6 years with an Arduino DUE.

Résumé :
Cette page décrit mon système d’acquisition de données qui enregistre de nombreux capteurs et affiche les courbes sur un écran LCD 480*320.
Il fonctionne parfaitement depuis 6 ans avec un Arduino DUE.

nextion  Introduction

Cette page décrit mon application de domotique qui a évolué au cours des années.
Tout a commencé dans la nuit des temps sur des cartes 6502, puis sur la famille 8051 et à l’avènement de l ‘Arduino, j’ai lâché les assembleurs pour une nouvelle aventure.
J’ai débuté alors avec les premiers UNO et un afficheur texte monochrome de 2 lignes * 24 caractères, puis 4 lignes * 20 caractères.
Ensuite à la sortie de la MEGA, passage sur des afficheurs graphiques couleur en 320*180 pixels.
Ensuite, à la sortie de la DUE, passage en 480*320.
C’est l’objet de cette page.

La dernière évolution impliquant le Nextion et un ESP32 est traitée dans cette autre page : Domotique Nextion nextion

ili

 Haut de page

nextion  Cahier des charges


Dans la version opérationnelle, la carte Arduino contient :
 Une horloge RTC (Real time clock) DS3231 fournissant le temps de référence avec une remarquable stabilité (quelques secondes par an si sa température reste assez stable autour de 20°).
Cette horloge fournit un top toutes les quatre minutes par interruption.
 Un capteur barométrique BMP280 fournissant la pression et la température (bien mieux que celle donnée par la DS3231).
 Divers capteurs de température répartis dans la maison par ses DS18b20 via un bus One-Wire.
 Un encodeur mécanique KY040
 Une commande de pilotage du chauffage central.
 Une EEPROM 512 kb (32 ko à comparer au 1ko ridicule du Nextion…).
 Un lecteur de micro SD pour archiver et exploiter l’historique.
 Un buzzer qui est capable de jouer la musique, mais qu'il n'est utilisé ici que pour émettre quelques bips, en particulier un très court toutes les 4 minutes un plus long toutes les heures (silencieux en mode blackout).

Ces interfaces fondamentales sont complétées à la demande par des capteurs sans fil (Wi-Fi, Bluetooth), afin de rajouter un détecteur de présence (pour mettre en sommeil quand il n’y a personne devant l’afficheur : blackout), un capteur d’ensoleillement, de pluie, de vent, les échanges par smartphone grâce à l’accès Internet.
Cinq potentiomètres (10 kOhms, 10 tours dans un boîtier), sont reliés à un convertisseur analogique-digital I2C et se branchent à la demande.
Les trois premiers servent pour les réglages RGB afin de déterminer une couleur exacte pendant le développement des menus, les deux autres sont affectés à la demande pour différents réglages dynamiques.

Ces compléments ne seront pas traités pour le moment afin de ne pas alourdir le propos, mais le système est très ouvert et accepte une vingtaine de capteurs simples à rajouter.

RTC

bmp280

ky040


Page d'introduction au boot :
Elle indique la date de compilation du firmware.
Les six leds de droite donnent de multiples indications pendant le déroulement du programme. Ces leds ne sont pas un gadget, elles sont en particulier très utiles pour le debug et montrent les états. Lorsque l'Arduino est en sommeil (personne devant l'écran) leur activité est extrêmement réduite à une brève impulsion d’une seule led au top minute.
Les deux leds du bas sont les recopies de RX et TX , les leds de la DUE étant masquées par le piggy back.

Le menu de base affichant les informations principales, après une attente de 10 secondes sur la page de boot.


L’encodeur rotatif KY040 (bouton gris) permet de naviguer dans les menus.

ili

Courbe barométrique indiquant le QNH (Atmospheric Pressure (Q) at Nautical Height), c’est-à-dire la pression ramenée à l’altitude zéro de référence (niveau de la mer).

La pression diminue rapidement avec l'altitude.


Le QNH se calcule simplement en multipliant la valeur absolue de la pression locale corrigée par ce coefficient lié à l’altitude :

float calcCoefAltitude (int Alt)
{
// Base : 1013.25 hPa, 0 m // 954.61, 500 = 1.0614 // 898.76, 1000 = 1.1274 // 845.58, 1500 = 1.1983
// 794.98, 2000 // 746.86, 2500 // 701.12, 3000 // 657.68, 3500 // 226.37, 11000
float P0 ;
P0 = (288.15-0.0065 * Alt) ;
P0 = 288.15 / P0;
P0 = pow (P0, 5.255) ; // 1.03484 pour 288 metres
return P0 ;
}
ili
L’Arduino étant alimenté autour de 12 Volts, un simple montage avec Zener 10 V et résistances permet de mesurer via une entrée de conversion analogique.
Un tableau de conversion sera utilisé après étalonnage sur une feuille Excel.

 

volt

Haut de page

nextion Déroulement du programme

Après la phase d’initialisation, le menu de base s’affiche et l’Arduino de met en consommation minimale.
La carte n’est réveillée très brièvement qu’une fois toutes les minutes pour faire les acquisitions et les moyennes.
Si la minute est multiple de quatre, enregistrement d’une série de données (positions tournantes sur quatre jours) dans l’EEPROM.
Le choix des quatre minutes est expliqué plus loin.
A minuit GMT, sauvegarde de la journée sur la carte SD.
Une commande série ou par l’encodeur KY040 réveille aussi le dispositif en demandant un changement de menus.

Haut de page

nextion Conception hardware

Le besoin de créer des cartes est lié au fait que l’afficheur parallèle est très envahissant, il vient s'enficher sur la DUE en bloquant tous les connecteurs pour brancher l'environnement.!
Ce nouveau concept comprend deux cartes reliées par une bretelle de câble plat pour dégager la DUE.

 La première carte « Shield » vient s'enficher sur l’Arduino DUE en récupérant tous ses points de contacts.
Elle comprend une dizaine de leds, tous les points de contacts sur pins à wrapper et les départs vers l’encodeur optique, le joystick et le Bluetooth.
(Avec l’expérience, les joysticks analogiques ayant une qualité très médiocre ont été définitivement oubliés…)
L’afficheur 480*320 s'enficheà son tour sur cette carte intermédiaire.
Une prise 2x10 permet de relier par câble plat la deuxième carte « Boîte de liaison ».

 La deuxième carte « BDL » (Boîte de liaison) à l’autre extrémité du câble plat est destinée à interfacer tous les capteurs domotiques et actionneurs. Elle fournit aussi l’alimentation 12V.
Ce concept permet l’acquisition de données centralisées et d’affichages vers divers systèmes, afficheur graphique 480*320, Android (par Bluetooth en cours), vers PC (graphiques en Processing).
Les fichiers Eagle et les sources Arduino sont disponibles sur simple demande.

 

shield
Schéma Eagle
carte shield
bdl
Schéma Eagle
boîte de liaison
cartes
Les circuits imprimés
réalisés

 J’utilisais au début des claviers matricés, assez pratiques mais très encombrants. J’ai tout basculé vers un nouveau concept,
l’encodeur mécanique KY040 en lui associant des menus hiérarchiques, la validation se faisant par appui central.
Cela ne s’est pas avéré très judicieux, car ces matériels à bas coût sont médiocres, les contacts rebondissent et le résultat est souvent trop incertain, même en divisant les impulsions par quatre.
Le Nextion et sa dalle tactile ont résolu tous les problèmes.

Haut de page

nextion  Consommations électriques

L’utilisation de l’afficheur graphique augmente beaucoup la consommation, car même en passant la DUE en sommeil, le rétro éclairage de l’afficheur est très énergivore, c’est pour cela que je l’éteinds dès que la pièce est vide (détection de présence par radar et infra-rouge).
Cette courbe donne les consommations en régime normal en fonction de la tension d’alimentation :

 

conso

Si le rétro-éclairage consomme beaucoup, a contrario les nouvelles leds CMS au format 1206 (pas de 0.1 pouce), qui équipent mes cartes, ont un rendement surprenant et sont mêmes visibles avec quelques dizaines de micro Ampères.
Suivant la couleur, ces leds ont des luminosités très différentes à résistance (et non courant identique). Il est difficile d’équilibrer les résistances pour obtenir des luminosités proches suivant les couleurs. Par défaut une seule résistance de 3.3 K sera installée au départ.
Une forte augmentation du courant n’amène qu’un gain réduit en luminosité !
Les leds jaunes et bleues sont les moins brillantes et peuvent demander plus de courant. Les vertes et blanches sont les plus brillantes (à R constant)

Il faut remarquer les tensions très variables des leds (de 0.7 à 1.5 V) et les courants extrêmement faibles pour des visibilités très correctes (de 0.2 à 0.5 mA avec 3.3k, le tiers avec 10k) !


Résultat des tests, alimentation à 3.3 V, résistance série de 3.3 kOhms puis 10 kOhms :

leds

Haut de page

nextion  Principe de gestion de la base de données

 En résumé :

Une EEPROM de 25c512 stocke les données sur 4 jours d’une dizaine de capteurs en 16 bits.
Chaque minuit les données des dernières 24 heures sont archivées dans une micro SD, pour pouvoir être traitées sur des années.

 Plus en détails :

Les formats des données enregistrées ont beaucoup évolué depuis des années et étaient liés au matériel. Au départ les données récentes étaient stockées sur la mémoire EEPROM liée à la DS3231 qui ne faisait d’origine que 2 koctets (25c16) ce qui laisse peu de place.
Le choix d’enregistrer 360 points par jour s’explique par l’afficheur principal utilisé pendant des années, le ili9481 en 420x320.
Cela a impliqué un intervalle d’acquisition de 4 minutes afin d’afficher une journée entière et exploiter au mieux les 420 points de l’axe X des temps.
En effet : 24 heures * 60 minutes / 4 minutes = 360 points d’abscisses, ce qui laissait 60 points de marge à gauche.
Avec le Nextion la résolution est passée en 800*480, ce qui a posé un nouveau problème !

Avec la résolution horizontale de 480 points, cela laisse la marge le 480-360 = 120 pixels, valeur juste parfaite pour afficher les étiquettes en ordonnées.

Haut de page

nextion  Choix des 360 points par jour

Le choix d’enregistrer 360 points par jour s’explique par l’afficheur principal utilisé pendant des années, le ili9481 en 420x320
Un intervalle de 4 minutes est optimal, en effet, (24h * 60 min)/4 = 360, ce qui laisse  60 points pour la marge de gauche, c’est jouable pour afficher dans cette marge les valeurs du capteur en cours sur 24 heures ou  2,4,8…, jours.
En pratique cette valeur est suffisante pour montrer les variations des capteurs habituels.
Le problème s’est posé quand je suis passé aux Nextion, que faire des 800*480 points offerts ?
J’ai testé diverses solutions pour les ordonnées (axe des X représentant le temps sur 24h) :
Passer à 2 minutes, soit 720 points laissant 80 pixels de marge gauche.
Passer à 3 minutes, soit 480 points, laissant trop de vide
Garder les 4 minutes en affichant un point tous les 2 pixels ce qui laisse 800-720=80 pixels pour la marge de gauche, solution la meilleure.

Il n’y a pas d’autre intervalle raisonnable avec cette résolution d’afficheur, et par chance ce délai convient bien pour tous les événements.
Les données sont mises en forme pour un stockage sur 2 octets soit +/- 32 k.
Chaque donnée occupe donc 360*2 = 720 octets pour un jour et au début avec 2k disponibles il a fallu faire des compactages acrobatiques.
Je remplace maintenant les EEPROMS de 2k par des 64 koctets (24c512 à moins de $0.5...) ce qui offre un espace très suffisant.
65536 / 720 = 91, soit par exemple 11 données pendant 8 jours, ou 22 données pendant 4 jours.
Une fois qu’un format a été choisi, il ne faut plus le changer si l’on veut récupérer les archives.
Chaque jour entier est sauvé dans la SD, il semblerait donc inutile de sauver plusieurs jours, mais l’affichage permet de montrer les dernières 24 heures, ou deux jours, ou quatre jours.
Il est plus rapide de faire les calculs d’interpolation directement dans l’EEPROM  plutôt qu’en chargements multiples depuis la  SD.
Pour des affichages sur de longues durées, il est indispensable évidemment de relire les données dans la SD.

C’est le format sur 4 jours d’une vingtaine de canaux de données qui a été choisi.
Il n’y a pas autant de capteurs en acquisition, mais tout cet espace disponible permet de sauver diverses autres données redondantes mais utiles en cas d’anomalies dans la base pour analyser les quelques valeurs aberrantes qui apparaissent aléatoirement.
Par exemple, les données sensibles sont mesurées plusieurs fois dans l’intervalle de 4 minutes et passent par un filtre à pondération temporelle pour enregistrer une valeur moyennée.
Le fait de sauver plusieurs valeurs brutes permet de débugger en cas de lecture erratique d’un capteur (phénomène inexplicable observé de temps en temps).
Pour beaucoup de capteurs, l’écart entre deux mesures à quatre minutes d’intervalle est faible (pression, température ambiante, humidité, etc..), il est donc simple d’éliminer une valeur aberrante, par exemple une température de la pièce qui est en moyenne de 20 degrés C, et passe à quelques centaines de degrés, en utilisant des filtres à fourchettes et écarts de la moyenne.
Pour la température de l’eau en sortie chaudière, c’est plus délicat, en quatre minutes, la température peut passer de 20 à 70 °C.

A titre anecdotique, certaines versions destinées à un affichage sur PC (Processing) qui dispose de quatre fois plus de résolution en abscisses enregistrent toutes les minutes.
La carte DUE est très rapide et passe la très grande majorité du temps à ne rien faire.
Pour sauver la planète en consommant le moins d’énergie possible, le principe du logiciel est de passer la carte en sommeil tout le temps.
Réduire les consommations au minimum est un exercice délicat de virtuosité, il semble que l’on arrive à faire toujours mieux !

La carte n’est réveillée très brièvement qu’une fois toutes les minutes pour faire les acquisitions et les moyennes.
Si la minute est multiple de quatre, enregistrement d’une série de données (Positions tournantes sur quatre jours) dans l’EEPROM.
A minuit GMT, sauvegarde de la journée sur la carte SD.
Une commande série, ou par l’encodeur, ou par le signal présence du  « blackout », réveille aussi le dispositif.

Variations sut le thème

Dans cet exemple je peux choisir n’importe quelle combinaison (dans la limite des 32k de mémoire), exemple, avec données sur 16 bits :
4 Jours / 10 capteurs / 4 minutes
1 Jour / 10 capteurs / 1 minute
10 Jours / 1 capteur / 1 minute…etc.
Et même des acquisitions chaque secondes pour les évolutions rapides.
Voici un bout du début du script qui configure cela :

#include "board_DUE_4.h"
//////////////// Basic adjustments /////////////////

//////////////////////// Master parameters /////////////////#FFFFCC

#define NB_DATAS_TO_SAVE 12 // Space for one record (2 bytes) max : 360 * 16 = 5760 bytes/day : 8 datas
#define INTERVAL_MIN 4 // Delay between records in minutes
// const uint16_t EEPROM_Size = 32768 ;

//////////////////////// Computed parameters /////////////////

const uint16_t RECORDS_BY_DAY = 24 * 60 / INTERVAL_MIN ; // option 4 min -> // 360 dans espace 480 > marges 120
const uint8_t NB_DAYS_TO_SAVE = EEPROM_Size / ( NB_DATAS_TO_SAVE * 2 * RECORDS_BY_DAY) ; // 32768 / 360 * 2 * 9 = 5
const uint16_t BANK_SIZE = RECORDS_BY_DAY * NB_DAYS_TO_SAVE * 2 ; // 360 * 5 * 2 = 3600

Haut de page

 

nextion  Buffer tournant : Quantième et index

Le quantième désigne le rang. Dans mes applications je l'utilise pour indiquer le numéro du jour dans l'année numéro allant de 1 à 365 ou 366. Cela me permet de créer un index des jours sur plusieurs années en résolvant le problème du saut entre le 31 décembre et le 1er janvier suivant que l’année est bissextile ou non.
Je prends une date de départ par exemple 1er janvier 2016 et à partir de ce moment-là je commence à compter les jours en tenant compte des années bissextiles ce qui me permet de faire toutes sortes de calculs par la suite pour revenir en arrière et afficher sur des périodes quelconques et connaître le jour correspondant à une date.

Problème au passage : 31 décembre > 1 janvier
Non bissextile : 365 > 1 %4 : 1 > 1
Bissextile : 366 > 1 %4 2 > 1 ?? Bug sans totaliser années

Pour éviter le trou mémoire, il faut passer 0 > 1 ou 1 > 2 ou 2 > 3

J'utilise par la suite cet index modulo 4 pour comme pointeur tournant dans ma base de données immédiate en EEPROM couvrant les 4 derniers jours.
En prenant un point de mesure toutes le 4 minutes, il y a donc 24h * 60 min/4 min = 360 points par jour soit 1440 points sur 4 jours.
Le pointeur est égal à : (Indexjour%4) * (heure TU *15) + (minute/4)
Sa valeur est donc entre 0 et 1339
Calculons l’espace mémoire disponible sur une E2Prom 24c512 de 32 k octets : 32768 / 1440 = 22.75

Nous allons donc pouvoir stocker 22 octets par jour, soit en codant chaque enregistrement sur 16 bits (2 octets), 11 canaux différents.
En pratique, on peut faire mieux, car chaque capteur n’a pas besoin d’un espace de 64k valeurs, et il est possible de compacter les données, mais restons au plus simple.
L’espace mémoire sera découpé en 11 blocs et sera organisée ainsi :
L’adresse de base est le pointeur de 1440 positions du jour %4, heure minute, (multiple de 4).
Une donnée est dans un canal parmi 11, noté 0 à 10
Chaque canal utilise 2 octets par enregistrement soit 1440*2 = 2880 octets
La position d’un enregistrement à un instant donné sera donc :
(Numéro du canal 0..10) * 2880) + (Pointeur temps 0…1439) * 2
Soit 2880*11 = 31680 octets sur 32768. Il reste 1 k de libre pour stocker divers paramètres.
Ce système est parfaitement stable, Les données des quatre jours précédents sont immédiatement disponibles en mémoire les données plus anciennes sont récupérées dans la micro SD qui sauve la journée à chaque minuit.

Haut de page

nextion  Stockage de données

Pour stocker les données des capteurs, il est impératif de me conserver que le format brut, en effet chaque capteur demande des paramètres propres d’étalonnage. Les matériels que nous achetons en Chine à faible au coût sont souvent du deuxième choix ou des contrefaçons et ne correspondent pas aux spécifications des datasheets du constructeur. Il faut donc faire une correction des valeurs lues en valeurs réelles.
Le plus simple est de faire une conversion au 1er degré de la forme :

Y = aX + b

Avec Y = valeur corrigée, X = valeur brute lue, a = coefficient multiplicateur (proche de 1), a = offset.
En ayant stocké les valeurs brutes, si par la suite si l'on s'aperçoit que les paramètres ne sont pas bien adaptés, on peut les modifier à la volée et récupérer l'ensemble des données sauvegardées avec les nouvelles valeurs.

 Capteurs de pression

Prenons l’exemple des lots de capteurs de pression type BMP280 achetés en Chine.
Pour tester, il suffit d’en grouper six dans le même environnement et d’enregistrer les valeurs brutes.
On prendra un capteur au hasard comme référence et ensuite on fera la différence des données reçu de tous les autres. On s'aperçoit alors que les écarts sont très importants et erratiques montrant la grande dispersion de qualité des matériels hors tolérance.
Dans le cas des barographes, ma référence est les enregistrements météorologiques pour ma ville de Météociel.
Je m'efforce de ramener les courbes au plus près de celle de Météociel en manipulant mes coefficients, mais dans ce cas particulier la fonction du premier degré n'est pas suffisante et il faut au moins passer au 2e degré de la forme y = AX + BX +C pour affiner et essayer de se coller aux valeurs extrêmes.
Il est très difficile de trouver des paramètres corrects pour un capteur et j’ajuste mes valeurs depuis des années pour tenter de m’accrocher à ma référence de QNH.

 Capteurs de température

Pour la température c'est plus simple un thermomètre à mercure de référence permettra des comparaisons afin de ramener les écarts autour de quelques dixièmes de degrés d'origine. Six capteurs de type de DS 18 B20 vont présenter des écarts dépassant largement le demi degré pour des températures de 5 à 25 °C.
Ici encore chaque capteur vie sa vie et les écarts par rapport à la référence partent dans tous les sens, mais je me contente d’une correction au premier degré car la mesure la température est particulièrement délicate et dépend beaucoup de la position du capteur, ce n'est qu'une simple indication.

 Mesure de tension

Le principe est ici un peu différent. En utilisant une Zener de 10 volts et des résistances si l'on veut par exemple mesurer une tension autour des 12 Volts, la courbe obtenue ne sera pas linéaire, il faudra passer par une feuille Excel pour faire une approximation par segments successifs.
Ce qui simplifie beaucoup les opérations est qu'il est extrêmement simple d'avoir des tensions de référence parfaites et de comparer aux valeurs lues, à la différence des précédentes pression ou température dont il est beaucoup plus difficile pour obtenir une référence fiable.

 Originaux ou chinois ?

À ce sujet il faudra se poser une question : Faut-il continuer à acheter des composants chinois à coûts dérisoires mais souvent très médiocres ou de rebuts ?
Vous préférerez pour vos applications critiques passer par un distributeur agréé qui vendra des produits beaucoup plus chers mais probablement originaux.

La comparaison de produits originaux qui sont souvent proches des spécifications et des chinoiseries a montré à l'usage des écarts considérables.

Haut de page

nextion  Données aberrantes

Lors d’acquisition de multiples données, les résultats sont globalement identiques d’une mesure à l’autre, mais il arrive erratiquement qu’une donnée soit aberrante, en particulier à cause de parasites sur les longs fils qui font antenne, ou de collision de données.
On enregistre par exemple la température ambiante autour de 20 degrés, et de temps en temps une des valeurs peut-être de plusieurs centaines ou milliers de degrés en positif ou en négatif, cette valeur aberrante doit être impérativement éliminée pour avoir une suite de données cohérente. Des algorithmes de calcul de moyenne statistique permettent de déterminer si la nouvelle donnée et inacceptable et dans ce cas relancer un certain nombre de fois la mesure pour retrouver une donnée cohérente.
Le problème se pose particulièrement avec les capteurs de température 18DS20 au bout de longs fils de plus de 10 mètres, s'il n’a pas été pris la précaution de mettre un filtre self et capacités sur l'alimentation en bouts de lignes. Une fois le filtre installé les erreurs de lecture sont beaucoup moins fréquentes.

Pour ne pas alourdir ce chapitre des anomalies de lecture, je ne rentrerai pas dans le détail des causes, cela demanderait plusieurs pages de développement.
Il ne faudra pas négliger ce détail pendant la conception sous peine de se retrouver avec des courbes hérissées de pics inexplicables.
Plus généralement, pour sécuriser un développement il faut faire des tests rigoureux par exemple :
 si la condition est remplie alors « faire cela »
 sinon « faire autre chose »
 sinon « solution parachute »

Cette dernière option parachute n’est pas un gadget car il arrive que lors du déroulement des tests les conditions changent pendant le test, il faut donc prévoir cette porte de secours.

Haut de page

nextion  L’erreur de conception

Depuis que je réalise des systèmes d'acquisition de données, je suis parti sur une mauvaise base !
L'erreur a été de mélanger la partie <corps de métier> c'est-à-dire l'acquisition des données et leur traitement avec la partie <IHM> (interface homme-machine), c'est-à-dire l'affichage et les organes de commande.
L'inconvénient de cette méthode, où dans le code l'affichage était entremêlé avec le traitement des données, est que lorsqu'il faut changer d'afficheur ce qui est arrivé très souvent, il faut revoir complétement l'ensemble du code, ce qui amène à un développement anarchique dans toutes les directions.

Avec l'arrivée du Nextion j'ai pris conscience que j'étais sur une mauvaise voie, il fallait maintenant trouver une autre stratégie.
Il faut traiter séparément la partie métier c'est-à-dire le traitement des capteurs et des données qui sont disponibles et produire un tableau à grande résolution (pour optimiser les arrondis), lorsque la demande d’un capteur particulier est faite par un périphérique.
Ce tableau sera toujours identique quel que soit le type de sortie (afficheur de taille quelconque, PC, Android , etc).
Le tableau contient les 360 données brutes en haute résolution calibrées entre le minimum et le maximum, plus divers paramètres nécessaires et suffisants, les valeurs du minimum et les pas d’affichage, l’unité, la valeur instantanée...

La partie métier n’a pas à connaître le type de la sortie.

Une bibliothèque d'affichage sera créée pour chaque type d’affichage et il suffira de sélectionner la bonne suivant la demande.

Il y a bien ainsi une séparation totale des données et de l’affichage, le développement de la partie métier ne dépend plus du tout de l’IHM.

Haut de page

nextion  Concept d'exploitation des données

Nous allons prendre un exemple simple, affichage des données sur 24 heures d’un seul capteur.

 Pour cela, on commence à charger le buffer précédemment défini de 360 mots de 16 bits à partir de l'adresse des dernières données rentrées, en décrémentent le pointeur.
Les valeurs brutes du capteur lu passent par la moulinette des coefficients correcteurs afin de stocker les valeurs corrigées dans le buffer.

 Une première passe détermine les valeurs maximales et minimales en fonction d’une table d’arrondis par capteur et sauve la valeur minimale.
Un algorithme calcule le pas d’affichage en abscisses, afin d’avoir un nombre optimal de graduations horizontales entre 5 et 10 et des valeurs bien arrondies.
En finale : Valeur maximale = Valeur minimale + (nombre de graduations * valeur du pas)

Voici un exemple type de ce qu’il faut éviter, le choix aberrant du pas des ordonnées, du a un bug pendant le développement.
Ce choix du meilleur pas et du nombre de pas optimal, n’est pas du tout évident, aussi cette page montrera l’algorithme d’optimisation utilisé pour avoir les graduations les plus intelligentes possibles :

Echelles de courbes optimales (en Y)Echelle

Gradhs
 Une deuxième passe éclate les valeurs du minimum à zéro au maximum à 65535 (0xFFFF)
 Une troisième et dernière passe ramène ces valeurs dans l'espace <zéro … résolution de l'afficheur (par exemple 359 pour un 480*360) > en tenant compte de la marge haute, recette c'est-à-dire la position absolue du pixel à afficher, sans toucher au buffer, en envoyant directement à l'afficheur.

Cela peut paraître étrange de passer par cette deuxième phase qui semble inutile mais l'intérêt et que la table une fois calculée servira quel que soit le type d'affichage choisi avec le meilleur arrondi possible. Ces résultats peuvent s'envoyer soit sur un afficheur classique soit sur un PC a beaucoup plus grande résolution soit vers un smartphone ou une tablette.
Il suffira au dernier moment de changer les coefficients d'affichage pour diviser ces valeurs et il n'y aura rien d'autre à modifier.

Voici un exemple de la courbe sortie sur un écran PC en 1920*1076, le dialogue ancien était fait sous Processing via l'USB et l'envoi simultané vers l’afficheur graphique.


Aujourd’hui, avec l’ESP32, la tendance est d’envoyer directement au Nextion (qui est un client comme un autre pour la partie affichage) et de diffuser par Wi-Fi et Bluetooth aux autres périphériques clients.

PC

Haut de page

nextion  Signal blackout

Afin d'éteindre les affichages énergivores quand il n'y a personne en face, j'utilise un signal blackout qui informe le microcontrôleur de couper le rétro-éclairage. Pour cela j'utilise plusieurs capteurs, par exemple des capteurs infra-rouges et des radars (matériel chinois à $1). Un ATTiny sous-traite l'opération et génère le signal blackout d'indication d'absence.
Attention toutefois au capteur choisi ! Mes infra-rouges marchaient fort bien pour des températures autour de 20°C mais plus du tout quand il y a eu la canicule que la température du bureau a pu monter au-delà de 30 °C degrés…
Les capteurs radars sont extrêmement sensibles et détectent un mouvement à plus de 5 mètres.

L'image nous montre quelques capteurs infra-rouges, radars et ATTiny :
blackout

Autre effet pervers du signal blackout
Le signal blackout est généré par un seul ATTiny pour être ensuite envoyé en étoile par un simple fil vers tous les automates, au travers de filtres en entrée.
Malgré cela, ces longues lignes font antenne et véhiculent des parasites secteur très perturbants. Il faut passer sur un petit coaxial ou en fibre optique pour éviter les plantages.

La première idée qui vient à l’esprit pour éviter ces parasites est de donner l’ordre de mise en sommeil par le Bluetooth.
Cela ne marche pas car toutes les cartes n’ont pas de Bluetooth, de plus cela permettrait de mettre en sommeil mais absolument pas de réveiller car tout est coupé alors. Un contact est indispensable pour le réveil.

Haut de page

nextion Inclusion hardware

Cette notion est très importante !

Depuis que je programme sur Arduino, j’ai monté des dizaines de cartes avec des processeurs et des périphériques différents.
Cette joyeuse anarchie posait un gros problème, un logiciel développé pour une carte ne pouvait tourner sur une autre qu’avec de profondes modifications.
Cette situation est intolérable quand on développe de gros logiciels sur de longues périodes.

Après bien des tâtonnements, j’ai résolu définitivement ce problème avec un concept simple, l'inclusion de fichiers hardware dans ma librairie personnelle.
Chaque fichier est spécifique pour un prototype donné, il contient tout le descriptif, le type de microcontrôleur (Uno, Mega, DUE, ESP32, STM32,…), le câblage des pins de sortie (leds, boutons, ..), les configurations et adresses des périphériques, etc.
En incluant le fichier correspondant au prototype testé, tous mes programmes tournent enfin sur toutes mes cartes sans aucun changement.
Les prototypes ont des afficheurs différents, depuis les anciens 2 lignes 20 caractères, plusieurs modèles en 320*240, ou 480*320, ou 800*480, etc.
Chaque programme s’adaptera en lisant le fichier de configuration qui donnera les bonnes définitions pour la cible choisie.
Chaque microcontrôleur est très différent, en brochage, pour les interruptions et les modes sommeil, la vitesse, les capacités mémoires, etc.
Un même programme tournera en mode réduit s’il manque un périphérique, par exemple un programme de domotique pourra reconnaître une dizaine de capteurs qui n’existent que dans une seule configuration, avec une carte plus petite, le menu ne les proposera pas.
Un programme peut évidemment être incompatible avec une carte, par exemple s’il joue de la musique et que la cible n’a pas de haut-parleur, il générera le message d’erreur.

Vous trouverez un exemple dans les fichiers joint qui correspond à la ligne : #include "board_DUE_4.h

Haut de page

nextion  Conclusion

Il y a encore beaucoup à dire sur ce sujet, mais cette page est déjà trop lourde. L’idée n’est pas de vous coller clefs en main un énorme programme difficile à suivre, mais vous donner des pistes pour réaliser votre propre enregistrement de données et affichage de courbes domotiques.
Le source Arduino est à disposition de qui le demandera et je reste ouvert à toutes vos suggestions pour corriger les erreurs et éclaircir ce qui est confus.
La page suivante Domotique Nextion nextion reprendra tous ces grands principes, mais avec une IHM (Interface Homme Machine) totalement différente.

Tous les détails sont dans les logiciels joints.

Vous trouverez tous les logiciels à jour dans cette page :

eclate

Haut de page

© Christian Couderc 1999-2019     Toute reproduction interdite sans mon autorisation


* Page vue   79   fois       IP : 35.173.234.237

 Haut de page         Dernière retouche le 27 Juin 2019 à 15 h         Retour page précédente

   Collector