search

RaspbianFrance / raspisms

RaspiSMS est un système de gestion et d'envoi de SMS par ordinateur, initialement conçu pour les Raspberry Pi
https://raspisms.fr
GNU General Public License v3.0
164 stars 70 forks source link

Inclure la gestion des accusés de récéption #15

Closed memento closed 9 years ago

memento commented 9 years ago

Bonjour Messieurs,

Merci de votre travail sur ce projet. Je résume ici mes échanges par mail avec un membre de votre équipe sous forme d'une proposition d'amélioration. Il devrait être possible de gérer les accusés de réception au sein du projet. gammu-smsd-monitor permet de gérer le statut des SMS envoyés.

Je cite la page d'information de Gammu :

The package includes also tool gammu-smsd-inject which will help you creating long text messages and gammu-smsd-monitor which allows you to monitor current status of SMS Daemon or phone.

Après quelques recherches, j'ai communiqué un début de piste prometteur via mail :

Dans RaspiSMS\controllers\internalConsole.php, en remplaçant la ligne 137 :

$commande_send_sms = 'gammu-smsd-inject TEXT ' . escapeshellarg($number) . ' -len ' . mb_strlen($text_sms) . ' -text ' . $text_sms;

par :

$commande_send_sms = 'gammu-smsd-inject TEXT ' . escapeshellarg($number) . ' -len ' . mb_strlen($text_sms) . ' -text ' . $text_sms . ' -report ';

C'est à dire, en ajoutant -report à la fin de la commande gammu-smsd-inject, on active la fonction accusé de réception. Pour information, on peut également ajouter -validity ( source pour les deux options )

Extrait man gammu

Note : Évidemment, cette modification du contrôleur n'est pas propre et il faudra que je continue à analyser le code et votre implémentation du MVC ( Cf. votre doc ) pour voir comment penser et inclure la possibilité de se servir des accusés de réception mais ça ne me semble pas trop complexe à faire. il faut savoir aussi que l'accusé de réception arrive comme un sms normal avec pour texte "Delivered" (par exemple, si le message est reçu) et comme numéro d'émetteur, le numéro du destinataire du SMS que l'on vient d'envoyer. Il va falloir réfléchir pour lier chaque accusé à son SMS (un accusé par portion de 160 caractères envoyés), sûrement supprimer directement cet accusé de réception pour éviter de polluer la boîte de réception. Si les sms ont une table à eux dans la base de données, le mieux serait peut-être d'ajouter une table accuse_de_reception (ou quelque chose du genre) avec en clef étrangère l'id du sms et de faire une jointure. Ensuite il faudrait colorer en jaune les sms envoyés avec accusés qui n'ont toujours pas été confirmés, en rouge les sms qui ont été envoyés avec accusé mais dont la durée de validité a été dépassée (même démarche pour la validité qui peut apporter un plus ) et bien sûr, les sms en vert seront ceux qui ont reçu un accusé (tout ceci n'est qu'une proposition, on peut très bien représenter l'information autrement).

Bien entendu, un simple ajout dans le formulaire d'envoi de SMS (cases à cocher) permettra de préciser si oui ou non on veut un accusé de réception et/ou une durée de validité pour le SMS au delà de laquelle le SMS sera considéré comme perdu.

Note : Il me faut aussi déterminer deux choses (si vous avez de infos, n'hésitez pas) :

Ps : Je suis prêt à mettre les mains dans le cambouis.

Bien à vous, Alexandre

RaspbianFrance commented 9 years ago

Salut, merci de ton retour ! Pour la gestion en base, je pense que le mieux est de simplement rajouter un champs "status" à la base "sendeds". Je présume qu'il existe un moyen de lié un SMS à son accusé avec un système d'ID, ce qui implique probablement une petite modification de la base pour enregistrer cet ID, et donc une modification de parseSMS.sh pour le transmettre.

Je pense que la gestion devrait se faire en PHP afin de garder le système le plus unifié possible !

Cordialement, Raspbian France

Le 22 juillet 2015 11:44, memento notifications@github.com a écrit :

Bonjour Messieurs,

Merci de votre travail sur ce projet. Je résume ici mes échanges par mail sous forme d'un proposition d'amélioration. Il devrait être possible de gérer les accusés de réception au sein du projet. gammu-smsd-monitor permet de gérer le statut des SMS envoyés.

Je cite la page d'information de Gammu :

The package includes also tool gammu-smsd-inject which will help you creating long text messages and gammu-smsd-monitor which allows you to monitor current status of SMS Daemon or phone.

Après quelques recherches, j'ai communiqué un début de piste prometteur via mail :

Dans RaspiSMS\controllers\internalConsole.php, en remplaçant la ligne 137 :

$commande_send_sms = 'gammu-smsd-inject TEXT ' . escapeshellarg($number) . ' -len ' . mb_strlen($text_sms) . ' -text ' . $text_sms;

par :

$commande_send_sms = 'gammu-smsd-inject TEXT ' . escapeshellarg($number) . ' -len ' . mb_strlen($text_sms) . ' -text ' . $text_sms . ' -report ';

C'est à dire, en ajoutant -report à la fin de la commande gammu-smsd-inject, on active la fonction accusé de réception. Pour information, on peut également ajouter -validity ( source pour les deux options http://www.guiguishow.info/2012/11/29/envoyer-des-sms-automatiquement-a-une-date-definie/ )

Extrait man gammu

-

report

  • request delivery report for message

  • validity HOUR|6HOURS|DAY|3DAYS|WEEK|MAX

  • sets how long will be the message valid (SMSC will the discard the message after this time if it could not deliver it).

Note : Évidemment, cette modification du contrôleur n'est pas propre et il faudra que je continue à analyser le code et votre implémentation du MVC ( Cf. votre doc http://raspisms.raspbian-france.fr/documentation/ ) pour voir comment penser et inclure la possibilité de se servir des accusés de réception mais ça ne me semble pas trop complexe à faire. il faut savoir aussi que l'accusé de réception arrive comme un sms normal avec pour texte "Delivered" (par exemple, si le message est reçu) et comme numéro d'émetteur, le numéro du destinataire du SMS que l'on vient d'envoyer. Il va falloir réfléchir pour lier chaque accusé à son SMS (un accusé par portion de 160 caractères envoyés), sûrement supprimer directement cet accusé de réception pour éviter de polluer la boîte de réception. Si les sms ont une table à eux dans la base de données, le mieux serait peut-être d'ajouter une table accuse_de_reception (ou quelque chose du genre) avec en clef étrangère l'id du sms et de faire une jointure. Ensuite il faudrait colorer en jaune les sms envoyés avec accusés qui n'ont toujours pas été confirmés, en rouge les sms qui ont été envoyés avec accusé mais dont la durée de validité a été dépassée (même démarche pour la validité qui peut apporter un plus ) et bien sûr, les sms en vert seront ceux qui ont reçu un accusé (tout ceci n'est qu'une proposition, on peut très bien représenter l'information autrement).

Bien entendu, un simple ajout dans le formulaire d'envoi de SMS (cases à cocher) permettra de préciser si oui ou non on veut un accusé de réception et/ou une durée de validité pour le SMS au delà de laquelle le SMS sera considéré comme perdu.

Note : Il me faut aussi déterminer deux choses (si vous avez de infos, n'hésitez pas) :

-

Pour chaque statut de message (accusé), il faut déterminé quel est le texte retourné. Par exemple,

  • Delivered : Message reçu
    • ...

  • Il me faudrait savoir à quoi ressemble un sms reçu (juste avant qu'il soit passé à la moulinette par le fichier parseSMS.sh), parseSMS.sh étant à l'interface entre Gammu et RaspiSMS. La réponse à cette question déterminera si la gestion des acusés doit commencer dans le code php de RaspiSMS ou plus en amont dans parseSMS.sh. On pourrait aussi avoir une réponse quant au problème de lier chaque accusé à chaque sms précédemment envoyé (numéro de "série" ou id du SMS ? timestamp ?).

Ps : Je suis prêt à mettre les mains dans le cambouis.

Bien à vous, Alexandre

— Reply to this email directly or view it on GitHub https://github.com/RaspbianFrance/RaspiSMS/issues/15.

memento commented 9 years ago

Salut,

Pour la gestion en base, je pense que le mieux est de simplement rajouter un champs "status" à la base "sendeds".

Ok, encore plus simple.

Je présume qu'il existe un moyen de lié un SMS à son accusé avec un système d'ID, ce qui implique probablement une petite modification de la base pour enregistrer cet ID, et donc une modification de parseSMS.sh pour le transmettre.

Je pense qu'il est très probable que le SMS envoyé se fasse attribuer un id ou un timestamp par gammu. Je parle de gammu car c'est bien lui qui doit aussi associer l'accusé de réception à un id/timestamp de message envoyé. Là encore, il faut d'une part savoir de quoi est constitué le sms qui est parsé par parseSMS.sh au moment de la récéption de l'accusé et d'autre part, qu'au moment de l'envoi, on ait récupéré l'id/timestamp du message envoyé.

Est-ce que l'équipe a eu accès à une doc expliquant la syntaxe originale des SMS pour pouvoir écrire le parseSMS.sh ? ça serait génial si je pouvais même la main dessus.

En attendant, si je trouve quelque chose s'en approchant, je le posterai dans ce fil.

Bien à vous, Alexandre.

RaspbianFrance commented 9 years ago

Salut, pour la rédaction de parseSMS nous avions utilisé la documentation de gammu disponible en ligne, c'est tout...

Le 22 juillet 2015 13:22, memento notifications@github.com a écrit :

Salut,

Pour la gestion en base, je pense que le mieux est de simplement rajouter un champs "status" à la base "sendeds". Ok, encore plus simple.

Je présume qu'il existe un moyen de lié un SMS à son accusé avec un système d'ID, ce qui implique probablement une petite modification de la base pour enregistrer cet ID, et donc une modification de parseSMS.sh pour le transmettre. Je pense qu'il est très probable que le SMS envoyé se fasse attribuer un id ou un timestamp par gammu. Je parle de gammu car c'est bien lui qui doit aussi associer l'accusé de réception à un id/timestamp de message envoyé. Là encore, il faut d'une part savoir de quoi est constitué le sms qui est parsé par parseSMS.sh au moment de la récéption de l'accusé et d'autre part, qu'au moment de l'envoi, on ait récupéré l'id/timestamp du message envoyé.

Est-ce que l'équipe a eu accès à une doc expliquant la syntaxe originale des SMS pour pouvoir écrire le parseSMS.sh ? ça serait génial si je pouvais même la main dessus.

En attendant, si je trouve quelque chose s'en approchant, je le posterai dans ce fil.

Bien à vous, Alexandre.

— Reply to this email directly or view it on GitHub https://github.com/RaspbianFrance/RaspiSMS/issues/15#issuecomment-123674823 .

memento commented 9 years ago

Salut, Effectivement, la page est ici.

memento commented 9 years ago

Pour information, concernant le type de SMS reçu (message ou accusé)

La classe du SMS nous informe de la nature de ce dernier Pour tester, on peut modifier le script parseSMS.sh comme suit

#!/bin/sh
date=$(date +%Y%m%d%H%M%S%N)
first_time=1
echo "---" >> /var/www/original.txt
echo "SMS_MESSAGES : $SMS_MESSAGES" >> /var/www/original.txt
for i in `seq $SMS_MESSAGES` ; do
    eval "sms_number=\"\${SMS_${i}_NUMBER}\""
    eval "sms_text=\"\${SMS_${i}_TEXT}\""
    eval "sms_class=\"\${SMS_${i}_CLASS}\""
    echo "Sms_Class : $sms_class" >> /var/www/original.txt
    if [ $first_time -eq 1 ]
    then
        sms="$sms_number:"
        first_time=0
    fi
    sms="$sms$sms_text"
done
echo "$sms" >> /var/www/RaspiSMS/receiveds/"$date".txt

Le fichier original.txt aura la forme :

SMS_MESSAGES : < nombre de sms de 160 caractères > Sms_Class : < classe du sms (son type) >

Résultat, lorsque l'on reçoit un sms classique, on a :

SMS_MESSAGES : 1 Sms_Class : -1

Lorsque l'on reçoit un accusé de réception (Delivered), on a :

SMS_MESSAGES : 1 Sms_Class : 0

Lorsque l'on reçoit un accusé d'echec (Failed), on a :

SMS_MESSAGES : 1 Sms_Class : 0

On n'a pas d'autre info, apparemment mais on peut en déduire que quelque soit le type d'accusé, on peut le détecter comme tel et faire le tri entre les accusés et les SMS avec la valeur de la classe (0 ou -1). ça va nous aider !

Bien à vous, Alexandre.