DigitalSpirit / Blog

Mise à jour de RaspiO'Mix : RaspiO'Mix+

RaspiO'Mix est, comme son nom l'indique, l'évolution logique de RaspiO'Mix pour les RaspberryPi dit « Plus » et Raspberry 2.

RaspiO'Mix est une carte fille (également appelée hats) pour RaspberryPi qui vous permet de connecter vos capteurs / actionneurs Grove (le système Grove chez Lextronic) au Raspberry simplement, sans connaissance en électronique.
RaspiO'Mix est un projet libre et ouvert, tous les plans sont disponibles en ligne.

product-plus.png

Caractéristiques

  • Compatible Raspberry A+, Raspberry B+, Raspberry 2
  • 8 entrées / sorties tolérantes 5V
  • 8 entrées analogiques, 0-5V, 18 bits de résolution
  • 2 entrées numériques via DIP switch
  • Horloge temps réel avec batterie de sauvegarde
  • 3 connecteurs pour I2C
  • 1 connecteur pour communication série
  • Alimentation 5V via jack ou bornier à vis

Utilisation en Python

Des exemples en Python sont présents sur GitHub et vous montreront à quel point il est simple de dialoguer avec les capteurs / actionneurs Grove.

Par exemple, pour faire clignoter une LED présente sur le port IO0 et afficher la valeur analogiques lue sur le port AN0.

# On importe les librairies qui nous seront utiles
from raspiomix import Raspiomix import RPi.GPIO as GPIO import time
r = Raspiomix()
GPIO.setmode(GPIO.BOARD)
# On configure le port IO0 de RaspiO'Mix en sortie GPIO.setup(r.IO0, GPIO.OUT)
# Et on boucle ! while True: GPIO.output(r.IO0, not GPIO.input(r.IO0))
print("%f Volt !" % r.readAdc(0))
time.sleep(1)

Difficile de faire plus simple ! Non ?

Plus d'informations

Tout ce dont vous avez besoin pour avancer avec RaspiO'Mix+ est disponible sur le site www.raspiomix.org :

Et bien entendu, pour commander votre RaspiO'Mix+, cela se passe sur www.raspiomix.org !

Ouvrir l'article

Piloter des prises électriques via un Raspberry

Comment piloter des appareils branchés sur le secteur simplement et surtout sans risque, directement via un Raspberry (bien entendu, ça marche avec n'importe quoi d'autre, Arduino, etc...) ?

On pourrait utiliser un relais, un triac, mais ça ne me plait guère, on doit pouvoir faire plus simple et plus sécuritaire... Et si nous utilisions tout simplement des prises commutables à distance du commerce, nous n'aurions plus à nous soucier de l'aspect isolation vu que l'appareil se pilote à distance et est censé avoir passé des tests de conformité CE...

D'autant plus que ces prises télécommandées ne valent pas grand chose, il est facile de trouver un lot de 3 pour moins de 15€ comme celle ci-dessous :

blister.jpg

Une fois les prises télécommandées en notre possession, 3 solutions s'offrent à nous :

  1. Ouvrir les prises et les piloter directement via un signal logique : Mauvaise idée, on perd l'avantage de l'isolation
  2. Sniffer le signal radio lors de l'appui sur une touche et le reproduire
  3. Piloter directement la télécommande en simulant des touches

N'ayant pas de quoi reproduire le signal sniffé sur le moment, j'ai choisi la dernière solution qui implique un démontage de la télécommande.

L'intérieur de la télécommande :
Recto de la carte électronique Verso de la carte électronique

Le coeur de la carte est un HT46R01T3 de Holtek, un microcontrôleur embarquant une partie radio, avec ce dernier, nous trouvons un peu de composant passif, un quartz, des boutons et voilà, vous avez une télécommande « qui fait le job » pour 2 kopeck.

Le schéma de la carte :
schema.png

Nous avons 6 boutons, 3 boutons à gauche pour allumer la prise correspondante et 3 autres boutons à droite pour les éteindre.
Les boutons sont reliés aux broches 2, 3, 4 et 5 via les diodes (D1 à D6) correspondant aux pin PA0 à PA3 du circuit intégré, 6 boutons présents mais seulement 4 entrées utilisées sur le microcontrôleur, cette ruse est possible grâce aux diodes: 3 entrées servent à connaitre la prise sélectionnée et une autre indiquent s'il s'agit du bouton OFF.

État des broches en fonction des appuis sur les touches :

Boutons Pin 2 Pin 3 Pin 4 Pin 5
ON1 1 1 0 0
OFF1 1 1 0 1
ON2 1 0 1 0
OFF2 1 0 1 1
ON3 0 1 1 0
OFF3 0 1 1 1

Afin de simuler des appuis sur les touches tout en gardant possible l'utilisation des boutons de la télécommande, nous allons court-circuiter brièvement les boutons, pour cela, je vais utiliser un circuit intégré très pratique, le 4066, un quadruple switch analogique dont voici le schéma :
Contenu du 4066

Il contient donc 4 interrupteurs pilotables directement via des signaux logiques, la technologie CMOS du 4066 nous permet une connexion direct au Raspberry.

Connexion entre le 4066 et le Raspberry

En rouge, on retrouve les points vus plus haut dans le schéma de la télécommande, en vert, il s'agit des liaisons avec le port GPIO (P1) du Raspberry, concernant l'alimentation, c'est assez simple, la télécommande étant alimentée avec une pile bouton de 3V, on va utiliser directement les 3V issus du Raspberry.

Un petit bout de code Python (outlet.py) et vous pouvez piloter vos télécommandes :

$ python
>>> from outlet import Power_Outlet
>>> po = Power_Outlet()
>>> po.on(0)
>>> po.off(1)
>>> 

Le tout sur une plaque d'expérimentation :
final.jpg

Ouvrir l'article

Présentation des OpenAlarm Node

Voilà enfin des nouvelles de OpenAlarm, mais le projet n'est pas mort, loin de là mais ce n'est pas mon seul projet et ça ne permet pas vraiment de payer mes factures, soyez donc patient, ou mieux, participez !

Funky v3

Pour le développement des modules capteurs que j’appellerai maintenant OpenAlarm Node ou pour faire plus court, « Node », je me suis basé sur l'excellent travail de Martin au sujet de module autonome basé sur des RFM12 : les Funky (en version 3), ces derniers sont très petits (un des premiers critères de choix) et consomme très peu (autre critère important) et pour finir, ils sont architecturés autour de microcontrôleurs ATMega, on peut donc bénéficier de la simplicité de développement de l'environnement Arduino...

funky_v3.jpg
Source de la photo

Caractéristiques (source) :

  • Poids de 3gr
  • Compatible avec Arduino
  • Microcontrôleur ATMega32U4, le même que celui utilisé sur l'Arduino Leonardo
  • Pas besoin de programmateur externe, programmation directe via USB
  • Utilisation des modules radios 433/868Mhz RFM12B
  • Peu être utilisé avec le nouveau module RFM69CW
  • Fonctionne à 8Mhz, et peut être alimenté via 2.7V - 3.3V, dont les piles boutons
  • Mode faible consommation
  • La version "step-up" inclu la version 3.3V du LTC3525 boost regulator.

Les Funky v3 étant libre, j'ai donc fabriqué mes propres modules afin de les tester et faire quelques mesures avec.

2015-06-15_10.53.06.jpg
Un de mes modules Funky v3 fait maison

J'ai effectué de multiples tests logiciel, notamment, afin d'obtenir au moins les même résultats annoncé de Martin concernant la faible consommation de ces modules.

La course à la consommation moindre

À quoi bon avoir un module autonome capable de détecter l'ouverture d'une porte si ce dernier demande à être rechargé toutes les semaines et donc retiré momentanément de son service ?

Il est donc essentiel que les modules capteurs de OpenAlarm soit très peu gourmand en énergie.

Le microcontrôleur central des OpenAlarm Node dispose d'un BOD (Brown-out Detection permettant de détecter une tension d'alimentation faible, très utile pour éviter les erreurs d'exécution du micrologiciel embarqué), sans BOD activé, il est possible de descendre la consommation à 5µA, en l'activant, on perd 20 µA mais avec une sécurité supplémentaire, si la tension descend en dessous du seuil configuré, l'AVR entre en veille, garantissant le bon fonctionnement général du programme.

Une solution intéressante aurait été de pouvoir désactiver le BOD durant les périodes de veille via un appel de fonction (sleep_bod_disable()), malheureusement, c'est uniquement possible sur les AVR suffixés d'un P comme Picopower et aucun AVR Mega intégrant un contrôleur USB ne fait parti de cette famille...

Une vue de la consommation pendant une phase d'émission, on remarque un pic de consommation à gauche au moment de la sortie de veille et les pics de conso lors de l'émission du module radio à droite :
TEK00000.PNG

LDO

Un régulateur LDO (Low DropOut) permet de travailler avec une tension d'entrée proche de celle en sortie, il permet dans la node OpenAlarm l'alimentation du montage en convertissant le 5V du port USB en 3.3V.

Dans le design de Martin, au choix, il est possible d'intégrer un MCP170X ou un XC2606 (même brochage) mais dans les 2 cas, j'ai eu quelques soucis...

Le MCP1700 / MCP1703 induit un courant de fuite et la consommation monte en flèche (voir les articles de Martin à ce sujet : High sleep current issue with Funky v2 sorted out, Funky v2’s LDO to blame for high sleep current. Now fixed et Every μA counts).

Le XC6206 est le plus intéressant car il induit une perte de seulement 10µA, ainsi, à 4V, sans LDO, l'AVR en veille, la carte ne consomme que 5.5µA, avec le LDO, on passe à 15µA...

Afin d'éviter un courant de fuite s'échappant via le LDO lors de l'utilisation sur batterie, une idée serait de mettre une diode Schottky (diode à faible chute de tension) en sortie du régulateur, mais il faut qu'elle est des caractéristiques qui nous conviennent bien, c'est à dire une tension directe la plus faible possible et un courant de fuite le plus faible possible (un article à ce sujet Reverse diode current), une diode ayant des caractéristiques intéressantes est la RB751S40 avec vf ~ 300mV et un courant de fuite de 300nA.

Les tests avec cette diode se sont montrés concluants, elle est donc embauchée pour cette tâche !

Mosfet

Le Mosfet est uniquement utilisé pour réduire le courant au démarrage en désactivant le RFM, il est activé une fois l'AVR démarré via logiciel.

Article de Martin à ce sujet : Funky v2 rev 1

Ma version

Basé sur mes tests, j'ai décidé de faire une version légèrement différente pour les OpenAlarm Node :

  • Réduire au maximum la taille
  • Intégrer le port USB dans le PCB afin de gagner en taille / épaisseur / cout (on verra ce que ça donne au niveau solidité mais ayant déjà cassé un port physique sur un Funky, je doute que cela soit pire)
  • Dissocier la partie alimentation du Node en lui même, selon moi, le type d'alimentation dépend avant tout de l'utilisation finale qui va en être fait, exemple :
    • Un Node situé à proximité immédiate d'une source de courant n'a pas besoin d'emmener avec lui des régulateurs ("step-up" comme dans le Funky).
    • Je souhaite alimenter mon module avec une batterie au plomb de 12V, idem, pas besoin de composant en plus
    Au final, les OpenAlarm Node sont conçu afin de pouvoir supporter des cartes filles qui pourront intégrer une partie pour la gestion de l'alimentation.
  • Ajouter une LED afin d'en avoir 2 (rouge et verte), pratique pour indiquer des états sur nos capteurs
  • Des points d'accroches sécables
  • Les broches des ports accessibles facilement en périphérie de la carte au pas de 2.54mm

Voici le schéma de principe qui diffère assez peu de celui des Funky v3 (ajout d'une diode après le régulateur LDO et d'une LED) :
schema.png

Et le PCB, recto / verso :
pcb.png

Une vue 3D à l'échelle avec une pièce de 1 euro :
gerber.png

On remarque le port microUSB réalisé directement dans le PCB, ce dernier faisant 0.8mm d'épaisseur.

Le circuit est légèrement plus petit que le Funky v3 et il est simple d'accéder au broches des ports qui sont matérialisés par les 14 pads à droite et à gauche de la carte.

Le bouton de reset est placé sur la gauche, les leds sont à droite du connecteur USB.

Et la base ?

Oui, c'est bien beau d'avoir des modules autonomes de détection mais où est la base recevant les informations des Nodes ? Et bien, pour le moment, il n'y en a pas ! Il suffit d'utiliser un Node branché directement sur le port USB d'un PC (RaspberryPi par exemple) et voilà, nous avons notre base...

Cette solution à beaucoup d'avantages (cout, facilité, etc...) et n'empêche en rien de créer une base par la suite, elle permet surtout d'avoir quelque chose de fonctionnel malgré le temps dont je ne dispose pas toujours pour avancer sur le projet.

Où en est-on ?

Les PCB sont en cours de fabrication, puis, viendra la phase d'assemblage des cartes, de tests et enfin, un nouvel article...

En attendant, tout est disponible sur GitHub !

Compléments d'informations

Ouvrir l'article

Des nouvelles de RaspiO'Mix

J'ai peu donné de nouvelle récemment, notamment au sujet de RaspiO'Mix et pourtant, il y a à dire...

Un site dédié

Un site dédié permet de commander directement les RaspiO'Mix : www.raspiomix.org, tant qu'il y a du stock, vous recevrez votre RaspiO'Mix en 48h.

Je n'exclus pas de proposer les RaspiO'Mix aux revendeurs intéressés, merci de me contacter directement.

Librairie Python

La librairie Python à quelque peu évoluée et est devenue encore plus simple.

Pour lire une tension sur une des entrées analogiques suivi d'une lecture des 4 entrées analogiques :

$ python
>>> from raspiomix import Raspiomix
>>> r = Raspiomix()
>>> r.readRtc()
2014-11-12T20:41:26
>>> print(r.readAdc(0))
[4.0669732000000005]
>>> print(r.readAdc((0, 1, 2, 3)))
[4.066934600000001, 0.010923800000000001, 0.08515160000000001, 0.2866822]
>>> 

Cette librairie est disponible sur GitHub : GitHub / RaspiOMix / raspiomix.py

RaspiO'Mix+

Présentation

RaspiO'Mix poursuit son évolution avec la RaspiO'Mix+ créés pour être utilisée comme vous pouvez vous en douter avec un Raspberry+.

J'ai repris le tableau d'un précédent article sur RaspiO'Mix comparant cette dernière avec la carte GrovePi :

Fonctionnalité GrovePi RaspiO'Mix RaspiO'Mix+
Entrées / Sorties 7 4 8
Entrées analogiques 3 4 8
Résolution CAN 10bits 18bits 18bits
Lignes I2C 4 2 3
Lignes série 1 1 1
Horloge Non Oui (via DS1307) avec batterie de sauvegarde Oui (via DS1307) avec batterie de sauvegarde
Interrupteur 0 2 2
Alimentation via le Raspberry via le Raspberry ou une prise jack / bornier via le Raspberry ou une prise jack / bornier
Option - - Capteur I2C TMP10

Note: GrovePi+, l'évolution pour RaspberryPi+ possède les même caractéristiques que GrovePi.

RaspiO'Mix+ est au format Raspberry HATs+ et donc bien plus petite que la version originale, la densité de composants est donc plus forte.

RaspiO'Mix comparée à RaspiO'Mix+ :
Comparatif de taille RaspiO'Mix vs RaspiO'Mix+

Une carte RaspiO'Mix+ sur un RasberryPi :
RaspiO'Mix+ sur un RaspberryPi+

En détail

Le schéma de principe :
schema.png

J'ai ajouté un deuxième MCP3424 afin de doubler le nombre d'entrées analogiques, un second convertisseur de niveau à 4 entrées / sorties (TXB0104PWR) rejoint le TXS0108PWR et sera utilisé pour les entrées sorties de type Push / Pull (le TXS0108PWR ayant un mode haute impédance).

Une EEPROM série rejoint la carte afin de répondre à la spécification HAT mais je ne sais pas si elle sera montée sur les cartes (quoiqu'il arrive, son emplacement sera laissé sur le pcb).

J'ai également ajouté un capteur de température I2C (TMP10x) sous la carte permettant la mesure de la température rayonnée par le Raspberry mais le circuit intégré ne sera pas disponible de série, ou alors, uniquement en option (sauf si j'arrive à les obtenir par quantité à un coût intéressant).

La suite

Pour le moment, la carte RaspiO'Mix est fonctionnelle mais non disponible à la vente, quelques modifications sur l'emplacement des composants sur le pcb doivent encore être faite (merci Seeedstudio de proposer des librairies Eagle légèrement foireuse).

Ouvrir l'article

Le poulailler connecté

Grâce à une campagne de test concernant la réduction des déchets à laquelle j'ai participé, j'ai maintenant 2 poules et un poulailler (c'est d'ailleurs le nom de la campagne : « deux poules et un poulailler pour réduire nos déchets »).
L'opération consistait à nourrir les poules avec un maximum de déchets qui finissent habituellement dans les poubelles ou au mieux dans un composteur. Plus de 6 mois se sont écoulés, l'opération est maintenant finie et je trouvais qu'il serait intéressant, et surtout amusant de mettre quelques capteurs dans le poulailler.

Cot ! Les poules

Après la brosse à dents connectée ou le produit qui va totalement révolutionner vos WC : SmartPQ, le premier rouleau de papier de toilette connecté et surfant sur cette vague de bullshit créativité, j'ai décidé de me lancer dans une première mondiale : ami des gallinacées, je vous présente le premier poulailler connecté !

Twitter @LaVieDePoule

Fonctionnalités du bestiau :

  • Prise de photos infrarouges, détection des œufs
  • Prise de température / luminosité / capteur mouvement / capteurs d'ouverture
  • Surveillance de la température, de la tension d'alimentation et du courant consommé
  • Alertes via Twitter et SMS (API Free Mobile) si certains seuils sont dépassés (température, alimentation)

Le tout est articulé autour d'un Raspberry et d'une carte fille RaspiO'Mix armée de capteurs :

  • Température de l'enceinte du poulailler
  • Température de chaque nid
  • Détecteur de mouvement IR
  • Caméra infrarouge
  • Capteur de luminosité extérieure
  • 3 capteurs sur tous les accès du poulailler (basse-cour, porte jardin et collecteur d’œufs)
  • Mesure de la tension d'alimentation et du courant consommé

2 sorties sont également pilotables et sont utilisées pour la led témoin et le relais pilotant les leds infrarouges.

Le tout en 1 image :
Vue des entrées / sorties

Le poulailler

Le poulailler fourni dispose de 2 portes et d'un collecteur d'oeufs, sur l'un des côtés disposant d'une ouverture, on vient coller une sorte de cage (à gauche sur la photo) disposant elle-même d'une ouverture permettant l'accès à une éventuelle basse-cour, dans la configuration actuelle, la seconde porte sert à faire sortir les poules directement dans le jardin (la porte devant).

Vue du poulailler

Le boitier et son logement

Afin de protéger l'électronique contre les conditions qui seront certainement rudes en pleine hiver, le tout est logé dans un boitier de répartition étanche.

Le coffret étanche

Détails techniques

Caméra

J'utilise Pi Noir (la caméra officielle de Raspberry sans le filtre infra-rouge), elle est placée face aux 2 nids et sa focale permet d'avoir une vue parfaite sur les poulettes.
Pour les photos de nuit, un relais pilote un anneau de leds infra-rouges permettant d'illuminer le poulailler afin d'y voir quelque chose et ça marche plutôt bien :

ir_0.jpg ir_1.jpg ir_2.jpg ir_3.jpg

La caméra (en noir à droite) et l'éclairage infrarouge situé à la verticale des nids
Le capteur infrarouge à gauche et la caméra Noir à droite Les leds infrarouges

Le principal intérêt de la caméra concerne la détection des œufs via OpenCV. À intervalle régulier, je prends une photo de la scène et je cherche des éventuels œufs après une succession de traitement sur l'image.

Pour le moment, la détection des œufs ne se lance pas automatiquement car j'ai encore un peu de développement à faire pour améliorer l’algorithme qui affiche pour le moment un taux de succès inférieur à 42%.

Pour pouvoir tester l'algorithme de détection, j'ai collecté des images en provenance de la caméra sur lesquelles apparaissent ou non des œufs, le nom des fichiers indique le nombre d’œufs présents (0_1.jpg signifie 1 œuf, il faut ignorer le premier numéro), ainsi, une fois l'image analysé, je peux savoir si le résultat est bon ou non, si tous les œufs de l'image ont bien été trouvés.

Un exemple d'utilisation :

$ python eggcounter.py --export=tests/export tests/with/*
Open tests/with/0_1.jpg [Ok]
Open tests/with/10_2.jpg [Error]
Open tests/with/11_1.jpg [Ok]
Open tests/with/11_2.jpg [Error]
Open tests/with/1_1.jpg [Ok]
Open tests/with/12_2.jpg [Error]
Open tests/with/13_1.jpg [Error]
Open tests/with/14_1.jpg [Error]
Open tests/with/15_1.jpg [Error]
Open tests/with/16_1.jpg [Error]
Open tests/with/2_1_highlight.jpg [Ok]
Open tests/with/3_1.jpg [Ok]
Open tests/with/5_1.jpg [Ok]
Open tests/with/6_1.jpg [Ok]
Open tests/with/7_2_highlight.jpg [Error]
Open tests/with/9_2_highlight.jpg [Error]
Result: 42% (7/16)
- Extra egg detected : 5
- Missed egg : 11
$ 

42%, ce n'est pas énorme mais c'est une partie que j'ai peu travaillé, le score ne peut donc que s'améliorer...

Notez que je lance le même test avec des images sans œuf, le résultat est meilleur (84%) mais ça signifie tout de même que j'arrive à trouver des œufs ou il n'y en a pas ;).

Enfin, je n'ai pas testé d'image depuis que l'éclairage infrarouge est installé, je pense que ça devrait grandement améliorer la détection.

Les différentes étapes de la détection
  1. On part de l'image source
  2. On applique 2 transformations (erode et dilate)
  3. Modification des niveaux (threshold)
  4. Le résultat : 1 œuf trouvé !

Tout ceci en image :
Image originale Erode / Dilate Niveaux Oeuf trouvé !

Capteur de mouvements IR

L'idée est de repérer les mouvements dans l'enceinte du poulailler afin de savoir si les poules sont dedans ou non lorsque les portes extérieures sont ouvertes.

J'utilise un capteur de type PIR HC-SR501 qui possède 3 broches, 2 d'alimentation et une de sortie. Le souci avec ce module est qu'il possède son propre régulateur 3V (à faible chute de tension), or, je l'alimente en 5V et j'ai besoin d'une tension de sortie de 5V pour un niveau haut (3V pourrait être pris un niveau indéterminé par l'adaptateur de niveau de la carte RaspiO'Mix #vécuInside, enfin, je ne souhaite pas le brancher en direct sur les IO du Raspberry), j'ai donc ajouté un petit montage avec un transistor et une résistance faisant office d’adaptateur de niveau (0V -> 5V, 3V -> 0V).

Le capteur étant assez sensible et surtout pas vraiment adapté à ce genre d'utilisation (dans un environnement aussi confiné), le logiciel gère en grande partie ces insuffisances (debouncer et compteur d'impulsions) et ça marche assez bien.

Le capteur infrarouge à gauche et la caméra RaspberryPi Noir à droite
Le capteur infrarouge à gauche et la caméra Noir à droite

Capteur de luminosité extérieure

Il est constitué d'une simple photorésistance (LDR) dont le principe de fonctionnement est une modification de la résistance à ces bornes proportionnellement à la luminosité (plus l'éclairage est fort, plus la résistance diminue).
Ce capteur permet de donner des indications sur l'heure de coucher des poules car le rythme de ces dernières est totalement calé sur celui du Soleil, d’où l'expression se coucher à l'heure des poules...

La LDR est utilisée avec un pont diviseur de tension qui attaque directement une des entrées analogiques de la carte RaspiO'Mix.

La LDR (à droite) et un capteur de température à gauche (DS1820)
La LDR (à droite) et un capteur de température à gauche

Capteur d'accès

Aux nombres de 3 et disposés sur toutes les ouvertures, ils sont simplement constitués de microswitch, à chaque changement d'état de l'entrée associée au capteur, un évènement est généré dans le code et une action est générée (Tweet, etc...), l'anti-rebond est géré du côté logiciel.

Les accès :

  • Basse court
  • Jardin entier
  • Collecteur d’œufs

Capteur d'ouverture basse-cour Capteur d'ouverture jardin Capteur d'ouverture collecteur oeufs

Mesures de tension et courant

La valeur de la tension d'entrée (environ 12V) juste avant le régulateur à découpage est présentée via un pont diviseur de tension à une des entrées analogiques du RaspiO'Mix, la seconde mesure concernant la courant consommé par le dispositif.

Le but serait d'alimenter le tout par panneau solaire, cela explique aussi la présence de ces 2 capteurs.

Les sondes de température

Le capteur de l'enceinte du poulailler est basé sur un simple LM35 connecté sur une des entrées analogiques de la carte RaspiO'Mix, au niveau logiciel, je lis très simplement cette valeur, la multiple par 100 (1 degré = 10mV) et l'affiche dans les log ou la publie sur Twitter, dans la configuration (config/general.py), il est possible de définir des seuils acceptables (3 à 32 degré C) au delà desquels une alerte est générée et un twit m'est directement adressé pour me prévenir que mes poulettes ont froid ou trop chaud...

La prise de température de chaque nid est un peu plus complexe que pour l'enceinte, la distance entre le Raspberry et les nids étant plus grande, un capteur analogique n'aurait pas été très précis, ainsi, afin d'avoir une mesure fiable, j'ai utilisé des sondes OneWire DS1820 qui autorisent de grande distance de câble sans perte de précision (et puis de toute façon, je n'avais plus d'entrées analogiques disponibles).

Ces 2 sondes n'utilisent que 2 fils (mode parasite), la masse et le tension / signal :

Screen_Shot_2014-08-13_at_14.45.41.png

Au niveau logiciel, afin de fonctionner correctement, ces sondes ont besoin des modules suivants avec les paramètres qui vont bien :

$ modprobe w1-gpio gpiopin=25 pullup=1
$ modprobe w1-therm
$ 

Une fois les modules chargés, ils vont "pouller" à intervalle régulier le bus afin de découvrir et lire les valeurs des capteurs connectés sur le bus, pour les découvrir, une petite commande suffit :

$ ls /sys/bus/w1/devices/
10-0008008ba2a9  10-0008008bceb5  w1_bus_master1
$ cat 10-0008008ba2a9/w1_slave
1b 00 4b 46 ff ff 01 10 23 : crc=23 YES
1b 00 4b 46 ff ff 01 10 23 t=13687
$ 

Le fichier w1_slave contient toutes les informations qui nous intéressent, il est à parser et c'est la fonction read_w1_temperature qui s'en occupe et pas folle la guêpe, en cas d'erreur de lecture sur le bus, une nouvelle tentative est faite...

Durant le développement, un bug dans le pilote w1 foutait la brouille sur le bus i2c et empêchait la caméra de fonctionner correctement, il n'était donc pas possible d'utiliser conjointement la caméra et les capteurs de température, si je voulais utiliser ces derniers, j'étais obligé de rebooter en activant les modules, la caméra devenant alors inaccessible, pour l'avoir, il fallait rebooter et bien entendu, ne pas charger les modules w1 (plus d'informations à propos de ce problème sur GitHub).

J'ai réglé ces problèmes avec cet ordre dans /etc/modules :

$ cat /etc/modules
# First load onewire driver before i2c module
w1-therm
w1-gpio gpiopin=25 pullup=1

i2c-bcm2078
i2c-dev
#spi-bcm2708
rtc-ds1307
#snd-bcm2835
bcm2708_wdog

cuse
$ 

Note à propos des capteurs de température des nids : en suivant leurs températures, il est possible de détecter la présence des poules sur les nids, plus pratique et précis qu'un système mécanique.

Le logiciel

C'est Python qui fait tout le travail de notifications, de surveillance, etc... J'utilise également Motion pour streamer « en live » le flux vidéo en provenance de la caméra afin de voir ce qui se passe dans le poulailler.

Pour tout le reste, c'est Python qui intervient, j'utilise, entre autre, les modules suivants :

  • OpenCV pour la recherche des œufs
  • Twython pour l'interfaçage avec Twitter

2 threads sont utilisés, un s'occupe d'envoyer les notifications dans la console, surveiller les seuils d'alertes, générer les messages et les envoyer sur Twitter et un autre thread gère les réponses aux messages qui sont adressés au compte Twitter, oui, je l'admet, mes poules n'ont pas le temps de répondre à tous les messages et un CM automatisé leur permet de vaquer à leurs occupations tranquillement !

J'ai également développé un bout de code qui permet de former des phrases de manières plus ou moins « aléatoire » afin de ne pas toujours envoyer les mêmes messages sur Twitter.

Voici un exemple d'utilisation très simple; imaginez que vous vouliez pouvoir dire bonjour à quelqu'un via l'appel à un programme mais d'une manière originale à chaque fois, par exemple :

Nous avons d'un côté "Bonjour", "Salut" et "Hello", de l'autre "toi", "l'ami" et "vous", en combinant tout ça, on obtient ces bouts de phrases :

  • Bonjour toi / Bonjour l'ami / Bonjour vous
  • Salut l'ami / Salut toi / Salut vous
  • Hello vous / Hello toi / Hello l'ami

Vous avez compris le principe, on combine plusieurs morceaux de phrases ensemble afin d'en former d'autres.

Pour automatiser ça avec ma lib, on créé un tuple de tuple ainsi :

test = (
    '{0} {1}',
    (
        ( 5, 'Bonjour'),
        ( 2, 'Salut' ),
        ( 2, 'Hello' ),
    ),
    (
        ( 1, 'toi'),
        ( 5, 'l\\'ami{0}', (
            ( 1, ', il est %hour% !'),
            ( 1, '!'),
        )),
        ( 5, 'vous'),
    )
)

Notes :

  • Le premier élément du tuple '{0} {1}' est une règle de formatage "format", le second élément et le troisième correspondent aux éléments que l'on va « sélectionner aléatoirement » et venir remplacer dans dans le premier élément.
  • Le second tuple est constitué de sous tuple contenant un nombre (la pondération) et une chaine de caractère, plus la valeur de la pondération est élevée et plus la chaine de caractère associée à de chance d'être choisi.
  • Vous pouvez imbriquez autant de tuple que vous le souhaitez pour créer des phrases très complexes

Après, il suffit de faire un appel à la fonction speak avec notre tuple en paramètre et elle nous généra une phrase automagiquement.

speak(test, hour='11h')

Vous noterez au passage que vous pouvez injecter des paramètres nommés qui serviront à remplacer leur équivalent sous la forme %param% dans les chaines de caractères.

Et voici ce que ça donne :

$ python speak.py
Bonjour l'ami, il est 11h !
$ python speak.py
Bonjour vous
$ 

Si vous voulez jouer avec cette lib, vous la trouverez dans lib/speak.py.

Les pistes d'évolutions

  • Améliorer la détection des œufs
  • Générer des stats (pontes, températures, éclairage, etc...)
  • Reconnaitre chaque poule (les lier à la production d’œufs)
  • Autonomie énergétique du dispositif

Le tout est disponible sur GitHub sous une licence évidemment libre : GitHub / hugokernel / LaVieDePoule

Ouvrir l'article

« Page 2 / 32 »