Christian Couderc

Et bien non, le webmaster n’est pas en hibernation malgré une longue navigation et la bronzette aux Antilles en compagnie des moustiques agressifs.
Mes programmes domotique étaient stables, avec 4000 lignes de code, un gros tas mal conçu, difficile à maintenir, mais sans plantages ; plus rien ne semble bouger dans les pages WEB depuis l’été Covid 2020 !
Tout marchait bien pendant des années sur de vieilles cartes DUE, mais le basculement en ESP32 a compliqué l’ensemble.
L’intégration du capricieux Nextion s’est avérée lourde, puis a été abandonnée.
Idem pour l’Atom PSRAM display.

La seule solution était de tout reconstruire en classes modulaires propres pour retrouver un système fonctionnel en séparant totalement les données et l’IHM
Il ne faut pas s’obstiner à boucher sans fin les fissures d’un bâtiment branlant, il faut tout raser et reconstruire sur de nouvelles fondations solides.
Citation d'auteur inconnu : "Ce n'est pas en améliorant la bougie qu'on a inventé l'ampoule électrique."
Tout doit être conçu en classes indépendantes et robustes, avec chaque fois un programme de test rigoureux pour chaque méthode mise à disposition.
On arrive ainsi à décomposer en un ensemble de nombreuses classes en C++

Les premières générations utilisaient des capteurs filaires, abandonnés pour des balises indépendantes en ESPNow et HC12.
Le système évolue sur un grand afficheur graphique Makerfabs en plus du serveur Web.
Je développe de manière erratique en parallèle toutes autres choses dans toutes les directions, donc rien n’est jamais fini. Le système tourne sur une vingtaine de classes, que je modifie sans arrêt, preuve d’une conception bâclée.

Chaque classe est testée par un programme ino le plus rigoureux possible pour déceler toute anomalie, vérifier les bonnes initialisations et chacune répond bien aux spécifications.

Tout fonctionne, mais avec des plantages aléatoires que je ne sais pas expliquer, bien qu’ayant pris un maximum de précautions dans l’écriture de chaque classe.
L’ensemble n’est donc pas publiable en l’état.

Un très gros problème apparaît lorsque toutes ces superbes classes sont mises ensemble, appelées depuis la classe mère, pour réaliser un ino d’exécution global presque vide !

Chaque classe testée séparément marche très bien, mais quand tout est en place, cela fait 20 classes encapsulés qui doivent papoter en n’utilisant quasiment aucune variable globale.

Alors que tout semblait bien conçu pour que les méthodes communiquent entre les classes, la compilation donne des messages d’erreurs obscurs indiquant que des méthodes des classes ne se voient pas...

Il s’agit d’un défaut de conception extrêmement difficile à régler, bien plus complexe que la programmation de tout le code précédent. C’est sur ce point que tout bloque et que l’ensemble des classes amoureusement concoctées refuse de coopérer. Ma conception est bancale et je suis pour le moment dans une impasse.

Qui, comment, dans quel ordre, …, se font les initialisations des classes et instanciations des objets ?
C’est la base pour que tout coexiste ! En cas de problèmes ici, rien ne fonctionnera.

Je suis dans le syndrome du « culte du cargo », j’applique des solutions en partant d’exemples mal ou non compris, et la résolution divine n’apparaît pas.
Je continue à développer les codes, mais les classes ne vivent qu’appelées individuellement depuis un ino encore trop gros, ce qui n’était pas l’objectif prévu. Le projet ne se concrétisera que lorsque le brouillard sera dissipé.
Ne sous-estimez pas ce problème de conception qu’il faut régler avant tout en faisant des classes quasiment vides avec des méthodes publiques qui ne font que renvoyer des données fictives pour vérifier les liaisons inter classes, sans se préocuper des fonctions (cuisine interne invisible hors de la classe).
Il sera ensuite facile d’écrire les vraies fonctions et méthodes. J’ai fait exactement le contraire.

* Page vue 22196 fois IP : 216.73.216.87

Dernière retouche le 12 Avril 2026 à 14 h