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 ^^).

Le but de ce projet est de proposer gratuitement à tout apiculteur amateur un peu bricoleur les plans d'un kit de suivi des ruches.

La description du projet est visible dans le fichier:Fichier:Projet Bzzz.pdf

Planning

premier proto Juin 2013

Réunion avancement : tous les mardis midi de 12H30 à 14H00 (salle FabLab lycée Le Dantec).

Structuration du projet et Membres associés

Brevet

@joc, @colvert

Le Cube

Capteur masse

@charg, @yann

Todo: Détailler le travail sur les capteurs (solutions envisagées, pour et contre)

Capteur jauge de déformation

pont de wheastone + amplification

Capteur jauge de déformation: A voir le modèle

Pont de wheastone: Définir la valeur des résistance

Amplification: Utilisation d'un AD620 (datasheet)

Capteur de pression

La pression est transmise depuis le support jusqu'au capteur en utilisant un liquide

A discuter: liquide à y insérer, car celui ci ne doit pas s'évaporer, ni geler.

TODO : Référence + datasheet du capteur + montage elec en sortie + Fct de transfer tension/kg

Utilisation d'une bouteille remplie d'eau

Proposition de l'assemblage:

4 bouteilles souples (type Cola) reliées à un capteur de pression.

Un robinet de purge est présent pour vider les bulles d'air.

Avancement 22/05/2013: test d'un capteur bouteille:

Utilisation de Pompote

L'utilisation de 2 sachets de Pompote remplis d'eau relié au capteur de pression a été validé.

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

Capteur de pression imprimé

Photo de l'avancement le 22/04/2013 côtés Capteur de pression imprimé:

L'impression 3D du capteur n'a pas donné un bon résultat, en effet le capteur n'est pas étanche

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.

La boîte (Plans et réalisation proto)

@charg, @joc

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 [1] 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é [2] + 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

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

ruche id = 100* Rucher Id + Id ruche ex 304 = 4ème ruche du rucher 3 => id unique

Gestion du SMS

Le SMS permet de collecter les infos de sondes on peut simuler l'envoi de SMS d'une ruche

soit en envoyant un SMS au 0645 113 265

le SMS doit être formaté comme suit

Bz 403 65.8 15.2 0.65

ce qui signifie la ruche 403 remonte la donnée 1 (MASSE) 65.8, la donnée 2 (TEMP) 15.2, la donnée 3 (HUMIDITE) et la donnée 4 (SON). le prefix est indispensable pour retrouver le service Bzzz

soit en simulant tout ça en envoyant une requète du style

http://projects.emerginov.org/Bzzz/smsreceiver.php?SOA=0614789123&Content=Bz+403+65.8+15.2+0.65

on peut multiplexer les données dans le SMS en séparant les jeux de valeur par le caractère *

Bz 403 65.8 15.2 0.65*1101 56.4 - 4.9 6.1*701 34 - - 5

- ruche 3 du rucher 4: 65.8kg, 15.2°, 0.65 (humidité) - ruche 1 du rucher 11: 56.4kg, 4.9 (humidité), 6.1db - ruche 1 du rucher 7: 34kg, 5db

l'ordre est important 1) MASSE 2) TEMPERATURE 3) HUMIDITE 4) SON

Gestion Ethernet

même principe que le SMS on peu ne pas simplifier la requête si on veut.. http://projects.emerginov.org/Bzzz/smsreceiver.php?Content=403+65.8+15.2+0.65

pour le moment on répond ok ou ko (pas de données)

Librairies

jquery mobile
leaflet: carto openstreetmap pour la localisation d'un rucher (adLocalisation.php)
jqplot: pour grapher les résultats des sondes (stats.php)

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
intégration avec sensonet (appli de gestion de réseau de capteurs développée par Benoît H.)
commentaire code
gérer le système d'alerting (partiel)

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:

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

Questions aux apiculteurs

delta masses d'une ruche

Question: JOC nous a indiqué un delta de masse de l'ordre de 2kg en cas d'essaimage, quid du delta journalier lié au butinage? En journée quelle proportion est sortie?

Réponse: Par rapport à la masse de référence journalière (mesurée à0H00) une bonne ruche voit sortir de 2000 à 4000 butineuses (i.e de 0,2 à 0,4 kg) soit en maximisant la variation naturelle peut être MasserefJour-0,5kg

Miel

Question: sur une ruche en fonction du temps, a-t-on une idée de la masse de miel produite?

Réponse: si la question est quelle la variation naturelle positive d’une ruche en une journée (rentrée de nectar, d’eau, de pollen, de propolis, d’abeilles qui dérivent …)? on peut l’estimer MasserefJour +1kg. Le miel est récolté par l’apiculteur une à deux fois/an (récolte éventuelle printanière en juin, récolte de l’année fin août) Mais de tout façon cela fait partie du travail de l’apiculteur au rucher et donc il inhibera les alarmes ce jour-là (il faut d’ailleurs prévoir une fin automatique de l’inhibition qui pourrait se faire juste après la mesure de référence soit à 0h01) Enfin pour répondre à ta question : sur une ruche on peut récolter disons, de 0 à 90kg suivant son type, emplacement, région , conditions météo, conduite du rucher par l’apiculteur expérimenté ou non, qualité de la reine, variété d’abeilles …. En Bretagne on pourrait partir en moyenne 15/20kg avec un écart-type de 10kg

Alarme

Question: systèem actuel basé sur une comparaison flottante, est ce ok?

Réponse: A mon sens il n’est pas nécessaire de prendre une référence journalière glissante (une ruche qui essaime ne va pas ou peu rentrer de nectar), pour moi il suffit que la référence journalière soit le poids de la ruche à 0h00 (toutes les abeilles sont à l’intérieur), et on déclenche simplement l’alerte à MasserefJour -1,5 ou -2kg. Maintenant c’est important d’alerter à bon escient et rapidement :

aussi pour éviter  de déclencher l’alarme intempestivement s’il y a une mauvaise mesure, tu peux effectivement déclencher l’alarme que si deux mesures consécutives sont au-delà de ce seuil.
Ce qui avec l’hypothèse que les mesures sont faites toutes les 5 minutes, on alarme au max 10 minutes après l’incident, ce qui est compatible avec le temps qu’a l’apiculteur pour récupérer l’essaim en cas d’essaimage (entre ½ heure et une heure max).

Liens utiles

site de test (login test mdp <rien> )

Code

code serveur