Suivi des ruches

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.

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

• 

  Ruche demi-châssis supervisée (Rucher Orange-Lannion)

• 

  Boîtier Étanche

• 

  Boîtier Étanche

• 

  Boîtier Étanche

• 

  Ruche demi-châssis supervisée

• 

  Ruche demi-châssis supervisée

• 

  Ruche demi-châssis supervisée

• 

  Pèse-ruche autonome Arduino