Domotique Shelly : premier contact

Domotique Shelly : premier contact

 

Cet article présente un test récent de quelques dispositifs domotiques de la marque Shelly.

1. Ma domotique de ces dernières années

1.1. Le cauchemar Blyss

En 2017, j'avais débuté en domotique en achetant une BlyssBox et quelques dispositifs :

• prises connectées
• détecteurs de mouvement
• contacts de fenêtres
• module télérupteur
• etc.

 Ce fut une catastrophe :

• relais qui restent collés en position ON
• module télérupteur HS
• modifications sans préavis sur les serveurs Blyss
• etc.

Le seul point positif de Blyss aura été de me faire mettre un pied dans la domotique, découvrir le monde ARDUINO et la domotique DIY, en réalisant quelques projets encore fonctionnels à l'heure actuelle.

Depuis quelques années, Blyss a abandonné la domotique, ce qui est une conséquence logique de la pauvre fiabilité de leurs produits.

1.2. Domoticz et la librairie MYSENSORS

Une Raspberry Pi, quelques ARDUINOs et modules radio, des capteurs, des relais, m'ont permis de satisfaire mes besoins. Ce fut une aventure longue et passionnante. Tous mes projets sont documentés sur ce blog.

Le DIY, c'est bien, mais il arrive forcément un moment où la lassitude vous gagne, et le projet reste incomplet, sauf pour les plus courageux.

1.3. Et ensuite ?

Est-il normal en 2026 de devoir encore empoigner le fer à souder et l'IDE ARDUINO pour réaliser ses propres dispositifs ?

Il existe à l'heure actuelle quelques marques qui proposent des dispositifs très intéressants et fiables :

• Fibaro
• Legrand
• Phillips
• Shelly
• etc.

2. Shelly

Qu'est ce qui m'a donné envie d'essayer Shelly ?

2.1. Pas de box

Alors que la plupart des autres fabricants proposent des systèmes organisés autour d'une box domotique, Shelly s'en passe, mais d'autres marques aussi, dont Legrand.

2.2. Le choix

Shelly propose un nombre très important de dispositifs. Certains sont totalement absents de l'offre d'autre marques, comme ce thermomètre :

Shelly H&T

Et surtout celui-ci :

Shelly BLU H&T

Ce minuscule (37x37x10 mm) thermomètre connecté fonctionne en BLE (BlueTooth Low Energy) et Zigbee. Il est vendu 19€.

Pour ma part j'aurais énormément de difficultés à fabriquer un dispositif d'une taille aussi réduite. Mon thermomètre hygromètre connecté a une autonomie supérieure, mais a des dimensions nettement plus importantes (76x76x30 mm).

2.3. Faire son choix

L'offre Shelly est très touffue. Il vaut mieux prendre son temps. Certains dispositifs sont capables de communiquer en WIFI, d'autres en BlueTooth, d'autres les deux, d'autres seulement en BLE et Zigbee.

Si l'on prend l'exemple du thermomètre Shelly BLU H&T, si l'on veut le raccorder au réseau WIFI, il faut l'associer à une passerelle USB :

Mais une prise connectée (GEN3 ou GEN4) peut aussi servir de passerelle, et c'est une idée très ingénieuse :

Shelly Plug M GEN3

J'ai donc choisi cette option, plus utile, et moins chère.

Comment choisir entre dispositifs BlueTooth et WIFI ? 

Pour ce qui concerne les dispositifs BLE, on n'a pas le choix. On ne peut pas demander à un appareil alimenté par une pile bouton d'embarquer un serveur WEB.

Pour le reste, tout dépend de la manière dont vous allez travailler. Soit vous vous contentez d'une application sur smartphone, dans ce cas peu importe, Blue Tooth ou WIFI conviendront.

Mais je dirais que pour vous laisser la possibilité d'évoluer plus tard, il vaut mieux avoir les deux : BlueTooth et WIFI.

2.4. L'installation

Il faut tout d'abord installer l'application Shelly Control sur son smartphone.

Celle-ci permet de créer différents objets :

• pièces
• dispositifs
• groupes de dispositifs
• scènes
• alarmes
• etc.

Je vous conseille de d'abord créer vos pièces (séjour, cuisine, chambres, couloir, etc.)

Si l'on a acheté des dispositifs BLE (thermomètre BLU H&T, bouton BLU button, détecteur de mouvement BLU motion, etc.), il faut d'abord installer la prise connectée qui va servir de passerelle, à l'aide de l'application Shelly Control.

L'ajout d'un dispositif se déroule assez classiquement :

• nom du dispositif
• type de dispositif
• pièce où il est situé
• etc.

ATTENTION : après avoir installé la prise connectée qui va servir de passerelle BLE/WIFI, il faut activer le BLE dans les settings de la prise. Étrangement, je n'ai pas trouvé d'autre moyen que d'utiliser l'application WEB de la prise elle-même (voir le paragraphe suivant). Ici sur mon PC :

La même opération peut être effectuée sur smartphone :

Il suffit de cocher la case Enable.

Sur ces deux captures, on voit que j'ai déjà associé plusieurs thermomètres BLU H&T (en bas).

En fin d'installation, on peut regrouper sur le dashboard (la page d'accueil de l'application), les dispositifs auxquels on accède régulièrement.

Note : l'application Shelly Control est accessible également sur le WEB, c'est à dire dans un navigateur sur PC, MAC ou autre, mais je n'ai pas l'impression qu'elle permette l'ajout de dispositifs.

2.5. Un peu de technique

Certains dispositifs ont plusieurs possibilités de communication.

Par exemple la prise Shelly Plug M GEN3 peut être contrôlée par l'application Shelly Control, mais elle peut l'être également par son application WEB interne, c'est à dire que le microcontrôleur de la prise est capable d'envoyer une page WEB à votre navigateur.

Pour lancer l'application WEB interne, il suffit d'entrer son adresse IP dans son navigateur, y compris sur smartphone, par exemple dans mon cas : http://192.168.1.17

On peut récupérer cette adresse dans l'application Shelly Control, dans l'onglet réseaux (le petit globe vers le bas, à gauche) :

L'adresse IP est située dans le petit encadré vert.

Dans le prochain paragraphe nous allons voir à quoi sert de récupérer l'adresse IP de la prise.

2.6. Accès par API

On peut maintenant s'attaquer à la partie la plus technique de cet article.

Certains diront que c'est bien joli d'avoir une belle application sur smartphone, mais un pilotage par une API serait la bienvenue. Hé bien Shelly l'a fait !

Par exemple, voici la documentation pour une prise connectée. Si l'on clique sur Shelly Plug/PlugS: /relay/0 à gauche, on voit que l'on peut piloter la prise à l'aide d'une simple requête HTTP. Nous allons reprendre l'adresse IP de la prise.

Essayons de récupérer l'état de la prise à l'aide d'un navigateur :

http://192.168.1.17/relay/0

Le navigateur affiche une ligne encodée en JSON :

{"ison": false, "has_timer":false, "timer_started_at": 0, "timer_duration": 0.00, "timer_remaining": 0.00, "overpower": false, "source": "init"}

Allumons la prise :

http://192.168.1.17/relay/0?turn=on

Le navigateur affiche :

{"ison": true, "has_timer":false, "timer_started_at": 0, "timer_duration": 0.00, "timer_remaining": 0.00, "overpower": false, "source": "http"}

Ici on voit que le résultat à changé : ison vaut true.

Éteignons la prise :

http://192.168.1.17/relay/0?turn=off

Le navigateur affiche :

{"ison": false, "has_timer":false, "timer_started_at": 0, "timer_duration": 0.00, "timer_remaining": 0.00, "overpower": false, "source": "http"}

L'API ne fournit pas tous les contrôles possibles. Par exemple elle ne permet pas de récupérer la température mesurée par un thermomètre BLU H&T associé à la prise.

Pour réaliser une telle opération, il faudrait envoyer à la prise l'URL de la page d'accueil de la prise, où toutes les températures sont affichées : http://192.168.1.17/#/

Ensuite il faudrait analyser la page WEB renvoyée, ce qui est un travail autrement plus conséquent que d'analyser une ligne JSON.

2.7. Exemple

Avec Domoticz ou un autre serveur Domotique, on peut envoyer des requêtes de pilotage de la prise connectée, comme je l'ai fait pour mon projet de télécommande domotique infra-rouge.

En résumé, la télécommande envoie un code à un ARDUINO équipé d'un récepteur infrarouge, qui l'envoie sur la ligne série de la Raspberry Pi. un script Python surveille cette ligne série et prend les décisions en fonction du code reçu.

En Python cela se fait comme ceci :

import os

os.system('curl -H "Accept: application/xml" -H "Content-Type: application/xml" -X GET "http://192.168.1.17/relay/0?turn=toggle"')

Ici, au lieu de donner à l'argument turn la valeur on ou off, j'ai utilisé toogle (basculer).

Pourquoi utiliser une télécommande infra-rouge et non pas son smartphone ?

Avec un smartphone, il faut effectuer plusieurs actions :

• trouver le smartphone
• activer l'application Shelly Control
• attendre environ 4 secondes
• cliquer sur l'icône de la prise

Avec une télécommande infra-rouge, on appuie simplement sur la touche dédiée à la prise.

Avec cette solution, on travaille uniquement en réseau local, sans internet, sans l'application Shelly Control. On n'est donc plus tributaire du cloud.

2.8. Sans serveur domotique

On pourrait faire exactement la même chose avec un ESP32 équipé d'un récepteur infrarouge, en utilisant l'API WiFiClient pour envoyer la requête :

  WiFiClient client;

  String request;

  HTTPClient http;

  int httpCode;

  request = "http://192.168.1.17/relay/0?turn=toggle";

  http.begin(client, request);

  httpCode = http.GET();

  log_printf("%s %d\n", request.c_str(), httpCode);

  if (httpCode > 0) {

    log_printf("OK\n");

  }

  http.end();

2.9. Et la box internet dans tout ça ?

Votre box internet va recevoir de la part des dispositifs WIFI des requêtes DHCP, et la box va attribuer une adresse IP à chacun d'eux. Cette adresse n'est pas attribuée pour un temps infini (tout dépend du routeur).

Si l'on désire utiliser l'API Shelly, et ne pas se laisser surprendre par un changement d'adresse, il vaut mieux rendre cette adresse fixe. Vous trouverez tous les renseignements nécessaires dans la doc de votre routeur, ou sa page d'accueil. Pour une LiveBox, on trouve tout ça dans Paramètres Avancés, puis Réseau.

3. Domotique commerciale vs domotique DIY

Je pense utile de rappeler certains points.

Avec la domotique commerciale, nous sommes très dépendants :

• de la viabilité de la marque choisie
• des pannes éventuelles et du remplacement des dispositifs défectueux, pas toujours possible sur le long terme.
• de la disponibilité des serveurs cloud

La domotique DIY est certainement la solution la plus pérenne. Nous ne sommes pas prêts de voir les cartes ARDUINO ni les modules radio disparaître du marché. Et même si certains disparaissaient, il serait toujours possible de se rabattre sur d'autres modèles, d'autres technologies.

4. Note pour les DYIers

Shelly propose des modules à base d'ESP32 pour des réalisations personnelles.

Certains modules sont assez difficiles à intégrer par un amateur sur une carte maison :

D'autres sont plus accessibles :

5. Conclusion

Je dois avouer que les ingénieurs de chez Shelly n'ont pas les deux pieds dans le même sabot et ont fourni un travail de conception absolument énorme. Et je parle en connaissance de cause, étant moi même développeur en informatique embarquée et WEB.

Contrairement à d'autres constructeurs qui se contentent de fournir une application sur smartphone, Shelly se permet d'embarquer un serveur WEB dans certains de ses dispositifs WIFI, avec en prime une API documentée !

Un dernier point : la plupart des dispositifs Shelly supportent les protocoles Matter et Apple Homekit.

Cordialement

Henri

Eclairage : Philips Hue

 

Eclairage : Philips Hue

Dans ma maison achetée récemment, on peut accéder au séjour par 3 portes. Malheureusement l'une d'entre elles est dépourvue d'interrupteur, et c'est la plus utilisée !

J'ai besoin donc d'ajouter un interrupteur si je ne veux pas entrer dans la pièce de nuit à l'aveuglette. Deux choix sont possibles : 

• installer un télérupteur et 3 poussoirs, ce qui réclamerait pas mal de travail
• installer un va et vient piloté par radio

Il va sans dire que j'ai opté pour la deuxième solution.

1. Réalisation personnelle ou pas ?

Il serait possible de réaliser soi-même un interrupteur connecté à l'aide d'un bouton poussoir, d'un  ATMEGA328 et d'un module radio NRF24L01 alimentés par pile, mais j'ai jugé qu'il serait difficile de développer une carte aux dimensions suffisamment restreintes pour pouvoir être logée dans une boîte d'encastrement. De plus, le temps manque. Cela fera peut être l'objet d'un futur projet.

Parmi tous les systèmes existants, après avoir consulté pas mal d'avis et de documentations, j'ai finalement choisi un pack de démarrage Philips Hue, comprenant un pont (bridge), 3 ampoules et une télécommande gradateur, auquel j'ai ajouté deux télécommandes supplémentaires.

Le protocole radio utilisé est Zigbee, qui apporte certains avantages :

• portée étendue et stabilité
• réseau maillé : chaque dispositif agit comme un répéteur
• faibles besoins en énergie
• sécurité renforcée

On peut ajouter à cela qu'il existe sur le marché une grande variété d'ampoules et de luminaires compatibles, y compris d'autres marques, dont Ikéa et Osram.

2. Câblage

Les ampoules connectées doivent bien entendu être alimentées en permanence afin de pouvoir recevoir les ordres par radio. Il est donc nécessaire de démonter les interrupteurs d'origine et de les shunter :

Une fois le câblage modifié et l'ampoule mise en place, celle-ci s'allume aussitôt. Cela permet de vérifier que le câblage est correct.

Il y a toutefois un petit inconvénient : en cas de coupure secteur, les lampes Hue s'allument lorsque le secteur revient. Il vaut mieux ne pas les installer dans une chambre si l'on veut éviter d'être réveillé en pleine nuit en cas de coupure secteur.

3. Installation

Il est tout à fait possible de se passer du bridge Hue dans le cas où l'on ne désire pas utiliser de fonctions avancées, par exemple la connexion à un système domotique. Les ampoules et interrupteurs fonctionnent alors en Bluetooth, et l'éclairage peut être piloté à l'aide d'un téléphone mobile.

Pour ma part j'ai l'intention d'intégrer mon éclairage à mon système DOMOTICZ. J'ai donc installé le pont à l'aide de mon téléphone mobile et d'une des nombreuses documentations et tutoriels disponibles sur le WEB.

Côté DOMOTICZ, il suffit d'ajouter le plugin "Philips Hue Bridge" à l'aide du menu Configuration / Matériel : 

L'adresse IP du pont est à récupérer via l'interface WEB de votre box Internet. Ensuite c'est très simple, comme dit sur la page :

Laissez l'identifiant vide et appuyez sur le boutton LINK du pont Philips Hue. Puis appuyez sur le bouton "Register on Bridge"

Il sera possible après cela de piloter les ampoules Philips en passant par mon serveur DOMOTICZ, à l'aide d'une simple télécommande infrarouge, qui reste ma solution préférée pour piloter certains de mes dispositifs :

• allumage / extinction home-cinema
• allumage / extinction éclairages d'appoint

4. Conclusion

La réactivité de l'éclairage Philips Hue est excellente. La puissance des ampoules 1100 lumens est suffisante pour éclairer un séjour. D'autres modèles 400, 800 et 1600 lumens existent.

Bien sûr j'aurais préféré développer mon propre interrupteur connecté MYSENSORS, mais actuellement le temps manque pour achever un tel projet.

Philips Hue constitue donc pour moi une alternative tout à fait acceptable pour le moment.

Cordialement

Henri

DOMOTICZ : quelques méthodes de dépannage

DOMOTICZ : quelques méthodes de dépannage

 

Cela fait maintenant plus de 6 ans que j'utilise un serveur domotique nommé DOMOTICZ, et j'en suis assez fan, mais il arrive que des ennuis surviennent. Je vais les décrire dans cet article.

Mon système domotique est constitué de différents composants :

• serveur DOMOTICZ hébergé sur une RASPBERRY PI
• passerelle série MYSENSORS
• capteurs développés à l'aide de cartes ARDUINO NANO, PRO MINI
• un écran TFT piloté par un ESP8266
• un répéteur MYSENSORS pour les capteurs éloignés

1. Panne de passerelle série

La passerelle série (serial gateway) permet de communiquer avec mes objets connectés équipés de NRF24L01 (capteurs de température, prises, relais, etc.) développés à l'aide de la librairie MYSENSORS.

Récemment, sur la page d'accueil de mon serveur, certains capteurs sont affichés en rouge, et ils n'ont pas communiqué depuis plusieurs jours :

J'ai deux types de dispositifs :

• dispositifs ARDUINO + NRF24L01
• dispositifs ESP8266

Apparemment seuls les dispositifs ARDUINO sont concernés. Comme il serait tout à fait étonnant que plusieurs capteurs aient le même problème simultanément, je soupçonne donc un problème sur la gateway. Après avoir branché celle-ci sur un port USB de mon PC, je lance le Moniteur Série de l'IDE ARDUINO, et les informations de DEBUG sont affichées :

0;255;3;0;9;MCO:BGN:INIT GW,CP=RNNGA--,VER=2.1.1

0;255;3;0;9;TSM:INIT

0;255;3;0;9;TSF:WUR:MS=0

0;255;3;0;9;TSM:INIT:TSP OK

0;255;3;0;9;TSM:INIT:GW MODE

0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0

0;255;3;0;9;MCO:REG:NOT NEEDED

0;255;3;0;14;Gateway startup complete.

0;255;0;0;18;2.1.1

MYSENSORS Gateway Serial

0;255;3;0;9;MCO:BGN:STP

0;255;3;0;9;MCO:BGN:INIT OK,TSP=1

Cela me semble un peu court. Par précaution je recharge le code de l'application gateway :

0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RNNGA---,FQ=16,REL=255,VER=2.3.2

0;255;3;0;9;5 TSM:INIT

0;255;3;0;9;7 TSF:WUR:MS=0

0;255;3;0;9;15 TSM:INIT:TSP OK

0;255;3;0;9;18 TSM:INIT:GW MODE

0;255;3;0;9;21 TSM:READY:ID=0,PAR=0,DIS=0

0;255;3;0;9;24 MCO:REG:NOT NEEDED

0;255;3;0;14;Gateway startup complete.

0;255;0;0;18;2.3.2

MYSENSORS Gateway Serial

0;255;3;0;9;30 MCO:BGN:STP

0;255;3;0;9;37 MCO:BGN:INIT OK,TSP=1

0;255;3;0;9;40 TSM:READY:NWD REQ

0;255;3;0;9;47 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

On voit bien deux lignes supplémentaires.

Je rebranche la gateway sur la RASPBERRY PI et au bout de quelques minutes tout rentre dans l'ordre.

2. Panne de répéteur

Il arrive que certains capteurs soient affichés en rouge, mais seulement les capteurs éloignés sont concernés. La communication avec ceux-ci passe par un répéteur. Ce n'est pas la première fois que cela arrive, et ici également, en cas de problème je recharge le code de l'application répéteur et tout rentre dans l'ordre.

3. Qualité du réseau

Il peut arriver qu'un capteur ne parvienne pas à envoyer ou recevoir des informations, ou que la communication passe par intermittence.

Il est nécessaire de vérifier que le réseau 2.4GHz passe bien à l'endroit où est situé le capteur.

Pour ce faire j'utilise la carte de test MYSENSORS, alimentée par batterie, développée il y a quelques années :

J'équipe cette carte de deux LEDs, une rouge et une verte, câblées chacune avec une résistance de 1KΩ en série, entre les sorties 2 et 3 de la carte PRO MINI et GND.

On peut parfaitement réaliser cette carte à l'aide d'une plaquette à pastilles. On peut même utiliser une UNO ou une NANO, sachant que l'autonomie sera beaucoup plus faible.

Voici le code utilisé :

//#define MY_DEBUG

#define MY_RADIO_RF24

//#define MY_RADIO_RFM69

#define MY_RF24_CE_PIN        7

#define MY_RF24_CS_PIN        8

#define RLED                  2

#define GLED                  3

#define SLEEP_TIME            5000L

#define VREF                  1.099

#include <MySensors.h>  

#define CHILD_ID_TEMP         0

void before()

{

  Serial.print("MYSENSORS test sensor: ");

  Serial.println("OK");

}

void setup()  

{ 

  Serial.begin(115200);

  Serial.print("Setup");

  pinMode(RLED, OUTPUT);

  pinMode(GLED, OUTPUT);

  Serial.println(" OK");

}

void presentation() {

  Serial.print("Presentation");

  // Send the sketch version information to the gateway and Controller

  sendSketchInfo("test sensor", "1.1");

  // Present all sensors to controller

  present(CHILD_ID_TEMP, S_TEMP);

  Serial.println(" OK");

}

void sendTemp(void)

{

  MyMessage tempMsg(0,V_TEMP);

  Serial.println("sendTemp");

  float temperature = 20.00;

  if (send(tempMsg.setSensor(CHILD_ID_TEMP).set(temperature, 1)) == true) {

    digitalWrite(GLED, HIGH);

    digitalWrite(RLED, LOW);

    delay(500);

    digitalWrite(GLED, LOW);

    digitalWrite(RLED, LOW);

  }

  else {

    digitalWrite(GLED, LOW);

    digitalWrite(RLED, HIGH);

    delay(500);

    digitalWrite(GLED, LOW);

    digitalWrite(RLED, LOW);

  }

}

void loop()     

{

  sendTemp();

  sleep(SLEEP_TIME);

}

Toutes les cinq secondes, un test d'envoi d'une température fictive est effectué. Si la communication passe bien, la LED verte est allumée pendant 500ms, sinon la LED rouge est allumée.

Ce dispositif ne permet cependant pas de quantifier la qualité du réseau, comme on pourrait le faire en WIFI (RSSI).

En baladant cette carte un peu partout à l'extérieur de la maison, je constate qu'il y a des zones où le réseau n'est pas accessible. Il s'agit principalement de zones où la maison, dont les murs de pierre ont 50cm d'épaisseur, fait obstacle. Par contre, je ne m'attendais pas à ce que mon répéteur ait une portée de plus de 20 mètres à certains endroits.

Tester son environnement avec ce genre de dispositif avant la mise en place d'un capteur peut s'avérer très intéressant, et peut éviter des déboires.

4. conclusion

Ma gateway et mon répéteur sont bâtis autour de cartes ARDUINO NANO. Ce n'est pas la première fois que je suis obligé de recharger le code sur ce type de carte.

Je soupçonne un problème de fuses, car ce genre de problème peut survenir lorsque l'on coupe l'alimentation d'un ATMEGA328, et la mémoire FLASH est partiellement corrompue. Mes cartes PRO MINI n'ont pas ce genre de problème, mais cela ne veut pas dire grand chose étant donné qu'elles sont alimentées par batterie, et que par conséquent leur alimentation n'est jamais coupée.

J'envisage sérieusement de remplacer certains ARDUINOs par des modules ESP8266 ou ESP32. Malheureusement cette opération n'est pas possible sur tous les capteurs. En effet, le temps de réveil d'un ESP8266 ou d'un ESP32 est énorme, car il redémarre en partant de ZÉRO, ce qui implique une reconnexion au réseau WIFI, qui peut être longue. Sur un capteur du type détecteur de présence ou bouton-poussoir, la latence serait inacceptable.

Autre possibilité : utiliser des STM32 ? Malheureusement, les STM32 ne sont pas supportés par la librairie MYSENSORS.

Il va falloir vivre encore un moment avec ces défauts répétitifs. Pour info, le code de la gateway a été rechargé une seule fois, celui du répéteur 4 à 5 fois.

5. A lire également

Pour ceux qui ne connaissent pas DOMOTICZ ou MYSENSORS :

DOMOTICZ : installation

MYSENSORS : présentation

Cordialement

Henri

Un Surpresseur DIY : dépannage

 

 

Un Surpresseur DIY : dépannage

 

J'avais présenté il y a 3 ans un projet de surpresseur :

Un Surpresseur DIY

Récupération d'eau de pluie : nouvelle installation

Récemment, j'ai observé que ma pompe se mettait en route pendant une fraction de seconde, se coupait, puis se remettait en route, plusieurs fois de suite, par à-coups.

En observant de plus près, je constate que lors de la mise en route de la pompe, l'aiguille du manomètre monte très rapidement au dessus de la pression maximale de réglage, qui est de 2 bars, la pompe se coupe, puis le manomètre retombe en dessous de la valeur minimale, et le cycle recommence.

Au premier abord, on pourrait soupçonner le pressostat, mais on va voir qu'il n'en est rien.

Il peut arriver qu'un surpresseur tombe en panne. On distingué 4 types de panne :

• pompe
• pressostat
• fuite
• ballon tampon

Cet article décrit les méthodes de dépannage, et ces méthodes peuvent être également utilisées pour dépanner un surpresseur du commerce.

1. Manomètre

Pour dépanner un surpresseur, il vaut mieux que celui-ci soit équipé d'un manomètre. Dans le cas contraire, il faudra en installer un. On peut parfaitement l'installer temporairement à la sortie du surpresseur.

2. La pompe

Il suffit d'ouvrir un robinet dans le circuit d'eau, et de relier la pompe directement au secteur pour voir si elle fonctionne ou pas. On peut également vérifier si elle est capable de relever l'eau à la hauteur désirée.

3. Le pressostat

Si la pompe ne se met pas en route lorsque la pression est trop basse, ou qu'elle ne se coupe pas lorsque la pression est trop haute, il y a de fortes chances que le pressostat soit déréglé ou en panne, et qu'il faille refaire les réglages, ou au pire, remplacer le pressostat.

4. Fuite

Une fuite peut occasionner des mises en route de la pompe sans raison apparente. Il peut s'agir d'une fuite vers l'extérieur du circuit, auquel cas celle-ci devrait être visible.

Si la fuite n'est pas visible, la cause de celle-ci peut être le clapet anti-retour en sortie de pompe. Le remplacer ou le nettoyer devrait résoudre le problème.

5. Le ballon tampon

Lorsque le ballon tampon est en cause, généralement la pompe se met en route par à-coups successifs.

Ce cas peut sembler anodin mais si vous tenez à votre installation d'eau de pluie, la mise en route répétée et par à-coups de la pompe peut occasionner des problèmes, car la pression risque de monter plus haut que prévu, même si c'est pendant de brefs instants. Cela met en danger l'installation. Je déconseille de laisser l'installation dans cet état, même si elle semble fonctionner.

Avant d'aller plus loin il faut bien comprendre le fonctionnement d'un ballon tampon :

Lorsque la pression tombe trop bas, le pressostat met la pompe en route. La vessie se remplit d'eau et gonfle, la pression d'eau augmente et le pressostat coupe la pompe lorsqu'elle a atteint la valeur maximale.

Lorsque la pompe se met en route plusieurs fois de suite par à-coups, il peut y avoir plusieurs causes :

• la vessie est percée
• la pression d'air dans le ballon est trop faible
• la pression d'air dans le ballon est trop haute

5.1. Vessie percée

Il peut arriver que la vessie soit percée, auquel cas la réserve d'air se remplit d'eau et la pression d'air devient nulle. Dans ce genre de cas de figure, l'air du ballon sort par la conduite de sortie du surpresseur et par conséquent se retrouve dans le circuit d'alimentation.

Si un robinet est ouvert, l'air est libéré et l'eau s'écoule par à-coups. Si l'on observe ce genre de phénomène, cela doit mettre la puce à l'oreille, car c'est un bon indice de panne. Par contre ce comportement est normal si l'on a réalisé dernièrement une intervention sur le circuit d'eau, dans le but de remplacer un élément, ou de modifier le circuit.

Quand le ballon est monté avec le raccordement d'eau en haut (ce que je conseille), la valve de gonflage est en bas. En général il s'agit d'une valve du type Schrader, comme sur une roue de voiture :

Comme on le voit sur cette photo, la valve est protégée par un bouchon en plastique, qu'il suffit de dévisser pour avoir accès à celle-ci.

Si l'on ouvre la valve et que la vessie est percée, de l'eau va s'écouler. Il est alors recommandé de remplacer la vessie, ou le ballon.

Avant de remplacer la vessie ou le ballon, il faut débrancher le surpresseur, et faire tomber la pression en ouvrant un robinet.

Si l'on parvient à se procurer une vessie neuve, il faudra démonter l'ancienne, vider le ballon de toute l'eau qu'il contient, et mettre en place la nouvelle vessie. Ensuite il faut regonfler le ballon à l'aide d'une pompe à vélo jusqu'à atteindre une pression égale à la pression minimale de réglage du pressostat, ou légèrement inférieure.

Si le ballon est remplacé, il faut savoir qu'un ballon neuf est gonflé à 3 bars. A l'aide d'un manomètre, vous devez dégonfler le ballon jusqu'à atteindre une pression égale à la pression minimale de réglage du pressostat, ou légèrement inférieure.

Après remontage du ballon, on vérifiera l'absence de fuite au niveau du raccordement d'eau.

5.2. Pression d'air trop faible

Dans ce cas, la quantité d'air dans le ballon est quasi nulle, et l'eau de la vessie occupe un volume maximal. Il sera donc impossible de faire entrer plus d'eau dans celle-ci.

Si la pression dans la vessie est trop faible, la pompe se met en route, la pression monte rapidement car le volume d'air dans le ballon est faible ou nul, et l'effet ballon tampon est quasi inexistant. Le pressostat coupe la pompe et la pression peut redescendre plus bas que la valeur minimale de réglage, et la pompe se remet en route. L'opération se répète jusqu'à ce que la pression se stabilise à une valeur plus ou moins au dessus de la valeur minimale fixée.

Il faut vérifier la pression d'air du ballon à l'aide d'un manomètre, et regonfler le ballon à l'aide d'une pompe à vélo jusqu'à atteindre une pression égale à la pression minimale de réglage du pressostat, ou légèrement inférieure.

Les puristes vous diront que regonfler un ballon tampon à l'azote est préférable, car l'air contient de l'oxygène qui détériore le caoutchouc. C'est en tous cas le gaz utilisé par le fabricant du ballon pour le remplissage initial.

La panne dont j'ai été victime est bien celle-ci. Aucun écoulement d'eau, ni d'air d'ailleurs, lorsque j'ouvre la valve de gonflage. Il m'a donc suffit de regonfler le ballon à 1 bar pour que le surpresseur fonctionne à nouveau correctement.

5.3. Pression d'air trop haute

Dans ce cas, la quantité d'air dans le ballon occupe un volume maximal, et la vessie est tellement comprimée qu'il est impossible de faire entrer de l'eau dans celle-ci.

Si la pression dans la vessie est trop haute, la pression de l'eau ne parvient pas à combattre la pression de l'air du ballon. La pression monte très rapidement, et on se retrouve donc dans le même cas que précédemment.

Normalement, ce cas ne doit pas se produire avec le ballon d'origine du surpresseur. Par contre si vous avez remplacé récemment le ballon, il se peut que celui-ci soit gonflé par le fabricant à 3 bars ou plus, et que vous n'ayez peut être pas pensé à le dégonfler. A l'aide d'un manomètre, vous devez dégonfler le ballon jusqu'à atteindre une pression égale à la pression minimale de réglage du pressostat, ou légèrement inférieure.

6. Conclusion

Pour éviter tout problème, je pense qu'il est préférable de vérifier régulièrement la pression d'air du ballon, et le regonfler si nécessaire, tous les 6 mois par exemple.

Après avoir été confronté à ce problème de dégonflage de ballon, il m'a semblé intéressant de partager avec vous mon expérience, car le diagnostic n'était pas si évident au premier abord.

Cordialement

Henri

ESP32 : Micro-irrigation Connectée (3ème partie)

 

ESP32 : Micro-irrigation Connectée (3ème partie)

Cet article fait suite à ceux-ci :

ESP32 : Micro-irrigation Connectée (1ère partie)

ESP32 : Micro-irrigation Connectée (2ème partie)

Pour rappel, le projet se trouve ici :

https://bitbucket.org/henri_bachetti/esp32-sprinkle-timer

1. Le hardware

Du côté matériel, le capteur d'humidité et le capteur de débit sont présents : 

• capteur d'humidité : GPIO36 (broche SVP)
• capteur de débit : GPIO39 (broche SVN)

Contrairement à ce que je pensais, l'ESP32 est tout à fait capable de mesurer une tension analogique de 3.3V, ou plutôt la librairie ARDUINO fait ce qu'il faut pour que cela soit possible. Le pont diviseur R3 R5 disparaît du schéma (paragraphe 5).

En ce qui concerne le capteur de débit, la mesure renvoie des valeurs non nulles pour un débit de zéro. Il faut que je fasse des essais afin de voir s'il ne s'agirait pas d'un problème d'alimentation. Il est alimenté par la broche 5V de l'ESP32 et celui-ci est alimenté par l'USB. Comme il ne reste que 4.7V, ce n'est peut-être pas suffisant.

L'écran OLED est connecté, ainsi que le bouton fonction et arrosage manuel: 

• SDA : GPIO21
• SCL : GPIO22
• bouton fonction : GPIO35
• bouton arrosage manuel : GPIO34

Comme il n'y a pas de résistance de PULLUP interne sur les GPIOS 35 et 34, il faut en ajouter une sur le schéma entre GPIO35, GPIO34 et 3.3V : 10KΩ.

2. La configuration

2.1. config.ini

Le paramétrage des capteurs a été ajouté :

[moisture]
sensor=36
max=50

[flow]
sensor=39
max=10

2.2 Schedule.ini

Ce fichier reste inchangé, mis à part que deux périodes d'arrosage ont été ajoutées :

[courges.voie1]
schedule1=08:00,15

[massif.voie1]
schedule1=08:30,15

3. L'interface HTML

La page d'accueil comporte maintenant des boutons permettant de modifier les périodes d'arrosage et même d'en ajouter : 

Cliquer sur l'un des boutons CONFIGURE permet d'accéder à un formulaire :

Il suffit de modifier les valeurs et de cliquer sur OK pour enregistrer les changements. Les changements sont stockés dans le fichier schedule.ini.

En cliquant sur le bouton AJOUTER on accède à un formulaire à peine différent :

Le formulaire propose une liste des zones existantes.

Attention il n'y a pas pour l'instant de contrôle de validité sur ces deux formulaires. Il faut bien respecter le format de saisie HH:MM.

Les durées sont exprimées en minutes.

Le bouton maintenance permet d'accéder au menu suivant :

Les actions suivantes sont possibles :

• tester les relais
• afficher le fichier config.ini
• afficher le fichier schedule.ini

Il est donc possible de sauvegarder ces deux fichiers avant une mise à jour des fichiers HTML. Les fichiers HTML et les fichiers de configuration (.ini) sont situés dans le même répertoire data du projet. Les fichiers de configuration seraient donc écrasés à la prochaine mise à jour si l'on ne prend pas de précautions.

4. L'écran OLED

L'afficheur montre la date et l'heure, ainsi que l'humidité et le débit :

Un appui sur le bouton fonction permet l'affichage de l'adresse IP de l'ESP32 pendant 4 secondes, puis de l'heure du prochain arrosage pendant 4 secondes, puis l'affichage revient à la normale.

Un appui sur le bouton d'arrosage manuel provoque l'affichage du premier arrosage manuel possible et de sa durée :

En appuyant plusieurs fois sur ce bouton on peut faire défiler les noms des voies. Un appui sur le bouton fonction déclenche l'arrosage manuel sur la voie choisie.

5. Rappels

Ce logiciel a besoin d'être compilé en utilisant les librairies suivantes :

ESPAsyncWebServer : https://github.com/me-no-dev/ESPAsyncWebServer

SPIFFSIniFile : https://github.com/yurilopes/SPIFFSIniFile

SSD1306 : https://github.com/adafruit/Adafruit_SSD1306

GFX : https://github.com/adafruit/Adafruit-GFX-Library

ezButton : https://github.com/ArduinoGetStarted/button

Quelques constantes peuvent être modifiées dans le code :

// max line length in config file

#define MAX_LINE 250

// max definition length for object names (relays, ways, zones, etc.)

#define MAX_DEF 50

#define MAX_BUF 30

// max ways and relays number

#define MAX_WAY 128

// max zones number

#define MAX_ZONE 12

// max waterings number in a day for each way

#define MAX_SCHEDULE 4

// max waterings number in a day for all ways

#define MAX_WATERING 256

On voit par exemple que le nombre d'arrosages par voie est limité à 4 par jour, ce qui me semble amplement suffisant. On peut bien entendu ajuster certaines valeurs, mais attention, celles-ci ne sont pas modifiables ultérieurement par l'interface HTML.

Pour le reste, relire l'article précédent : 5. Essayer

6. Le code

Le code, comme on peut s'en douter, n'est pas constitué d'un seul sketch, il serait énorme et illisible.

Voici une liste des fichiers :

esp32-sprinkle-timer.ino : le sketch principal

config.cpp, config.h : lecture du fichier de configuration config.ini

constants.h : constantes

flow.cpp, flow.h : capteur de débit

hmi.cpp, hmi.h : interface homme/machine sur l'écran OLED

html.cpp, html.h : interface homme/machine HTML

humidity.cpp, humidity.h : capteur d'humidité

module.cpp, module.h : gestion des modules (GPIOs, MCP23017, etc.)

oled.cpp, oled.h : écran OLED

relay.cpp, relay.h : gestion des relais

schedule.cpp, schedule.h : lecture du fichier de configuration schedule.ini

valve.cpp, valve.h : gestion des vannes

watering.cpp, watering.h : gestion des arrosages

way.cpp, way.h : gestion des voies

zone.cpp, zone.h : gestion des zones

Je veux bien admettre que ce code commence à devenir très conséquent, mais la complexité ne se gère pas avec simplicité. En opérant un découpage en modules simples, on peut toutefois réduire cette complexité et améliorer la lisibilité.

7. Conclusion

Les difficultés sont immenses car ce logiciel est hyper-paramétrable, et le temps manque. En effet, on peut difficilement s'occuper d'un jardin de 45m², récolter, cuisiner, faire des conserves, gérer un poulailler, aménager une nouvelle habitation, modifier son circuit électrique, et faire du développement logiciel en parallèle.

La période hivernale sera certainement plus productive en lignes de code. Patience ...

Cordialement

Henri

8. Mises à jour

18/08/2023 : ajout de l'écran OLED et du bouton fonction

22/08/2023 : ajout du bouton d'arrosage manuel

ESP32 : Micro-irrigation Connectée (2ème partie)

 

ESP32 : Micro-irrigation Connectée (2ème partie)

Cet article fait suite à celui-ci :

ESP32 : Micro-irrigation Connectée (1ère partie)

Démarré en novembre, ce projet a bien progressé ces derniers jours. C'est l'occasion de donner un état d'avancement.

Pour rappel, le projet se trouve ici :

https://bitbucket.org/henri_bachetti/esp32-sprinkle-timer

1. La configuration

Les fichiers de configuration sont lus grâce à cette librairie :

SPIFFSIniFile

Elle est directement installable depuis le gestionnaire de bibliothèques de l'IDE.

1.1. config.ini

La configuration, un fichier config.ini chargé dans le système de fichier SPIFFS, n'a pas fondamentalement évolué, ce qui est bon signe. Par contre le logiciel exploite de nouvelles données : la configuration des zones d'arrosage.

Avant tout, il s'agit de bien comprendre les paramètres de ce fichier :

• [relays] modules : la liste des modules :
• gpio-1 : gestion des GPIOs de l'ESP32
• mcp23017-1(0x20) : gestion des GPIOs d'un MCP23017 (adresse I2C 0x20)
• mcp23017-2(0x21) : gestion des GPIOs d'un autre MCP23017 (adresse I2C 0x21)
• [relays] gpio-1=GPIO-L(4), GPIO-L(5), etc. : liste des GPIOs de l'ESP32
• [relays] mcp23017-1=I2C-H(0-15) : liste des sorties du MCP23017 N°1
• [relays] mcp23017-2=I2C-H(0-15) : liste des sorties du MCP23017 N°2
• [valve] main=gpio-1.0 : la sortie sur laquelle se trouve la vanne principale
• [zones] zones=potager, courges, massif : la liste des zones
• [potager] ways=tomates(gpio-1.2), etc. : la liste des voies d'arrosage pour cette zone

Les relais sont décrits avec une syntaxe donnant divers renseignements :

• type-niveau(gpio) :
• type : le type du module (GPIO ou I2C)
• niveau : bas ou haut (L ou H) qui représente le niveau de commande du relais
• gpio : le N° de la GPIO. Il peut s'agir d'une liste

Les modules relais du commerce sont activables par un niveau haut ou bas :

• digitalWrite(pin, HIGH);
• ou :
• digitalWrite(pin, LOW);

Certains relais possèdent même un cavalier permettant de changer le niveau. Cette configuration permet d'indiquer au logiciel le type de relais que l'on utilise.

Exemples : 

• GPIO-L(4), GPIO-L(5), GPIO-L(13), GPIO-L(14), GPIO-L(15), GPIO-L(16), GPIO-L(17), GPIO-L(18) : 8 GPIO de l'ESP32 commandent des relais activable par un niveau bas
• I2C-H(0-15) : les 16 GPIOs d'un module I2C commandent des relais activables par un niveau haut

Par la suite, chaque voie d'arrosage va être associée à un relais. Pour ce faire, on ne va pas utiliser la même syntaxe, ce qui serait redondant et source d'erreurs. Les relais sont donc nommés comme ceci : 

• module.index
• module : le nom du module
• index : l'index à partir de ZERO

Exemples : 

• gpio-1.0 : la première GPIO du module gpio-1. Dans l'exemple précédent il s'agit donc de GPIO-L(4), GPIO-L(5) étant la deuxième (gpio-1.1), etc.
• mcp23017-1.3 : la quatrième GPIO du module mcp23017-1

Une voie d'arrosage est le moyen physique d'arroser un point précis d'une zone. Elle est forcément associée à une GPIO, à un relais (ou un MOSFET), et à une vanne avec ses tuyaux et goutteurs.

Une zone est une zone géographique, normalement alimentée par sa propre arrivée d'eau. Elle regroupe un certain nombre de voies d'arrosage. Cette notion est totalement inutile d'un point de vue logiciel, sauf que plusieurs voies d'arrosage peuvent porter le même nom, si elles sont situées dans des zones différentes :

[zones]
zones=potager1, potager2

[potager1]
ways=tomates(gpio-1.2), courgettes(gpio-1.3), menthe(gpio-1.4), salades(gpio-1.5)

[potager2]
ways=tomates(gpio-1.6), courgettes(gpio-1.7)

On voit ici que deux voies tomates et deux voies courgettes existent, commandées par des GPIOs différentes bien sûr.

Dans la description des horaires d'arrosage (voir plus loin 1.3. schedule.ini), ces différentes voies seront nommées par rapport à leur zone d'appartenance (ce qui permet de les différencier) : 

• potager1.tomates
• potager2.tomates
• potager1.courgettes
• potager2.courgettes

La configuration des multiples voies d'une zone a été simplifiée par rapport à celle décrite dans l'article précédent. Elle se fait maintenant sur une seule ligne : 

[zones]
zones=potager, courges, massif

[potager]
ways=tomates(gpio-1.2), courgettes(gpio-1.3), menthe(gpio-1.4), salades(gpio-1.5)

[courges]
ways=voie1(gpio-1.6)

[massif]
ways=voie1(gpio-1.7)

Enfin, le dernier paramètre est la durée d'arrosage manuelle par défaut, en minutes :

[manual] duration=10

1.1.1 Exemples

Deux exemples de configuration sont fournis (dossier examples) : 

config.small.ini : un module 8 relais

config.mcp23017.ini : un module 8 relais + un module MCP23017

Un module MCP23017 peut piloter 16 MOSFETs ou 16 relais. Pour essayer le logiciel dans cette configuration, le module MCP23017 suffit. Il doit être relié aux broches I2C de l'ESP32 : GPIO21 & GPIO22.

Il suffit de copier l'un ou l'autre dans le répertoire data et de le renommer en config.ini. Renseigner ensuite la variable permettant l'accès au réseau WIFI : 

[WIFI]

access-point=SSID:ABCDEFGHIJ

Charger les fichiers du dossier data à l'aide du menu de l'IDE : "ESP32 sketch data upload".

Voici un exemple simple et commenté :

[WIFI]
' remplacer SSID et ABCDEFGHIJ par vos identifiants
access-point=SSID:ABCDEFGHIJ

[relays]
' un seul module gpio-1, gérant 8 GPIO de l'ESP32 (4, 5, et 13 à 18)
modules=gpio-1
gpio-1=GPIO-L(4), GPIO-L(5), GPIO-L(13), GPIO-L(14), GPIO-L(15), GPIO-L(16), GPIO-L(17), GPIO-L(18)

[valve]
' vanne principale sur les deux premières GPIO 4 et 5
main=gpio-1.0, gpio-1.1

[zones]
' 3 zones d'arrosage
zones=potager, courges, massif

[potager]
' 4 voies d'arrosage pour cette zone sur les GPIOs 13 à 16
ways=tomates(gpio-1.2), courgettes(gpio-1.3), menthe(gpio-1.4), salades(gpio-1.5)

[courges]
' 1 voie d'arrosage pour cette zone sur la GPIO 17
ways=voie1(gpio-1.6)

[massif]
' 1 voie d'arrosage pour cette zone sur la GPIO 18
ways=voie1(gpio-1.7)

[manual]
' durée d'arrosage manuel : 10 minutes
duration=10

1.2. Erreurs

Si une erreur est détectée dans le fichier de configuration, celle-ci est signalée sur le moniteur série : 

way::create voie1gpio-1.6)
voie1gpio-1.6): bad format, missing parenthesis
voie1gpio-1.6): error creating way
configuration failed

On voit bien ici qu'il manque une parenthèse :

voie1gpio-1.6)

La bonne syntaxe est : voie1(gpio-1.6)

1.3. schedule.ini

Un nouveau fichier a été créé : schedule.ini

Ce fichier décrit la programmation des zones d'arrosage :

• heure de début
• durée
• arrosage systématique ou non en fonction du capteur d'humidité

[potager.tomates]

schedule1=06:00,15,*

schedule2=20:00,15,*

Cette section par exemple, décrit l'arrosage des tomates dans le potager :

• un premier arrosage à 6H00 pendant 15 minutes
• un deuxième arrosage à 20H00 pendant 15 minutes

Le caractère * signifie que l'arrosage est systématique, indépendant du capteur d'humidité. Si ce caractère est absent, l'arrosage sera dépendant du capteur :

[potager.courgettes]

schedule1=06:30,15

schedule2=20:30,15

1.4. Vanne motorisée

Une vanne motorisée (3 fils) nécessite d'être pilotée par deux relais, un pour l'ouverture, l'autre pour la fermeture. Ce genre de vanne met un certain temps à s'ouvrir et se fermer, environ 10 secondes, ce qui fait que le code nécessite un timer (la librairie ESP32 Ticker convient très bien).

Le logiciel est capable de prendre en compte une vanne motorisée comme vanne principale :

[valve]

main=gpio-1.0

Ce paramètre indique que la vanne principale est non motorisée, commandée par la GPIO-1.0

[valve]

main=gpio-1.0, gpio-1.1

Ce paramètre indique que la vanne principale est motorisée, commandée par les GPIO-1.0 et GPIO-1.1.

2. Arrosage automatique

La fonction loop() vérifie toutes les minutes qu'un arrosage automatique est nécessaire ou non, et le stoppe au moment adéquat.

L'interface HTML décrit les différentes voies d'arrosage configurées :

3. Arrosage manuel

L'interface graphique HTML montre également un bouton DEMARRER en face de chaque voie d'arrosage. Il suffit de cliquer sur ce bouton pour démarrer un arrosage manuel, après avoir saisi la durée dans le champ de saisie en haut à droite.

Lorsqu'un arrosage manuel est lancé, le bouton change de libellé (ARRETER), et un compteur affiche le temps restant, en minutes et secondes : 

Un clic sur le bouton ARRETER permet d'arrêter l'arrosage manuel.

On peut lancer plusieurs arrosages manuels simultanés.

3.1. Quelques explications techniques

Le pilotage de l'arrosage manuel est fait de manière autonome par l'ESP32, c'est à dire que l'on peut sans problème fermer le navigateur une fois l'arrosage lancé, ce qui ne serait pas le cas si j'avais choisi de piloter l'arrosage dans le code JavaScript. Ici, le code JavaScript se contente de demander régulièrement à l'ESP32 quel est le temps restant.

Pour les connaisseurs, le code JavaScipt envoie une requête HTTP à l'ESP32 via une WEB socket. Voir la fonction getData() de index.html.

4. HTML

Dans sa première version ce logiciel a été développé avec le librairie WebServer. Je me suis vite aperçu que sans AsyncWebServer et sa gestion de fichiers stockés en FLASH (SPIFFS), et surtout sa gestion des templates, le développement serait beaucoup trop complexe.

Installez cette librairie :

https://github.com/me-no-dev/ESPAsyncWebServer

Il s'en suit que le code HTML n'est plus intégré dans le code C++ du projet, mais dans le filesystem SPIFFS : index.html

4.1. Quelques explications tecniques

On peut remarquer deux choses dans ce code :

La présence de deux balises spéciales (place holders) :

• %PLACEHOLDER_MANUAL_DURATION% : durée de l'arrosage manuel
• %PLACEHOLDER_WATERINGS% : la liste des arrosages, sous forme de table HTML

Certains caractères % sont doublés, par exemple :

.mytable th { background-color:#BDB76B; color:white; width:50%%; }

Il s'agit probablement d'un bug de la gestion des templates AsyncWebServer, que j'ai contourné en utilisant cette astuce, un peu comme on le ferait avec printf() ou sprintf().

Pour résumer le principe, AsyncWebServer, après avoir lu le fichier index.html, va remplacer les place holders par leur vraie valeur :

• %PLACEHOLDER_MANUAL_DURATION% : 10
• %PLACEHOLDER_WATERINGS% : la table HTML des arrosages

Le remplacement est fait par une fonction située dans le fichier html.cpp : 

String templateProcessor(const String& var)
{
  if (var == "PLACEHOLDER_MANUAL_DURATION") {
    return String(Watering::manualDuration());
  }
  else if (var == "PLACEHOLDER_WATERINGS") {
    return wateringsTable;
  }
  return "";
}

5. Essayer

Pour essayer ce logiciel, il est nécessaire de connaître certains détails : 

• savoir installer le core ARDUINO nécessaire à la compilation des sketchs ESP32
• savoir installer le plugin "ESP32 sketch data upload"
• savoir charger des fichiers dans SPIFSS (ceux qui sont dans le dossier data du projet arduino)

Si la carte choisie est l'ESP32 DevKitC, La carte a sélectionner dans le menu Outils / Type de Carte est  la suivante : ESP32 Dev Module.

La configuration hardware actuelle est la suivante :

• un module à 8 relais sur GPIO4, GPIO5, GPIO13 à GPIO18
• un module MCP23017 connecté au bus I2C (si l'exemple config.mcp23017.ini est choisi)

Ceux qui sont à l'aise avec ces petits détails n'auront aucun mal à essayer ce logiciel dans sa version actuelle.

6. Conclusion

Ce projet n'est pas terminé. Il ne va pas cesser d'évoluer pendant les semaines à venir.

Il reste encore pas mal de travail, en particulier sur l'interface graphique :

• modifier les heures d'arrosage, les durées
• ajouter des heures d'arrosage
• ajouter des zones, des voies
• capteur d'humidité, de débit
• écran OLED
• etc.

Je suis parfaitement conscient que le code c++ et JavaScript de ce projet est complexe et certainement incompréhensible pour un débutant, mais il est difficile de faire simple quand on fait du développement WEB. L'essentiel est de bien comprendre la syntaxe des fichiers de configuration.

Si certaines notions sont incomprises, il est recommandé de poser des questions, même si je ne suis pas censé donner des cours de base de C++, HTML ou JavaScript en ligne.

Les développeurs expérimentés en JavaScript trouveront probablement que mon code JavaScript n'est pas celui d'un vrai professionnel JS, et qu'il ressemble trop à du C++, mais qu'ils me pardonnent, JS n'est pas mon langage de prédilection, je préfère C++ et PYTHON.

Pour conclure, le contenu de cet article risque d'être augmenté dans les prochains jours. Ne pas hésiter à revenir le consulter (voir 7. Mises à jour).

Cordialement

Henri

7. Mises à jour

04/05/2023 : paragraphes ajoutés ou fortement remaniés :

• 1.1. config.ini
• 1.1.1 Exemples
• 1.2. Erreurs
• 3.1. Quelques explications techniques
• 4.1. Quelques explications techniques