Journal appli web cooperative viticole

Posté par  . Licence CC By‑SA.
4
19
déc.
2019

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  . Évalué à 1.

    django channel

    • [^] # Re: pour l'asynchrone

      Posté par  . Évalué à 1.

      Long Polling, Server Sent Event ou websocket
      recursivité

      • [^] # Re: pour l'asynchrone

        Posté par  . É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  . É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  . É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  . Évalué à 2. Dernière modification le 21/12/19 à 06:18.

              Django 3 est asynchrone

              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  . É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  . É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  . É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  . É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?).

  • # "module d'identification ?"

    Posté par  (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  . Évalué à -5.

    chez IBM à bois colombes

  • # c'est du dev

    Posté par  (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  . Évalué à 6.

      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.

      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  . Évalué à 1.

    Bonjour
    Je suis intéressé par l’offre
    Comment puis-je vous contacter ?

  • # Formation AgTech

    Posté par  (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  . Évalué à -1. Dernière modification le 20/12/19 à 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.