Journal Hacker sa pompe de relevage 2 !

Sommaire

• Première difficulté : Mise à jour de l'IDE Arduino
• Watchdog Timer
• Refonte de l'IHM
• Utilisation de Preferences.h pour stocker les valeurs de configuration
• Utilisation de SPI et LittleFS pour les logs
• Utilisation de millis() pour afficher des messages régulièrement
• les résistances de tirage
• conclusion
• le futur oui j'aime l'amelioration

journal precedent : https://linuxfr.org/users/chocolatineflying/journaux/hacker-sa-pompe-de-relevage

Je vais vous faire un résumé ici, ce sera plus intéressant que de chercher les pépites dans les sources sur github.

https://github.com/ygueparm/lift_pump2

Première difficulté : Mise à jour de l'IDE Arduino

Lorsque j'ai mis à jour l'IDE Arduino sans faire attention, j'ai découvert que la version 3.x.x du core ESP32 par Espressif n'est pas compatible avec certaines bibliothèques comme AsyncWebServer et d'autres que j'utilise. J'ai passé beaucoup de temps à résoudre ce problème, mais vraiment beaucoup.

Conseil : Utilisez la version 2.0.9 du core ESP32 par Espressif et évitez toute mise à jour ultérieure.

j’étais pas fan de l'ide 2.X de arduino, finalement effectivement ça fait gagner vraiment plus de temps que la version 1.8.X MAIS c'est super lent pour compiler, deja que c'etait pas fameux.

Watchdog Timer

J'ai mis en place le watchdog interne de l'ESP32. Ce n'était pas facile à trouver, mais c'est simple à implémenter. Le temps est configuré en secondes :

#include <esp_task_wdt.h>

void setup() {
  esp_task_wdt_init(10, true); // Initialisation du watchdog (10 secondes)
  esp_task_wdt_add(NULL);      // Ajout de la tâche principale au watchdog
}

void loop() {
  esp_task_wdt_reset(); // Réinitialisation du watchdog à chaque itération
}

Si vous utilisez une instruction delay() supérieure à 10 secondes, cela bloquera l'ESP32 et le redémarrera automatiquement. donc attention a vos delay un peu partout dans le code

Refonte de l'IHM

je ne mets qu'une copie d’écran, le reste sur github

j'utilise un affichage conditionnel, if elseif elseif else pour afficher les différente page web en fonction de l’état des capteurs, j'ai voulu faire autrement sans succées, finalement ca fonctionne plutôt bien uniquement car je n'ai pas trop de page a afficher.

https://github.com/ygueparm/lift_pump2/blob/main/web_server.cpp

Utilisation de Preferences.h pour stocker les valeurs de configuration

J'ai utilisé la bibliothèque Preferences.h pour sauvegarder les paramètres de configuration et le temps de démarrage. c'est stocké dans l'eeprom interne, pour mon cas je trouvais cela plus simple, et c'est écrit une fois tous les 2 à 15 jours suivant les fonctionnement, très simple a utiliser, a éviter pour écrire beaucoup d'information taille environ 81920 octets

#include <Preferences.h>

// Instance pour sauvegarder les données
Preferences prefsPompe;

void setup() {
  prefsPompe.begin("pompe", false); // Namespace "pompe"
}

void loop() {
  unsigned long dernierDemarrage = millis();
  prefsPompe.putULong("dernierDemarrage", dernierDemarrage); // Sauvegarde du dernier démarrage dans le stockage pompe
}

Utilisation de SPI et LittleFS pour les logs

Pour enregistrer les logs, j'ai utilisé la bibliothèque LittleFS. Voici un exemple de fonction pour écrire des compteurs dans un fichier, principalement les log de debug que j'affiche dans le terminal série, la j'enregistre tous dans la flash environ 2Mo de disponible :

#include "LittleFS.h"

void enregistrerCompteurs(int niveauHaut, int etatContacteur, int etatRelaisSecurite, int moteurEnMarche, int capteurBloque) {
  File file = LittleFS.open("/compteurs.txt", FILE_WRITE);
  if (!file) {
    Serial.println("Erreur lors de l'ouverture du fichier compteurs pour écrire");
    return;
  }

  file.printf("Niveau haut: %d\nContacteur: %d\nRelais sécurité: %d\nMoteur en marche: %d\nCapteur bloqué: %d\n",
              niveauHaut, etatContacteur, etatRelaisSecurite, moteurEnMarche, capteurBloque);

  file.close();
  Serial.println("Compteurs enregistrés");
}

c'est un peu plus lourd que l'utilisation de préférence, pour moi.

Utilisation de millis() pour afficher des messages régulièrement

Pour éviter de surcharger la sortie série avec trop d'informations, j'ai utilisé la fonction millis() pour afficher des messages de manière régulière et non à chaque itération :

unsigned long previousMillis_print = 0;
const unsigned long interval_print = 5000; // Interval de 5 secondes

void loop() {
  unsigned long currentMillisled = millis();

  if (currentMillisled - previousMillis_print >= interval_print) {
    previousMillis_print = currentMillisled;

    Serial.print("État du capteur de niveau haut : ");
    Serial.println(capteurs.niveauHaut);
    Serial.print("État contacteur : ");
    Serial.println(capteurs.etatContacteur);
    Serial.print("État du relais sécurité : ");
    Serial.println(capteurs.etatRelaisSecurite);
    Serial.print("Moteur en marche : ");
    Serial.println(moteurEnMarche);
    Serial.print("État si le capteur a été bloqué : ");
    Serial.println(capteurBloque);

   }
}

les résistances de tirage

ça aussi j'ai découvert un peu tard

  //résistance de tirage pour les entrée :
  pinMode(CAPTEUR_NIVEAU_HAUT, INPUT_PULLDOWN); //ajouter la mention PULLDOW ou PULLUP
  pinMode(RELAIS_SECURITE, INPUT_PULLDOWN);
  pinMode(CAPTEUR_CONTACTEUR, INPUT_PULLDOWN);

suivant votre utilisation, sa simplifie le montage grandement !

conclusion

C'est maintenant bien plus agréable de se connecter à l'interface avec un téléphone. Je ne perds plus les valeurs qui étaient stockées en RAM, ni le temps total de fonctionnement de la pompe, ni les logs. et ca c'est cool pour analyser si il y a eu un pb

Cette partie est terminée, je pense. La factorisation nécessiterait encore plus de travail pour rendre le code encore plus clair. J'ai passé environ 100 heures pour passer du fichier original à celui-ci. C'était un peu la misère ! Une personne expérimentée aurait probablement fait cela beaucoup plus vite et n'aurait pas tous mis dans un seul fichier au depart.

Pas de regrets sur la simplification du code, même si elle reste subjective. J'ai utilisé un IA principalement pour orienter mes choix stratégiques plutôt que pour générer du code directement. On atteint rapidement les limites des outils IA pour des cas spécifiques comme celui-ci.

En production, cela ne fonctionnait pas au début, mais grâce à une structure relativement propre, j'ai pu identifier rapidement d’où cela provenait, un niveau actif a LOW plutôt qu'a HIGH, bref c'etait assez satisfaisant a corriger. et sans IA !

Je travaille avec des lunettes anti-lumière bleue (de couleur rouge ou orange) pour éviter les maux de tête ou de yeux après de longues heures devant l'écran. D'où les émoticônes un peu partout dans le code, car les couleurs d'indentation ne sont pas très visibles pour moi. Tous les IA m'ont supplié de ne pas les garder, car cela ne semble pas professionnel, mais c'est moi qui ai mal à la tête ou aux yeux ! et ca a transformé ma vie au travail, mais il faut assumer de les mettre : https://fr.aliexpress.com/item/1005006898114168.html je conseil fortement, c'est impressionnant d'efficacité et mocheté. adieu l'indentation coloré pour retrouver ses petites lignes

le futur oui j'aime l'amelioration

La version 3 inclura :

Un module IR pour mesurer la vitesse de rotation de l'arbre de la pompe. Il y a suffisamment de place à l'intérieur de la pompe pour le faire.
Un accéléromètre pour enregistrer les vibrations et réaliser une analyse fréquentielle.
j'ai trouvé la meme pompe que moi sur lbc pour pas trop chère ca me permet de la modifier tranquillement.

et je pense passer par domoticz ou qqhchoses d’équivalents, imaginons avoir 40 pompes a surveiller, dans une piscine public par exemple, ce serait dommage de ne pas utiliser qqchoses d'existant et d'avoir un écran centralisé pour surveiller tous cela !

Maintenant que tout fonctionne correctement, je peux enfin monter ma startup !