Data Logger mais fichier mal écrit
Modérateur : Francois
Data Logger mais fichier mal écrit
Bonjour,
Bon ça fait un moment que j'utilise des Raspberry pour un tas d'utilisation "fixe" (serveur Emby , samba, Hot spot Wifi, etc)
Dans ces contextes, le raspberry est utilisé un peu comme un serveur, il est connecté en permanence à une alimentation à domicile et on l'éteint proprement (shutdown -h now)
Mais maintenant je m'intéresse à l'usage nomade. Là pas d'écran, pas de clavier. Jusque une alimentation, un interrupteur et le stockage des données sur la carte SD.
Dans ce contexte , on commence par protéger la carte SD : j'ai désactivé le swap, et l'écriture des fichiers journaux. Avec ça, j'ai une carte SD qui tient plus d'un an avec une utilisation de l'ordre de 10 allumages/extinctions brutales par jour. C'est pas mal du tout
Mais, oui il y a un mais. le datalogging c'est le stockage de données mesurées au fil du temps sur la carte SD.
A chaque utilisation j'ai donc un fichier qui grossit, jusque maximum 2Mo (pour 2h d'utilisation). Au redémarrage, le dernier fichier est archivé (tar/Gzip) et stocké dans un dossier. L'archive fait dans les 0,1Mo
Jusque là, pas de soucis
Mais, pourquoi donc la dernière ligne de mon fichier de données contient-il dans 10% des cas seulement tout un tas de m........ (un gros packet de 0 binaires)
Je sais fort bien que cela est lié à l'extinction brutale du raspberry, et je n'ai aucun moyen de faire autrement.
Pourtant, dans mon code (c'est du python), j'ai mis ceinture+bretelle+capote :
Juste après le f.write(............)
j'ai un f.flush()
suivit d'un os.sync(f)
et d'un f.close()
Il n'y en a déjà trop, là, le f.close() ne sert à rien, le fichier est déjà fermé par f.flush()
Dans une évolution, j'aimera réutilisé au démarrage suivant, la dernière valeur logée lors du dernier démarrage mais là, ce n'est possible que dans 90% des cas (lorsque la dernière ligne est correcte)
Avez-vous déjà rencontré un tel problème ? si oui, comment l'avez-vous résolu ?
Pour info, lorsque les logs systèmes n'étaient pas désactivés, ces fichiers de logs ne rencontraient pas ce problème ==> donc il y a un moyen de résoudre cela.
D'autre part, pour avoir déjà fait du datalogging sur carte SD avec un Arduino, je n'ai jamais rencontré ce type de problème, et pourtant, un arduino ne s'éteint qu'en débranchant l'alimentation (bon ok, il n'a aucune gestion de cache...... et pour une fois c'est cool)
D'avance merci de vos réponses
Bon ça fait un moment que j'utilise des Raspberry pour un tas d'utilisation "fixe" (serveur Emby , samba, Hot spot Wifi, etc)
Dans ces contextes, le raspberry est utilisé un peu comme un serveur, il est connecté en permanence à une alimentation à domicile et on l'éteint proprement (shutdown -h now)
Mais maintenant je m'intéresse à l'usage nomade. Là pas d'écran, pas de clavier. Jusque une alimentation, un interrupteur et le stockage des données sur la carte SD.
Dans ce contexte , on commence par protéger la carte SD : j'ai désactivé le swap, et l'écriture des fichiers journaux. Avec ça, j'ai une carte SD qui tient plus d'un an avec une utilisation de l'ordre de 10 allumages/extinctions brutales par jour. C'est pas mal du tout
Mais, oui il y a un mais. le datalogging c'est le stockage de données mesurées au fil du temps sur la carte SD.
A chaque utilisation j'ai donc un fichier qui grossit, jusque maximum 2Mo (pour 2h d'utilisation). Au redémarrage, le dernier fichier est archivé (tar/Gzip) et stocké dans un dossier. L'archive fait dans les 0,1Mo
Jusque là, pas de soucis
Mais, pourquoi donc la dernière ligne de mon fichier de données contient-il dans 10% des cas seulement tout un tas de m........ (un gros packet de 0 binaires)
Je sais fort bien que cela est lié à l'extinction brutale du raspberry, et je n'ai aucun moyen de faire autrement.
Pourtant, dans mon code (c'est du python), j'ai mis ceinture+bretelle+capote :
Juste après le f.write(............)
j'ai un f.flush()
suivit d'un os.sync(f)
et d'un f.close()
Il n'y en a déjà trop, là, le f.close() ne sert à rien, le fichier est déjà fermé par f.flush()
Dans une évolution, j'aimera réutilisé au démarrage suivant, la dernière valeur logée lors du dernier démarrage mais là, ce n'est possible que dans 90% des cas (lorsque la dernière ligne est correcte)
Avez-vous déjà rencontré un tel problème ? si oui, comment l'avez-vous résolu ?
Pour info, lorsque les logs systèmes n'étaient pas désactivés, ces fichiers de logs ne rencontraient pas ce problème ==> donc il y a un moyen de résoudre cela.
D'autre part, pour avoir déjà fait du datalogging sur carte SD avec un Arduino, je n'ai jamais rencontré ce type de problème, et pourtant, un arduino ne s'éteint qu'en débranchant l'alimentation (bon ok, il n'a aucune gestion de cache...... et pour une fois c'est cool)
D'avance merci de vos réponses
-
- Raspinaute
- Messages : 1587
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: Data Logger mais fichier mal écrit
Salut
Je pense que c'est liée justement a l'extinction brutal : il faut au moins faire un sync en tant que root avant de l’éteindre. Avec un arret électrique brutal, les caches seront sans doute pas écrits.
Il est aussi possible de modifier le filesystem pour y désactiver le cache (je n'ai plus les détails sous la main, je te laisse chercher), mais la conséquence sera une usure prématurée de la carte.
Mais sinon :
- comment et surtout pourquoi le PI est-il stoppé ?
- pour un datalogger, l'utilisation d'un microcontoler (genre ESP) est sans doute plus adapté que balader un PI, non ?
Je pense que c'est liée justement a l'extinction brutal : il faut au moins faire un sync en tant que root avant de l’éteindre. Avec un arret électrique brutal, les caches seront sans doute pas écrits.
Il est aussi possible de modifier le filesystem pour y désactiver le cache (je n'ai plus les détails sous la main, je te laisse chercher), mais la conséquence sera une usure prématurée de la carte.
Mais sinon :
- comment et surtout pourquoi le PI est-il stoppé ?
- pour un datalogger, l'utilisation d'un microcontoler (genre ESP) est sans doute plus adapté que balader un PI, non ?
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
Re: Data Logger mais fichier mal écrit
Merci pour ta réponse.
Je me doute que le problème vient de l'arrêt brutal.
J'ai ajouté aujourd'hui un os.sync comme je le disais, avant je me contentais du flush (qui n'a rien changé) je vais voir ce que cela donne.
Sinon, je chercherai comment désactiver le cache dans l'OS, c'est une bonne piste je pense.
Sinon, s'il ne s'agissait que de logger, je l'aurais fait en Arduino.
Mais le boitier Raspberry a :
- une page web de paramétrage (serveur web ultra light mais avec une jolie feuille de style)
- une connexion wifi (pour accéder là la page web)
- le raspberry fait à la fois hot spot wifi et client wifi.
- un envoi automatique des archives zip via ftp (connexion internet de la maison lorsqu'à proximité)
- et j'envisage une capacité d'interrogation en live (via GSM)
Tout ça, c'est trop pour un Arduino, j'avais fait un datalogger en arduino : concentration de gaz + température + pression + affichage sur écran LCD + écriture sur SDCARD et j'arrivais au taquet de la mémoire et des connecteurs disponibles, alors ajouter un serveur web, une connexion wifi.....
Une fois j'avais fait sur arduino, un petit service web accessible via wifi. rien que l'affichage d'une page web toute simple était déjà d'une longueur conséquente.
Mon rapberry est dans un boitier "embeded" en voiture, inaccessible, invisible. Il s'allume à la mise du contact et s'éteint à la coupure d'alimentation.
Je n'ai pas envie d'envisager une batterie de secours pour soutenir l'alimentation le temps d'une extinction propre. Où alors, à la limite, si un condo suffisant existe pour tenir une dizaine de secondes à 5V/0,15A (c'est ce que consomme mon boitier avec tout ses capteurs)
En gros, l'idée de départ ,si vous avez une peugeot récente, l'idée c'est l'équivalent de l'appli Mypeugeot , si nous ne connaissez pas, cette appli vous donne : kilométrage réalisé, consommation : moyenne générale, par trajet, kilométrage total, positionnement, logging des trajets.
Avoir ça sur une vielle guimbarde de 25 ans, j'ai trouvé ça marrant. je ne sais pas si en cas de vol ça pourrait servir ou pas. Ce n'était pas ma motivation première.
Tout fonctionne, sauf cette ligne de données binaire en fin de fichier et il ne me manque que la partie GSM
Je sais; certains vont me dire "il y a presque équivalent" avec AutoPi. Mais c'est plus drôle de le faire soit même et quand on le fait soit même, la seule limite aux fonctionnalités c'est l'imagination.
Je me doute que le problème vient de l'arrêt brutal.
J'ai ajouté aujourd'hui un os.sync comme je le disais, avant je me contentais du flush (qui n'a rien changé) je vais voir ce que cela donne.
Sinon, je chercherai comment désactiver le cache dans l'OS, c'est une bonne piste je pense.
Sinon, s'il ne s'agissait que de logger, je l'aurais fait en Arduino.
Mais le boitier Raspberry a :
- une page web de paramétrage (serveur web ultra light mais avec une jolie feuille de style)
- une connexion wifi (pour accéder là la page web)
- le raspberry fait à la fois hot spot wifi et client wifi.
- un envoi automatique des archives zip via ftp (connexion internet de la maison lorsqu'à proximité)
- et j'envisage une capacité d'interrogation en live (via GSM)
Tout ça, c'est trop pour un Arduino, j'avais fait un datalogger en arduino : concentration de gaz + température + pression + affichage sur écran LCD + écriture sur SDCARD et j'arrivais au taquet de la mémoire et des connecteurs disponibles, alors ajouter un serveur web, une connexion wifi.....
Une fois j'avais fait sur arduino, un petit service web accessible via wifi. rien que l'affichage d'une page web toute simple était déjà d'une longueur conséquente.
Mon rapberry est dans un boitier "embeded" en voiture, inaccessible, invisible. Il s'allume à la mise du contact et s'éteint à la coupure d'alimentation.
Je n'ai pas envie d'envisager une batterie de secours pour soutenir l'alimentation le temps d'une extinction propre. Où alors, à la limite, si un condo suffisant existe pour tenir une dizaine de secondes à 5V/0,15A (c'est ce que consomme mon boitier avec tout ses capteurs)
En gros, l'idée de départ ,si vous avez une peugeot récente, l'idée c'est l'équivalent de l'appli Mypeugeot , si nous ne connaissez pas, cette appli vous donne : kilométrage réalisé, consommation : moyenne générale, par trajet, kilométrage total, positionnement, logging des trajets.
Avoir ça sur une vielle guimbarde de 25 ans, j'ai trouvé ça marrant. je ne sais pas si en cas de vol ça pourrait servir ou pas. Ce n'était pas ma motivation première.
Tout fonctionne, sauf cette ligne de données binaire en fin de fichier et il ne me manque que la partie GSM
Je sais; certains vont me dire "il y a presque équivalent" avec AutoPi. Mais c'est plus drôle de le faire soit même et quand on le fait soit même, la seule limite aux fonctionnalités c'est l'imagination.
-
- Raspinaute
- Messages : 1587
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: Data Logger mais fichier mal écrit
A mon avis, tout ce que tu fais passerait sur un ESP32 (en plus, certains models comme le LilyPI viennent directement avec un lecteur SD et un écran ... sans doute trop petit pour mettre dans une voiture ).
Pour ton raspberry, je verrai comme solutions :
La Lipo est évidemment surdimentionnée, mais elle a comme avantage que certaines machine ont de PMU (genre le BananaPI) donc ils ont toute l'électronique pour chargé la dite batterie et t'envoie des interruptions lorsque l'Alim est mise sous tension ou coupé.
En clair, la seule chose qui te reste a faire ... c'est soudé la batterie
Pour ton raspberry, je verrai comme solutions :
- un supercondo pour qu'il tiennent encore quelques secondes
- une batterie lipo
La Lipo est évidemment surdimentionnée, mais elle a comme avantage que certaines machine ont de PMU (genre le BananaPI) donc ils ont toute l'électronique pour chargé la dite batterie et t'envoie des interruptions lorsque l'Alim est mise sous tension ou coupé.
En clair, la seule chose qui te reste a faire ... c'est soudé la batterie
Je confirme : c'est exactement ma philosophie
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
Re: Data Logger mais fichier mal écrit
Merci pour tes conseils.
Pour le cache, on ne peut désactiver que le cache disque
Reste le cache du contrôleur I/O, le cache de la RAM, le cache du CPU auxquels je n'ai pas accès.
Donc soit os.sync suffit, soit je passerai par un condo.
Etant modéliste, les batteries lipo, je connais : parfaites pour un modèle réduit. Au pire, si après un crash, la batterie enflamme tout, ce n'est pas grave (c'est du vécu).
Pour la détection d'arrêt je vois comment faire :
Le raspberry est alimenté par un mini transformateur qui sait transformer du courant entre 7V et 32V en 5V (la tension en sortie ne change pas même si celle en entrée change) . La chute de tension en entrée du transfo, je peux la mesurer par le raspberry via un INA219 en I2C. Si je passe en dessous de 12V (par exemple) c'est que je suis en extinction. A ce moment là, le côté 5V sera maintenu par le condo pendant quelques secondes et je déclencherai un shutdown -h now.
Je vais faire des mesures pour vérifier la faisabilité.
J'avais regardé l'ESP32. C'est chouette mais avec 512ko de SRAM, inutile de penser y mettre mon interface web en plus du reste. La mémoire vive serait insuffisante.
Mon boitier ne doit justement pas être visible, donc aucun besoin d'un écran LCD mais besoin de cette page web de consultation/paramétrage (y compris du SSID/mot de passe du wifi de la maison, arrêt, redémarrage des services, consultation des status des services, extinction propre, etc...).
Par contre le LilyPi un beau joujou qui me plait bien pour d'autres projets de passe-temps (genre mon ancien logger de concentration de gaz et de pression)
Pour le cache, on ne peut désactiver que le cache disque
Reste le cache du contrôleur I/O, le cache de la RAM, le cache du CPU auxquels je n'ai pas accès.
Donc soit os.sync suffit, soit je passerai par un condo.
Etant modéliste, les batteries lipo, je connais : parfaites pour un modèle réduit. Au pire, si après un crash, la batterie enflamme tout, ce n'est pas grave (c'est du vécu).
Pour la détection d'arrêt je vois comment faire :
Le raspberry est alimenté par un mini transformateur qui sait transformer du courant entre 7V et 32V en 5V (la tension en sortie ne change pas même si celle en entrée change) . La chute de tension en entrée du transfo, je peux la mesurer par le raspberry via un INA219 en I2C. Si je passe en dessous de 12V (par exemple) c'est que je suis en extinction. A ce moment là, le côté 5V sera maintenu par le condo pendant quelques secondes et je déclencherai un shutdown -h now.
Je vais faire des mesures pour vérifier la faisabilité.
J'avais regardé l'ESP32. C'est chouette mais avec 512ko de SRAM, inutile de penser y mettre mon interface web en plus du reste. La mémoire vive serait insuffisante.
Mon boitier ne doit justement pas être visible, donc aucun besoin d'un écran LCD mais besoin de cette page web de consultation/paramétrage (y compris du SSID/mot de passe du wifi de la maison, arrêt, redémarrage des services, consultation des status des services, extinction propre, etc...).
Par contre le LilyPi un beau joujou qui me plait bien pour d'autres projets de passe-temps (genre mon ancien logger de concentration de gaz et de pression)
3 Pi4 : Emby / Samba , Librelec, Android TV
3 Pi3 : Hifiberry /OSMC, Games station, Samba / VPN / HotSpot Wifi
2 Pi2 : RFID, radio reveil (PiReveil)
1 Pi0 : traker GPS et acquisitions
1 Pi0 2W : tests divers
5 Arduinos dont 4 nanos et 1 Mega
1 ESP32
3 Pi3 : Hifiberry /OSMC, Games station, Samba / VPN / HotSpot Wifi
2 Pi2 : RFID, radio reveil (PiReveil)
1 Pi0 : traker GPS et acquisitions
1 Pi0 2W : tests divers
5 Arduinos dont 4 nanos et 1 Mega
1 ESP32
-
- Raspinaute
- Messages : 1587
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: Data Logger mais fichier mal écrit
Ben tien nous au courant : projet intéressant.
Tu passes par l'ODB pour avoir les infos ?
Tu passes par l'ODB pour avoir les infos ?
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
- Flachy Joe
- Messages : 88
- Enregistré le : mar. 20 sept. 2016 22:30
Re: Data Logger mais fichier mal écrit
Salut,
pourquoi ne pas coupler RPi et Arduino ?
Sur l'Arduino juste la journalisation et un petit serveur sur la liaison série pour que le RPi puisse récupérer les infos.
Sur le RPi toute l'interface homme/machine.
Les plus :
pourquoi ne pas coupler RPi et Arduino ?
Sur l'Arduino juste la journalisation et un petit serveur sur la liaison série pour que le RPi puisse récupérer les infos.
Sur le RPi toute l'interface homme/machine.
Les plus :
- tu es assuré du fonctionnement "temps réel" de la journalisation.
- Ça fait un peu plus de matos
- Si tu as de données ne pouvant venir que du RPI il faudra les faire voyager dans la liaisons série elles aussi pour que tout soit stocké au même endroit. La synchronisation des deux sources sera sans doute compliquée.
Re: Data Logger mais fichier mal écrit
Bonjour,
Pour destroyedlolo : Oui, je passe entre autre par un ODB bluettoth
Sinon, au départ, je pensais tout faire en Arduino mais je me suis vite rendu compte que tout ce que je voulais y mettre ne rentrerai pas. Alors je suis parti sur le Raspberry.
Au départ, je n'imaginais pas ce problème de fichier mal écrit en extinction par coupure de courant, j'étais prêt à accepter un remplacement régulier de carte SD et j'ai mis toutes les chances de mon côté (pas de log système, pas de swap). La 1ère carte, je l'ai changé après plus d'un an. Et en plus, elle a gouté à de multiples réinstallations donc ça me va. La 2ième a plus d'un an et elle va bien.
Après avoir rencontré ces problèmes de fichiers de data mal écrits j'ai pensé à coupler Raspberry et Arduino.
Le truc c'est que je suis à l'aise en programmation, en câblage de composants mais pas du tout en réalisation de boitier pour y mettre tout ça.
Le boitier est ce qui m'a pris le plus la tête (le choisir, faire une patine de support des composants qui se glisse et se verrouille dedans.....), maintenant que j'en ai un qui me va bien (j'en ai même fait 3 autres qui sont actuellement vides), ça me saoule de tout revoir pour caser en plus un Arduino (même un nano : je n'ai plus de pace et mon câblage est devenu un vrai plat de spaghettis).
Sinon, bonne nouvelle , depuis la dernière fois :
Depuis que j'ai mis un os.sync(f) dans mon code, je n'ai plus rencontré de problème pour le moment ! (12 logs d'utilisations depuis la dernière fois, et tous les fichiers sont parfaits) pourvu que ça dure !
Pour destroyedlolo : Oui, je passe entre autre par un ODB bluettoth
Sinon, au départ, je pensais tout faire en Arduino mais je me suis vite rendu compte que tout ce que je voulais y mettre ne rentrerai pas. Alors je suis parti sur le Raspberry.
Au départ, je n'imaginais pas ce problème de fichier mal écrit en extinction par coupure de courant, j'étais prêt à accepter un remplacement régulier de carte SD et j'ai mis toutes les chances de mon côté (pas de log système, pas de swap). La 1ère carte, je l'ai changé après plus d'un an. Et en plus, elle a gouté à de multiples réinstallations donc ça me va. La 2ième a plus d'un an et elle va bien.
Après avoir rencontré ces problèmes de fichiers de data mal écrits j'ai pensé à coupler Raspberry et Arduino.
Le truc c'est que je suis à l'aise en programmation, en câblage de composants mais pas du tout en réalisation de boitier pour y mettre tout ça.
Le boitier est ce qui m'a pris le plus la tête (le choisir, faire une patine de support des composants qui se glisse et se verrouille dedans.....), maintenant que j'en ai un qui me va bien (j'en ai même fait 3 autres qui sont actuellement vides), ça me saoule de tout revoir pour caser en plus un Arduino (même un nano : je n'ai plus de pace et mon câblage est devenu un vrai plat de spaghettis).
Sinon, bonne nouvelle , depuis la dernière fois :
Depuis que j'ai mis un os.sync(f) dans mon code, je n'ai plus rencontré de problème pour le moment ! (12 logs d'utilisations depuis la dernière fois, et tous les fichiers sont parfaits) pourvu que ça dure !
3 Pi4 : Emby / Samba , Librelec, Android TV
3 Pi3 : Hifiberry /OSMC, Games station, Samba / VPN / HotSpot Wifi
2 Pi2 : RFID, radio reveil (PiReveil)
1 Pi0 : traker GPS et acquisitions
1 Pi0 2W : tests divers
5 Arduinos dont 4 nanos et 1 Mega
1 ESP32
3 Pi3 : Hifiberry /OSMC, Games station, Samba / VPN / HotSpot Wifi
2 Pi2 : RFID, radio reveil (PiReveil)
1 Pi0 : traker GPS et acquisitions
1 Pi0 2W : tests divers
5 Arduinos dont 4 nanos et 1 Mega
1 ESP32