Archives pour la catégorie PYTHON

send_smsd ou comment un script devient un daemon

L’envoi de sms pfffff … yaka cliquer !

C’est presque vrai. Mais dès que l’on veut que cela soit fais correctement et proprement cela devient moins simple.

Comme je le disais dans cette précedente page de mon blog. mettre en place un modem GSM c’est facile.

Les scripts d’exemples permettent de rapidement comprendre comment cela fonctionnent, python à d’excellente librairie pour communiquer avec des liaisons série bref que de bonheur.

Non c’est après que viennent ces petites choses qui agacent.

D’abord, une liaison série c’est pas multi-tàche : et pourtant j’en ai bouffé de cette @!$% de liaison RS232 au siècle dernier, mais non avec une liaison série on ne communique qu’avec une seule connexion à la fois.

Comme quoi certain réflexe s’émoussent avec le temps, et comme il est normal que certaines technos disparaissent 🙂

Donc un script qui ouvrent la liaison série pour envoyer les commandes AT, tout seul il marchent, si plusieurs SMS doivent être envoyés et ben il faut le gérer.

Allons y c’est pas sorcier non plus, après tout ne n’ai que 5 SMS à envoyer, on fait un plus gros scripts avec des sleep entre chaque envois, cela marche … presque. En fonction des opérateurs et si votre correspondant est sur le même continent ou non le temps d’envoi est TRES variable.

D’une solution passable, on passe à un solution plus que moyenne bref cela ne me convenait pas du tout.

Et donc naturellement l’idée d’utiliser un fichier FIFO m’est venu. Et donc l’esquisse d’un serveur d’envoi de SMS commençait à poindre le bout de son nez.

Allons y :

un script en shell pour envoyer les infos dans le fifo, ce qu’il y a de bien dans les SMS c’est que c’est court et que cela tient dans une ligne 🙂

un script qui scrutent continuellement le fifo ligne par ligne et qui effectue l’envoi, une ligne = 1 SMS.

Simple, pas tant que cela. Car si pour un raison ou une autre un SMS ne passe pas il faut réessayer un certain nombre de fois avant d’abandonner.

Oui d’accord mais la lecture du fifo est bloquante. Je ne vais pas attendre les n tentatives  pour envoyer les suivants, ou je ne vais pas attendre le prochain SMS pour envoyer ceux qui sont en attente.

faire une boucle qui lit de manière non bloquante le fifo, vérifier que la liste des sms en attente est vide sinon on repart pour un tour.

Heureusement, la communauté python regorge de ressources et d’exemples et après quelques essais la solution est apparu auréolé de lumière quasi divine …

Bref vous trouverez le code complet ici, il n’y a pas encore de procédure d’installation automatique mais bon cela tient en 3 fichiers.

send_sms : le shellscript qui dépose le numéro et le message dans le fifo

send_smsd : le daemon qui lit le fifo et envoi les commandes AT sur le modem (faire un lien avec send_smsd.py)

send_smsd.conf : à configurer en fonction de vos besoins (seul le chapitre MAIN est utilisé, l’autre c’est de la déco)

send_smsd.service : le script init.d spécial SUSE (désolé mais la VM qui en avait besoin était sous SUSE)

Même si je l’utilise en exploitation, je ne le considère pas comme finalisé il reste encore beaucoup de choses à faire. (un seul modem de géré, pas franchement objet etc …)

Mais je me suis bien amusé et cela marche 🙂

A+

chris

Le capteur de température

Image

Voici les entrailles de la bête.

A gauche l’écran LCD, à droite le rasperry avec par dessus son « shield de prototypage ».

4 connexions donc sur ce rasperry :

  • En haut l’alimentation via le port micro usb prévu à cet effet
  • L’écran LCD qui se connect sur le port I2C du rasperry (en jaune et rouge)
  • Le capteur de température qui est un dallas DS18B20 1wire
  • Le réseau

Tout ça pour connecter un bête composant comme le DS18B20 ?

Oui et j’assume, plusieurs raisons, l’écran affiche alternativement l’heure et la température ainsi chaque fois que je descend dans la salle je peu vérifier que cela fonctionne.

Cela permet aussi de justifier le budget pour les non initiés 🙂

Le shield de prototypage est très pratique car cela  permet de visser les connexions, ne sait on jamais peut être qu’il y aura des extensions 🙂

Le matériel provient de chez MCHobby que je soutiens à 100%, ne vous arrêtez pas à la boutique et parcourez le wiki et le blog.

Vous trouverez une vrai mine de renseignements et de tutoriels traduits en français mais surtout commenté ET corrigé. Chaque produit de la boutique le nécessitant est accompagné des liens et tutos du fabricant et aussi quand c’est nécessaire des tutos et notice de montage en image faite par Mr Dominique Meurisse le responsable de ce site.

Je vous conseille la lecture de cet_article   l’a propos du wiki.

Le composant principal : le Dallas DS18B20

Pour la connexion du composant DS18B20 j’ai suivi cet excellent tutoriel   qui en plus me fait dire que j’ai encore beaucoup de choses à apprendre pour faire de joli blog.

Par contre j’ai nettement modifié le code fourni en exemple. En effet parfois le capteur renvoi des valeurs incohérentes style -0.625 de manière un peu aléatoire. C’est pour cette raison et suivant l’avis de quelques moules expérimentées que le script effectue 10 lectures, les tri supprime les 2 premières et les 2 dernières et transmets la moyenne des 6 autres.

Attention : si comme moi vous voulez utiliser ce script avec zabbix vous devez impérativement modifier la valeurs Timeout à 20 ou 30 secondes, sur le serveur ET l’agent.

Le temps de réponse du script est d’environ 8 à 10 secondes sur un rasperry pas du tout optimisé.

Il aurait été plus judicieux d’effectuer les prélèvements « brutes » (une seule lecture) cela dure moins de 3 secondes (valeur par défaut du Timeout Zabbix) et de trouver le bon paramétrage coté Zabbix. Si je trouve je ne manquerais pas d’en parler sur ce blog 🙂

Un dernier truc : au départ j’avais prévu de connecter 2 capteurs d’où la possibilité d’appeller des devices dans le script.

Voici le code actuellement en exploitation :

get_temp2.py  Note : je ne mets plus de code sous WordPress car sournoisement il le tronque.

Voici le schéma de connexion :

SCHEMA CONNEXION

J’aurais bien aimé utiliser Fritzing mais j’ai pas trouvé tout les composants

Sinon voici les connexions :

Pour l’écran :

les bornes 2 – 5V / 3 – SDA / 5 – SCL / 6 – GND sur les mêmes bornes que l’écran LCD

Pour le capteur DS18B20

Le port GPIO #4 (borne 7) sur la borne DATA du DS18B20 (pin 2)

La borne  17 donne 3.3 V à connecter sur la borne VDD du DS18B20 (pin 3)

La borne 25 – GND à connecter sur la borne GND du DS18B20 (pin 1)

Il faut aussi relier une résistance de 4.7 K Ohms entre 2 et 3 (data + VDD) du DS18B20

Rien de très compliqué en fait.

Le shield de prototypage se révèle pratique pour visser les câbles.

L’écran LCD

OK c’est plus pour le fun et pour apprendre, normalement il devrait se connecter directement sur le raspberry mais cela ne m’arrangeait pas. Aussi il à fallut faire une rallonge.

L’écran connecté il faut régler le potentiomètre sinon cela ne fonctionne pas

Pour le montage de celui ci il suffit de suivre les tutos, rien de compliqué non plus.

il faut un peu de code pour que cela fonctionne dont voici celui en exploitation : cmd_LCD.py

NOTE : Impossible de mettre du code propre dans worldpress 😦 il me sucre des portions entières …

il permet d’afficher une couleur différente part tranche de température et j’avais commencé à gérer les boutons directement sur l’écran, mais rien de concret.

En gros il utilise le get_temp pour récupérer la température ambiante et en fonction change de couleur. Pour indiquer que le raspberry est toujours vivant j’alterne l’affichage de la date/heure et de la température.

Ce code est une utilisation de la librairie et des exemples fournis par Adafruit

Si j’ai le temps un jour je modifierai ce script pour que l’on puisse rebooter le raspberry depuis les 5 touches (qui ne sont pas accessible dans le découpage actuel de la boîte).

En fait cette partie a été très simple, même si j’ai galéré pour trouver une boîte et des connecteurs.

En fait en électronique, comme dans beaucoup de choses, il faut savoir rester simple.