Suivi des ruches
Présentation
Le projet Bzzz (Bee Zen Cube) est un projet de suivi de ruches pour une apiculture vraiment Zen ( pour l'apiculteur et pour ses abeilles ^^), il a pour but de proposer gratuitement à tout apiculteur amateur un peu bricoleur les plans d'un kit de supervision de son rucher (mono-ruche voir évoluer vers le multi-ruche). Le projet Bzzz souhaite suivre l'évolution de la santé de la ruche à distance c'est à dire, la prise de poids, son bien-être interne (température) et l'alerte en cas d'essaimage. Évitant ainsi de multiples déplacement de l'apiculteur.
Le projet Bzzz est un projet Open-source et Open-hardware
Le projet est né suite à la demande d'un apiculteur amateur de pouvoir superviser (surveillance avec divers capteurs) sa ruche avec une solution innovante et abordable. La présentation de l'idée de départ:Fichier:Projet Bzzz.pdf
Après avoir définit le besoin, un cahier des charges a été définit pour cette supervision d'un rucher monoruche (v1.0 du projet):
- Une seule et unique ruche supervisée
- Supervision de la masse, la température interne, la luminosité extérieur
- Autonomie électrique du système (pas de branchement électrique filaire nécéssaire)
- Envoi par SMS des données de manière périodique
- Système d'affichage des données (portail en ligne)
- Système d'alerte avec seuil définit (configurable via le portail)
Ce projet fédère plusieurs bénévoles au sein du fablab et est suivi par les médias locaux ainsi que par des apiculteurs d'autres régions (volontaire pour prototypage notamment). Plusieurs apiculteurs ont aussi faits le déplacement au sein du fablab de Lannion pour venir découvrir ce projet et se porter volontaire pour une période de béta-test dés que la solution sera pleinement fonctionnelle:
Les évolutions possibles sont notées dans la partie ToDoList (amélioration, bug à corriger, ajout de capteurs, multi-ruche, etc...).
Les recherches effectuées n'ont montrées aucune contre indication par rapport aux brevets déjà existants.
Planning
Avril/Mai 2013: Définition du cahier des charges, choix de la méthode de supervision (capteur, portail, ...), test des solutions en labo
Juin 2013: Premier prototype fonctionnel et mise en place en condition réel pour première conclusion de fonctionnement.
Juillet 2013: Evolutions/améliorations suite aux tests en condition réels.
Aout 2013: Deuxième essai en condition réel et évolution possible. Etudes pour résoudre les différents problèmes rencontrés.
Novembre 2013: Recherche de béta testeurs et de budget pour pouvoir finaliser le projet. Plusieurs béta-testeurs se sont manifestés (participation de leur part pour l'achat du matériel).
Décembre 2013: Etude sur l'autonomie, prototypage avec des puces basse consommation (hors ruches).
Janvier 2014: Todo: Mise à jour de la documentation, Test d'autonomie sur puce Atmel.
Février 2014: Todo: Test du prototype et Contacter les béta-testeurs qui se sont manifestés.
Mars 2014: Todo: A définir (mise en place des béta-tests).
...
Type de supervision
Détails technique côté rucher
Détails fonctionnels de la supervision et la mise en oeuvre sur le terrain sont décrites dans cette partie (les choix techniques possibles ont été discutés dans la partie discussion du projet)
Supervision pour un rucher monoruche
Le système actuellement développé est un prototype qui nécessite d'être optimisé (en consommation et en coût) dans des versions futures, les informations présentes dans cette partie présente le prototype pour superviser un rucher mono-ruche. Ce prototype est nommé Step-1.01 (prototype éligible à béta-test).
Le système mono-ruche est composé des éléments suivant: - Une ruche (tous type de ruche) - Un support de ruche (supporte la ruche et le système de supervision) - Un lot de sachet type "pompote" (supporte la ruche et se compresse en fonction du poids) - Des tuyaux silicone et un raccord en T de section
- Page supervision d'une ruche (système du capteur, de la pesé et l'installation de la ruche)
- Une seule ruche (explication de la communication vers le serveur) + lien vers les deux cas (couverture wifi ou non)
Supervision pour un rucher multiruche
- Une fois que la version mono-ruche sera validée - Étude de cout et mise en œuvre à faire - Page supervision d'une ruche (système de capteur), identique au mono ruche - n ruche esclave + mise en oeuvre du réseau courte portée emetteur vers le maitre - 1 ruche maitre + mise en oeuvre du réseau courte portée récepteur + lien vers les deux cas (couverture wifi ou non)
Rucher à portée d'un réseau Wi-Fi
- Etude de cout et mise en oeuvre à faire - Si le rucher est à proximité d'une maison
Rucher sous couverture GSM
- Etude de cout et mise en oeuvre à faire - Envoi de SMS, couverture nationale
Aperçu du code arduino pour une unique ruche (capteur et envoi de SMS): File:Bzzz_Proto_v0.2.txt
Réseau dédié M2M bas débit
http://www.sigfox.com/ couvre apparemment la France métropolitaine
La taille utile du message est de 12 octets. On peut émettre 140 messages/jour maximum
Description et détails à réécrire
On utilise 2 sachets de Pompote remplis d'eau placé sous le support pour mesurer les variations de poids de la ruche.
La pression est transmise depuis le support jusqu'au capteur en utilisant un liquide pour éviter les variations de température et de pression atmosphérique.
Le liquide doit être de l'eau sucrée pour éviter le gel et l'évaporation.
On utilise un capteur MPX 5100 (0 a 1 Bar) [1]
Test: Utilisation de Pompote
- La tension en sortie du capteur + montage semble stable.
- Avancement 12/06/2013: Test sur une chaine de bout en bout avec la pompote solution:
- Résultat visible dans site de test (login test mdp <rien> ), joli bois
TODO : montage elec en sortie + Fct de transfer tension/kg
La boîte (Plans et réalisation proto)
Une photo d'un proto presque complet (monoruche sans zigbee) => Ruche / Capteur Masse / Capteur Température / Capteur Lumière / Panneau solaire.
Mise en place de ce proto en condition réel (mesure tous les 15min le jour, toutes les 2h la nuit.
Energie
@david.blaisonneau, @cedricbou
Limitation de la consommation d'énergie
Sur l'arduino, la librairie 'Narcoleptic' (modifiée pour prendre en compte de longues durées) est utilisée pour endormir l'arduino pendant une durée configurable. Coté shield, le shield GSM choisi [2] permet d'allumer/éteindre la puce GSM via un soft-switch, cela limite donc la consommation au strict nécéssaire.
Alimentation
L'alimentation par le Solar shield testé [3] + Batterie Lipo 3.7V n'est pas assez puissante, d'autres tests dans des configurations différentes sont à faire. Un test de durée de batterie est en cours avec une pile 9v et une période d'envoi de SMS toutes les 15 minutes.
Communication entre les ruches
@laurent, @guillaume.remy
Filaire ou ZigBee. Pour l'instant ZigBee est retenu.
Le prototypage se fait sur deux Arduino Uno munis de shields ZigBee, l'un simulant une ruche et l'autre le collecteur du rucher. Nous sommes parvenus à faire communiquer la ruche avec le collecteur du rucher par l'intermédiaire du ZigBee. La prochaine étape consiste émuler un capteur qui envoi des données à l'Arduino, afin d'évaluer la consommation en énergie de chaque ruche.
Photo avancement au 22/04/2013:
Module Xbee utilisé:
Module ZigBee Xbee série S2.
Modules mis à jour pour une version firmware type ZB, par le logiciel XCTU.
TODO:
Desactiver l'émission de Data_Request du Xbee, par une commande API venant de l'Arduino pour mise en sommeil profonde du XBee.
Estimer la consommation du module XBee End_device (Slave) accompagné de son Arduino.
Définir la pile/batterie à utiliser sur l'ensemble Arduino/Xbee Slave.
Etablir une gestion de sommeil de l'Arduino par Timer, de manière à se réveiller toutes les 15 mns.
Fusionner le soft Arduino Master (GSM / Xbee) pour tester la chaîne complète.
Fait:
Mesure d'une entrée brute de l'ADC "Arduino Xbee Slave" envoyée, reçu et affichée sur la sortie "Arduino Xbee Master".
Reprogrammation du firmware XBee Router livré usine, en firmware End_Device (adapté Low Power).
Mise en sommeil du XBee commandé par une IO de l'Arduino.
Liste du matériel
Détails techniques côtés serveur de données
Serveur Collecte et Affichage Smartphone
@colvert, @benoitb
Nano spec
Le but du serveur est de
- déclarer des ruchers
- déclarer des ruches dans des ruchers
- collecter des données de ruches
- afficher les graphs de données par ruche
- générer une alerte en acs de delta entre 2 mesures pour une ruche donnée
Data model
le petit modèle objet peut être décrit comme suit
Le serveur est développé en jquery model histoire d'être visualisable indiféremment sur PC, tablette ou smartphone.
Fichiers
l'arborescence fichier simplifiée peut être vue comme suit:
Nommage des ruches
chaque ruche est identifié par le numéro de téléphone du shield GSM (à terme ça sera l'identifiant de rucher)
On se base désormais sur le système sensonet pour la gestion du réseau de capteur. le projet Bzzz s'est donc "abonné" aux données du réseau Bzzz et a indiqué une classe de callback (bzzzsensonet.php) qui est invoquée à chaque fois qu'un SMS relatif à Bzzz est reçu via sensonet. L'utilisationd e sensonet permet de bénéficier de toutes la logique de ce réseau de capteurs, de son API, de ses pages de visualisation et de son application android.
La fonction de callback permet de monter en base les données collectées par Sensonet, un peu à la manière de l'ancienne gestion (cf plus bas)
Librairies
- jquery mobile
- leaflet: carto openstreetmap pour la localisation d'un rucher (adLocalisation.php)
- jqplot: pour grapher les résultats des sondes (stats.php)
captures d'écran
l'accueil
test/ <pas de mot de passe>
visualisation d'un rucher
configuration du rucher
options d'alertes du rucher
Todo liste
A faire:
- codage des cas pas droits (TODO dans le code qui vérifie si le rucheid n'est pas valide, si le rucherid est le bon .. pour le moment je fais confiance au gars qui tape
- commentaire code
- gérer le système d'alerting (partiel)
- Mettre à jour le wiki avec explication du fonctionnement (faire une partie monoruche et une partie multiruche)
- Mettre une conclusion sur les réflexions sur les capteurs
- Mettre le protocole du premier essai en condition + les conclusions de cet essai
- Plein d'autres choses encore
en option
- ajout d'un tag admin/user dans la base (pour l'instant un user qui peut voir tous les ruchers et donc toutes les ruches)
- IVR (kiosque vocale de consultation et/ou appelle le responsable du rucher en cas d'alerte en plus du SMS)
- des stats annuels / mensuels / comparatives ruche
- gestion du filtre pour l'affichage des ruches (sinon si y a 20 ruches dans un rucher la page va être un peu longue...)
- bouton pour export CSV des données d'un rucher ou d'une ruche
Fait:
- intégration avec sensonet (appli de gestion de réseau de capteurs développée par Benoît H.)
- suppression des fichiers qui servent à rien
- mise en place du système de session (pour l'instant la page de login ne sert à rien (login:test mdp:<rien>) mais on peut attaquer directement les pages subséquentes
- display des courbes à finir (pas de display si pas de valeurs, affichage des N derniers points....)
- addRuche à finir
- intégration de carto (pour le moment je rentre longitude/lattitude via des champs, je pense le faire via l'intégration d'une carto, faut que je regarde comment on fait ça en jquery mobile)
- fonction edit_rucher (modifier descriptif / localisation / propriétaire)
- choix pour l'utilisateur du mode d'alerte (SMS, mail, appel) - partiellement fait
- afficher la carte sans avoir à recharger la page cf. explications de Benoît B. ci-dessous
- comprendre pourquoi la carte et les graphs ne se chargent pas avec la page (besoin de reforcer le chargement de la page) => Benoit:"
Le « pourquoi cela ne marche pas ». C'est assez simple. Avec JQuery Mobile (JQM par la suite), toute l'application est constituée de « cartes ». À chaque fois qu'un contenu (une « carte ») est ouverte (lien, bouton etc.), JQM intercepte la requête, fait une requête AJAX sur l'URL correspondante, génère et insère le DOM de la page reçue en réponse et l'affiche. Donc seul ce qui est contenu entre les balises <body> et </body> est pris en compte. De ce fait, tu n'as aucune chance qu'un script ou une CSS spécifié dans la partie <head /> soit pris en compte. Par contre, avec un service suffisamment REST, un « reload » de la page la charge bien complétement, comme une nouvelle application JQM, avec le résultat attendu, mais c'est un peu dommage. Cependant il est possible de +/- contourner ce principe, en indiquant à JQM (attribut data-ajax="false" dan sles balises <a ...>) que le document joint est indépendant. Mais de mon point de vue, c'est assez improductif de procéder de la sorte. L'autre solution, c'est simplement de penser l'application comme une seule page, et d'aller systématiquement chercher les contenus dynamiques en AJAX. De mon expérience, ce n'est pas un problème et permet même une meilleure séparation de la logique métier (coté serveur) et de l'affichage.
Pour contribuer
2 url pour commencer sur Emerginov (faut avoir un compte de dev)
Relation avec Beewatch
@cedricbou
Liste des composants
-MPX 5100 : http://www.conrad.fr/ce/fr/product/183890/Capteur-de-pression-differentielle-MPX-5100-DP
- 2 sachets de Pompote
- 50 cm de tuyau pour le circuit hydraulique
Communication autour du projet
Bzz au carrefour des possibles
Une petite vidéo de présentation du projet Bzzz au carrefour des possibles Video Vimeo
Le télégramme de novembre 2013 Explication du dispositif au Télégramme en novembre 2013 disponible en vidéo
Liens utiles
site de test (login test mdp <rien> )