Centrale Domotique : Différence entre versions

Etape n°1 - Schéma de principe

(Merci Clément pour le dessin qui parle de lui-même ;-) )

En bref, depuis smartphone ou ordinateur, à travers internet, je visualise les graphes des mesures dans différents lieux, j'active ou désactive des appareils, je choisi le mode de chauffage.

Etape n°2 - Faire un plan de toutes les étapes

En bref, il faudra faire:

• 1) Branchement des 2 capteurs sur le Arduino
• 2) Branchement de la shield Ethernet
• 3) Installation de Gladys et configuration
• 4) Création du circuit de contrôle du fil pilote et branchement à l'Arduino (Merci à Vincent pour avoir vu les problèmes de soudure)
• 5) Ecriture du code Arduino pour envoyer les 3 mesures à Gladys
• 6) Mise à jour du code Arduino pour prendre en compte les commandes HTTP pour les 4 modes du fil pilote

Etape n°3 - Réalisation

Voici les 2 versions:

• Arduino et
• Nano,

avec chacune leur shield respectif, le capteur DHT22 et le capteur MQ135.

Il y a aussi au milieu l'électronique du fil pilote (plaque verticale avec un fusible) qui n'est que sur la version Arduino actuellement.

Etape n°4 - Les déboires

• Alimentation

Sans surprise, il faut passer par une alimentation sur VIN car l'alim par usb ne suffit plus quand les 2 capteurs et le shield sont branchés.

• 1er déboire) La carte W5100.

Tout d'abord, le "bug" chinois: erreur sur la résistance sur la prise RJ45. La bonne résistance aurait dû être “510” = 51 x 10^0 = 51 Ohms et non pas 51 x 10^1 = 510 Ohms, sinon pas de connexion au-delà de 10Mbps !

Ensuite, le couple Arduino/W5100 parait peut fiable. J'ai de nombreux crash aléatoires et inexpliqués. En désespoir de cause, je passe sur nano v3 + shield Ethernet ENC28J60 v1.

• 2nd déboire) Le DHT22 (AM2302)

Le DHT22 ne semble pas fonctionner sur le nano! Merci à Philippe pour l'utilisation de l'oscilloscope numérique. On voit sur l'image que le signal série est bien visible, mais le niveau 0 ne redescend pas en dessous de 1,5 V sur le modèle de marque "ASAIR" (1V/graduation) ! Sans doute un problème de résistance "pull-up". En attendant, heureusement le DHT 22 de "AOSONG", lui, fonctionne sur le nano.

• 3ie déboire) Encore le DHT22

Finalement pas fiable. Parfois 1 mesure sur 10, parfois aucune. Que me dit Internet? OK, je passe sur Si7021. Et le mesures deviennent fiables. J'obtiens de belles courbes sur Gladys.

• 4ie déboire) La librairie UIPEthernet.h

Sur le papier, l'idée est géniale: compatibilité totale avec la librairie Ethernet.h de la carte W5100. Rien à changer dans le code si ce n'est le "#include". Mais voilà, il y a un "mais". Cette librairie consomme 70% de la mémoire avant même d'avoir écrit 1 ligne de code. Les résultats sont bons au début, puis mon programme s'étoffe et j'arrive aux limites. Encore bloqué.

Je peux réduire de 50% la conso de la librairie en désactivant UDP. Cela ne m'aide pas car j'en ai besoin pour le DHCP. Sinon le système perd sa capacité plug&play.

Je passe alors sur la librairie EtherCard.h. Malheureusement elle est très peu documentée. Avec les exemples on s'en sort, et finalement le code est plus simple qu'avec Ethernet .h

Etape n°5 - Tests longue durée

• 5ième étape du plan.

Victoire! ENC28J60 et librairie EtherCard.h, c'est la paire gagnante. Je recommande. La librairie est plus simple et beaucoup plus fiable que l'autre. Testé sur plusieurs semaines, j'ai des courbes 100% complètes et aucune panne.

Finalement le réseau cible ne me permettra pas d'envoyer des commandes à l'arduino car je ne pourrais pas maîtriser le NAT distant. Donc je passe en mode polling: l'arduino va venir interroger le Gladys pour récupérer la consigne. Autre avantage: c'est plug&play. Brancher le module n'importe où dans le monde, il marche de suite sans configuration à faire.

• Des améliorations pour la suite:

Gérer les 2 cas DNS et IP local ( Surtout chez orange qui aime bien compliquer les choses simple :-( !! ) et les reconnexions sans reboot.

Ajouter les boutons de contrôle.

Etape n°6 - Capteur connecté en USB

En local, pourquoi passer par Ethernet? J'ai donc fait une version avec connexion directe sur le Raspberry Pi qui héberge Gladys.

Le code est disponible là:

Lien vers le code .ino version Gladys sur gitlab

Lien vers le code .ino version Domoticz sur gitlab

Une fois les numéros des métriques alignés entre Gladys et le code (ici 13,14,15), il faut brancher l'usb et faire un "Configuration" dans le module "Serial-Isokar" de Gladys. Ensuite ça marche tout seul.

Etape n°7 - Carte avec Gestion du Fil Pilote

Voici le circuit électronique complet. Il contient:

• Le Nano
• Le shield ENC28J60 avec connecteur Ethernet
• Le capteur de température/humidité Si2170
• Le capteur MQ135
• Le circuit Pilote relié au fil pilote central: 2 optocoupleurs + 2 diodes
• Un bouton de contrôle local
• 2 leds pour visualiser l'état

Etape n°8 - Codage du signal fil pilote

Le circuit comprend 2 opto-coupleurs, chacun avec une diode afin de contrôler le signal du fil pilote. L'image montre l'ordre envoyé, selon la sinusoide générée.

Je suis plutôt fâché contre les concepteurs de ce standard: des gens peut être bien intentionnés, mais qui n'ont pas la moindre notion de modération énergétique.

En effet, on voit que lorsque le signal est coupé, le chauffage démarre à fond, en mode Confort ! Donc si le boîtier de contrôle n'est plus alimenté, vous verrez votre consommation exploser. Il va falloir m'expliquer pourquoi ce choix qui me semble absurde !!

"Hors-gel" ou à la limite "Eco" auraient été de bien meilleurs choix à mon avis.

En conséquence, pour éviter ce risque il va falloir modifier le circuit et remplacer un des opto-coupleurs par un relai. Ainsi, lorsque le contrôleur est coupé, le relai laissera passer le signal "-115 V" ce qui correspond au mode "Hors Gel". Avec les inconvénients: le relai est mécanique, la bobine sera en permanence alimentée en mode "Confort" ou "Arrêt", il tombera en panne un jour ou l'autre.

Je suis aussi preneur du schéma Kicad pour réaliser le PCB, si quelq'un veut s'y atteler. Contact ici.

Etape n°9 - Mise en boitier

Contrôler à distance avec un appareil c'est bien. mais quand on se trouve juste devant le boîtier, ne pas connaître l'état courant, ni pouvoir le changer, c'est frustrant.

Pour cela 2 leds de couleurs sont ajoutées avec une étiquette explicative. Chaque led est connectée directement sur l'une des 2 sorties qui partent vers la carte Pilote. C'est le plus simple, et cela permet de vérifier le bon fonctionnement.

Le bouton poussoir change l'état de manière circulaire. Les leds reflètent immédiatement le nouvel état. Pour gérer tout conflit entre les 2 sources de commande (bouton ou Internet), la date des derniers changements de chacun est conservée. La modification la plus récente s'applique.

Etape n°10 - Tableau de bord version Gladys

Sur Gladys, un dashboard permet en un coup d'oeil de voir:

• la temperature mesurée
• la comande envoyée depuis internet
• le mode pilote réellement appliqué

Avec à chaque fois l'heure de modification. Le mode pilote diffère de la commande lorsque le bouton local a été actionné. Il montre l'état réel.

Etape n°11 - Tableau de bord version Domoticz

Voici la version du dashboard cette fois pour Domoticz. Avec:

• la temperature et l'humidité mesurée
• la comande envoyée depuis internet sous forme de boutons
• le mode pilote réellement appliqué

Et un graphe puissant avec zoom et historique sur 7 jours. Les codes arduino sont adaptés pour la connexion directe USB (explications ici), et pour la connexion HTTP avec l'API Domoticz.

Etape n°12 - Statistiques dans Graphana

Nouvelle étape: ajout d'une base InfluxDB et d'un Graphana. Cela se fait nativement dans Domoticz: Options/Push/InfluxDB. J'ai mis un container qui inclut InfluxDB et Graphana et se déploie en quelques minutes.

Merci à : - Lien vers le container Influx/Graphana

Note: les calculs restent approximatifs.