Logo projet Bzzz

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

Schématisation du fonctionnement du projet Bzzz

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:
- Le télégramme de novembre 2013
- Explication du dispositif au Télégramme en novembre 2013 disponible en vidéo] (une présentation improvisé pour l'occasion)

Les évolutions possibles sont notées dans la partie ToDoList (amélioration, bug à corriger, ajout de capteurs, multi-ruche, etc...).

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 2013: Todo: Mise à jour de la documentation, Test d'autonomie sur puce Atmel.
Février 2013: Todo: Test du prototype et Contacter les béta-testeurs qui se sont manifestés.
Mars 2013: Todo: A définir (mise en place des béta-tests) ...

Brevet

Les recherches effectuées n'ont montrées aucune contre indication au niveau des brevets existants.

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 ont été discutés dans la partie discussion du projet)

Supervision pour un rucher monoruche

- Etude de cout et mise en oeuvre à faire (systeme homemade pour la baisse des couts)

- 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 monoruche sera validée)

- Etude de cout et mise en oeuvre à 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

Rucher sous couverture GSM

- Etude de cout et mise en oeuvre à faire

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.

Communication entre le rucher et internet

@laurent, @guillaume.remy

WiFi : Si le rucher est à proximité d'une maison

GSM : Envoi de SMS, couverture nationale

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

@david @nicolas
Aperçu du code arduino pour une unique ruche (capteur et envoi de SMS): File:Bzzz_Proto_v0.2.txt

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>

le menu principal (tous les ruchers)

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.