Balance connectée pour ruches :

[Evorlde]

Bonjour,

Je cherche à faire une balance connectée pur suivre le poids de mes ruches.
Étant développeur informatique, embarqué, C/C++ de profession toute la partie programmation ne me posera pas de problème.
Je ne peu malheureusement pas en dire autant de la partie électronique. Si je sais lire des plans de cartes électronique pour retrouver les infos GPIO et autre ça se limite en gros à ça.

J'aurai donc besoin que l'on me confirme/infirme mes hypothèse, idées de départ.

Les besoins du projets:
Je devrais pouvoir toutes les 30min environ faire et envoyé des.
__ Relevé de poids
__ Relevé de température extérieur
__ Relevé de température intérieur
__ Relevé de position GPS

De plus en cas de brusque changement de poids et ou ouverture (lié à un contacteur) : envoyer un message.
Tout cela 24H/24 et 7J/7 de façon autonome (faible coup en énergie) et en extérieur.


Pour le moment je comptais partir sur
__ Une carte ESP32 qui intègre le GPRS (pour envoyer mes données via la data mobile). https://www.cnx-software.com/2019/07...32-gprs-board/
__ 2 sondes de température DS18B20
__ 2 capteurs de force 50Kg CZL635-50

Mes questions :
1) Pensez-vous que la carte ESP32 soit un bon point de départ pour mon projet, surtout niveau faible conso ? Y a t-il plus adapté ?
2) Quelle alimentation dois-je utiliser pour alimenter mon système de façon a ce qu'il puisse tourner plusieurs mois sans intervention de ma part (remplacement/recharge de batterie) ?
3) Les capteurs de force CZL635-50 peuvent-ils être monté en duo pour atteindre un total de pesé de 100Kg ?
4) Le GPRS intégré à la carte ESP32 est-il suffisant pour transférer quelques datas toutes les 30min ?
5) Puis-je passer en radio plutôt qu'en GPRS ? En gros du GPRS/Radio lequel est le plus adapté à mon besoin ? Je ne connais pas la portée radio...et les avantages inconvénients par rapport au GPRS...
6) En quoi la température va telle jouer sur les capteurs de force ? Ils sont prévu pour une utilisation jusqu'a -10 degrès mais si il fait -20 ? Et plus généralement est ce que les variations de température vont grandement fosser les données. Car entre la nuit et la journée en plein soleil il peu y avoir facilement 30degrés d’écart en ressenti (quand le soleil tape sur le matos ça monte vite).
7) Est-il possible via GPRS/Radio de contacter le système via l’extérieur et demander un relevé en live ? Sorte de Wake on Wan...

D'avance merci pour vos retour,

Evorlde.
-----

[invitef86a6203]

ça ;
Une carte ESP32 qui intègre le GPRS 24h/24h
ET ça
de façon a ce qu'il puisse tourner plusieurs mois

Semble un peu incompatible, quand on veut tenir longtemps on essai de consommer peu.
Les téléphones qui passent leur temps à borner sans arrêt se déchargent en 2 jours voire moins...

Quant à la radio il faudrait savoir quel est le contexte, distance et environnement.

Pour le soft et les capteurs je commencerais à me renseigner si toutes les librairies sont disponibles, avant d'avoir à dépouiller le datasheet et se taper un ou plusieurs drivers pendant 1 mois...

[Evorlde]

Quand je dis 24H/24 et 7J/7 c'est bien sur en optimisant le code afin que le GPRS ne soit pas constamment connecté.
C'est du 24H/24 et 7J/7 en faisant 1 relevé toutes les 30min et donc un envoi toutes les 30min. Le reste du temps la board sera en hibernation.


Pour ce qui est de la radio, je suis à environ 700m de distance...

[invitef86a6203]

Quelle la consommation , pendant combien de temps ?
Elle boot en combien de temps ?
En cas d'urgence. Peut on activer rapidement une int quand on est en mode sleep , veille ou autre ?


Par exemple avec un raspberry qui boot en 3 minutes pour travailler quelques secondes , vraiment pas terrible...


la distance radio et environnement ?

[A voir en vidéo sur Futura]

[invitef86a6203]

il existe des modules radio FPV assez puissant (à mon avis interdit...sauf autorisation) , mais c'est pareil si c'est en plein bois , ça dépend de la météo , de la saison , etc... idem pour le téléphone !

[Jack]

Quelle la consommation , pendant combien de temps ?

Quelques µA en deep sleep mode.

Elle boot en combien de temps ?

Quelques secondes, il n'y a pas d'OS.

En cas d'urgence. Peut on activer rapidement une int quand on est en mode sleep , veille ou autre ?

Oui, c'est d'ailleurs comme ça qu'elle sort du deep sleep mode: on connecte la sortie du timer sur l'entrée d'interruption (ou RESET, je ne suis plus sur).

la distance radio et environnement ?

Je ne sais pas trop. Je compte justement faire quelques tests avec cette carte. Je dois attendre un peu afin de recevoir un cordon USB-C car j'avais zappé cette connectique, les ESP utilisant plutôt du micro USB.

[Jack]

@Evorlde: pour les problèmes d'autonomie, il faudra envisager un petit panneau solaire + batterie, car je pense que l'USB-C est signe de consommation importante lors de l'activation du GPRS.

[invitef86a6203]

Les panneaux solaires sont toujours surévalué par leur constructeur, il faut donc prévoir plus large.
Surtout s'il ne sont pas équipés de suiveur solaire.

Et ... ça attire l'attention car le vol de ruches est courant.

Mais le problème numéro un c'est la radio , est ce qu'elle fonctionnera quel que soit les conditions, temps couvert, brouillard, les feuilles l'été , la neige l'hiver etc ...

[adipie]

Bonjour,
Une autre alternative pour mesurer le poids.
https://www.instructables.com/id/Ard...d-Cells-and-H/
La carte ampli sort le poids en mode SPI vers un microcontrôleur.
Ayant réalisé un pesage pour 4 ruches il y a quelques années pour un ami apiculteur je peux confirmer :
Pour l'alimentation un capteur solaire 400 x 300 mm + régulateur de charge + batterie au plomb ont fait leurs preuves.
Un relevé du poids journalier est largement suffisant pour surveiller la ruche.
700 m pour la radio va être difficile, il faut faire un essai de portée par exemple avec ceci: https://www.ebay.fr/itm/Ebyte-SX1276...8AAOSwzvZdixEz
La mesure de la température interne est inutile, les abeilles vont complètement enrober le capteur.

[inviteb061eab7]

tu pourrais rajouter 2 photodetecteurs pour compter les abeilles qui rentrent ou sortent ( 2 fourches optiques montées à 2 cm l'une de l'autre ?)
pour la radio des puces TI cc1310 annoncées pour 10 km en vue degagée donnent peniblement 500 metres en site valloné à condition de mettre des antennes ( coax denudé sur 6.8cm) à 3 metres de haut
ça c'est à puissance 10 mW ( bande 868MHz ) et je n'ai pas essayé la bande etroite à 500mW ( car systeme autonome sur plusieurs années avec pile bouton et 1 capteur de temperature ) qui devrait permettre de gagner mais je ne sais pas quelle distance
je suppose que les autres ( st ,siliconlabs etc ) c'est pareil
autre solution : mettre du lora ( plutot que du sigfox qui impose un abonnement et qui va deposer le bilan d'ici 3 ans ) ou attendre amazon qui se lance dans l'IOT
ton angoisse pour la derive en temperature des capteurs de force n'a pas lieu d'etre si les jauges de contraintes sont montées en pont ( 4 jauges ) pour compenser . A verifier

[ATdevice]

Bonjour,

Vu le besoin, côté intelligence un simple petit uC ferait l'affaire, avec un mode sleep et réveil par watchdog ou interruption, au moins une entrée analogique, un périphérique SPI et/ou UART.
Pour la communication éviter les liaisons type GPRS, WiFi, etc, déjà pour la consommation, mais aussi pour la complexité de mise en oeuvre, la portée et la bande de fréquence.

Comme souligné par Adipie le LoRa est plutôt optimisé pour ce genre d'application, de préférence dans la bande 868 MHz : http://www.onditech.com/documents/freq_433_868.pdf

[nornand]

Bjr , on laisse les ruches sans visite pendant plusieurs mois ?

[invitef86a6203]

Pendant 3 mois d'hiver , il vaut mieux leurs fichent la paix...
Enfin dans le Nord de la France.

Dans ce genre de projet on ne sait jamais quelles sont les priorités numéro un ?
On peut croire que seul le but est de recueillir des données soit le but final ?.

Les composants cités sont ils imposés ?
A t on le choix du matériel ?
La communication GSM est elle aussi imposée ?
La radio est obligatoire ?
Si oui quel est l’environnement ?
Doit on pouvoir communiquer dans les 2 sens ?
Peut on mettre le matériel sans risque ?

[inviteb061eab7]

Bonjour,

Vu le besoin, côté intelligence un simple petit uC ferait l'affaire, avec un mode sleep et réveil par watchdog ou interruption, au moins une entrée analogique, un périphérique SPI et/ou UART.
Pour la communication éviter les liaisons type GPRS, WiFi, etc, déjà pour la consommation, mais aussi pour la complexité de mise en oeuvre, la portée et la bande de fréquence.

Comme souligné par Adipie le LoRa est plutôt optimisé pour ce genre d'application, de préférence dans la bande 868 MHz : http://www.onditech.com/documents/freq_433_868.pdf

non, un simple petit µC ne fait plus l'affaire à partir du moment ou on doit communiquer et là il faut communiquer , les cartes multiusages sont beaucoup plus performantes avec tous les trucs qui sont necessaires bien que parfois superfétatoires ( gps , gprs gsm wifi bluetooth lora ) avec des prix very low cost ( 14 € pour l'esp32 avec gprs c'est donné ) et on trouve des tas de programmes deja fait
c'est un peu comme conseiller de programmer en assembleur

[inviteb061eab7]

Bjr , on laisse les ruches sans visite pendant plusieurs mois ?

non mais quand tu as des ruches en montagne et que tu habitues à 100 km tu ne fais pas le deplacement tous les jours .
C'est un peu comme les eleveurs qui se plaignent des ours et qui ne mettent les pieds que 2 fois par an en montagne avec leur gros 4x4 , sauf que les apiculteurs n'en font pas tout un fiel quand l'ours vient lui piquer le miel

[ATdevice]

non, un simple petit µC ne fait plus l'affaire à partir du moment ou on doit communiquer et là il faut communiquer

Du SPI, I²C ou UART on en trouve sur des uC à 2€ (MSP430G2553 par exemple) et ça permet de s'interfacer avec n'importe quel module GPS et communication.
Il n'y a à priori pas besoin d'USB, de liaison TCP/IP ou autres protocoles gourmands en RAM (stack), donc pas besoin d'un uC trop compliqué. De ce que je peux lire, il faut un réveil planifié toutes les 30 minutes (via watchdog) ou sur interruption GPIO (commutateur d'ouverture/fermeture), une acquisition du capteur de force (analogique?), éventuellement le décodage d'une trame NMEA venant d'un module GPS (UART ou SPI), et envoi d'un message par liaison radio (UART ou SPI), avec éventuellement possibilité de recevoir un message.

On reste sur de la programmation bas niveau, facile à gérer et plutôt accessible : la partie configuration et accès aux périphériques (UART, SPI, I²C, ADC...) peut se trouver dans les application note et dans de nombreux exemples, et il en sera de même pour chaque module (interprétation de trame NMEA, configurations par SPI, etc).

les cartes multiusages sont beaucoup plus performantes avec tous les trucs qui sont necessaires bien que parfois superfétatoires ( gps , gprs gsm wifi bluetooth lora ) avec des prix very low cost ( 14 € pour l'esp32 avec gprs c'est donné ) et on trouve des tas de programmes deja fait

Certes c'est performant et très pratique pour évaluer certaines fonctions sans se soucier des éventuels problèmes de conception, mais le problème que je vois c'est justement la complexité de la chose par rapport à l'application finale. Les programmes tout faits sont une bonne base pour du test, mais quand tu veux imbriquer plusieurs blocs il faut avoir une certaine maîtrise de ce que chaque bloc fait, et c'est très dépendant de la façon dont ont été codées les fonctions, et on peut vite être confronté à des limitations/conflits.
Sur ce point il faudrait attendre plus d'informations sur les réels besoins en terme de communication.

c'est un peu comme conseiller de programmer en assembleur

Ce n'est pas le même combat, mais tu ne conseillerais pas un STM32F7 dans le simple but de faire clignoter une LED. Pour une application simple avec quelques interactions extérieures, un uC 8-bits fait le job (il y en a des très simples comme des plutôt costauds en terme de nombre de périphériques, taille de RAM et fréquence d'horloge)

[inviteb061eab7]

Du SPI, I²C ou UART on en trouve sur des uC à 2€ (MSP430G2553 par exemple) et ça permet de s'interfacer avec n'importe quel module GPS et communication.
Il n'y a à priori pas besoin d'USB, de liaison TCP/IP ou autres protocoles gourmands en RAM (stack), donc pas besoin d'un uC trop compliqué. De ce que je peux lire, il faut un réveil planifié toutes les 30 minutes (via watchdog) ou sur interruption GPIO (commutateur d'ouverture/fermeture), une acquisition du capteur de force (analogique?), éventuellement le décodage d'une trame NMEA venant d'un module GPS (UART ou SPI), et envoi d'un message par liaison radio (UART ou SPI), avec éventuellement possibilité de recevoir un message.

On reste sur de la programmation bas niveau, facile à gérer et plutôt accessible : la partie configuration et accès aux périphériques (UART, SPI, I²C, ADC...) peut se trouver dans les application note et dans de nombreux exemples, et il en sera de même pour chaque module (interprétation de trame NMEA, configurations par SPI, etc).



Certes c'est performant et très pratique pour évaluer certaines fonctions sans se soucier des éventuels problèmes de conception, mais le problème que je vois c'est justement la complexité de la chose par rapport à l'application finale. Les programmes tout faits sont une bonne base pour du test, mais quand tu veux imbriquer plusieurs blocs il faut avoir une certaine maîtrise de ce que chaque bloc fait, et c'est très dépendant de la façon dont ont été codées les fonctions, et on peut vite être confronté à des limitations/conflits.
Sur ce point il faudrait attendre plus d'informations sur les réels besoins en terme de communication.


Ce n'est pas le même combat, mais tu ne conseillerais pas un STM32F7 dans le simple but de faire clignoter une LED. Pour une application simple avec quelques interactions extérieures, un uC 8-bits fait le job (il y en a des très simples comme des plutôt costauds en terme de nombre de périphériques, taille de RAM et fréquence d'horloge)

tout ça c'est intellectuel ou estudiantin ou les 2 , mais quand tu es dans la vraie vie tu ne t'amuses pas à acheter un module gps puis un module gsm pour ensuite galerer à faire l'interface uart et faire un vilain montage de 200x100 mm sur une carte veroboard avec des tas de fils .
Non tu achetes sur alibaba ou amazon ou sparkfun la carte qui fait tout .

[Evorlde]

J'ai pas mal avancé dans mes recherches.

Après avoir lu énormément d'articles et prit des conseils à droite a gauche (notamment sur ce thread, merci) je vais partir sur une carte Arduino MKRFOX1200 ou Arduino MKRWAN 1300.
Cette carte a l'avantage de ne consommer que très peu ce qui me permet avec quelques piles (6 dans mon cas) de tenir 12 mois sans soucis.
De plus le réseau SIGFOX ou Lora, que je ne connaissait pas, pour ce qui est l'envoi de data me semble le meilleur choix compte tenu de sa couverture géographique et sa faible consommation en énergie puisqu'on part sur un protocole très allégé (largement suffisant pour envoyer quelques octets de datas 5 fois par heure).
D'autant plus que les opérateurs traditionnel on dans leur clauses d'utilisations un paragraphe qui interdit l'utilisation d'une SIM pour ce que je veux faire (à savoir communication m2m = machine to machine). Beaucoup d'utilisateurs (d'alarme maison notamment) ce retrouvent avec une sim bloquée car l’opérateur en ce basant sur la fréquence (temps) d’émission, la zone d’émission qui ne bouge pas détecte que la SIM est utilisé dans des conditions dites m2m interdite.

Aujourd'hui un problème restant est de trouver un détecteur de mouvement, assez petit, qui fonctionne en extérieur.
A première vue je vais partir https://www.gotronic.fr/art-detecteu...0171-22704.htm qui accepte des températures inférieur à -20. Je dois encore m'assurer qu'il verra l'affaire.

Enfin et ce qui est de loin mon plus gros problème les cartes Arduino citées plus haut supportent 3.3V donc il va pas falloir que je me rate en connectant des éléments 5V.
Je vais donc commencer la partie documentation sur tout ce qui est faire évoluer une tension 5V vers 3.3V et inversement.

Il faut aussi que je me rassure par quelque recherche sur la partie résistance à l'humidité. En principe l'intérieure d'une ruche n'est pas humide mais les jours de brouillard notamment ça peu poser problème de façon ponctuel.