Je viens de lire tout ça (projet bien intéressant) et je suis tombé là-dessus :
spourre a écrit : ↑jeu. 5 avr. 2018 14:26
...
Il reste encore une alternative, c'est de s'inspirer (avec son aide) du tuto de Bud . Après tout, il y a déjà 2 canaux analogiques à surveiller et afficher (turbidité et batterie).. Ça ne dispensera pas de toute la quincaillerie liée à un écran LCD mais ça peut simplifier considérablement la conception de l'IHM (et le stockage des données récemment demandée par François.
..
Si tu fais allusion au tuto sur les appli web dynamique, c’est effectivement tout à fait envisageable avec ces méthodes et cela pourrait même être plutôt bien adapté. Sans vouloir interagir avec vos idées, je vous en soumets quelques une à titre de réflexion.
Un PI Zero W avec le petit montage pour l’acquisition et la gestion de la robinetterie pourrait former les modules embarqués pour chaque patient. Au niveau du programme cela peut se résumer à peu de chose puisqu’il suffirait de faire l’acquisition toutes les X minutes et transférer les données sur un socket vers un serveur de supervision qui lui retournerait le paramètre adapté pour ‘l’ouverture du robinet’. Pour consolider le procédé, on pourrait aussi envisager un ACK pour informer le serveur de la bonne prise en compte du paramètre et même envisager le transfert d’autres infos que le serveur pourrait interpréter (force du signal, niveau de batterie …).
Pour le serveur de supervision, un Pi 3 pourrait parfaitement faire l’affaire. Il n’aurait qu’à recevoir les infos des modules clients et les traiter suivant les règles définies pour retourner à chacun d’eux le paramètre ‘robinet’ adapté et générer les alertes. En plus de traiter les données, le code serveur pourrait facilement être capable de les transférer sur un système de stockage disposant d’une bonne garanti de fiabilité, de détecter les éventuelles pertes de connexion avec les modules clients mais aussi servir d’IHM de supervision centrale. Bien sur cette IHM serait servie par le même script serveur, ce qui permettrait aux infirmières ou autres hommes de science de le consulter en temps réel depuis n’importe quel appareil connecté (tablette, smartphone ...) ou tout simplement de l’avoir en temps réel sur un écran de leur desktop.
Pour les options d’ergonomie, tout est envisageable avec ces méthodes. Ça peut aller de la simple détection automatique des clients par le serveur sans aucune intervention (juste mettre le bouton du client sur on) jusqu’à de l’analyse statistique en temps réel pour mieux gérer les débits de sérum.
Synthétisé vite fait, voilà les premiers avantages que je vois dans cette méthode :
- Un seul langage de programmation pour les modules clients, le serveur et la GUI. Du code simple à entretenir sans besoin d’aucun outil de développement spécifique et ne nécessitant aucun compilateur. Aucune lib spécifique hormis celle qui permet l’accès au GPIO sur les PI Zéro.
- En cas de panne du PI3, le code serveur pourrait très facilement être provisoirement exécuté sur n’importe quel autre ordinateur existant quel que soit son os (en tous cas les plus usuels). On pourrait même envisager des modules hybrides embarquant tous le même programme et étant configurable soit en mode client soit en mode serveur par la simple position d’un jump (ce qui en plus simplifierait les déploiements)
- GUI riche et supervision centralisée disponible en simultané et en temps réel depuis des sources multiples ne nécessitant aucune programmation ni aucun paramétrage.
- Aucun paramétrage spécifique des clients puisque tous les paramètres peuvent être centralisé et distribuer automatiquement à la connexion par le serveur
- Aucune donnée stockée en dur sur les clients ou sur le serveur.
- Pas besoin d’écran du côté des embarqués. C’est un des points les plus important ça. Si on regarde bien, se déplacer pour aller visualiser un écran ou contrôler le bon fonctionnement d’un système revient au même que de se déplacer pour aller visualiser la transparence d’un fluide dans un tuyau, donc c’est à mon sens à côté de l’idée de base du cahier des charges. Dans l’extrême du luxe, ils pourraient disposer juste d’un petit lcd 2x16 pour faire plus geek et user un peu plus vite les batteries. Ce serait très largement suffisant pour afficher quelques infos inutiles puisque tout serait déjà centralisés.
- Dans l’absolu, le serveur peut lui aussi se passer d’un écran dédié et être lui-même administrer à distance sans rien programmer de plus.
- Possibilité d’imposer des règles spécifiques à chaque client depuis le serveur.
…
Voilà, c’est juste quelques idées qui me viennent comme ça et je ne vois là-dedans aucune contrainte particulière qui empêcherait la prise en charge intégrale de la partie software par le seul modèle cité.
ps : pour la partie dosage, il ni aurait pas moyens de trouver des petits robinets 1/4 de tours qui fasse l'affaire ? Mécaniquement parlant gérer un angle d'ouverture serait plus simple que de gérer l'écrasement d'un tuyau ?
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).