Atelier 1 : Mise en oeuvre du fonctionnement de capteurs sur la carte RaspberryPI

Posté le 10/06/2016

    Dans cet article, nous énumèrerons les principales étapes de brochage de nos capteurs avec toute la configuration de la Raspberry Pi2, pour nous concentrer, par la suite, sur le suivi et l'affichage de la température via Munin. Nous conclurons avec la conception de notre environnement d'entrée. 

    Matériel Nécessaire

         Raspberry

         Res 1m8 0 6w

         Learn arduino breadboard half

         21035 dscn3810

    Montage électrique

    Nous allons ici monter nos capteurs. 2 sortes de capteurs ont été choisis :

    1- Brochage du 1er Capteur : DS18B20

         Ds18b20 dallas

    Description :

    Le capteur DS18B20 est un capteur de température 1-wire simple d'utilisation avec le Raspberry Pi. Ce type de capteur 1-wire peut être alimenté de 2 manières : soit en alimentant une des pattes à 3.3V ou bien en laissant le composant charger un condensateur avec les parasites ambiants et utilisant la charge de ce condensateur pour effectuer une mesure.

    La 2ème méthode a l'avantage de nécessiter un câble de moins dans l'installation mais il est possible qu'il faille être un peu plus patient pour effectuer des lectures de température (quelques secondes pour charger le condensateur selon le niveau des parasites).

    Montage électrique :

    Nous alimenterons directement le composant en 3.3V. Nous allons donc simplement connecter :

    Nous ajouterons, par la suite, la résistance de 4.7KOhms en parallèle avec la sonde i.e. entre l'alimentation 3.3V et la ligne de lecture.

                                                 Connextion Raspberry Pi2 avec le DS18B20

    NB : Attention à ne pas inverser la masse et l'alimentation. Cela pourrait endommager le composant.

    Nous pourrons nous référer à cette documentation en cas de doute : http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf.

    2- Brochage de 2ème Capteur : AM2302

         Am2302

    Description :

    L'AM2302 est un capteur de température et d'humidité à faible coût. Il utilise un capteur d'humidité capacitif et une thermistance pour mesurer l'air ambiant. Très simple à utiliser, mais nécessite une synchronisation délicate pour la saisie des données.

    Par rapport à la DHT11, ce capteur est plus précis et fonctionne sur une plus grande gamme de température/humidité.

    Important : Nous allons ajouter à notre matériel un Bridge ArduinoToRaspberry, ci-après une documentation détaillée sur ce bridge : https://www.cooking-hacks.com/documentation/tutorials/raspberry-pi-to-arduino-shields-connection-bridge/

    Montage électrique :

    3 fils à connecter : le rouge à l'alimentation 3-5V, le jaune ou vert à la broche d'entrée de données et le noir à la masse.

              Brochage AM2302 vs Bridge

    Paramétrer la Raspberry PI2

    Nous pouvons alors brancher le Pi, se connecter en SSH et charger les modules nécessaires à la lecture des GPIO :

    modprobe w1-gpio
    modprobe w1-therm
    

    Il faut aussi modifier le fichier /boot/config.txt et ajouter cette ligne :

    dtoverlay=w1-gpio
    

    Pour ne pas avoir à les charger à nouveau à chaque re-démarrage du Pi, nous ajouterons les 2 lignes suivantes au fichier /etc/modules :

    w1-gpio
    w1-therm
    

    NB : si vous prévoyez plus de 10 capteurs, il est possible qu'il faille ajouter un fichier wire.conf dans /etc/modprobe.d avec ce contenu :

    options wire max_slave_count=50
    

    Si tout fonctionne, on doit alors voir un dossier du nom de la sonde apparaître dans le dossier /sys/bus/w1/devices :

    cd /sys/bus/w1/devices
    ls
    >> 28-000005330085 w1_bus_master1
    

    Si le numéro 28 apparaît, cela signifie que tout est correct. En effet, "28-000005330085'' est le nom du capteur installé.

    Si nous avions plusieurs capteurs  sur le bus, nous verrions un dossier avec un nom unique pour chaque capteur.

    En entrant dans le dossier, nous accèdons aux différentes valeurs retournées par le capteur : le fichier w1_slave contient la température sur la 2ème ligne en millièmes de degré Celsius :

    4c 01 4b 46 7f ff 04 10 f5 : crc=f5 YES
    4c 01 4b 46 7f ff 04 10 f5 t=20750
    
    

    La petite ligne bash suivante extrait alors la température en °C :

    cat /sys/bus/w1/devices/28-000005330085/w1_slave | grep "t=" | awk -F "t=" '{print $2/1000}'
    >> 20.75
    
    

    Relever la température avec Munin

    Munin est un logiciel utilisé par le adminsys pour suivre les variables vitales de serveurs. Mais l'outil peut également être utilisé pour suivre n'importe quelle variable accessible sur un ordinateur, telle que la valeur de la température relevée par notre capteur.

    Nous ne détaillerons pas ici le paramétrage du serveur Munin (qui récolte régulièrement les données des clients, génère les graphes et les rend disponibles au travers d'un serveur http) mais seulement celui du client Munin.

    Nous installerons un client (noeud dans le vocabulaire de Munin) sur le Pi avec cette commande :

    aptitude install munin-node
    

    Le noeud/client munin fonctionne en récoltant les variables de scripts stockés dans /etc/munin/plugins : par défaut les plugins seront des liens relatifs vers les scripts disponibles dans /usr/share/munin/plugins/. Si vous ne souhaitez suivre aucune variable vitale du Pi, il vous est possible de supprimer tous les liens dans /etc/munin/plugins (si vous souhaitez revenir à l'état initial, il vous suffira de les reprendre depuis /usr/share/munin/plugins).

    Nous allons donc créer un nouveau script Munin pour collecter la température. Les scripts Munin sont simples - ils comprennent 2 parties : une partie qui décrit le graphique (et les éventuelles options graphiques que l'on souhaite voir appliquées) et une seconde partie imprime chaque variable et sa valeur sur chaque ligne. Par exemple, le script "memory" de Munin retourne les valeurs suivantes :

    slab.value 8949760
    swap_cache.value 0
    page_tables.value 638976
    vmalloc_used.value 954368
    apps.value 21979136
    free.value 291938304
    buffers.value 35708928
    cached.value 99397632
    swap.value 0
    committed.value 51347456
    mapped.value 6803456
    active.value 64913408
    inactive.value 85291008

    Nous allons donc générer un script qui imprime la valeur de notre sonde de la même façon dans /etc/munin/plugins

    nano temperature_1
    

    et voici le contenu du script :

    #!/bin/sh
    
    case $1 in
       config)
            cat <<'EOM'
    graph_title Temperature probe 1
    graph_vlabel temperature_1
    temperature_1.label temperature_1
    EOM
            exit 0;;
    esac
    
    printf "temperature_1.value "
    cat /sys/bus/w1/devices/28-000005330085/w1_slave | grep "t=" | awk -F "t=" '{print $2/1000}'
    

    En exécutant ce script (./temperature_1) voici la sortie :

    temperature.value 21.5
    

    Nous pourrons alors redémarrer le client Munin.

    Lors de la prochaine collecte des données, le serveur Munin récupèrera la sortie du script temperature_1 et proposera alors les graphes standards de Munin pour cette valeur.

    Dans l'hypothèse où nous disposons de plusieurs sondes, nous pourrons alternativement multiplier les scripts (un script par sonde) ou alors laisser au script imprimer les valeurs de chacune des sondes : les différentes valeurs seront alors affichées sur un même graphe !

                                    Suivi de la température par jour

    Notre environnement d'entrée

    Nous avons choisi d’utiliser des capteurs proposés par le constructeur espagnol Libelium. Cependant, n’importe quel capteur ferait l’affaire, si tant est que le code nécessaire à son interrogation est connu.

    Nous avons choisi d’avoir deux points d’entrée : température et humidité

    Le code d’exemple de ce capteur (température/humidité) suffit dans un premier temps.

    temp1

    temp2

    Notre code est bien conçu pour afficher toutes les 5 secondes deux mesures instantanées d'humidité et de température. 

    Qu'en est-il du modem Sigfox et de ses caractéristiques, ainsi que l'intérêt avec ces données issues de nos capteurs ? Le prochain atelier répondra à ces interrogations ...