You are not logged in. Please login or register.
OpenHiveScale → Posts by Pierre
Non je n'ai pas encore préparé de compte demo avec un jeu de données représentatif, mais à défaut, un screenshot :
Le reste est minimaliste, de quoi déclarer les ruchers et les ruches, leur mettre un nom, associer l'identifiant wifi de la balance ou du modem sigfox. C'est volontairement pensé minimaliste bien que fonctionnel.
Openhivemanager, c'est clairement prévu de fonctionner de paire, c'est juste (encore) sur ma todo.
Bonjour Julien,
Dans l'immédiat, nous avons fait un site, simple, qui présente sous forme de graphe poids et température :
http://www.openhivescale.org/monitor
J'ai réalisé dans le passé une modif sur une copie d'openhivemanager pour y intégrer les pesées automatiques. C'était fonctionnel, mais il reste à intégrer cette modif dans la version hébergée sur openhivemanager.org.
C'est sur ma liste de choses à faire. Il y a aussi sur cette liste l'intégration du site btree.at
L'idée sera de centraliser tous les modes d'envois par www.openhivescale.org/monitor, site sur lequel j'ai la main, et d'activer de façon optionnelle l'export vers les autres sites.
Et pourquoi pas vers une URL personnalisée...
Pour une intégration plus simple sur un site tiers, il faut que je creuse la question, surtout d'un point de vue sécurité. Rien d'impossible, mais probablement pas une priorité première.
Hello,
I fixed the zoom issue. Data were wrongly ordered, and highchart doesn't support that when zooming.
Bonjour Julien,
Sur la carte principale, aucun capteur n'est embarqué.
Le modem sigfox embarque un capteur de température, donc on l'a exploité.
Sur le connecteur permettant de connecter les modules sigfox/gsm/lora etc..., il y a bien sur l'alimetation, l'UART pour communiquer en série avec les modems, et enfin l'I2C, qui permettrait d'y connecter des capteurs utilisant ce bus, typiquement le répandu DHT22, même si un modem est connecté (moyennant une petit soudure). Evidemment pour l'humidité il ne faut pas que le capteur reste dans le boitier étanche de l'électronique.
Concernant Lora, nous avons une carte en beta-test en Allemagne, aux dernières nouvelles tout allait bien. Les tests que j'avaient fait en France sur le réseau Lora d'orange étaient tous concluants. Bref ça marche tout seul.
J'ai quelques modems d'avance, ainsi que des PCB, donc je peux en assembler facilement.
Je viens de regarder sur https://www.sigfox.com/en/coverage
La Belgique est... parfaitement couverte. On cherche les zones blanches.
Sigfox a deux gros avantages : Le modem coûte beaucoup moins cher (10€ d'écart à l'achat, qui sera nécessairement répercuté), et je peux activer des modems dans toutes les zones couvertes sur un seul contrat (sorte de roaming), alors que Lora il faudrait ouvrir un contrat par pays/opérateur... vu notre taille, c'est inenvisageable.
Mais Lora permet de se monter un réseau privé, ou collaboratif (TTN).
Donc on supporte les deux!
En l'état actuel des choses, je peux fournir un module Lora au meme prix que le sigfox, mais sans abonnement, pour lequel il faudra vous débrouiller... :-|
Electroniques alternatives :
Il existe une carte alternative par nos amis/voisins d'OpenBeeLab, dont la compatibilité avec notre balance est prévue.
Par contre la philosophie est très différente : carte embarquant un O/S linux, permettant mille fois plus de choses, mais qui ne se contentera pas de 3 piles AA.
https://www.openbeelab.org/
D'autre part, si vous voulez monter votre propre électronique de pilotage, éventuellement en forkant notre code qui est développé sous l'IDE arduino mais pour le compilateur de l'ESP8266, tout à fait possible.
L'interface hardware est très simple :
Il faut 4 sorties numériques pour piloter le moteur, et 4 transistors pour la puissance (ou un ULN2003), et une entrée analogique simple. Bref largement à la portée d'un arduino uno.
La grosse valeur ajoutée de notre carte, outre le wifi, c'est l'étage de mise en veille : 200nA aux bornes des piles ... ;-)
(Je précise car les microcontrôleurs donnent leur courant en veille, mais ça n'inclut pas la conso de la régulation de tension qui devient prépondérante)
Bonne journée, Pierre
Hello Robert,
I finally find some time to look into.
I reproduce the problem, it looks like a bug in highchart library.
It's been reported, but not fixed, I still reproduce even with last version.
https://github.com/highcharts/highcharts/issues/393
I tried to separate the graphs, but doesn't seems really better.
I also added a module for export. You should see a new menu on top right of the graph.
Bonjour Norbert,
Réponse envoyée par mail..
Une simplification du processus de commande est prévue pour la fine d'année.
Hello,
in the meantime I answered to Michael directly by email.
For information to anybody else :
There is no specific reset procedure other than removing batteries.
I would advice to let the jumper on config mode when you do that : it empties the capacitor much faster (otherwise RTC doesn't reset properly).
You don't need to play with jumper on flash side. This is for initial flashing when there is absolutely no program on the board, normally it's made once by us. It may be useful if for some reason we brick the firmware update, but you'll need an UART adapter.
Could you check batteries voltage?
Let the jumper in config mode, try to remove batteries and put it back.
Connect one single device at a time.
I'm also wondering if a large amount of wifi networks around are not an issue. Is this the case where you are?
To investigate if the wakeup works fine, in config mode, click on the 'file editor link'. All the config and log files used by the board are accessible. Don't modify files unless you understand what you do.
For exemple, file bootlog.txt :
wakeUpByRTCAlarm tells if boards wakes up automatically, or by config mode jumper.
boot...
06-08-2018 17:08:02
wakeUpByRTCAlarm : 1
sendingMode : wifiHotspot
switch off 06-08-2018 17:08:13
boot...
06-08-2018 17:09:02
wakeUpByRTCAlarm : 1
sendingMode : wifiHotspot
switch off 06-08-2018 17:09:09
boot...
06-08-2018 17:09:16
wakeUpByRTCAlarm : 0Hello and thank you!
Please send an email to contact@openhivescale.org with details : which connectivity, where you live (for shipping cost), and we'll reply with a bank account number for transfer.
Pierre
Assembly manual for mechanical part
https://github.com/openhivescale/mechan … manual.pdf
Video tutorial for mechanic and electronic wiring/assembly
https://www.youtube.com/playlist?list=P … 13EpodO7md
Hello,
first, sorry for the late reply.
In the mean time, I've read your post, and I ordered a SIM7000E (2G+4G(nb-iot)), and just received the module.
I'll make a prototype PCB to test it this week. My difficulty is that there is no nb-iot network in France to test this mode.
This summer I'm travelling in Germany (end of august), where there is a nb-iot network. I'll try the module there.
Or, if you want to be an 'alpha' tester, I can also make a SIM7000E for you before, if I get good results in 2G here.
Pierre
Bonjour,
Pour la connexion à un autre serveur :
- en wifi (hotspot/box disponible) ou GSM GPRS, puis via une requête HTTP GET simple, c'est prévu dans la page de config, il n'y a qu'à rentrer votre URL et y mettre deux balises (identifiant carte, pesée).
- wifi/gprs, mais avec un autre protocole plus sioux, le code est à dispo sur notre github, no limit...
- pour sigfox, on est obligé de regrouper les abonnements chez sigfox, et passer pas notre plateforme. Ce qui ne m'empêche pas ensuite de re-router le message vers votre serveur, mais vous serez pas "pleinement indépendant".
Aucun problème pour passer commande, on a commencé à livrer juste semaine dernière, et on a encore du stock. Je vous envoi le détail pour le règlement par email.
Pierre
Electronic case decoration...
The mainboard, and the 3 daughter boards prototypes : sigfox, lora, gsm...
Hello,
Here are some news about our progress, as of friday 6/4/18
What do we do ourselves? from who are we supplying? Where we are?
All the complex plate parts are laser cut, we subcontract that from a local company. We already got a run for a single kit, to test the parts, especially last minute improvements, and tolerances, no big issue encountered. 100 batch is planned for next friday (13rd)
Screws/nuts/spacers are supplied locally, ordered today. We buy in bulk, so we'll have to prepare kits (count and put in bag)
Aluminium tube and profilés, already cut all the parts. Next big job is to drill... we do that ourself.
We already built a prototype of the tooling. Today be build the definitive one in a more stable material. Next week, drilling...
All other supplies like motor, belt, pulley, shaft support etc.... comes from China, we received everything.
Mainboard PCB design is finalized. Found a subcontractor in France to make the PCB and assemble the SMDs. Ordered.
Components are already delivered.
PCB delivery planned week of 16th. We'll have to solder trough holes connectors, and flash the MCU.
Daughter boards / shields : Testing the different options, including GSM and Lora in addition of Sigfox. For components supply and planning issues, we'll assemble that ourselves.
Sigfox modules, GSM modules, Lora modules (for proto), antennas, are ordered. Still to order PCB (quite fast). Assembly planned for week 16th
Case : we already received the case. We have to drill them, and build a part for sealing the cables going out. It's likely to be a 3D printed part and some acrylic or silicone paste to seal. We'll deliver a small amount in syringe, to avoid you to build a 300ml cartridge, and throw away of let dry 295ml.
Box and bag for screws are ordered, will be there soon (next monday likely).
Already made something nice in the past, but we have to complete it with last modifications. It'll look like the video on the
website, black wire of white background (Ikea manual inspired ;-) ). I think it's the most readable when printed on paper.
We'd like, it time allows, ask some friends, normally handy, who doesn't know the project, to assemble it, and we observe him without helping, to see what would make assembly confusing. We already worked hard to make the easiest possible, by reducing the amount of different parts, to avoid parts looking like the same, but not the same, by marking a reference on laser cuts etc...
But there is a big bias.... We know our project like our pocket. We need a virgin brain ;-)
We'd like also, in addition, film ourself mounting completely one scale, from packaging opening, to electronic configuration.
Might help to see how we mount it the easiest way. Because sometimes, it looks easy on paper, but it happens the last screw are pretty inaccessible.
List the the necessary tools, to be done.
Pictures soon...
Bonjour,
Je réponds volontairement dans l'autre sens : oui, le programme bêta est ouvert. Nous sommes actuellement en plein dans la production, on vise les livraisons pour mi-avril.
Ce programme bêta a justement pour objet de tester l'objet en conditions réelles. En extérieur, sur au moins une année, mais surtout avec une diversité de lieux, climats, type de supports, végétation, exposition, etc...
Vous avez raison, des éléments mécaniques en extérieur, c'est un point sensible qui mérite attention.
C'est pour ça que dans notre calcul, on a déjà inclus l'envoi à posteriori et à nos frais de pièces modifiées aux beta-testeurs, pour que les beta-testeurs ne se trouvent pas lésés.
Tout ce qui a pu être mis en inoxydable l'est déjà. Pas de vis sans fin sur ce modèle, mais une courroie, insensible à l'humidité/oxydation.
Reste en pièces critiques : la douille de roulement linéaire et le moteur.
La douille linéaire, nous avons déjà une alternative : les douilles en plastiques autolubrifiant Igus. Mais on attend de voir le retour, car plus cher, et plus de résistance mécanique, donc moins bon pour la conso et sensibilité de la mesure. Facile à remplacer.
Pour le moteur, toute sa pignonerie interne est en plastique, même s'il venait à rouiller entièrement, pas certain que ça l'empêche de fonctionner. Et s'il posait problème, il reste des possibilités pour le protéger. Le coût de son remplacement serait marginal.
Sinon, pour l'instant, les quelques balances que nous avons dehors de nos premiers prototypes ne montrent aucun signe de faiblesse.
De façon plus générale, j'ai l'expérience d'une machine avec moteur et électronique qui est en extérieur depuis 7 ans (un héliostat 2 axes). Structure bois, peinte. C'était un proto qui n'était pas destiné à rester aussi longtemps dehors. Eh bien, il vieillit bien, mieux qu'espéré. Donc, oui, on peut avoir des soucis, mais rien qui soit insoluble.
Pierre
Currently, the board we prototyped is a single board with sigfox modem.
But as I started to think about having a GSM version, it appeared clear that the strategy will be to have on one side a main board, (with esp8266 (main mcu+wifi), Power regulator, rtc, motor driver, and optical endstop entry), and "daughter" board plugged in. Kind of the idea of arduino and shields, but simplified.
The interface between both would be simple :
- tx/rx serial uart
- +3V3 regulated when board wake up
- +VBAT
- GND
Doing this way, it'll easy to make variants. We can produce the main board by hundreds, and make à single prototype with engraver to test this or that modem, including lorawan of course.
Hello,
That would be perfectly doable.
Without hardware modification, by using the wifi only version.
We change the software to add an option "Store locally, don't send". I have plenty of flash memory to store data.
When you want to get the data, connect to the scale via wifi with a smartphone (or tablet, laptop), and grab the data.
You think there is no network at all (gsm nor sigfox) where you have your hives?
Pierre
Bonjour,
Pour les deux points, vous avez raison, et cela vient de raison historiques :
- Le positionnement de l'entrée alimentation correspond à un bloc pile directement soudé derrière la carte est donc solidaire de la carte. Option abandonnée car moins facile de concevoir un boitier permettant un accès facile aux piles.
- Mes prototypes étant gravés à l'anglaise (à la CNC directement dans le cuivre) le cuivre entre les pistes restant présent, je me retrouvais de toute façon avec du cuivre derrière l'antenne.. du coup j'ai négligé la disposition des pistes derrière.
Et en effet, je vais redessiner la carte, car je voudrais désolidariser le module sigfox. Deux raisons principales :
- J'utiliserai le breakout que yadom fournis comme carte fille. Comme ce module n'est pas disponible chez les grands distributeurs, ca m'évitera des allers-retours avec le futur assembleur du PCB.
- Et je me calerais sur ce format pour faire d'autre carte filles notamment GSM, mais aussi Lora. Ainsi la partie wifi n'aura plus à être modifiée, et restera évolutive.
J'en profiterai pour laisse vierge de pistes l'emplacement de l'antenne de l'ESP, voire la faire dépasser de la carte, et je mettrai un connecteur pour l'alimentation, en bord de carte donc ;-)
Merci pour les remarques.
Welded tubes, optical sensor, sigfox, pushing geometry, but still screw for motion
All wood version, GSM, DC motor with encoder, "pulling" geometry
Bonjour,
Merci pour ces questions, effectivement il y a des choses qui nous semblent évidentes, que l'on rajoutera sur le site.
Pour l'envoi des données :
De façon générale, le but est que tout arrive sur un site web, facilement consultable, avec les courbe de poids etc...
On a deux options pour ce site :
- OpenHiveManager, qui est un autre projet, à la base de gestion apicole au sens large. Et dans ce projet il y avait déjà enregistrement du poids et graphe... il aurait été trop dommage de ne pas se "brancher" dessus.
https://openhivemanager.org/ (site à l'instant ou je parle en rade pour une histoire de DNS pas à jour, j'espère que l'admin va résoudre ça bientôt, sinon il y a un fork ici http://ohm.pierrebeck.fr )
OHM (appellons le comme ça), est très bien pensé, très riche.
- Et peut être même trop riche, du coup on pense à remettre en place un site plus minimaliste, qui affiche dans des graphes séparés (ou pas) le poids des ruches. Point. J'avais réalisé une maquette de ce site dès nos premiers proto, donc il n'y a pas énormément de boulot pour le reprendre, mais rien de prêt la sous la main à montrer.
Maintenant de façon plus spécifique, et si la question sous-jacente est "je veux rester maître des données de bout en bout, et ne pas dépendre de vos infra"
En wifi, on peut implémenter le protocole que l'on veut, et donc tout imaginer : MQTT, mail, serveur web perso, serveur web herbergé, etc...
En GSM, pareil si on utilise la data, en plus on peut faire un mode SMS pur.
Enfin, pour sigfox, on a la contrainte technique que l'on doit passer par l'infrastructure de sigfox. Et que sigfox ne permet pas de prendre un abonnement en direct, pour une ligne. Entre eux et l'utilisateur final, il y a forcément un intermédiaire. Nous, en l’occurrence. Ou un distributeur de module, comme snootlab ou yadom.
Et dans leur "backend", la console où l'on configure les modems, et ce que sigfox doit faire des messages, on peut configurer un renvoi vers à peu près n'importe quelle adresse web. Avec cependant une contrainte, c'est conçu pour configurer une adresse pour une classe d'appareil, et tous les messages vont au même endroit. Du coup il n'est pas facilement envisageable que chaque apiculteur ait son serveur web, et de configurer une adresse différente.
Par contre, implémenter une option de renvoi du message "ailleurs" en utilisant notre site web, ça c'est parfaitement envisageable.
Quelles données :
Le poids principalement.
Température extérieure, sonde embarquée dans le modem sigfox.
On a pas mis de sonde de température sur le carte en plus, qui pourrait servir en wifi seul. Ca peut encore se rajouter, j'ai prévu une ou deux petits modifs avant de lancer la production d'une série de 100.
Réseau entre elles :
Oui! C'était une de nos réflexions dès le début.
D'où le wifi de base sur les cartes. Sachant qu'elle savent communiquer entre elles sans hotspot.
Et d'où une carte dédiée, qui embarque une horloge assez précise pour que le réveil de toutes les cartes se fassent synchro à maxi une ou deux secondes près. Dans l'idée, chacune des balances fait sa mesure, puis les esclaves poussent leur mesure à la balance maitre, et la maitre l'envoi en sigfox ou GSM.
En vue directe, il faut s'attendre à une portée entre la maitre et les esclaves d'une trentaine de mètres. (il faut que je fasse des tests sur ce point d'ailleurs)
Enfin pour les courbes, oui c'est un gros manque sur le site.
On a fait toute une batterie de tests, qui se retrouvent agglomérés sur un même graphe.
Je viens d'extraire les données dans un tableur, et on est en train de préparer un graphe avec seulement les séquences pertinentes, pour lisibilité.
On essaie de poster ça dans la journée.
Pour te donner un avant-goût, des données brutes sont visibles ici :
http://www.pierrebeck.fr/dumbpostlist.php
En partant de la ligne 12606, et remontant, il y a des messages Balance_45_7:17:35_Pesee_xxx, où xxx est la valeur brute en nombre de pas du moteur. Un pas vaut environ 3g, et du fait d'une histoire de demi pas, je n'ai que des résultat pairs.
Et à chaque mesure, l'algorithme casse l'équilibre, et le recherche à nouveau.
Sur environ 400 points, 99% sont sur la même valeur 552, environ 1% 554 (donc 6g au dessus). A la fin, il y a des 588, c'était un poids supplémentaire que j'ai retiré. Le poids pesé était donc d'environ 1,5kg. On a fait des tests avec beaucoup plus lourd (on est allé jusqu'à 180kg avec un contrepoids plus gros)
On documente tout ça le plus sérieusement possible, et on poste dès que c'est prêt.
Salut!
I was wondering if it was a good idea to have many languages on a forum, where discussion may interest non french-speakers.
I created french and spanish sections... but well.
Drawings are already available, link to github is in the 'DIY' section.
https://github.com/openhivescale
I did my CAD with openscad.
It's free, so this is cool. But it's CAD for programmer. I never managed to do what I can do with openscad with other wysiwyg like freecad.
Download openscad, get the sources, try to open it, and tell me.
Also, the sources on github are not yet 'cleaned up'. Still all variables name in french, and a big lack of comments, and some dead code here or there.
Anyway...
And last, we built 3 prototype before designing this one. And this one was optimized to make a version than we can produce in series, to sell it.
But for a full DIY, I think the previous versions we did were easier for a single.
You can check also the website of the openbeelab, where they put freecad drawing of the scale they built, which was based on our precedent version.
Main difference is that it was steel tubes, welded. And counterweight was moved with a screw. Which is not the best solution.
The last version we did, we moved to timing belt.... much better.
OpenHiveScale → Posts by Pierre
Powered by PunBB, supported by Informer Technologies, Inc.
