|
|
|
|||
|
Domotique Arduino |
|
Introduction |
Maj : 23/03/24
|
||
Cette page décrit mon ancienne application de domotique qui a évolué au cours des années. La dernière évolution impliquant le Nextion et un ESP32 est traitée dans cette autre page : Domotique Nextion |
 |
|
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. |
|
Page d'introduction au boot : |
 |
||
Le menu de base affichant les informations principales, après une attente de 10 secondes sur la page de boot.
|
 |
||
|
 |
||
| 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. |
|
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.
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 480x320 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.
 Schéma Eagle carte shield |
 Schéma Eagle boîte de liaison |
 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.
|
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).
|
 |
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. 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) !
|
 |
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.
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 800x480 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 / 1capteur / 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" //////////////////////// Master parameters /////////////////#FFFFCC #define NB_DATAS_TO_SAVE 12 // Space for one record (2 bytes) max : 360 * 16 = 5760 bytes/day : 8 datas //////////////////////// Computed parameters ///////////////// const uint16_t RECORDS_BY_DAY = 24 * 60 / INTERVAL_MIN ; // option 4 min -> // 360 dans espace 480 > marges 120 |
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 connaitre le jour correspondant à une date.
Problème au passage : 31 décembre > 1 janvier 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.
Remarque : Sur les nouvelles cartes le temps est traité en Unixtime pour simplifier.
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.
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.
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.
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.
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. |
 |
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, le paradigme a changé.
|
 |
|
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. |
 |
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.
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
Un automate, comme ceux décrits ici est sujet à des plantages plus ou moins imprévisibles, par exemple à cause d’un parasite secteur véhiculé par des fils trop longs.
Dans l’industrie on privilégie toujours trois systèmes identiques indépendants, qui se surveillent mutuellement et si l’un dérive par rapport aux deux autres, il reboote.
Cella n’est pas une sécurité absolue, et dans les navettes de la Nasa, les trois ont planté simultanément…
Nous n’avons pas les mêmes moyens et devons adapter des systèmes plus simples.
Voici un bon exemple de plantage gênant, mes deux automates pilotent le chauffage de la maison (c’est un <OU>) qui est de 20 degrés le jour et 17 degrés la nuit.
Les traits verticaux rouges indiquent que l’automate donne l’ordre chauffage.
| Considérons l’écran de droite. Tout est normal jusqu’à 23 heures, moment auquel doit s’enclencher le mode nuit, la température étant dépassée, il ne donne plus d’ordre chauffage. Mais il enregistre une montée très anormale de la température ! Considérons l’automate de gauche. Il doit couper le chauffage à 23h, mais à ce moment un gros parasite secteur lié à la coupure des PC sur le réseau, le plante alors qu’il était en ordre <active chaudière>. Il chauffe donc en continu jusqu’à 5h du matin, à ce moment, dérangé par la chaleur anormale, je me suis levé pour le reseter… Donc de 23h à 5h, il n’a rien enregistré, et le morceau de la courbe décroissante correspond aux enregistrements normaux d’il y a 4 jours (période d’enregistrement des données) ! |
 |
Sur ces versions, j’avais désactivé le chien de garde et le contrôle mutuel. Cette grossière erreur à empêché de déclencher un reboot qui aurait rétablie une situation normale.
Il est donc indispensable au moins d’activer un chien de garde qui effacera beaucoup de plantages.
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 
reprendra tous ces grands principes, mais avec une IHM (Interface Homme Machine) totalement différente.
Depuis 2022 je n’utilise plus qu’exclusivement |
Tous les détails et logiciels sont dans cette page à jour au : 220511 |
 |
© Christian Couderc 1999-2024 Toute reproduction interdite sans mon autorisation
* Page vue 20046 fois IP : 3.144.115.125
Dernière retouche le 25 Mars 2024 à 11 h
Abstract :
Résumé :
