Archives du blog

Avec des Plugins c’est plus festif

Il y a deux semaines je vous avais parlé de mon Bus Arduino (qu’entre temps j’ai nommé ARV, comme Arduino Rendez-Vous). J’ai décidé de le faire évoluer pour que le collector puisse faire d’autres choses.

J’ai imaginé plusieurs architectures pour pouvoir évoluer facilement suivant les besoins et j’en suis arrivé à développer des plugins pour le collector.

Un plugin c’est quoi ?

Un plugin c’est une librairie partagée (dll ou .so suivant votre plateforme) ayant des noms de fonction normalisée.

Tous les plugins pour une même application auront donc des fonctions et des variables en communs : celles qui seront appelées par le programme « maitre ».

Ce programme va donc ouvrir chaque plugin à charger et récupérer un pointeur sur chaque fonction/variable qu’il compte utiliser.

Comment ça s’implémente ?

On commence par « ouvrir » le plugin

void * plugin = dlopen (fileName, RTLD_NOW);
 if (!plugin)
 {
  printf ("Cannot load %s: %s\n", fileName, dlerror ());
  return 1;
 }

et après on peu « lier » une variable  (par exemple la variable pluginName contenu dans le plugin)

char * pPluginName = dlsym (plugin, "pluginName");
result = dlerror ();
if (result)
[...] traitement des cas d'erreur

ou une fonction

typedef int (*init_f) ( char * _subject, sirElement * config );
init_f init = dlsym (plugin, "init");
 result = dlerror ();

Notez bien le typedef du prototype de fonction.

Pour chaque plugin chargé je stocke un pointeur vers une fonction d’initialisation du plugin (init), qui va me permettre d’ouvrir des fichiers ou de me connecter à une base de donnée, et une fonction de traitement du message reçu (parse).

Le chargement ? quel chargement ?

Oui, car il faut charger tous les plugins qu’on compte utiliser, j’ai opté pour un fichier de paramétrage (collector.ini dont un exemple est reproduit ici) qui va définir les plugins à charger et quand les utiliser.

[base]
pluginDir=plugins
[plugins]
arduinoTP.StationMeteo=stationMeteo.so
arduino.StationMeteo=stationMeteo.so
arduinoTP.StationMeteo=toFile.so
[stationMeteo]
DBHost=127.0.0.1
DBName=BaseArduino
DBUser=UserArduino
DBPassword=MotDePasseArduino
[toFile]
#Par défaut le plugin prends "toFile.csv", on peut aussi le fixer par configuration
fileOut=
[toFile:arduinoTP.StationMeteo]
#On peu aussi définir des paramétrage pour un couple plugin/sujet
fileOut=fichierOut.csv

Détaillons ce fichier de configuration

La section [base] contient pour le moment le chemin vers le répertoire des plugins. Tous les plugins devront être dedans au risque de ne pas être chargés.

La section [plugins] détaille les plugins à charger. Attardons nous un peu plus sur cette syntaxe.

arduinoTP.StationMeteo=stationMeteo.so

Il y a donc une clef  (arduinoTP.StationMeteo) qui à une valeur (stationMeteo.so),par cette directive on définie quel plugin utiliser (stationMeteo.so) lors de la réception d’un message de type « arduinoTP.StationMeteo ». C’est la fonction parse() du plugin qui sera utilisée pour traiter le message.

Le plugin stationMeteo.so a pour mission de stocker dans une base MySQL les message reçus (deux photoresistances et 5 capteurs de température), dans le but d’être accessible sur mon site web personnel.

Il est possible de mettre plusieurs ligne ayant une même clef afin de multiplier les actions à réaliser sur réception d’un message (par exemple stocker un message en base ET faire agir un autre arduino en envoyant un autre message sur le bus)

Le plugin de type stationMeteo a droit à une section de paramétrage, j’y ai placé les paramètres d’accès à la base de donnée.

[stationMeteo]
DBHost=127.0.0.1
DBName=BaseArduino
DBUser=UserArduino
DBPassword=MotDePasseArduino
J’ai écrit un autre plugin : toFile.so qui se contente d’écrire ce qu’il reçoit dans un fichier. C’est aussi une bonne méthode pour illustrer une autre façon de paramètrer des plugins.
[toFile]
#Par défaut le plugin prends "toFile.csv", on peut aussi le fixer par configuration
fileOut=
[toFile:arduinoTP.StationMeteo]
#On peu aussi définir des paramétrage pour un couple plugin/sujet
fileOut=fichierOut.csv

toFile a deux sections de configuration : [toFile] et [toFile:arduinoTP.StationMeteo]. Dans le second cas vos pouvez reconnaître un nom de message qui a déjà été paramétré dans la section [plugins]. Cela implique qu’un message de type arduinoTP.StationMeteo utilisera un plugin initialisé grâce à la section [toFile:arduinoTP.StationMeteo] et [toFile] dans les autres cas.

Dans le cas présent cela influe sur le nom de fichier, mais cette méthode est applicable par tout les plugin installé pour avoir des particularité suivant le message reçu (base de donnée différente, fichier différent, …).

Concernant la lecture du fichier d’ini

Par défaut le C n’a pas de librairie d’accès standard pour ce genre de fichier alors j’en ai ré-implémenté une aux fonctions minimales (sir.c dans le repository). J’avais d’abord cherché à utiliser ce qui existe déjà mais j’avais la contrainte de la taille (n’oublions pas que je compile pour une machine ayant 1.5Mo de filesystem ^^) , dans mes pérégrinations je suis tombé sur iniParser qui fait le boulot de recherche dans un .ini mais qui n’accepte pas d’avoir plusieurs clefs identiques, et comme j’utilise cette fonction pour multiplier les actions sur réception d’un message … j’ai été contraint d’en réécrire un plus simple.
L’accès au code se trouve comme d’habitude : ici