Shell et suppression de ligne

bonjour

Je ne trouve pas de tuto sur le shell . Avec un script sh , 3 lignes sont écrites dans un fichier .

Code:

---

1 2	/home/pi/rspi/adafruit/Adafruit_DHT 11 4 >> /home/pi/rspi/adafruit/ht24_12.csv exit 0

---

Adafruit fournit >>> t=xx °C et ht=yy % sur la troisième ligne

1. Dans un premier temps , je veux ne garder que la troisième ligne
2. Dans un deuxième , reformater cette ligne avec 'date +%x:%X' +'xx'+'yy'

Pouvez vous donner conseils ?

@+

tail (éventuellement avec head si la sortie peut évoluer) ainsi que awk devraient t'aider.

Bonjour,

sed va faire ça; ce n'est pas très compliqué.
voir :
sed tutorials
sed - an Introduction

Citation:

---

Dans un premier temps , je veux ne garder que la troisième ligne

---

alors comment comptes-tu récupérer xx ?
il faut falloir améliorer/approfondir ton algorithme.

ok , c'est un début ..

Citation:

---

sed "1,10d" fichier : sortie du fichier à partir de la onzième ligne
sed "/^From/!d" fichier : On n'efface tout sauf les lignes commençant par From , donc on imprime les lignes commençant par From.

---

Dans mon cas , chaque exécution de Adafruit_DHT 11 4
sort 3 lignes qui partent dans un fichier .
Adafruit_DHT 11 4 >> /home/pi/rspi/adafruit/ht24_12.csv

Je veux formater avant écriture dans le fichier pour placer
ensuite un cron horaire .

Citation:

---

Using pin #4
Data (40): 0x22 0x0 0x18 0x0 0x3a
Temp = 24 *C, Hum = 34 %

---

Dans le fichier , je ne veux que 3 champs ( date ; xx ; yy ) en csv
exportable via sql ( 24 lignes horaires ) .

Je peux aussi laisser tel quel et formater les 24x3 ( 72 lignes )
après les 24 cron .

Bonjour,

Pour ma part, je n'ai rien compris de ton problème.
c'est quoi dans ton input le date, le xx, le yy ?

A priori, tu nous as donné l'input à filtrer, pourrais-tu nous donner l'output final de cet input que l'on comprenne mieux ?

Après, on pourra peut-être t'aider...

Je peux aussi laisser tel quel et formater les 24x3 ( 72 lignes )
après les 24 cron .

C'est très facile avec python :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#!/usr/bin/python # -*- coding: utf-8 -*-     import time import os import sys   os.system('clear') ofi = open('dh25_12.csv') t = ofi.read() # ------------------------------------------ i=90*0 j=i+72 k=j+13 print(t[i:i+17]+';'+t[j:j+2]+';'+t[k:k+2]) # ------------------------------------------ i=90*1 ...

---

Ce qui donne :

25/12/14 -- 19:00;23;51
25/12/14 -- 19:30;23;49
25/12/14 -- 20:00;23;48
...

:? et tu recopies 24 fois la même séquence de code ?
de plus :

Code:

---

1 2 3 4 5 6 7 8

$ cat dh25_12.csv Using pin #4 Data (40): 0x22 0x0 0x18 0x0 0x3a Temp = 24 *C, Hum = 34 % $ ./test.py Using pin #4 Data;; $

---

:koi:

Hé ! C'est pas moi qui recopie ..
C'est le cron qui ajoute les data dans le fichier

je ne parle pas des données :

Code:

---

1 2 3

Using pin #4 Data (40): 0x22 0x0 0x18 0x0 0x3a Temp = 24 *C, Hum = 34 %

---

mais de la séquence de code :

Code:

---

1 2 3 4 5 6 7 8

# ------------------------------------------ i=90*0 j=i+72 k=j+13 print(t[i:i+17]+';'+t[j:j+2]+';'+t[k:k+2]) # ------------------------------------------ i=90*1 ...

---

qui, en l'occurrence, ne donne pas le résultat que tu présentes :

Code:

---

1 2 3

25/12/14 -- 19:00;23;51 25/12/14 -- 19:30;23;49 25/12/14 -- 20:00;23;48

---

25/12/14 -- 19:00

Citation:

---

Using pin #4
Data (40): 0x22 0x0 0x18 0x0 0x3a
Temp = 24 *C, Hum = 34 %

---

25/12/14 -- 19:30

Citation:

---

Using pin #4
Data (40): 0x22 0x0 0x18 0x0 0x3

---

Pour l'instant je traite les retours capteurs à la main .
Vu que la ligne de data peut sortir moins de caractère que prévu .
Et aussi aucune data Temp / Hum .

Pourquoi cette perte de data ?
Si c'était prévisible , je n'irai pas sur des forums , vu que le théorique
n'est pas bien difficile à comprendre .

:koi: tu fais exprès de ne pas répondre à mes interrogations ?

j'ai l'impression de demander mon chemin, et qu'on me donne l'heure :?

pour nous informer de l'état d'avancement de ton projet, de tes questionnements à son propos, il y a ton blog !

pour les questions et échanges techniques précis, nous sommes ici.

Un script shell doit afficher au moins 1 ligne :
Temp = xx *C, Hum = yy %

Faut pouvoir vérifier à la volée si entre :

Temp = et *C il y a xx
Hum = et % il y a yy

Si oui , valider l'heure avec date + xx + yy dans un fichier
C'est cette vérification , qui est la réponse de ce post

Si non le capteur ne réponds pas , et rien écrire dans le fichier
Je ne peux pas donner la solution vu que je ne l'ai pas

et la date, on la trouve où ? parce qu'on va parcourir le fichier CSV à un temps T qui ne correspondra pas forcément au temps auquel les données ont été inscrites dans le fichier.

on reprend :
tu as une commande (/home/pi/rspi/adafruit/Adafruit_DHT 11 4), qui ajoute (>>) des données dans un fichier (/home/pi/rspi/adafruit/ht24_12.csv)

ce fichier CSV (qui n'est d'ailleurs pas au format csv) peut contenir des lignes telles que :

Code:

---

1 2 3 4 5

Using pin #4 Data (40): 0x22 0x0 0x18 0x0 0x3a Temp = 24 *C, Hum = 34 % Using pin #4 Data (40): 0x22 0x0 0x18 0x0 0x3

---

tu veux récupérer les lignes qui commencent par Temp si il y a des données numériques.

c'est ça ?

Pµµµ, sois précis !
et «je ne trouve pas de tutos» :evil: il y en a quelques uns dans ma signature.

Je connais mieux python que le bash , et j'ai posé la question .
Ensuite des problèmes inattendus sont arrivés et je vois ce que je peux faire avec python .

[Résolu]

La solution py :

Vérifier si temp et hum sont dans les 2 ou 3 lignes du capteur
Après afficher l'heure quand la condition est True
Filtrer ensuite xx ,yy , date
Quand temp et hum sont False , passer à la ligne suivante

Un synoptique qui fait le tri , avec un capteur DH (humidité)
qui a des retards à l'allumage :

Pièce jointe 165013

C'est toujours incompréhensible...

On n'a pas les données d'entrées à traiter.
Le synoptique n'est pas claire, on dirait que tu exécutes les fichiers txt qui vont sortir le fichier csv.

Mais à priori, c'est résolu...

Pour un futur problème, essaye de donner des explications comme tu le ferais à ta boulangère (en espérant que ce n'est pas ta femme :) ).

Bonnes et joyeuses fêtes de fin d'année

ah, c'est sûr que vu comme ça, ça va être cahotiqueeux !

le script .py devrait être exécuté par le script .sh, mais
le script .py n'aurait aucune utilité si le script .sh appelait le DH jusqu'à obtention d'une ligne correcte (on pourrait ajouter la contrainte d'un certain nombre de tentatives).
le fichier .txt serait alors inutile (de toutes façons, les fichiers temporaires ça craint) : on écrirait directement au format CSV.

à ta place, j'aurais tenté de modifier le script python, développé par le fabricant, qui se charge d'interroger ton appareil, pour y ajouter la validation des données, et la redirection au format CSV dans un fichier.

Citation:

---

Envoyé par disedorgue

Pour un futur problème, essaye de donner des explications comme tu le ferais à ta boulangère

---

:koi:
à ma boulangère, je demande une baguette, si elle ne comprend pas, je change de boulangerie !

edit: ah, j'ai compris ! comme si je lui exposais un problème algorithmique ! :mur:

Citation:

---

le script python, développé par le fabricant

---

C'est du C . Maintenant que les data sont collectées et sans accro , pour implémenter une bdd , je peux
tenter des transformations du script C fabricant .

Si il y a des conventions pour un synoptique , je veux bien quelques liens
de référence pour obtenir un schéma standardisé ..

mouais :( un truc qui s'appelle machin_python_truc est devenu du C, mais a gardé le même nom :aie: : erreur de jeunesse du fabricant.

Citation:

---

pour obtenir un schéma standardisé

---

il y a UML, et Merise, au moins.

à synoptique, je préfère l'expression arbre de décisions, qui met l'accent sur les opérations qui doivent être réalisées, et sous-tendant que les données en sont des arguments.

Citation:

---

à synoptique, je préfère l'expression arbre de décisions, qui met l'accent sur les opérations qui doivent être réalisées, et sous-tendant que les données en sont des arguments.

---

Et cela ressemble à quoi ?

à la même chose, ce n'est pas l'aspect, c'est la démarche qui change.

si je pense à faire un tableau synoptique, je pense à gribouiller un schéma.
quand je pense à réaliser un arbre décisions, je ne prends en compte que les opérations; et je prends soin à leur relations, aux conditions, aux alternatives...
je dessine mon programme.

les standards sont là pour que les intervenants aient un socle commun, et éviter les malentendus.
pour ton projet personnel, tu peux choisir les conventions que tu veux, pourvu qu'elles restent cohérentes tout au long du cheminement : ne dessine pas un losange pour définir une chose au début, pour en faire un cercle à la fin. :aie:

Les arbres de décisions s'est surtout pour gérer :
- les utilisateurs
- les groupes
- les versions de projet
- améliorer des process en agissant sur les goulots d’étranglement

.. c'est vaste

quand «c'est vaste», ça ne peut pas être «surtout», mais effectivement, les domaines d'applications sont nombreux et variés, alors que le principe est identique.

surtout: adverbe
Sens: Particulièrement, principalement

oui, j'ai bien compris : le particulier s'oppose à la multitude !

ne cherche pas à compliquer les choses, tu n'en paraîtras pas plus glorieux.
en tous cas pas d'un point de vue `*n?xien', ici, c'est "KISS" («keep it simple stupid!»).

Le simple est le capteur qui donne direct le bon signal .
Quand il est cassé , un remplaçant est déjà là .