Archive for 14 janvier 2013

RaspberryPi : utilisation d’Open2300 pour les stations météo La Crosse Technology

14 janvier 2013

J’ai fait acquisition (enfin, le père Noël m’a gentiment apporté) un Raspberry Pi avec une station météo La Crosse Technology WS2355. Cette station a la particularité d’être connectable à un ordinateur par RS232, l’idée d’utiliser le Raspberry Pi pour conserver un historique des données s’est donc faite naturellement. La station est livrée avec un adaptateur RS232 vers USB Prolific PL2303. Mes premières lectures sur le net semblaient indiquer que cet adaptateur ne fonctionne pas avec le Raspberry Pi, mais après avoir essayé, tout semble fonctionner avec ce dernier. Voici donc la procédure pour installer tout ce beau monde sur le RPi avec la bibliothèque open2300, dédiée à l’accès aux données des stations météo de la gamme WS23xx. L’enregistrement des données se fera dans une base de données MySQL.

Je suppose dans ce tuto que vous avez un serveur MySQL fonctionnel. Pour ma part, j’ai un serveur LNMP sur mon Raspberry (Linux, Nginx, MySQL, PHP), avec PhpMyAdmin d’installé, ce qui va faciliter les choses. Pour ma part, je me connecte sur le Raspberry Pi avec SSH, ce qui permet entre autre le copié-collé de commandes.

Le système connecté sur le RPi

Le système connecté sur le RPi

Téléchargement, compilation et configuration basique de open2300

Première étape, télécharger open2300, le décompresser, puis aller dans le répertoire des sources, ce qui peut se faire en ligne de commande avec :

wget http://heanet.dl.sourceforge.net/project/open2300/open2300/1.10/open2300-1.10.zip
unzip open2300-1.10.zip
cd open2300-1.10

On va compiler open2300, ceci se fait de façon automatique avec la commande make. Cependant, mysql2300, qui permet d’enregistrer les données dans la base de données, se compile séparément. Pour compiler les 2, il faut donc faire :

make
make mysql2300

Il est possible que l’on vous dise après la commande make mysql2300 que le fichier mysql.h n’a pas été trouvé. Il faut donc installer la bonne bibliothèque puis relancer la compilation de mysql2300 :

sudo apt-get install libmysqld-dev
make mysql2300

Branchez ensuite l’adaptateur sur le Raspberry Pi et la station à l’adaptateur.Sur le Raspberry Pi, tapez la commande

lsusb

Vous devriez voir l’adaptateur apparaître s’il est bien reconnu :

Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

Vérifiez sous quel nom apparaît l’adaptateur dans le système, avec la commande :

sudo ls -l /dev/tty* | grep dialout

L’adaptateur doit apparaître sous le nom ttyUSBx (ou éventuellement ttySx mais ça serait plus étonnant)  :

crw-rw---T 1 root dialout 5, 3 janv. 1 1970 /dev/ttyprintk
crwxrwxrwt 1 root dialout 188, 0 janv. 13 14:05 /dev/ttyUSB0

Notez sous quel nom il apparaît (en principe ttyUSB0 donc). Il va falloir configurer ensuite open2300. Créez le fichier de configuration en utilisant le fichier open2300-dist.conf comme modèle :

cp open2300-dist.conf open2300.conf

Il faut ensuite éditer ce fichier afin d’indiquer sur quel port la station se trouve. Tapez :

nano open2300.conf

Trouvez la ligne SERIAL_DEVICE et remplacez /dev/ttySO présente par défaut par /dev/ttyUSB0. A ce moment, il est en principe possible de récupérer les données. Pour cela, on va utiliser fetch2300. Toujours dans le répertoire open2300-1.10, tapez :

sudo ./fetch2300

Il est très probable que vous obteniez une erreur « Could not reset », c’est du a une erreur de droit sur l’adaptateur série. Il faut donner tous les droits avec la commande :

sudo chmod a+rwx /dev/ttyUSB0

Vous devriez maintenant obtenir quelque chose du type en réponse à la commande fetch2300 :

pi@raspberrypi ~/open2300-1.10 $ sudo fetch2300
Date 2013-Jan-14
Time 15:45:19
Ti 19.6
Timin 14.4
Timax 20.8
TTimin 12:22
DTimin 2013-01-10
TTimax 15:48
DTimax 2013-01-12
To 81.1
Tomin 81.1
Tomax 81.1
TTomin 00:10
DTomin 2000-00-00
TTomax 00:10
DTomax 2000-00-00
DP 81.1
DPmin 81.1
DPmax 81.1
TDPmin 00:10
DDPmin 2000-00-00
TDPmax 00:10
DDPmax 2000-00-00
RHi 58
RHimin 53
RHimax 68
TRHimin 23:21
DRHimin 2013-01-13
TRHimax 11:41
DRHimax 2013-01-14
RHo 110
RHomin 110
RHomax 110
TRHomin 00:10
DRHomin 2000-00-00
TRHomax 00:10
DRHomax 2000-00-00
WS 51.0
DIRtext N
DIR0 0.0
DIR1 0.0
DIR2 0.0
DIR3 0.0
DIR4 0.0
DIR5 0.0
WC 81.1
WCmin 81.1
WCmax 81.1
TWCmin 00:10
DWCmin 2000-00-00
TWCmax 00:10
DWCmax 2000-00-00
WSmin 0.0
WSmax 0.0
TWSmin 00:00
DWSmin 2001-01-01
TWSmax 00:00
DWSmax 2001-01-01
R1h 0.00
R1hmax 0.00
TR1hmax 15:44
DR1hmax 2013-01-14
R24h 0.00
R24hmax 0.00
TR24hmax 15:00
DR24hmax 2013-01-14
Rtot 0.00
TRtot 17:42
DRtot 2001-01-01
RP 977.100
RPmin 975.100
RPmax 992.500
TRPmin 04:40
DRPmin 2013-01-11
TRPmax 00:00
DRPmax 2001-01-01
Tendency Falling
Forecast Rainy

A noter les valeurs qui semblent étranges chez moi, c’est parce que je n’ai pas encore branché les capteurs extérieurs, on a donc les valeurs par défaut. Cela provoque également une grande lenteur de la récupération des données (enfin, je pense que cela vient de la), chez moi, tous les programmes proposés par open2300 mettent donc environ 4 minutes à retourner leurs données.

Le logo du Raspberry Pi

Le logo du Raspberry Pi

Sauvegarde des données dans MySQL

Nous allons ensuite mettre en place l’historique des données dans MySQL. Il est nécessaire avant de lancer mysql2300 (utilitaire qui lit les données de la station et les enregistre dans MySQL) de créer la base de données et de créer l’utilisateur open2300. La création de la base de données se fait en utilisant le fichier mysql2300.sql. Depuis la sortie de open2300, la syntaxe MySQL a été modifiée. Dans le fichier SQL, la requête de création est la suivante :

CREATE TABLE `weather` (
`timestamp` BIGINT(14) NOT NULL DEFAULT '0',
`rec_date` DATE NOT NULL DEFAULT '0000-00-00',
`rec_time` TIME NOT NULL DEFAULT '00:00:00',
`temp_in` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`temp_out` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`dewpoint` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`rel_hum_in` tinyint(3) NOT NULL DEFAULT '0',
`rel_hum_out` tinyint(3) NOT NULL DEFAULT '0',
`windspeed` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`wind_angle` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`wind_direction` CHAR(3) NOT NULL DEFAULT '',
`wind_chill` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`rain_1h` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`rain_24h` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`rain_total` DECIMAL(4,1) NOT NULL DEFAULT '0.0',
`rel_pressure` DECIMAL(4,1) NOT NULL DEFAULT '0.0',
`tendency` VARCHAR(7) NOT NULL DEFAULT '',
`forecast` VARCHAR(6) NOT NULL DEFAULT '',
UNIQUE KEY `timestamp` (`timestamp`)
) TYPE=MyISAM;

Cette requête fait donc une erreur lorsqu’on l’exécute dans MySQL :

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM' at line 21

Il faut donc remplacer TYPE=MyISAM par ENGINE = MyISAM

CREATE TABLE `weather` (
`timestamp` BIGINT(14) NOT NULL DEFAULT '0',
`rec_date` DATE NOT NULL DEFAULT '0000-00-00',
`rec_time` TIME NOT NULL DEFAULT '00:00:00',
`temp_in` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`temp_out` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`dewpoint` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`rel_hum_in` tinyint(3) NOT NULL DEFAULT '0',
`rel_hum_out` tinyint(3) NOT NULL DEFAULT '0',
`windspeed` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`wind_angle` DECIMAL(4,1) NOT NULL DEFAULT '0.0',
`wind_direction` CHAR(3) NOT NULL DEFAULT '',
`wind_chill` DECIMAL(3,1) NOT NULL DEFAULT '0.0',
`rain_1h` DECIMAL(5,1) NOT NULL DEFAULT '0.0',
`rain_24h` DECIMAL(5,1) NOT NULL DEFAULT '0.0',
`rain_total` DECIMAL(7,1) NOT NULL DEFAULT '0.0',
`rel_pressure` DECIMAL(5,1) NOT NULL DEFAULT '0.0',
`tendency` VARCHAR(7) NOT NULL DEFAULT '',
`forecast` VARCHAR(6) NOT NULL DEFAULT '',
UNIQUE KEY `timestamp` (`timestamp`)
) ENGINE=MyISAM;

A noter également le rel_pressure qui passe de decimal(4,1) à decimal (5,1), car sinon, on ne peut enregistrer la pression que jusqu’à 999,9 hPa, alors qu’on dépasse fréquemment cette pression (merci à Lecerf qui me l’a signalé dans les commentaires. Il signal aussi de son côté qu’il a passé wind_angle à decimal(4,1)). Pour ma part, j’ai aussi passé le rain_1h, rain_24h à 5,1 (au lieu de 3,1, ce qui limite à 99,9 mm de pluie sur 1 ou 24h), et le rain_total à 7,1 (sinon ça  limite le total à 999,9 mm, chiffre qu’on atteint assez rapidement à peu près partout en France).

Personnellement, j’ai exécuté cette requête directement dans MySQL. Profitez en pour créer l’utilisateur open2300 qui as les droits sur cette base. Le mot de passe par défaut est mysql2300. Soit vous utilisez ces mots de passes et login, soit vous les personalisez, auquel cas il faut indiquer ces paramètres dans le fichier open2300.conf dans la section « >### MYSQL Settings (only used by mysql2300) ».

Lancez la commande mysql2300 en tapant dans le repertoir ou nous avons compilé open2300:

sudo ./mysql2300

Quelques minutes plus tard, les données doivent apparaître dans la base de données si tout est bien configuré. S’il n’y a pas d’erreur, rien n’est retourné par le programme.

Installation de open2300 dans le système

Il faut ensuite installer les différents exécutables dans le système. Cela peut se faire grâce aux commandes suivantes :

sudo make install
sudo cp mysql2300 /usr/local/bin/mysql2300
sudo cp open2300.conf /usr/local/etc/open2300.conf

Les 2 dernières lignes sont nécessaires car mysql2300 n’est pas copié automatiquement par la commande make install et que le fichier de configuration n’est pas non plus copié.

Désormais, on doit pouvoir appeler les différents exécutables de de la suite open2300 depuis n’importe quel dossier du système.

Automatisation de la capture des données

Enfin, il faut mettre en place l’automatisation de la capture des données. Cela se fait avec cron notamment.

Tout d’abord, il est nécessaire de remettre à chaque démarrage les bons droits sur le convertisseur USB vers série car ces droits ne sont pas sauvegarder à l’arrêt. Pour cela, il faut éditer le fichier /etc/rc.local :

sudo nano /etc/rc.local

Rajouter tout en bas du fichier, juste avant exit : sudo chmod a+rwx /dev/ttyUSB0, puis quitter en sauvegardant.

Enfin, il faut automatiser le lancement du programme mysql2300, on le fait avec cron. Editer avec nano le fichier des Cron Tables :

sudo nano /etc/crontab

Ajouter tout en bas du fichier :

*/10 * * * *    pi sudo mysql2300 /usr/local/etc/open2300.conf

Cela provoquera l’appel toutes les 10 minutes du programme mysql2300 sous l’utilisateur pi (il faut changer le nom d’utilisateur si comme moi vous utilisez un autre nom d’utilisateur). Par ailleurs, j’ai rajouté « /usr/local/etc/open2300.conf » après mysql2300 car chez moi, les programmes de la suite open2300 ne parviennent pas à trouver où se situe le fichier de config. Cet argument permet d’indiquer à mysql2300 ou le fichier de configuration se trouve. Enfin, si vous souhaitez changer la périodicité de l’enregistrement des données, il suffit de changer le /10 en /x ou x est le nombre de minutes entre chaque mise à jour.

Pour information, chaque enregistrement prend au maximum 86 octets en base de données. Sur cette base, on a donc les quantités de données produites suivantes en fonction de l’intervalle de temps  :

Périodicité Nombre/h Taille/heure Taille/jour Taille/an
1  min 60 5,04  ko 120,94  ko 43,11  Mo
2  min 30 2,52  ko 60,47  ko 21,55  Mo
5  min 12 1,01  ko 24,19  ko 8,62  Mo
10  min 6 0,50  ko 12,09  ko 4,31  Mo
15  min 4 0,34  ko 8,06  ko 2,87  Mo
20  min 3 0,25  ko 6,05  ko 2,16  Mo
30  min 2 0,17  ko 4,03  ko 1,44  Mo
60  min 1 0,08  ko 2,02  ko 0,72  Mo

 Mise à jour du 10 mars 2013

Je complète cet article après quelques semaines de fonctionnement et suite aux nombreux commentaires laissés par les lecteurs (merci à eux).

Script de lancement

J’ai constaté à plusieurs reprises que l’exécutable « mysql2300 » plantait de façon aléatoire pour une raison indéterminée. La conséquence était que la mise à jour dans la base de données ne se faisait que toutes les 10 minutes au lieu de 5 (une fois sur 2), j’imagine que si je laissais les choses telles quelles, il arriverait un moment ou je n’aurait plus aucune mise à jour. La solution pour que tout rendre dans l’odre ? Tuer le processus « zombifié ». J’ai donc créé un script qui fait ceci, placé chez moi dans /usr/local/etc/open2300.sh :

kill `egrep mysql2300`
mysql2300 /usr/local/etc/open2300.conf

Cela tue le processus mysql2300 (s’il existe encore…) avant de lancer une nouvelle instance.

Il faut modifier en conséquence le crontab, afin de ne plus appeler directement mysql2300 mais le script, sans oublier de supprimer l’appel direct à mysql2300 que nous avions mis précédemment :

*/10 * * * *    pi sudo /usr/local/etc/open2300.sh

Pour que le script puisse s’exécuter, il faut bien sur donner les droits d’exécution avec un petit chmod :

sudo chmod u+x /usr/local/etc/open2300.sh

Se connecter sur le réseau Weather Underground

J’ai ensuite voulu collaborer au site Weather Underground. Un logiciel de la suite open2300, wu2300 permet en théorie de le faire (voir dans les commentaires, il semble que ce soft soit boguée, une solution a été proposée par Thibault). Cependant, cette solution nécessite d’accéder à la station. Le problème est que je fait un relevé toutes les 5 minutes et qu’un relevé prend entre 3 et 4 minutes (je ne sais pas si cette lenteur est normale). Bref, si j’utilisent wu2300, je vais avoir un soucis…

Comme les données sont déjà en base de données, j’ai eu l’idée de ré-exploiter ces données. Je ne suis pas le premier à avoir voulu le faire, voici donc une version du script qui fonctionnera avec l’installation proposée dans ce billet d’open2300 :

#!/bin/bash

date=$(date '+%s')
data=$(mysql -s -u open2300 -pMotDePasseDBOpen2300 -D open2300 << !
SELECT timestamp, rec_date, rec_time, ROUND((temp_out * 9 / 5 + 32), 2) AS temp_outf,
ROUND((dewpoint * 9 / 5 + 32), 2) AS dewpointf, rel_hum_out,
ROUND(windspeed * 2.23693629, 2) AS windspeedmph,
wind_angle,
ROUND(rain_1h / 25.4, 2) AS rain_1hin, ROUND(rain_24h / 25.4, 2) AS rain_24hin,
ROUND(rel_pressure / 33.8638864, 3) AS rel_pressurein
FROM weather ORDER BY timestamp DESC LIMIT 1 ;
!
)
if [ $? -ne 0 ]
then
echo "Erreur accés base MySql meteo !"
exit 1
fi

liste="timestampws rec_date rec_time temp_outf dewpointf rel_hum_out windspeedmph wind_angle rain_1hin rain_24hin rel_pressurein"
echo $data | while read $liste
do
datews=`echo $timestampws | cut -c1-8`
heuresws=`echo $timestampws | cut -c9-10`
minutesws=`echo $timestampws | cut -c11-12`
secondesws=`echo $timestampws | cut -c13-14`
secondesdata=`date +%s -d $datews`
timestamp=$(echo "$secondesdata + $heuresws*3600 + $minutesws*60 + $secondesws" | bc)
diffsecondes=$(( $date - $timestamp ))
#echo "Diff. sec. = $diffsecondes"
if [ $diffsecondes -gt 600 ]
then
echo "Donné Ws2300 plus à jour !"
exit 1
fi

BASEURL_wu="weatherstation.wunderground.com"
PATH_wu="/weatherstation/updateweatherstation.php"
ID_wu="IdStationWU"
PASSWORD_wu="motDePasseWU"
SOFTWARETYPE_wu="open2300%20v1.10"
date_wu=$(date -u "+dateutc=%Y-%m-%d+%H%%3A%M%%3A%S")
url_wu="http://$BASEURL_wu$PATH_wu?ID=$ID_wu&PASSWORD=$PASSWORD_wu&$date_wu&tempf=$temp_outf&dewptf=$dewpointf&humidity=$rel_hum_out&windspeedmph=$windspeedmph&winddir=$wind_angle&rainin=$rain_1hin&dailyrainin=$rain_24hin&baromin=$rel_pressurein&softwaretype=open2300%20v1.10m&action=updateraw"
#echo $url_wu
reponse_wu=$(wget -q -O - "$url_wu")
#echo $reponse_wu
if [ "$reponse_wu" != "success" ]
then
echo "$reponse_wu"
echo "Erreur mise à jour station WS2300 sur Weather UnderGround !"
fi
done

J’ai enregistré le script dans sudo chmod u+x /usr/local/etc/wu2300.sh, il fait bien sur le chmoder également pour le rendre exécutable.

Ensuite, je me content de l’appeler depuis le script open2300.sh, qui devient :

kill `egrep mysql2300`
mysql2300 /usr/local/etc/open2300.conf
/usr/local/etc/wu2300.sh

Il faudra bien sur créer au préalable un compte sur WU, et l’identifiant de la station sur cette page. C’est l’identifiant de la station qu’il faut déclarer comme identifiant (ID_wu) dans le script et non le login utilisé pour se connecter sur le site Weather Underground. Voici le résultat de ma station.

Sauvegarde de la base de données

Je souhaitais sauvegarder la base de données régulièrement. Une fois de plus, on fait un petit script + un cron et ça roule :

On créé un fichier save2300.sh puis on le chmod :

mysqldump -u open2300 open2300 -pMotDePasse --opt > /home/pi/saveDb/open2300dump`date "+%Y%m%d"`.sql

Et on place la règle dans le cron qui va bien.

01 00   * * *   pi sudo /usr/local/etc/save2300.sh

Tous les jours, à minuit 01, on aura une sauvegarde dans le répertoire saveDb un fichier daté de la date du jour de la sauvegarde.

Reste encore à faire pour réaliser une station pleinement exploitable, une solution pour afficher les données archivées. Pour ma part, je suis en train de bidouiller une solution à base de HighCharts, qui permet de faire des graphs très propres.

 

Mise à jour du 14 novembre 2015 :

Thierry a également eu des problèmes de blocages… il a pris le temps d’enquêter et à trouvé les causes et donc les solutions les plus efficaces… Je me permet donc de reproduire ici, directement dans le corps de l’article, ses 2 derniers commentaires
Commentaire du 9 octobre

Bonjour,

Je reviens avec un complément d’info:
Les blocages de liaisons ont été résolus de la façon suivante:
Par cron, je lance un job acq_meteo.sh qui contient ce qui suit:

#!/bin/bash
# Role: Programme maître de lancement des acquisitions:
# Tue le précédent processus s’il pas terminé.
# Lance le nouveau cycle d’acquisitions.
#
#
/usr/local/bin/clear_2300.sh
/usr/local/bin/acq_donn_w2300.sh

le job clear_2300.sh contient:

#!/bin/bash
# Role: Tuer le programme resté en mémoire avant de lancer le processus
# suivant.
#
ps aux | grep acq_donn_w2300.sh | awk{print $2}| xargs kill -9

Et le job acq_donn_w2300.sh est celui qui lance les acquisitions .

Pourquoi ce choix: acq_donn_w2300.sh quand il est lancé est le processus père des acquisitions. Si une des acquisitons reste bloquée, il reste en mémoire.

Quand cron lance l’acquisition suivante, avec clear_2300.sh on regarde d’abord si le processus père acq_donn_w2300.sh de l’acquisiton précédente est toujours présent en mémoire; si oui, on le tue ce qui a pour effet de tuer les processus fils. On peut alors lancer le processus d’acquisition suivant.

Par contre, j’ai toujours des problèmes de perturbations radio. J’envisage de déplacer les capteurs pour les rapprocher et ainsi disposer d’un signal plus fort.

Cordialement.

Et celui du 13 octobre

Bonjour,

Derniers constats et solutions:
Les pertes de liaisons ne sont finalement pas dues à des problèmes de propagation mais au cordon de liaison USB-RS232. Il semble que chez moi ce dernier s’est dégradé au point de tout bloquer.
Il faut quand chercher bien longtemps pour identifier qu’une liaison série avec l’ordinateur (Pi) est la cause du blocage des acquisitions!

Donc, en complément de ce qui est écrit ci-dessus, qui débloque le processus en mémoire du Pi, il s’agit de débloquer la liaison série.
Pour ce faire, j’ai choisi de continuer le processus décrit précédemment (post du 9 octobre 2015) et d’ajouter un script qui:
– Décharge le module pilote de la liaison USB série.
– Réinitialise le port USB concerné
– Recharge le module pilote de la liaison USB série.

La difficulté, c’est qu’il n’existe pas de commande en natif pour réinitialiser un port USB; il a fallu rechercher pour trouver quelque chose qui le fasse.
Finalement, j’ai trouvé un petit programme en C qui le fasse: usbreset.c dont le listing est ci-dessous:

/* usbreset — send a USB port reset to a USB device */
/* Programme de Alan Stern venant du site: */
/* https://marc.info/?l=linux-usb&m=121459435621262&w=2*/
/* ——————————————————————- */
/* Compilation: cc usbreset.c -o usbreset */
/* Utilisation: lsusb pour identifier le port a reinitialiser */
/* on obtient (par exemple): */
/* Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. */
/* Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub */
/* Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. */
/* Bus 001 Device 004: ID 7392:7811 Edimax Technology Co., Ltd EW-7811 */
/* Un 802.11n W$ */
/* Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 */
/* Serial Port */
/* Le port qui nous intéresse est celui concernant PL2303 Serial Port */
/* La commande sera: usbreset /dev/bus/usb/001/005 */

#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
const char *filename;
int fd;
int rc;
if (argc != 2) {
fprintf(stderr, « Usage: usbreset device-filename\n »);
return 1;
}
filename = argv[1];
fd = open(filename, O_WRONLY);
if (fd < 0) {
perror("Error opening output file");
return 1;
}
printf("Resetting USB device %s\n", filename);
rc = ioctl(fd, USBDEVFS_RESET, 0);
if (rc < 0) {
perror("Error in ioctl");
return 1;
}
printf("Reset successful\n");

close(fd);
return 0;
}

Une fois compilé, rendre exécutable le binaire (chmod +x usbreset) et le copier dans le répertoire /usr/local/bin
Ecrire ensuite dans /usr/local/bin le script: resetusbserial.sh

#/bin/sh
# Decharger le module usb de la liaison serie
modprobe -rf pl2303

# Reinitialisation de la liaison usb serie
# Pour connaitre quel port USB doit etre reinitialise, utiliser la
# commande lsub, reperer dans le retour de la commande la ligne
# contenant: PL2303 Serial Port et recuperer les valeurs Bus et
# Device pour lancer la commande:
# usbreset /dev/bus/usb/Bus/Device
/usr/local/bin/usbreset /dev/bus/usb/001/005
# Recharger le module
modprobe -a pl2303

Une fois écrit, le rendre exécutable.
Modifier le script acq_meteo.sh décrit dans le précédent message comme suit:

#!/bin/bash
# Role: Programme maitre de lancement des acquisitions:
# Tue le precedent processus s'il pas termine.
# Lance le nouveau cycle d'acquisitions.
# Reinitialiser la liaison serie
#
#
/usr/local/bin/clear_2300.sh
/usr/local/bin/acq_donn_w2300.sh
/usr/local/bin/resetusbserial.sh

Bon, maintenant avec tout ceci j’ai un système à nouveau opérationnel. Que de temps et d’essais pour en arriver là. C’est certainement la rançon d’utiliser du matériel « cheap », mais pour l’instant je dois m’en contenter.

J’espère que tout ceci pourra aider ceux qui voudrons tenter l’aventure.