« Suivi des ruches » : différence entre les versions

De Kernel Fablab Lannion
mAucun résumé des modifications
 
(143 versions intermédiaires par 10 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
[[Fichier:Bzzz-logo fond blanc.jpg|thumb|Logo projet Bzzz]]
[[Fichier:Bzzz-logo fond blanc.jpg|thumb|Logo projet Bzzz]]


= Présentation =
= 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.


Voir le fichier:[[Fichier:Projet Bzzz.pdf|thumb|Presentation V0]]
Le projet Bzzz (Bee Zen Cube) est un projet de suivi de ruches pour une apiculture plus anticipative, il a pour but de proposer gratuitement à tout apiculteur amateur les plans d'un kit de supervision de son rucher (châssis de mesure autonome, et si le prix des émetteurs LoRa reste élevé réaliser une station d'émission qui centraliserait plusieurs châssis secondaires). Le projet Bzzz suit l'évolution de la santé de la ruche à distance, principalement par la mesure des variations de poids, la température locale et donner l'alerte en cas d'essaimage ou surtout, de la préparation de l'essaimage. On fait tout cela pour éviter de multiples déplacements de l'apiculteur.


mis à jour [[Utilisateur:Joc|Joc]] ([[Discussion utilisateur:Joc|discussion]]) 9 avril 2013 à 12:43 (UTC)
Le projet Bzzz est un projet [http://fr.wikipedia.org/wiki/Open_source Open-source] et [http://en.wikipedia.org/wiki/Open-source_hardware Open-hardware]


= Planning  =
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 fait 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.<br />
premier proto Juin 2013


Réunion avancement : tous les mardis midi de 12H30 à 14H00 (salle FABLAB à l'ADIT zone ANTICIPA).
<br />


= Structuration du projet et Membres associés =
= Participants =
<div class="toccolours mw-collapsible mw-collapsed">
<div class="mw-collapsible-content">
* Bernard Arzur
* Frédéric Carré
* David Blaisonneau
* Thierry Houdouin
* Jérôme Labidurie
* Tangi Lavanant
* François-Xavier Potel
* Morgan Richomme
</div>
</div>
= Chassis / Capteurs =


== Brevet ==
Porteur: Bernard
@joc, @colvert


== Le Cube ==
== Module Chassis ==
===Demi-Chassis (abandonné)===
* Une seule jauge de contrainte (50 kg) par capteur/demi-chassis(diminution du prix)
* On accède au paramètre de variation du poids
* La valeur absolue du poids de la ruche n'est pas connue
* On peut voir le shield W6Labs associé à un Arduino UNO et un HX711.
[[File:DemiRuche.jpeg|400px]]
[[Fichier:DSCF1946.jpg|400px]]


=== Capteur masse ===
===2 Demi-Chassis (abandonné) ===
@charg, @yann
*Le support associé est remplacé par un 2éme demi-chassis
* Le poids exact est connu par la somme des 2 valeurs issues des 2 capteurs
* Le coût est un peu plus élevé


=== La boîte (Plans et réalisation proto) ===
@charg, @joc


=== Energie ===
@david.blaisonneau, @cedricbou


=== Architecture Filaire versus Sans fil (WiFi/ZigBee/autre) ===
===Chassis autonome===
@laurent, @guillaume.remy


Solutions de transmission Sans-Fil :
Cette solution, simple, a été rendue possible par la forte baisse du prix des composants (LoRa, jauges, ...) et aussi par la réduction drastique de la consommation du Lopy4 en mode veille (=> abandon de l'Arduino associé à une carte économiseur).
* Quatre jauges de contrainte par châssis.
* On accède aux paramètres de poids dans l'absolu, de la variation du poids, et aussi du centre de gravité (placement de l'essaim dans la ruche et des cadres remplis).
* La valeur absolue du poids de la ruche est connue, mais il ne faut pas oublier la variation due à l'humidité du bois (peut monter à 15% du poids du bois de la ruche) et la correction nécessaire pour compenser les écarts thermiques. Comme on mesure des microvolts, le moindre effet de couple thermo-électrique est largement amplifié : éviter soudures, connectiques...


ZigBee : Collecte locale entre les ruches d'un rucher
<big>Cahier des Charges :</big>


WiFi : Si le rucher est à proximité d'une maison
-système autonome pendant une année entière


GSM : Envoi de SMS, couverture nationale
-l'ensemble des composants doit fonctionner entre -30°C et +70°C


Réseau dédié M2M bas débit : http://www.sigfox.com/ couvre apparemment la France métropolitaine
-une mesure toutes les 10 minutes, y compris pendant la nuit (éviter le vol de ruche), soit ~50 000 mesures/an


== Serveur Collecte et Affichage Smartphone ==
-précision souhaitée : 10 grammes (100 abeilles) pour une masse maximum de 100 kg
@colvert, @benoitb


=== Nano spec ===
-compatibilité avec la norme LoRa (durées et fréquences d'émission)
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 ====
-coût inférieur à 100 €
le petit modèle objet peut être décrit comme suit
[[File:Bzz SQL model.png|400px]]


Le serveur est développé en jquery model histoire d'être visualisable indiféremment sur PC, tablette ou smartphone.
-pas de câbles ni fils visibles


==== Fichiers ====
-hauteur maximum 30 mm
l'arborescence fichier simplifiée peut être vue comme suit:
[[File:Bzzz spec.png|400px]]


'''Nommage des ruches'''
-gestion simple


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


'''Gestion du SMS'''
*Il est connu à 10 grammes près, sur une plage de  0 à 100 kg, avec des jauges de 20 kg. Si on vise au-delà de 80 kg (4*20kg), il existe des jauges de 50 kg beaucoup plus coûteuses et forcément un peu moins précises.
*Mesuré par une jauge de contrainte résistive connectée en un pont de Wheatstone [https://fr.wikipedia.org/wiki/Jauge_de_d%C3%A9formation]
*Numérisation de la mesure (0-10mV) par un module HX711 (convertisseur analogique/numérique à 24 bits de précision)
*Le module HX711 est connecté au plus près de la jauge, pour éviter les interférences électromagnétiques et les effets thermiques (thermo-couple). Les effets thermiques sur la résistance de mesure sont en principe compensés par l'utilisation d'une autre résistance montée en orthogonal sur la jauge.
*Le module HX711 est connecté au module d'émission IoT, qui peut donc en recevoir plusieurs. Avec Lopy, il a été impossible d'utiliser un canal de données commun (DOUT), alors qu'avec Arduino, cela fonctionne. Comme on dispose d'assez d'entrées/sorties, la question se résout facilement : chaque HX prend une entrée (DOUT) et une sortie (SCK).


Le SMS permet de collectzer les infos de sondes
= Arrachage / Vol =
on peut simuler l'envoi de SMS d'une ruche
Alarme au bout de 10 minutes maximum, sur variation de poids brutale
* 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 et la donnée 3 (??)
* soit en simulat 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 pourra par la suite multiplexer les données dans le sms => traitement à adapter dans smsreceiver.php et misfunctions.php (pour le moment on transforme le texte du SMS dan un tableau. Sur l'exemple précédent on appelle la fonction addData en passant le tableau ([Bz, 403, 65.8, 15.2, 0.65])
Alarme instantanée sur capteur de contact, optionnel


'''Librairies'''
= Châssis autonome (Mesure et Émission) =
* jquery mobile
* [http://leafletjs.com/ leaflet]: carto [http://openstreetmap.fr/ openstreetmap] pour la localisation d'un rucher (adLocalisation.php)
* [http://www.jqplot.com/ jqplot]: pour grapher les résultats des sondes (stats.php)


=== Todo liste ===
==Boitier==


==== A faire: ====
L'idée, au départ, était d'avoir un boîtier avec émetteur RF qui collecte plusieurs balances sans émetteur, voire sans batterie, vu le prix élevé des composants à ce moment...
* 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 [http://projects.emerginov.org/sensonet/ sensonet] (appli de gestion de réseau de capteurs developpée par Benoit)
* commentaire code
* fonction edit_rucher (modifier descriptif / localisation / propriétaire)
* comprendre pouquoi la carte et les graphs ne se chargent pas avec la page (besoin de reforcer le chargement de la page)
* choix pour l'utilisateur du mode d'alerte (SMS, mail, appel) - partiellement fait
* gérer le système d'alerting


==== en option ====
*Il doit être étanche, résistant car il restera à l'extérieur plusieurs années.
* 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)
*Il doit donc être de catégorie IP64 au moins. Nous avons choisi IP65 pour une meilleure fiabilité à long terme.
* IVR (kiosque vocale de consultation et/ou appelle le responsable du rucher en cas d'alerte en plus du SMS)
*Ce boîtier contiendra :
* des stats annuels / mensuels / comparatives ruche
** L'alimentation électrique (batterie lithium + carte économiseur)
* gestion du filtre pour l'affichage des ruches (sinon si y a 20 ruches dans un rucher la page va être un peu longue...)
** Arduino + carte Lora
** Antenne


==== Fait: ====
*Nous avons donc choisi un boîtier "Raccordement Fibre Optique" qui permet d'ajouter facilement des entrées-sorties -> abandon, on ne veut plus de fils/cables autour de la ruche, pour des raisons de sécurité et de fiabilité.
* 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)


=== Pour contribuer ===
==Alimentation solution Arduino==
2 url pour commencer sur Emerginov (faut avoir un compte de dev)
* Batterie de 4 éléments de 2800mAh
* http://www.emerginov.org/main_authen/selfcare.php
* La carte économiseur (basée sur 3 relais basse consommation Reed et un Ampli-Op LM324)  permet de diviser la consommation par 100 :
* http://developers.emerginov.org/
** 1 mA en consommation moyenne > 6 mois d'autonomie prévue
** 0.6mA au repos
** 120mA en émission (qq secondes toutes les 10 min)
Cependant, l'autonomie obtenue est insuffisante et la carte économiseur revient cher (>20€).


== Relation avec Beewatch ==
==Alimentation solution Lopy==
@cedricbou


Solution retenue : 3 Batteries de 3000mAh
La carte Lopy4 (pas toutes les versions, malheureusement!) dispose d'une mise en veille profonde : elle coupe l'alimentation du processeur principal, et la consommation chute à une valeur très faible, entre 20 µA et 200µA. Cette consommation varie à la hausse si on utilise la carte Expansion Board pour connecter le Lopy4.
On essaiera de s'affranchir de cette carte, à cause de son prix (~20€), de sa conso (due entre autre autres au pont diviseur pour mesurer la tension batterie) et des limitations du chargeur de batterie (500 mA max).
On la remplace par un circuit de charge, un pont diviseur de haute impédance et on soude directement le Lopy sur le circuit imprimé.
Pour se maintenir en veille, les HX711 ont besoin d'être polarisés en tension sur la broche SCK, il faut monter des résistances de pull-up d'environ 1 MOhm entre SCK et +3.3V. Sinon, chaque HX711 pourrait rajouter 8 mA à la consommation de veille.
** 10 000 heures(~une année) au repos représentent donc, pour 100µA ->  1000 mAh
** Lorsque Lopy4 se réveille, il doit recompiler son code : ça prend entre 2,5 s (70 lignes) et 3.5 s (250 lignes) selon la complexité du programme et l'appel aux différentes bibliothèques. Puis il effectue la mesure de poids et envoie le paquet LoRa.
La durée de transmission LoRa est minimisée en configuration RAW : on transmet le paquet en clair vers un récepteur calé sur la même fréquence. Le type de trame est le suivant : "labeld4212dbzz3d284d452d406d233d", soit 32 à 40 octets, label permet d'identifier que c'est notre trame, d est le délimiteur avec le champ suivant qui est la tension batterie, bzz3 est le nom de la ruche tel qu'on l'a défini sur TTN par exemple, puis les quatre poids en grammes. La somme des 4 donne le poids total et sa position en 2D.
On peut transmettre en APB vers une GateWay de TTN par exemple. On envoie d'abord plusieurs champs que TTN aura calculé au préalable : un champ de 8 octets pour l'identité d'émetteur, un champ de 32 octets pour l'application et un champ de 32 octets pour l'identité du réseau. Et puis, on envoie notre trame sans le champ label, qui est remplacé par les champs TTN. On devine que ce deuxième mode APB sera un peu plus lent et plus gourmand en énergie et bande passante(70 octets de plus) et pas forcément compatible avec les critères LoRa.
Le mode OTAA n'a pas été considéré, il nécessite régulièrement un échange bidirectionnel avec la GateWay de TTN pour maintenir notre émetteur sur le réseau TTN, entraînant une surconsommation d'énergie.
Le courant absorbé varie durant le cycle entre 40 mA (compilation), 140 mA (mesure) et 200 mA (envoi paquet LoRa), avec une moyenne à 120 mA pour un cycle de 14s. Pour 5 s, l'intensité moyenne devrait être plus basse (à vérifier), puisque le % du à la compilation est plus grand.
[[:File:integration_intensite_lopy_pour_un_cycle.jpg]]
Si on veut faire 50 000 mesures, elles vont durer 50 000 *(3.5s + 1.5s) / 3600 = 70 heures, soit 8300 mAh avec une consommation de 120 mA.
** il faudra donc (1000 + 8300) = ~9000mAh, soit 3 batteries de 3000 mAh.
On ne tient pas compte de l'auto-décharge, qui est faible avec les batteries Lithium.
==Arduino Lora==
Actuellement il y a 3 pistes:
* LoRa + Arduino : abandon, prix shield >> et conso >>
* LoRa + Lopy : retenue
* LoRa + ESP32 : à creuser, retenue pour Projet Macareux qui est très similaire
=== Lora + Arduino ===
*Le module HX711 émet un signal numérique sur la broche DOUT (data out) lorsqu'il est piloté par la broche SCK.
* Il est connecté sur les broches I/O de l’Arduino
* On peut mettre 4 HX711 sur l’Arduino en l'état actuel, à voir si on peut multiplexer les capteurs sur 2 broches. Pas utile en fait, il y a assez de broches sur Arduino ou Lopy.
* Le module LoRa (shield W6Labs, Rennes)[https://froggyfactory.com/shop.php#shop : carte pour Arduino], utilise les pins 10-11-12-13
=== LoRa mDot ===
Piste abandonnée : MTDOT-868-X1P-SMA-1 - http://www.multitech.com/models/94557138LF
== Conformité à LoRa ==
La norme LoRa impose deux critères : temps d'occupation global de l'espace aérien (airtime de 30 secondes par jour pour TTN) et temps d'occupation d'une sous-bande de 1%. Voir par exemple : https://forum.thethingsnetwork.org/t/limitations-data-rate-packet-size-30-seconds-day-fair-access-policy-nodes-per-gateway/1300
Trame LoRa : il y a  13 octets pour l'encapsulation WAN  (qui peut monter à 23 o en cas de join request,
voire jusqu'à 28 o ), mais il ne faut pas oublier les 10,25 temps symboles du préambule de la couche physique (en SF8 ça fait 10 o), avec en plus 5 o optionnels pour header et CRC, soit minimum de 23 octets pouvant aller à 43 o.
cf : https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5038744/
Avec le calculateur joint [[:File:LoRa(WAN) airtime calculator.ods]] , en SF8, on trouve que la ruche peut émettre 323 mesures de 2 octets par jour, 224 mesures de 20 o et 182 à 30 octets, compatible avec un cycle de 10 minutes (24*6=144).
Les durées d'émission, en SF8, iraient de 92 ms à 164 ms pour une payload (charge utile) de 2 à 30 o.
En bref, jusqu'à 30 octets, on peut presque négliger l'importance de la payload....
== Fiabilité ==
La fiabilité recouvre plusieurs aspects :
* fiabilité physique des composants (en particulier de la batterie, qui pourrait vieillir assez vite)
* fiabilité logicielle : on a vu que l'on faisait 50 000 mesures par an, soit 50 000 fois la compilation. Sur les premières versions de Lopy4, au bout de 500-2000 mesures, celui "plante" une fois pendant la compilation, reste dans un état intermédiaire (le chien de garde qui "tourne" sur le logiciel actif est alors inopérant) et vide la batterie en quelques jours. La dernière version semble mieux se comporter...
* fiabilité des mesures : il ne s'agit pas de lancer des alarmes à tort et à travers, à tout moment, à cause d'une mauvaise mesure. La programmation des HX711 a due être revue pour obtenir une bien meilleure fiabilité.
Il y a quelques fois des mesures hors norme, mais on peut les rejeter en les opposant aux valeurs des trois autres capteurs. Si trois capteurs sont stables et que le quatrième s'égare, on déclare la mesure fausse et on attend un cycle.
== Web ==
Porteur: David
=== Principe ===
* L'utilisateur ajoute une ruche > un module > N capteurs
* L'utilisateur configure chaque capteur si besoin (tare, échelle)
* L'utilisateur configure le seuil de déclenchement des alertes
* Le site web recoit les données brutes des capteurs via la passerelle et les transforme en données utile si besoin
* Le site web graph les données
* Le site web alerte l'utilisateur si un seuil est franchi.
=== Taches ===
Fait:
* base Web2Py
* Site de base avec authentification
* Modèle de données
* API Rest
TODO:
* Restreindre l'accès à une partie de l'API -> NOK
* Ajouter la fonction de déclaration de la tare -> se fait dans le fichier config.py associé à chaque Lopy
* Ajouter la fonction de transformation de donnée brute en donnée normée -> NOK. Est ce utile? Les données sont envoyées en grammes.
* Grapher les données des capteurs -> OK en local (cf fichier joint), NOK sur TTN + ATTM
* Ajouter les fonctions web d'ajout/suppression/modification de ruches/capteurs/modules -> NOK
lien :
http://letmeknow.fr/blog/2015/10/27/tutomodulelora/
==Liste du matériel-Coût==
L'ensemble des composants doit fonctionner entre -30° C et +70°
===Configuration Point à point===
voir le fichier pour les composants
[[:File:composants_balance_ruche_bzzz.odt]]
et un devis estimatif sur:
[[:File:septembre_2019__ruche.ods]]
* Récepteur Arduino/Lora : 50€ qui peut servir pour x émetteurs à portée (c'est un Lopy connecté à un PC ou configuré en GateWay)
* Pas de coûts d'utilisation des réseaux Lora
Total : environ 90 € TTC pour un chassis autonome
== Liens Web ==
Logiciels pour Lopy et Arduino : https://github.com/bernardarzur/bzzz
Arduino : choisir tx_rx_v_3_simplifiée.ino
Lopy: choisir boot.py (RX comme récepteur point à point)ou boot_sans_wifi.py (TX comme émetteur) selon que l'on est en mode local ou distant, main.py (correspond à version_v_18), config.py (correspond à version_v_18) et HX711.py
Présentation du projet Bzz en juin 2019  [[:File:bzz_2019.odp]]
Présentation du projet Bzz en 2018 [[:File:BZZZ_2.pptx]]
Balance connectées pour ruches : http://itsap.asso.fr/outils/balances-automatiques/
http://makerspace56.org/wiki/asso-wiki/projets/la-ruche-connectee/capteurs-et-composants/
https://www.thethingsnetwork.org/forum/t/the-beehive-topic/25599/37
https://makerslab.em-lyon.com/makers-beehive.html
= Communication autour du projet =
La présentation de l'idée de départ:[[Fichier:Projet Bzzz.pdf|thumb|Presentation V0]]
[http://fablab-lannion.org/2013/06/le-fablab-selectionne-pour-les-carrefours-des-possibles-avec-bzzz/ Bzz au carrefour des possibles]
[http://www.youtube.com/watch?v=rTx5RfXS9_4 Une petite vidéo de présentation du projet Bzzz au carrefour des possibles]
[http://vimeo.com/69476342#at=0 Video Vimeo]
[http://fing.org/?Les-10-projets-du-CDP-Bretagne Les 10 projets Juin 2013]
[http://www.letelegramme.fr/local/cotes-d-armor/lannion-paimpol/ville/fablab-les-abeilles-font-le-buzz-a-la-ruche-13-11-2013-2300993.php Le télégramme de novembre 2013]
[http://www.dailymotion.com/video/x16yp5y_lannion-le-projet-bzzz-a-son-prototype Explication du dispositif au Télégramme en novembre 2013 disponible en vidéo]
<div class="mw-collapsible-content">
= Liens utiles =
= Liens utiles =


Ligne 125 : Ligne 271 :


[https://svn.emerginov.org/listing.php?repname=Bzzz code serveur]
[https://svn.emerginov.org/listing.php?repname=Bzzz code serveur]
[https://github.com/bernardarzur/bzzz]
== Photos ==
<gallery>
DSCF1946.jpg|Ruche demi-châssis supervisée (Rucher Orange-Lannion)
DSCF1949.jpg|Boîtier Étanche
DSCF1948.jpg|Boîtier Étanche
DSCF1957.JPG|Boîtier Étanche
DSCF1956.JPG|Ruche demi-châssis supervisée
DSCF1955.JPG|Ruche demi-châssis supervisée
DSCF1954.JPG|Ruche demi-châssis supervisée
Attention_au_merle_DSCF2228.JPG|Pèse-ruche autonome Arduino
</gallery>
[[Category:Projet]]
[[Category:LoRa]]

Version actuelle datée du 19 septembre 2020 à 08:49

Logo projet Bzzz


Présentation

Le projet Bzzz (Bee Zen Cube) est un projet de suivi de ruches pour une apiculture plus anticipative, il a pour but de proposer gratuitement à tout apiculteur amateur les plans d'un kit de supervision de son rucher (châssis de mesure autonome, et si le prix des émetteurs LoRa reste élevé réaliser une station d'émission qui centraliserait plusieurs châssis secondaires). Le projet Bzzz suit l'évolution de la santé de la ruche à distance, principalement par la mesure des variations de poids, la température locale et donner l'alerte en cas d'essaimage ou surtout, de la préparation de l'essaimage. On fait tout cela pour éviter de multiples déplacements de l'apiculteur.

Le projet Bzzz est un projet Open-source et Open-hardware

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 fait 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.


Participants

  • Bernard Arzur
  • Frédéric Carré
  • David Blaisonneau
  • Thierry Houdouin
  • Jérôme Labidurie
  • Tangi Lavanant
  • François-Xavier Potel
  • Morgan Richomme

Chassis / Capteurs

Porteur: Bernard

Module Chassis

Demi-Chassis (abandonné)

  • Une seule jauge de contrainte (50 kg) par capteur/demi-chassis(diminution du prix)
  • On accède au paramètre de variation du poids
  • La valeur absolue du poids de la ruche n'est pas connue
  • On peut voir le shield W6Labs associé à un Arduino UNO et un HX711.

DemiRuche.jpeg DSCF1946.jpg

2 Demi-Chassis (abandonné)

  • Le support associé est remplacé par un 2éme demi-chassis
  • Le poids exact est connu par la somme des 2 valeurs issues des 2 capteurs
  • Le coût est un peu plus élevé


Chassis autonome

Cette solution, simple, a été rendue possible par la forte baisse du prix des composants (LoRa, jauges, ...) et aussi par la réduction drastique de la consommation du Lopy4 en mode veille (=> abandon de l'Arduino associé à une carte économiseur).

  • Quatre jauges de contrainte par châssis.
  • On accède aux paramètres de poids dans l'absolu, de la variation du poids, et aussi du centre de gravité (placement de l'essaim dans la ruche et des cadres remplis).
  • La valeur absolue du poids de la ruche est connue, mais il ne faut pas oublier la variation due à l'humidité du bois (peut monter à 15% du poids du bois de la ruche) et la correction nécessaire pour compenser les écarts thermiques. Comme on mesure des microvolts, le moindre effet de couple thermo-électrique est largement amplifié : éviter soudures, connectiques...

Cahier des Charges :

-système autonome pendant une année entière

-l'ensemble des composants doit fonctionner entre -30°C et +70°C

-une mesure toutes les 10 minutes, y compris pendant la nuit (éviter le vol de ruche), soit ~50 000 mesures/an

-précision souhaitée : 10 grammes (100 abeilles) pour une masse maximum de 100 kg

-compatibilité avec la norme LoRa (durées et fréquences d'émission)

-coût inférieur à 100 €

-pas de câbles ni fils visibles

-hauteur maximum 30 mm

-gestion simple

Mesure du poids

  • Il est connu à 10 grammes près, sur une plage de 0 à 100 kg, avec des jauges de 20 kg. Si on vise au-delà de 80 kg (4*20kg), il existe des jauges de 50 kg beaucoup plus coûteuses et forcément un peu moins précises.
  • Mesuré par une jauge de contrainte résistive connectée en un pont de Wheatstone [1]
  • Numérisation de la mesure (0-10mV) par un module HX711 (convertisseur analogique/numérique à 24 bits de précision)
  • Le module HX711 est connecté au plus près de la jauge, pour éviter les interférences électromagnétiques et les effets thermiques (thermo-couple). Les effets thermiques sur la résistance de mesure sont en principe compensés par l'utilisation d'une autre résistance montée en orthogonal sur la jauge.
  • Le module HX711 est connecté au module d'émission IoT, qui peut donc en recevoir plusieurs. Avec Lopy, il a été impossible d'utiliser un canal de données commun (DOUT), alors qu'avec Arduino, cela fonctionne. Comme on dispose d'assez d'entrées/sorties, la question se résout facilement : chaque HX prend une entrée (DOUT) et une sortie (SCK).

Arrachage / Vol

Alarme au bout de 10 minutes maximum, sur variation de poids brutale

Alarme instantanée sur capteur de contact, optionnel

Châssis autonome (Mesure et Émission)

Boitier

L'idée, au départ, était d'avoir un boîtier avec émetteur RF qui collecte plusieurs balances sans émetteur, voire sans batterie, vu le prix élevé des composants à ce moment...

  • Il doit être étanche, résistant car il restera à l'extérieur plusieurs années.
  • Il doit donc être de catégorie IP64 au moins. Nous avons choisi IP65 pour une meilleure fiabilité à long terme.
  • Ce boîtier contiendra :
    • L'alimentation électrique (batterie lithium + carte économiseur)
    • Arduino + carte Lora
    • Antenne
  • Nous avons donc choisi un boîtier "Raccordement Fibre Optique" qui permet d'ajouter facilement des entrées-sorties -> abandon, on ne veut plus de fils/cables autour de la ruche, pour des raisons de sécurité et de fiabilité.

Alimentation solution Arduino

  • Batterie de 4 éléments de 2800mAh
  • La carte économiseur (basée sur 3 relais basse consommation Reed et un Ampli-Op LM324) permet de diviser la consommation par 100 :
    • 1 mA en consommation moyenne > 6 mois d'autonomie prévue
    • 0.6mA au repos
    • 120mA en émission (qq secondes toutes les 10 min)

Cependant, l'autonomie obtenue est insuffisante et la carte économiseur revient cher (>20€).

Alimentation solution Lopy

Solution retenue : 3 Batteries de 3000mAh

La carte Lopy4 (pas toutes les versions, malheureusement!) dispose d'une mise en veille profonde : elle coupe l'alimentation du processeur principal, et la consommation chute à une valeur très faible, entre 20 µA et 200µA. Cette consommation varie à la hausse si on utilise la carte Expansion Board pour connecter le Lopy4. On essaiera de s'affranchir de cette carte, à cause de son prix (~20€), de sa conso (due entre autre autres au pont diviseur pour mesurer la tension batterie) et des limitations du chargeur de batterie (500 mA max). On la remplace par un circuit de charge, un pont diviseur de haute impédance et on soude directement le Lopy sur le circuit imprimé.

Pour se maintenir en veille, les HX711 ont besoin d'être polarisés en tension sur la broche SCK, il faut monter des résistances de pull-up d'environ 1 MOhm entre SCK et +3.3V. Sinon, chaque HX711 pourrait rajouter 8 mA à la consommation de veille.


    • 10 000 heures(~une année) au repos représentent donc, pour 100µA -> 1000 mAh
    • Lorsque Lopy4 se réveille, il doit recompiler son code : ça prend entre 2,5 s (70 lignes) et 3.5 s (250 lignes) selon la complexité du programme et l'appel aux différentes bibliothèques. Puis il effectue la mesure de poids et envoie le paquet LoRa.

La durée de transmission LoRa est minimisée en configuration RAW : on transmet le paquet en clair vers un récepteur calé sur la même fréquence. Le type de trame est le suivant : "labeld4212dbzz3d284d452d406d233d", soit 32 à 40 octets, label permet d'identifier que c'est notre trame, d est le délimiteur avec le champ suivant qui est la tension batterie, bzz3 est le nom de la ruche tel qu'on l'a défini sur TTN par exemple, puis les quatre poids en grammes. La somme des 4 donne le poids total et sa position en 2D.

On peut transmettre en APB vers une GateWay de TTN par exemple. On envoie d'abord plusieurs champs que TTN aura calculé au préalable : un champ de 8 octets pour l'identité d'émetteur, un champ de 32 octets pour l'application et un champ de 32 octets pour l'identité du réseau. Et puis, on envoie notre trame sans le champ label, qui est remplacé par les champs TTN. On devine que ce deuxième mode APB sera un peu plus lent et plus gourmand en énergie et bande passante(70 octets de plus) et pas forcément compatible avec les critères LoRa.

Le mode OTAA n'a pas été considéré, il nécessite régulièrement un échange bidirectionnel avec la GateWay de TTN pour maintenir notre émetteur sur le réseau TTN, entraînant une surconsommation d'énergie.

Le courant absorbé varie durant le cycle entre 40 mA (compilation), 140 mA (mesure) et 200 mA (envoi paquet LoRa), avec une moyenne à 120 mA pour un cycle de 14s. Pour 5 s, l'intensité moyenne devrait être plus basse (à vérifier), puisque le % du à la compilation est plus grand.

File:integration_intensite_lopy_pour_un_cycle.jpg

Si on veut faire 50 000 mesures, elles vont durer 50 000 *(3.5s + 1.5s) / 3600 = 70 heures, soit 8300 mAh avec une consommation de 120 mA.


    • il faudra donc (1000 + 8300) = ~9000mAh, soit 3 batteries de 3000 mAh.

On ne tient pas compte de l'auto-décharge, qui est faible avec les batteries Lithium.

Arduino Lora

Actuellement il y a 3 pistes:

  • LoRa + Arduino : abandon, prix shield >> et conso >>
  • LoRa + Lopy : retenue
  • LoRa + ESP32 : à creuser, retenue pour Projet Macareux qui est très similaire

Lora + Arduino

  • Le module HX711 émet un signal numérique sur la broche DOUT (data out) lorsqu'il est piloté par la broche SCK.
  • Il est connecté sur les broches I/O de l’Arduino
  • On peut mettre 4 HX711 sur l’Arduino en l'état actuel, à voir si on peut multiplexer les capteurs sur 2 broches. Pas utile en fait, il y a assez de broches sur Arduino ou Lopy.
  • Le module LoRa (shield W6Labs, Rennes): carte pour Arduino, utilise les pins 10-11-12-13

LoRa mDot

Piste abandonnée : MTDOT-868-X1P-SMA-1 - http://www.multitech.com/models/94557138LF

Conformité à LoRa

La norme LoRa impose deux critères : temps d'occupation global de l'espace aérien (airtime de 30 secondes par jour pour TTN) et temps d'occupation d'une sous-bande de 1%. Voir par exemple : https://forum.thethingsnetwork.org/t/limitations-data-rate-packet-size-30-seconds-day-fair-access-policy-nodes-per-gateway/1300

Trame LoRa : il y a 13 octets pour l'encapsulation WAN (qui peut monter à 23 o en cas de join request, voire jusqu'à 28 o ), mais il ne faut pas oublier les 10,25 temps symboles du préambule de la couche physique (en SF8 ça fait 10 o), avec en plus 5 o optionnels pour header et CRC, soit minimum de 23 octets pouvant aller à 43 o. cf : https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5038744/

Avec le calculateur joint File:LoRa(WAN) airtime calculator.ods , en SF8, on trouve que la ruche peut émettre 323 mesures de 2 octets par jour, 224 mesures de 20 o et 182 à 30 octets, compatible avec un cycle de 10 minutes (24*6=144). Les durées d'émission, en SF8, iraient de 92 ms à 164 ms pour une payload (charge utile) de 2 à 30 o.

En bref, jusqu'à 30 octets, on peut presque négliger l'importance de la payload....

Fiabilité

La fiabilité recouvre plusieurs aspects :

  • fiabilité physique des composants (en particulier de la batterie, qui pourrait vieillir assez vite)
  • fiabilité logicielle : on a vu que l'on faisait 50 000 mesures par an, soit 50 000 fois la compilation. Sur les premières versions de Lopy4, au bout de 500-2000 mesures, celui "plante" une fois pendant la compilation, reste dans un état intermédiaire (le chien de garde qui "tourne" sur le logiciel actif est alors inopérant) et vide la batterie en quelques jours. La dernière version semble mieux se comporter...
  • fiabilité des mesures : il ne s'agit pas de lancer des alarmes à tort et à travers, à tout moment, à cause d'une mauvaise mesure. La programmation des HX711 a due être revue pour obtenir une bien meilleure fiabilité.

Il y a quelques fois des mesures hors norme, mais on peut les rejeter en les opposant aux valeurs des trois autres capteurs. Si trois capteurs sont stables et que le quatrième s'égare, on déclare la mesure fausse et on attend un cycle.

Web

Porteur: David

Principe

  • L'utilisateur ajoute une ruche > un module > N capteurs
  • L'utilisateur configure chaque capteur si besoin (tare, échelle)
  • L'utilisateur configure le seuil de déclenchement des alertes
  • Le site web recoit les données brutes des capteurs via la passerelle et les transforme en données utile si besoin
  • Le site web graph les données
  • Le site web alerte l'utilisateur si un seuil est franchi.

Taches

Fait:

  • base Web2Py
  • Site de base avec authentification
  • Modèle de données
  • API Rest

TODO:

  • Restreindre l'accès à une partie de l'API -> NOK
  • Ajouter la fonction de déclaration de la tare -> se fait dans le fichier config.py associé à chaque Lopy
  • Ajouter la fonction de transformation de donnée brute en donnée normée -> NOK. Est ce utile? Les données sont envoyées en grammes.
  • Grapher les données des capteurs -> OK en local (cf fichier joint), NOK sur TTN + ATTM
  • Ajouter les fonctions web d'ajout/suppression/modification de ruches/capteurs/modules -> NOK


lien : http://letmeknow.fr/blog/2015/10/27/tutomodulelora/

Liste du matériel-Coût

L'ensemble des composants doit fonctionner entre -30° C et +70°

Configuration Point à point

voir le fichier pour les composants

File:composants_balance_ruche_bzzz.odt

et un devis estimatif sur: File:septembre_2019__ruche.ods

  • Récepteur Arduino/Lora : 50€ qui peut servir pour x émetteurs à portée (c'est un Lopy connecté à un PC ou configuré en GateWay)
  • Pas de coûts d'utilisation des réseaux Lora

Total : environ 90 € TTC pour un chassis autonome

Liens Web

Logiciels pour Lopy et Arduino : https://github.com/bernardarzur/bzzz

Arduino : choisir tx_rx_v_3_simplifiée.ino

Lopy: choisir boot.py (RX comme récepteur point à point)ou boot_sans_wifi.py (TX comme émetteur) selon que l'on est en mode local ou distant, main.py (correspond à version_v_18), config.py (correspond à version_v_18) et HX711.py

Présentation du projet Bzz en juin 2019 File:bzz_2019.odp

Présentation du projet Bzz en 2018 File:BZZZ_2.pptx

Balance connectées pour ruches : http://itsap.asso.fr/outils/balances-automatiques/

http://makerspace56.org/wiki/asso-wiki/projets/la-ruche-connectee/capteurs-et-composants/

https://www.thethingsnetwork.org/forum/t/the-beehive-topic/25599/37

https://makerslab.em-lyon.com/makers-beehive.html

Communication autour du projet

La présentation de l'idée de départ:Fichier:Projet Bzzz.pdf

Bzz au carrefour des possibles

Une petite vidéo de présentation du projet Bzzz au carrefour des possibles Video Vimeo

Les 10 projets Juin 2013

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

Code

code serveur [2]


Photos