Comment bien coder avec un fichier de configuration

Bonjour,
Je travaille sur un fichier ino qui avec le temps prends beaucoup de ligne. Il fonctionne mais j'aimerais penser à l'optimiser.
En autre, je dois scroller pour activer/désactiver des fonctions, entrer des clés, etc.

J'aimerais avoir un fichier de configuration ou je retrouverai les "modules" à activer ou pas.
Je vais pas tout modifier tout de suite, mais j'aimerais commencer à le faire, du mois partir sur un bon commencement.

Avec mon fchier ino, je peux activer ou activer des capteurs, comme le BME280, un capteur watermak (irrigation), un ds18b20, un anénomère, et encore, un RTC, une carte SD, etc....

Par exemple, j'active une librarire avec un define, comme par exemple

#define ST4 // activation ou pas de la station4
//#define RFM95 //activation de LoRaWAN
//#define OTAA  // activation du mode de transmission
//#define SD_CARD // activation de la carte SD
//#define OLED // activation de LCD
#define EEPROM // activation de l'EEPROM
//#define SENSOR_RTC_DS3231 // activation de l'horloge
//#define ARDUINOLOWPOWER // activation du mode sleep  (low power)
//#define SENSOR_BME280_ADA // activation du BME280
//#define SENSOR_DS18B20  // active le sensor de temprazure

Voilà, c'est un exemple

J-M-L m'a ben conseiller pour créer un fichier de calibration.h qui se trouve au même niveau de mon ino.

J'ai aussi ma libraire.h et librairie.cpp.
Dans mon fichier librairie.h j'ai ceci, apr exemple

struct Config {
    bool init;
    int32_t interval = 15; // (sec) 15, 30, 60 (1mn), 120 (2mn), 300 (5mn), 900 (15mn), 1800 (30mn), 3600sec (1h)
    bool lowpower = false;
    bool radio = false; //RFM95
    bool wifi = false;
    bool irrigation = false;
    bool buds = true;

Mais ce n'est pas optimal car c'est indépendant du
#define RFM95

L'idée serait de développer ce struc config pour actier ou désactiver des capteurs, ou par exemple, je pourrai reprendre celui-ci

struct Config_radio {
    bool activate = false
    char c_appeui[100];        // FOR OTAA
    uint8_t appeui[8];        // FOR OTAA
    
    char c_deveui[100];        // FOR OTAA
    uint8_t deveui[8];        // FOR OTAA

    char c_appkey[100];        // FOR OTAA
    uint8_t appkey[16];        // FOR OTAA

    uint32_t devaddr;        // FOR ABP
      char c_devaddr[11];        // FOR ABP
    
    char c_appskey[100];    // FOR ABP
    uint8_t appskey[16];    // FOR ABP

      char c_nwkskey[100];    // FOR ABP
    uint8_t nwkskey[16];    // FOR ABP

};

pour activer ou désactiver le RFM95 (LoRaWAN)

Donc voilà les activations et configuration peuvent se trouver un peu partout.

Ma question est comment vous me recommendriez-vous d'optimiser mon script, avec un fichier de configuration centraliser qui me permettrait de facilement activer ou pas un capteur, ou de sauver des clés

L'idéal serait de tout faire dans /librairies/mylibrairie/ mais il faudrait que tout soit accessible aussi depuis librairie.cpp et monfichier.ino.

Je ne vais pas tout modifier maintenant, mais j'aimerais bien commencer par, par exemple, sur mes DS18B20, mas radio RFM95 avec ses clés, activer une station (j'en ai 4 pour le moment, mais j0en aurai 10) et quand j'active une station, il sélection les bonnes configurations des ds18b20, pouvoir activer facilement le mode sleep (lowpower)
Aussi, si j'active la station1, il devrait sélectionner les bonnes clés radio (LoRaWAN) car elles sont différentes d'une station à une autre.

Peut-être que je devrait faire un fichier dans /libraires/malibrairie/config.h, et accessible depuis fichier.ino?

L'aventage de
#define RFM95, si je le commente, il ne ca pas charger la librairire de LoraWAN qui allège bien le code, idem pour #define AUTRECHOSE
Mais bon, d'un côté si je télécharge les librairies que je n'utiliserais pas, est-ce un gros problème, si je n'utilisais plus les #define QUELQUECHOSE?

Voilà, j'espère avoir bien introduit ma situation et mes ambitions

Milles mercis!!!

J’aimerais encore préciser un truc que j’aimerais bien garder. Et ca va probablement montrer que ca part un peu dans tous les senses :slight_smile:
Actullement, je n’utilise pas ma carte SD, mais initialement, j’ai développé mon code pour que les activations des modules se fasse en lisant ma carte SD. Et ca j0aime bien, car si je chnage de station, il me suffit que passer la carte dans la nouvelle station.

Par exemple, pour mes clés LoRaWAN, je les mets dans ma carte SD. Quand la station démarre, il va lire le fichier dans la carte SD. Si les clés sont des 0, il va ignorer le conteu. Si les zéro sont remplacer par des clés valide, il va les lire et les sauver dans l’EEPROM puis remettre les clés de la carte à Zero. Ainsi, si on me vol ma station on ne pourra pas lire les clés qui se trouvaient dans la carte SD. Cette fontionnalité fonctionne très bien.
Pour les autres configurations, il va lire ma carte SD et sauver les valuers dans les struct.

Donc si je n’utlise pas ma carte SD, il faut que je définsse mes configurations dans des struct. mar exemple dans un fichier config.h. Si j’utilise ma carte SD; il lit le contenu de ma carte et met à jour mes struc, si non il utilise les struc défini dans mon script.

pierrot10:
J'aimerais encore préciser un truc que j'aimerais bien garder. Et ca va probablement montrer que ca part un peu dans tous les senses :slight_smile:

Je confirme.
Tu pars dans tous les sens.
Ce genre de problématique apparait en principe au début du projet au cours de l'analyse, bien en amont du codage. C'est toujours difficile de rajouter ce genre de fonctionnalités à posteriori car c'est comme ça que l'on arrive à des usines à gaz un peu boiteuses.

pierrot10:
Je vais pas tout modifier tout de suite, mais j'aimerais commencer à le faire

Ce genre de chose, on le fait ou on le fait pas. On peut difficilement le faire à moitié car cela va fatalement toucher à la structure du programme et la manière de coder.
Si ton programme est bien codé, toutes les fonctions bas niveau ne devraient pas être impactés. C'est plutôt la manière de les exploiter qui va changer.

Tout est faisable mais il faut un cahier des charges clair comme le dit fdufnews de façon à être certain de ce qui prime pour définir les valeurs (par exemple si vous avez déjà des valeurs en EEPROM et des valeurs non nulles sur la carte SD, il faut bien définir que c'est la carte SD qui "gagne")

Le plus simple est d'avoir une structure globale de l'ensemble des trucs à sauvegarder que vous stockez en EEPROM / relisez de l'EEPROM et éventuellement modifiez si au boot vous détectez une carte SD avec de nouveaux paramètres

Ensuite le reste du programme ne fait que toucher la structure (et la sauvegarder en cas de modification).

Merci beaucoup,
Je ne vais pas consacrer beaucoup d'énergie la dessus maintenant

C'est toujours difficile de rajouter ce genre de fonctionnalités à posteriori car c'est comme ça que l'on arrive à des usines à gaz un peu boiteuses.

d'accord

Ce genre de problématique apparait en principe au début du projet

Je pense en effet refaire de zero et reconstruire mon code en commençant par la partie config

Salut

J'ai retrouvé un bout de code d'un ancien programme qui permet de gérer sur carte SD un fichier de configuration et qui utilise la bibliothèque SdFat. je l'ai extrait pour en faire un petit code de démo --> cf les tutos