Hello Peter,
As told by email, we're very very late, and we didn't even take the time to communicate about it. Again, we're sorry.
Parcel is on its way.
Pierre
You are not logged in. Please login or register.
OpenHiveScale → Posts by Pierre
Hello Peter,
As told by email, we're very very late, and we didn't even take the time to communicate about it. Again, we're sorry.
Parcel is on its way.
Pierre
Hi Peter,
Juan should have answered by email. Sorry for the delay, beekeeping keeps us (very) busy.
Pierre
Hello,
I finally found the time to adapt the service endpoint to accept TTN.
It's not easy because I don't have a TTN coverage here to test.
I took your request body example, and just changed the payload_raw :
"payload_raw": "MDAwMA=="
(4 bytes, all equals to decimal 48 (== ascii '0'))
And posted as is :
curl -d "@bodyexample2.txt" -H "Content-Type: application/json" -A http-ttn/2.6.0 http://openhivescale.org/monitor/index.php?r=post-measure%2Findex
I rely on user-agent to decide to process the request as a sigfox packet, or lora.
From the body, I just read hardware_serial and payload_raw.
I modified the admin page, http://openhivescale.org/monitor/index. … ve%2Findex and added a Lora DevEUI field.
I also did modifications on the firmware to make AppEUI/AppKey configurable. But not yet a smart 'join OTAA'.
To be continued...
Bonjour, problème corrigé. Dans la section en anglais j'ai détaillé les autres points corrigés.
01/04/2019
Improvements on web site (http://openhivescale.org/monitor/) :
Fixed : negative temperature values
Fixed : delete a hive
+ Ability to access account settings to change password and more
+ Chart is now displayed in local time and not UTC anymore
+ In account settings you can change the time window the chart will display
Hello Carsten,
In theory yes. But...
Without other modification than a lighter counterweight, you won't be able to do the tare without weight on the scale. The beam is not balanced without counterweight. We placed the knives so that with 500g counterweight we could find the balance.
Two solutions, put a dead weight to make the tare, or modify the position of the knives (which is not that easy, you'll need to drill new holes)
Having a dead weight should not reduce precision/sensibility, probably the best way.
You can even place the dead weight directly on the beam near the motor, and fix it.
Pierre
Hello Michael,
First, I was not understanding. Tonight I tried to compile and flash boards from a new computer....
I got the same error than you. So I spent some time to understand.
And I don't really understand why, but it doesn't compile with recent versions of arduino and board extension.
I updated the README with the version I had originally and that is working.
You need to fallback to arduino 1.8.2 and a git version of esp8266 from 5 May 2018, links in the readme.
Tell me if you still have issues to compile.
Hello Manuel,
No you won't need to do the firmware modifications and recompilation like phisch92 did. I did make some modifications in the firmware in the meantime, and if needed additional I'll do it. Eventually you'll need to upgrade the firmware, but this is easy.
Could you go on the debug link in config mode, and look in the very first lines, the compilation time, it's the actual version of the firmware (I have to make a simpler versioning)?
About LoRa : It's a bit more complex scenario than sigfox where everything is configured on their backend with just the modem id, or GSM where once you have a SIM and its PIN code, network gives you access to internet.
For now I didn't manage personally the network configuration part for other users, but I ran some test with Orange and Bouygues national LoRaWan networks. It worked, but some stuffs are not perfectly clear to me.
You can read this :
https://www.microchip.com/forums/m945840.aspx
- I don't understand in which scenario hwid and deveui should be different? One is readonly, the other is configurable.
- appeui / appkey : who must define it? The board developer? Or the network manager? Is just a random string, or is there rules?
- join otaa : should it be ran each time board wakes up? or only once for lifetime?
For you information :
Once connected to the wifi board in config mode, you have access to the modem through telnet. Get a telnet client (putty under windows is nice), connect to 192.168.4.1 default telnet port, and play the commands you want. Starting by 'sys get ver' to check it works.
Could you ask to the people who give you access to the LoRa network how you/they will configure the modem? Will they give you an appeui/appkey or do you have to define it yourself? What is the process to pair the hwid/deveui with the network, and the callback URL?
For the callback URL, do you want to use our website? Or do the university have something that you can use?
Once you get some information about the lora network you'll use (access to some sort of configuration backend website), I can assist you, ideally with a laptop (for wifi) connected to internet through cable. So that we can share the screen, and in the same time wifi connected to the scale to run tests.
Pierre
Hello Manuel,
as explained by Olivier, motor endstop is not currently used. But we plan to make the missing parts to use it, and send it to everyone.
In short, it'll allow to detect step loss, for software compensation, or to guarantee the measurement quality.
200-300g fluctuation is not a nominal performance, but not catastrophic enough to be explained by a big issue.
Batteries health doesn't explain the fluctuation.
What is the most likely is a small friction somewhere in the mechanical system. Of course by triggering 3 times the measurement and keep the median would work, but it's clearly sub-optimal, and will reduce significantly battery life.
I'll discuss with Juan what we can do, but I think about two things :
- A video to explain where to look after mechanical friction, some tips, and how to evaluate by hand the sensitivity.
- A software procedure to run x times the balance search, and quantify the dispersion. With that we would have a factual value, and give some reference value.
To make it short, you may have a small burr on the tips of the knives (which are laser cut inox, so blurr is unavoidable, but you can remove it during assembly), and you may have some misalignment during assembly, that make two parts touching while it shouldn't. Difficult to explain without a sketch.
Thanks for your feedback!
I know it looks pretty complex, even though we spent nights and nights to discuss how the reduce the number of parts/bolts.
Fragility is less an issue. We had the idea to run a crash test by weighing under a wheel of 2t van and see if it breaks, and what breaks. But it's likely it won't.
The risk is more about grass that could grow under, or small animal/insects interacting, and make the measurement wrong.
Again, we would also be happy to collaborate across projects, share good ideas, make system interoperable, etc..
Hello Pim,
Just replied to you by email.
For public, in short, yes we would be happy to make our scale system interoperable with any application.
We have to discuss the technical details.
Bonjour Olivier,
tout d'abord toutes mes excuses pour l'absence de réaction. Je ne surveille pas le forum, car je reçois normalement des alertes email quand il y a un nouveau message.... c'est un loupé complet!
Pour ce qui est du problème :
- la valeur de 250kg, une fois convertie avec le facteur de 270 pas/kg, on arrive à environ 65000, qui correspond en fait à un dépassement de capacité informatique : Le poids est envoyé sur le réseau sous forme brute, c'est à dire en nombre de pas, sur deux octets. J'ai fait le choix de ne pas gérer les négatifs pour conserver de l'amplitude dans les positifs. Si la valeur passe en négatif, on se retrouve à boucler sur le maximum sur 2 octets, soit 65535. Une fois converti en kg, on arrive à ces 240-250kg.
Le scénario qui peut expliquer cela, tout dysfonctionnement mis à part, c'est de faire une "tare" sous charge, puis que cette charge baisse. Clairement c'est un scénario que j'ai exclu.
Pour écarter tout soucis de compréhension :
Sur l'interface en mode config, il y a deux boutons, un pour déclencher manuellement la recherche d'équilibre, l'autre "tare".
Comme souligné par cfort78, l'électronique est aveugle sur la position réelle, et fonctionne en incrémental. Elle sait très exactement de combien est censé avoir bougé le contrepoids. Mais n'a aucune idée d'où il est réellement. Donc à chaque fois que le moteur est piloté, l'électronique enregistre de combien il s'est déplacé.
Le bouton tare ne fait que remettre cette position "logique" à zéro. Mais en réalité s'il y a déjà 50 kg sur la balance, l'électronique ne peut pas le détecter.
Pour établir une référence, c'est à dire une tare, on se place "à vide", on déclenche la recherche d'équilibre, puis on clique sur tare.
Vous pouvez déclencher la recherche d'équilibre plusieurs fois d'affilée, et vérifier que la position remontée est stable. Eventuellement recliquer sur tare sur un point qui semble centré dans la dispersion. Quand il n'y a aucun point dure, les valeurs ne dévient pas de plus de 10 pas, soit environ 30g.
Puis vous mettez en charge, et ne touchez plus jamais au bouton tare! (sans retirer la charge j'entends)
Si vous n'avez pas fait de fausse manip avec le bouton tare, et si en plus vous semblez voir le bras en équilibre, le contrepoids qui n'est pas en butée, j'aurais tendance à exclure un problème mécanique (que ce soit une pièce défectueuse ou un soucis de montage), ainsi que la partie pilotage du moteur de l’électronique.
En revanche, un défaut dans la EEPROM interne au microcontrôleur, ou un bug dans mon code, c'est tout à fait plausible.
Est ce que depuis la page de config, puis en cliquant sur debug, vous pouvez copier le contenu de ce qui est renvoyé, et le poster ici?
Je réfléchis à comment vous guider pour poser un diagnostique, étant en déplacement et n'ayant pas de carte avec moi...
Bonjour,
problème identifié :
Dans la version du firmware qui est sur votre carte, l'URL est codée en dur dans le code (et donc ignorant celle configurée), et pointant ici :
http://www.pierrebeck.fr/dumbpostlist.php
Les paquets sont bien passés.
Je corrige cela au plus vite, et je vous fait suivre un firmware qui fonctionne, avec les explications pour mettre à jour.
Désolé pour ce couac.
Le code 200 après "Performing HTTP request" signifie que la connexion se fait bien.
Donc il faut regarder du côté du paramétrage sur le site monitor.
Ca marche en wifi?
Bonjour,
En effet, si le SMS fonctionne, ça veut dire que le modem et la SIM fonctionne, que le code PIN est bien désactivé.
Reste probablement l'APN à configurer... très possible que ça suffise à corriger le problème.
Quel opérateur? (Et éventuellement quel type d'abonnement, je crois par exemple qu'une ligne orange mobicarte (ça existe encore?) n'a pas le même apn qu'une ligne orange pro....)
Il faut aussi que l'URL soit bien configurée, tel que dans la doc.
Il y a des logs accessibles, depuis le mode config, par le lien edit puis gsmlog.txt. Ou directement :
http://192.168.4.1/gsmlog.txt
Il manque dans l'interface de config un moyen plus simple de tester la connectivité GSM, et d'avoir un retour d'erreur. C'est au (long) programme des améliorations à apporter.
En attendant, ou pour info, et si ce qui suit vous "parle", il est possible d'attaquer directement le modem GSM par commandes AT :
Une fois la carte en mode config, et connecté au wifi, il est possible de s'y connecter en telnet (port 21 donc).
Idéalement plutôt avec un PC, et un client (telnet sous linux, telnet aussi sous les vieux windows, plus récemment supprimé, un bon remplaçant gratuit est putty)
Une fois en telnet, la carte maître redirige tout vers le module (qu'il soit sigfox, gsm, lora...)
Pour tester, commencer par un AT<entrée>. On doit obtenir une réponse du type AT=OK, ou OK.
Ensuite :
https://www.elecrow.com/download/SIM800 … _V1.09.pdf
Bonsoir,
Sigfox permet la transmission de paquets de seulement 12 octets. Le 1/12 d'un SMS ;-)
Donc une photo, même ultra compressée, on en est très loin. Cette très faible charge utile permet d'excellent compromis portée/conso électrique. On ne peut pas tout avoir.
De plus, l'électronique que nous avons conçu est alignée sur la philosophie sigfox, je suis incapable de traiter plusieurs dizaines de ko avec le microcontrôleur utilisé.
En revanche, https://www.openbeelab.org/, eux ont une électronique qui relève plus de l'informatique embarquée, parfaitement apte à traiter des images. Mais il faut l'alimentation électrique qui va derrière. Nous travaillons ensemble, et leur carte est prévue pour pouvoir piloter notre mécanique. C'est à ma connaissance toujours "work in progress".
Hi,
No, we didn't put the component to read battery voltage.
And we already use the analog input of the MCU for reading the endstop state in linear mode.
GSM and sigfox modem have functions to return their supply voltage, but it's the 3.3V stage.
So it's not really helpful to know where the batteries are, unless they're too weak to maintain 3.3V.
Clearly, it may be an improvement of the board. I'll look into it for the next batch. But only if cost (energy and money) is marginal.
Pierre
Bonjour,
Le volume est très faible, de l'ordre du kilo-octet par envoi. Généralement le minimum de facturation par session est de 10ko =>
5000 envois/mois...
Dans notre idée, pour optimiser l'autonomie, on préconise une mesure/jour.... et si on veut analyser des choses plus fines, une/heure maximum.
Je vous envoi un email avec la marche à suivre.
Bonjour,
On utilise un opérateur virtuel basé au royaume uni.
https://www.globalm2msim.com/
Ça couvre à peu près toute la planète, dont au moins 3 opérateurs français (donc meilleur couverture qu'une sim mono opérateur locale) et ils ont le gros avantage de ne rien facturer en récurrent. Du coup en étant sage sur la conso, ça arrive à être plus économique qu'un abo à 2€/mois.
En plus, sur le papier, les opérateurs classique n'autorise pas l'usage M2M car leur modèle économique est base sur le redevance des appels entrants. Isolément, ça ne doit pas poser de soucis, mais on ne peut pas de baser dessus de façon généralisée.
Oui vous pouvez utiliser la SIM que vous voulez.
Quelles différences? Avant envoi (mesure) aucune.
Consommation supérieure (mesures en conditions réelles à venir), probablement moins de tolérance avec des piles en fin de vie.
Avantages : outre la complémentarité avec les réseaux LPWAN (sigfox/lorawan), pas d'infrastructure réseau tiers (sigfox collecte les paquets, et les redirigent au travers de leurs informatique) qui oblige à utiliser notre site, au moins en passerelle.
Donc oui, possibilité d'envoyer directement vers votre propre URL en GPRS, ou bien encore par SMS.
Le SMS aurait l'avantage d'une meilleur tolérance à une couverture réseau limite, et potentiellement moins consommateur. (ça reste à vérifier/mesurer).
Inconvénients :
- Le coût du SMS avec notre opérateur (15cents), pour le coup, un opérateur national redeviendra compétitif avec les SMS souvent illimités.
- Autant il est simplissime de faire arriver la donnée directement sur n'importe quel dumbphone (ça peut être un choix tout à fait respectable), autant ça devient compliqué de renvoyer le SMS vers le web sur notre plateforme.
Un numéro mobile virtuel avec renvoi des SMS vers Web n'est pas tout à fait gratuit. Je sais que c'est possible. Mais pour l'instant ca reste au statut d'idée. Utiliser une appli genre android, et y dédier n'importe quel vieil android obsolète pour cela, qui resterait branché à demeure au secteur... pourquoi pas. Mais je n'aime pas bien le côté dépendance à un "serveur" perso qu'il faut maintenir en vie....
Pour l'instant, cette option GSM est prête techniquement sur la partie module.
Mais on est pas encore très carrés sur l'offre. Est ce qu'on propose de façon systématique la SIM pour facilité?
Est ce qu'on refacture au réel les consos? On fait un forfait basé sur un scénario qu'on limiterait? etc...
Dans l'immédiat, si vous voulez partir sur du GSM, démarrer avec votre propre SIM est peut être la meilleure option.
Pierre
It's possible to use the connector for RF, where you have UART (for modem) but also I2C, perfect for HR/Temp sensor. And of course 3.3V supplied only when board is awake.
So on the hardware side, it's easy to plug a DHT22/11.
Next time I order PCB, I can also make a new one to adapt properly the DHT22/11 4 pins, but for a single board, not a problem.
On the software side, it's not a huge amount of work, just have a find a time slot to do it.
When done, I'll post here.
Bonjour,
Pour l'instant rien de formalisé un peu sérieusement.
Mais vu la tête des graphiques que remonte l'ensemble des balances connectées, il y a clairement une information à exploiter.
Pour les balances qui mesurent au moins toutes les heures, voire demi heure, on voit très bien durant la nuit une perte de poids, qui serait dû au séchage du nectar (dixit les apiculteurs de la bande).
Evidemment le matin, la grosse perte de poids, la sortie d'abeilles, qui rentrent le soir.
Moyennant un traitement de signal un poil bien pensé, on pourrait imaginer calculer la masse de nectar rentré dans la journée, l'heure de sortie des abeilles (qu'il est surement intéressant de corréler à la météo et l'heure de lever du soleil)...
C'est là que prendrait tout l'intérêt d'une mesure précise et stable : pouvoir extraire beaucoup plus d'information qu'une pesée au kilo près.
Bref, un sujet qui a surement de quoi occuper l'hiver.
Bonjour Olivier,
A l'heure actuelle, non.
Mais ça fait clairement partie des améliorations que je voudrais mettre en place.
Idéalement dans les semaines qui viennent...
Pierre
Bonjour Olivier,
Pour l'instant je ne tiens pas à jour un "changelog" pour le firmware, mais ça va venir.
Il y aura des améliorations à l'avenir, mais pour l'instant pas de révolution entre le firmware d'origine et le plus récent, donc ça peut attendre.
La dernière version est là : https://github.com/openhivescale/firmwa … .8.ino.bin
Hormis les logs propres à github, je mettrais à jour le readme :
https://github.com/openhivescale/firmware
Bonjour Charles,
Merci pour ce retour des plus encourageants !
L'accès direct tel que je pense vous l'imaginez impliquerait de laisser le wifi de la balance disponible. Or l'autonomie chuterait a quelque chose de l'ordre de la journée.
Maintenant si c'est uniquement le temps de mener une batterie tests, vous pouvez rester en mode config, utiliser le bouton 'search for balance', puis ... La valeur brute va s'afficher dans motor position a 8 points près, sinon il faut accéder à la page de debug dont le lien se trouve tout en haut de la page. Dans l'idée le plus pratique serait de l'ouvrir dans une autre fenêtre, et de la raraichir a chaque recherche d'équilibre.
Mais ça n'applique pas le facteur de conversion qui est géré sur le site.
Pierre
OpenHiveScale → Posts by Pierre
Powered by PunBB, supported by Informer Technologies, Inc.