Bonjour,
j'ai besoin de conseils. parce que ça part dans tous les sens.
pour faire une petite appli web, qui grosso modo stocke des paramètres utilisateurs, lit sur un ou plusieurs RPI/thermomètre(sonde) connecté (via une autre pageweb json) des entrées sorties analogiques me fait un calcul (paramètre * entrées), le stocke et me fait un beau graphe.
Les paramètres sont pour les sondes de température calibrées et étalonnées.
Je dois stocker en base les valeurs pour consultation ultérieure. Y a t'il un framework de rad dev web. et faire un beau rapport pdf pour le suivi de la fermentation. in vino veritas.
ça servira à faire l'optimisation de production (avec du calcul de non régression sur les résultat de la production). y aura un stagiaire IA c'est à la mode. Faut que je durcisse le processus d'acquisition et stockage.
je connais python, je peux intégrer des dashboards GPL (mais lequel). et si ça marche les coopératives le voudrons sur un cloud (ils ons des adresses gmail), pour pas avoir de PC ou serveur dans les champs. consultations sur son smatrphone. alerte email… Etat alive des sondes.
quelle BD (SQL, no SQL)?
quelle dashboard/ librarie ?
comment je sécurise l'accès, module d'identification ?
je pense que tout existe. la je suis un peu un maçon sans brique.
Merci pour les tips.
# pour l'asynchrone
Posté par jepostesurlatribune . Évalué à 1.
django channel
[^] # Re: pour l'asynchrone
Posté par jepostesurlatribune . Évalué à 1.
Long Polling, Server Sent Event ou websocket
[^] # Re: pour l'asynchrone
Posté par Destop . Évalué à 2.
Je ne vais pas parler de machineries lourdes, parce que j'imagine que pour une application vinicole, il n'y a pas un flux de données gigantesque (mais peut-être que je me trompe).
J'imagine que ton scénario, c'est un capteur de température relié à un GPIO de ton RPI. Tu multiplies cette configuration par autant d'exploitations vinicoles que tu veux.
Puis tu as un serveur central vers lequel chaque RPI va envoyer une mesure dès qu'elle est disponible. Sur le serveur, tu as une moulinette pour faire tes calculs, tu sauvegardes les mesures, leur origine, les résultats associés et tu envoies tout ça sur une page web en temps réel.
Voilà pour le scénario.
Pour une solution pas trop compliquée, je vois ça:
- côté RPI, un client python qui va lire la mesure et va faire une requête PUT classique vers ton serveur avec la mesure. Rien de bien méchant.
- côté serveur du Django classique avec une app REST. L'app REST va recevoir ta requête, va la mouliner et va la sauvegarder dans une base de donnée. La partie classique va servir à créer la page web où tes mesures seront affichées.
- côté frontend, tu peux prendre ce que tu veux comme widget pour afficher les données. Pour les recevoir, le mieux c'est de faire du server sent event. Il y a une app Django pour ça. Depuis le frontend tu fais une requete GET vers le serveur. Puis après il te balance des données dès qu'il y a des modifications dans la base de données. Il ne reste plus qu'à les afficher.
[^] # Re: pour l'asynchrone
Posté par jepostesurlatribune . Évalué à 1.
En fait, on va monitorer chaque cuve de fermentation pour ensuite optimiser les cycles. ç'est à la sortie que le gouteur va évaluer la prod. Puis un stagiaire IA fera un neural network pour trouver le bon algo. ça va prendre bon nombre de mesure sur plusieurs années. (cycle de fermentation , un cooperative entre 3 et 6 cuves pour commencer, dépend de la qualité du raisin en entrée, pas mon boulot).
Santé à toutes et tous.
merci pour les infos.
[^] # Re: pour l'asynchrone
Posté par Destop . Évalué à 1.
Je ne connais pas du tout le domaine, donc j'ai du mal à voir combien de capteurs et combien de mesures sont nécessaires, donc c'est difficile d'en dire plus. Mais du coup si je comprends bien, à terme il s'agit de piloter aussi l'installation?
Je n'avais pas répondu sur la partie asynchrone. Django 3 est asynchrone (à terme Django channels et Django vont fusionner). Mais cette partie asynchrone n'est pas utile pour sauver les données dans une base (l'opération est par définition synchrone et bloquée par Django), ni pour faire des calculs très légers, ni pour les envoyer sur le frontend. Par contre si tu veux commencer à utiliser des algorithmes lourds pour analyser les données, je découplerai cette partie calcul du serveur de données.
Et s'il y a vraiment de gros flux de données à gérer et des gros calculs à faire, des solutions plus lourdes sont nécessaires (du genre Apache Kafka, Spark ou équivalent avec du Spring Cloud Stream pour lier le tout).
[^] # Re: pour l'asynchrone
Posté par elf32 . Évalué à 2. Dernière modification le 21 décembre 2019 à 06:18.
Hum… Django 3 supporte maintenant l'interface ASGI, mais est-il vraiment, vraiment, asynchrone pour l'instant ? :)
Comme tu l'expliques bien, il y a encore des choses à faire. En attendant, je ne dirais pas que Django 3 est asynchrone de façon utile dans le cas présent.
[^] # Re: pour l'asynchrone
Posté par Destop . Évalué à 0.
oui tu as raison, ils commencentjuste à poser les premières briques. Ce n'est pas encore utilisable à moins de redévelopper Channels from scratch. Donc autant utiliser Channels. Mais d'après ce que je comprends des besoins immédiats, l'asynchrone n'apporte pas grand chose.
# Supervision
Posté par Seb . Évalué à 10.
Hello,
Ca semble assez proche d'un processus de supervision classique. Du coup je pense que tu peux regarder des outils de type Prometeus pour la collecte et le stockage, et Grafana pour la présentation par exemple ;)
Bon courage.
[^] # Re: Supervision
Posté par damaki . Évalué à 2.
Effectivement, ça m'a directement fait penser aux outils de supervision, genre InfluxDB et Grafana pour ceux qu'on utilise en prod.
[^] # Re: Supervision
Posté par Marc Quinton . Évalué à 3.
je pencherai aussi, par expérience perso et pro pour influxdb + scripts python (les miens sont en ruby). Et une visu sur chronograph parce qu'il fonctionne très bien avec la suite influx et parce qu'il permet l'authentification (oauth2) avec la gestion de droits.
si les dashboards ne sont pas uniquement basés sur des suites temporelles, il faudra choisir autre chose (ELK?).
[^] # Re: Supervision
Posté par Marc Quinton . Évalué à 3.
voici une copie d'écran sur le dashboard associé à ma chaudière : https://pasteboard.co/IM0ieoFz.png
# "module d'identification ?"
Posté par Mathieu CLAUDEL (site web personnel) . Évalué à 2.
Fédéré !
OpenId Connect sur leur fournisseur de mail (ici google) et bascule sur un autre fournisseur si ils changent de crémerie.
# va te faire incuber
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -5.
chez IBM à bois colombes
# c'est du dev
Posté par xulops (site web personnel) . Évalué à 5.
Mettre en place un tel système de suivi de prod, ça demande du travail de développement.
Ce n'est pas en collant un dashboard avec un base de données et tes capteurs, le tout dans un éventuel cloud (pourquoi d'ailleurs, parce cloud est un mot à la mode ? un simple serveur ouvert sur le web suffit, si les backups sont bien pensés et mis en place) que ça va marcher.
Au mieux ça marchouillera, ça sera insatisfaisant, non-évolutif, mal-adapté aux besoins, mais gratuit (beurre, argent du beurre, cul de la crémière, tout ça).
Bref, si c'est pour faire ça sérieusement, c'est un projet qui requiert quelqu'un du metier (de l'informatique, un dev web, en gros). C'est néanmois un projet intéressant, dommage que je sois en Chine pour quelques temps encore.
Le plus crucial ne sera de toute façon pas l'informatique, mais les capteurs, et surtout leur placement afin que leurs valeurs aient une réelle signification.
Bon courage !
[^] # Re: c'est du dev
Posté par freem . Évalué à 6.
D'ailleurs, je suis le seul à trouver le déploiement de rPI overkill? C'est un peu du gâchis pour un système qui n'a besoin que de relever des températures et de les transmettre… surtout si une exploitation peut avoir plusieurs cuves, ça va faire beaucoup de rPI au bout d'un moment, non?
# Demande contact
Posté par barou27 . Évalué à 1.
Bonjour
Je suis intéressé par l’offre
Comment puis-je vous contacter ?
# Formation AgTech
Posté par Elephant (site web personnel) . Évalué à 4.
Salut,
Après mes aventures dans les logiciels de caisse (les curieux iront lire mes anciens journaux), je suis à présent responsable d’une formation dans le domaine de l’AgTech / AgriTech / AgroTech etc. (ce domaine a pas vraiment de nom défini pour le moment …)
C’est une formation au format Grande École du Numérique : 4 mois de cours, 2 mois de stage. Un CAP informatique pour l’agriculture en somme :)
On a donc des élèves avec la double casquette agro et informatique. Je pense que ça peut être intéressant en projet réel ou en stage pour eux.
Si ça t’intéresse, on peut en parler ici ou tu peux me joindre via philippe tructoutronddesadressemails pop.eu.com
# Prise de contact
Posté par Killian . Évalué à -1. Dernière modification le 20 décembre 2019 à 15:01.
Bonjour,
Actuellement apprenant dans une formation professionnelle liant l'agriculture et les appareils connectés. Nous avons ainsi les connaissances pour développer votre projet.
Je vous invite à prendre contacte avec moi à l'adresse mail ci-dessous: leonardkillian97@gmail.com
Ains qu'au mail du formateur popschool : thomashocedez@pop.eu.com
Cordialement
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.