Le forum ⇒ Pico open source

[Cede]

Je vois que la réflexion avance

Je suis aussi pour un système serveur client, ce qui permettrait d'avoir une ou plusieurs ihm et des clients mobiles.
Doux rêve

Dans la gestion de process, c'est la norme, et comme exemple qui me vient tout de suite à l'esprit: Prolon.net
C'est du chauffage/clim, avec un module serveur qui gère l'usine à gaz, et un client java ( moyen je trouve java, mais multiplateforme ) qui permet d'interagir et de superviser le bouzin.

Ce qu'il y a de bien, c'est que lorsque le client se connecte, il récupère la configuration et batit l'ihm en direct live.
Ensuite il n'y a plus qu'à essayer de régler le merdier ( l'histoire des filles de la compta qui voyaient leurs feuilles s'envoler du bureau au démarrage de la clim ! )

Mais de ce que je comprends Nico, tu pousserais encore plus loin en mettant un agent pour chaque section, un serveur pilotant les agents et des ihms.

Dans le cas de la chambre de garde, ou cuve de fermentation contrôlée, je pense que prendre un BBB, c'est légèrement violent Un simple microcontrôleur avec une liaison bluetooth ou wifi suffirait largement à s'occuper de tout ça.
J'ai bidouillé un contrôleur de température dans le genre, très simple ou pas... avec un pic, une horloge temps réel, une carte SD pour logger, un module bluetooth et un ipod pour programmer.
Je donnais les températures, les temps et roulez jeunesse !
Je repassais 2 jours plus tard et je récupérais les données.
Le but de la chose était de chauffer le sol à puissance ou température constante et d'observer la réaction le jour, la nuit etc...

Retour à la bière

J'ai avancé beaucoup le module E/S analogiques, 4 de chaque. Il faudra que je paufine.
Pour la partie entrées analogiques, pas trop de problèmes, ça fera donc du 0-10V ou 0-20mA, et en plus.... 10V ou 20mA ça donnera une valeur de 4000 ! Pas beau ça ?
Je ferais la même chose dans l'autre sens pour que 2000 donne 10V. Oui 2000 car en entrée c'est sur 12 bits et 10 en sortie pour l'instant.
Pour les sondes PT 100, il faut aussi que je recalcule les composants pour avoir 4000 en valeur pour 100*C.

En l'état actuel des choses, dans les cartes dessinnées j'ai:

• base 4x PT 100, 4x MLI (PWM), 8x entrées TOR, 8x sorties
• module 8x Relais 10A , chacun ayant commun, NO, NC
• module 4x entrées analogiques 0-10V ou 0-20mA et 4x sorties 0-10V ( on pourrait adapter en 0-20 mA si besoin )

Il resterait un module 8x entrées TOR et 8x sorties TOR à faire, en fait à cloner du module de base.

En dessinant, j'ai aussi pensé à quelques petites choses comme mettre les jumpers ou dip switches sur le coté du boitier ou dessous pour ne pas être obligé de l'ouvrir pour régler ça.
Mettre des leds en façade pour valider l'état des entrées et des sorties sur les modules TOR et relais.

Vous me direz ce que vous en pensez

Mon dessinateur favori est partit en mission, mais dès qu'il revient je vais lui demander si il peut me faire une vue iso des boitiers avec ces options.... Contre quelques bières

[NicoJ]

Mais de ce que je comprends Nico, tu pousserais encore plus loin en mettant un agent pour chaque section, un serveur pilotant les agents et des ihms.

Dans le cas de la chambre de garde, ou cuve de fermentation contrôlée, je pense que prendre un BBB, c'est légèrement violent Un simple microcontrôleur avec une liaison bluetooth ou wifi suffirait largement à s'occuper de tout ça.
J'ai bidouillé un contrôleur de température dans le genre, très simple ou pas... avec un pic, une horloge temps réel, une carte SD pour logger, un module bluetooth et un ipod pour programmer.
Je donnais les températures, les temps et roulez jeunesse !
Je repassais 2 jours plus tard et je récupérais les données.
Le but de la chose était de chauffer le sol à puissance ou température constante et d'observer la réaction le jour, la nuit etc...

Oui, l'agent ajoute un niveau supplémentaire en effet. Dans le cas de monsieur tout-le-monde, c'est-à-dire pour piloter uniquement une pico, on pourrait faire en sorte que l'agent soit intégré dans le serveur et donc il n'y aurait qu'un paquet à installer sur le BBB. Dans le cas général, l'idée c'est bien de permettre d'avoir 1 serveur et n agents (avec n peu élevé...).

• chaque agent gère une carte, c'est-à-dire un ensemble de capteurs et d'actionneurs. Il est donc installé sur le BBB. Effectivement, il faut un BBB par carte (sauf à prévoir que plusieurs cape puissent cohabiter sur le même BBB).
• l'un des BBB (ou un autre PC) héberge le module serveur. Celui-ci dialogue avec les agents pour leur transmettre les ordres de pilotage et récupérer les données collectés depuis les capteurs. Il se charge également de la persistance de ces données. Enfin, il expose à l'IHM une API permettant de traduire les ordres de l'utilisateur.
• l'IHM c'est la couche présentation, à base de HTML, javascript (AngularJS). Elle est téléchargée depuis le serveur et elle communique avec ce dernier via une API afin de traduire les ordres de l'utilisateur. Elle peut également être constituée d'une appli mobile qui utilise la même API de communication

Effectivement, le sujet chambre de garde peut se régler rapidement comme tu l'indiques. D'ailleurs pour ça il y a brewpi. Après, c'est juste une architecture qui permet de généraliser le concept et donc de proposer cette fonctionnalité si besoin.

[Cede]

Un petit update.

Je viens de pousser les schémas de la carte 4E + 4S analogiques.

J'ai aussi envoyé une autre carte 8 entrées + 8 sorties, celle là un peu différente de ce que j'avais fait, à savoir les entrées sont isolées par optocoupleurs et les sorties sont sur FETs avec une possibilité de 3A par sortie en 12 ou 24V.

Prochaine étape pour moi, faire les circuits qui vont dans le haut des boitiers permettant de les relier les uns aux autres puis réaliser des protos.
Et bien entendu sortir les couts de chaque carte.

Un peu plus tard, je verrais pour faire une carte pour débimètres.
J'ai pensé à quelquechose permettant de lire les débits en continu et de paramétrer une interruption si un volume est atteint.
Je ne pars pas de rien, car j'ai déjà fait un circuit débimètre sur bus 1-wire qui permettait d'avoir des débits, pour l'interruption c'est relativement aisé à paramétrer.

[NicoJ]

Nickel, ça avance bien en tout cas !

Dans la série module d'extension, ça pourrait être pas mal également d'avoir un module permettant de mesurer la consommation électrique de l'installation. J'avais repéré ce circuit (AD7953) pour couvrir ce besoin.

[dickymoe]

Pour moi la logique de ton schéma est bonne (c'est plus la représentation qui ma perturbée).

1 serveur <-> n agents nikel.

On peut imaginer, comme le dit cede avoir une carte arduino qui surveille la température de fermentation, la stoque sur une carte SD ou envoie en bluetooth a son agent les données. Ces données sont soit directement mises en bases soit envoyées au serveur et ça laisse de la liberté de codé un agent en fonction de son besoin.

Un agent peut être considéré comme un serveur local et peut être en n'importe langage (python, nodejs (a voir les possibilités gpio), apache) : communication en JSON.

Je vois que tu est pour de l'angularjs pour la partie IHM. Je connais peu, mais pourquoi pas (bonne occasion d'apprendre : tutorial en cours).
Pour le langage du serveur pas de préférence, j'avais en tête initialement un serveur php/symfony2 qui gérerai les accès base et l'api JSON : ça me semble un peu lourdingue.
Donc si on part sur du angularjs pour l'ihm, faire un serveur nodejs avec des bases de données nosql me semble intéressant (a voir les performances).

[NicoJ]

Oui, mon schéma n'est peut-être pas très clair. J'ai essayé de montrer les différents possibilités de déploiement:

• 1 serveur + 1 agent sur le même système
• 1 serveur + 1 agent distant
• 1 serveur + n agents distants ou locaux

Pour le stockage des données, je pensais à un stockage temporaire coté agent et un stockage persistant coté serveur. Sur le langage je suis pas chaud pour node.js. Je préfèrerais une solution à base de python, sachant que la version 3.4 apporte des fonctions similaires à node.js en terme d'I/O asynchrones.
Sur l'IHM j'ai proposé AngularJS, car j'ai eu l'occasion de tester un peu et je trouve que c'est bien conçu et vraiment puissant. Je pense que ça évite pas mal de prise de tête avec le navigateur, jquery et sa bande ...
Pour tout ce qui concerne les API (IHM <-> serveur ou serveur <-> agent) Python ça se fait bien en python, par exemple avec le micro framework bottle.

Node.js + base NoSql : pour moi c'est un choix qui se justifie pour des gros sites avec beaucoup d'accès concurrents et beaucoup de données (facebook, google, ...). Ici a priori on n'a qu'un seul utilisateur (le brasseur) et "peu" de données. Pour moi le couple python avec une base type sqlite, devrait amplement faire l'affaire. Il ne faut pas oublier non plus que malgrè tout la carte BBB à une puissance limitée. Ca permet également de confiner le javascript au traitement de l'IHM pure. Cela pose également la question des compétences nécessaires pour participer au projet (node.js n'est pas ) la portée du premier venu ...)

Mais bon, ça se discute ...

[Cede]

Nickel, ça avance bien en tout cas !

Dans la série module d'extension, ça pourrait être pas mal également d'avoir un module permettant de mesurer la consommation électrique de l'installation. J'avais repéré ce circuit (AD7953) pour couvrir ce besoin.

Oui ça peut être intéressant.
Je dois avoir un circuit que j'avais fait pour la mesure de consommation électrique d'une pompe à chaleur.

Pour le matériel, j'ai mis en commande des composants avant de partir ce soir, et la semaine prochaine je pourrais finaliser les circuits imprimés en fonction. Ça évitera les mauvaises surprises de pouvoir poser les composants sur une copie taille réelle.

Coté logiciel, une chose à ne pas oublier: il faut le le langage soit capable de monter en mémoire un programme dans le PRU et d'accéder à la mémoire partagée. https://bitbucket.org/intelligentagent/pypruss par exemple pour le python. Pour le C, ça fonctionne aussi, mais pour les autres langages, je ne sais pas trop.
C'est une petite contrainte que je met là, pour une raison simple: laisser les PRU s'occuper des PWM, il savent faire ça très bien.
Il suffira d'envoyer en mémoire un mot de 32 bits, 8 bits par pwm et il s'occupera de faire les pwm en fonction et synchronisé sur le secteur si besoin pour limiter l'échauffement des SSR.

Pour la partie serveur, n'étant pas spécialiste en logiciel, je pensais à un thread s'occupant exclusivement des communications avec les cartes, et comprenant un buffer de commandes que l'on remplirait avec des priorités si besoin, et répondant aux interruptions par exemple lorsque l'on appuie sur un bouton ou qu'un capteur envoie une impulsion. ( pas les débitmètres, le système serait trop lent à répondre pour calculer ).

[NicoJ]

Coté logiciel, une chose à ne pas oublier: il faut le le langage soit capable de monter en mémoire un programme dans le PRU et d'accéder à la mémoire partagée. https://bitbucket.org/intelligentagent/pypruss par exemple pour le python. Pour le C, ça fonctionne aussi, mais pour les autres langages, je ne sais pas trop.
C'est une petite contrainte que je met là, pour une raison simple: laisser les PRU s'occuper des PWM, il savent faire ça très bien.
Il suffira d'envoyer en mémoire un mot de 32 bits, 8 bits par pwm et il s'occupera de faire les pwm en fonction et synchronisé sur le secteur si besoin pour limiter l'échauffement des SSR.

La bibliothèque pypruss se base sur une partie en C un un module spécifique du noyau (uio_pruss), mais ça ne pose pas de problèmes normalement.

Les threads c'est efficace lorsque ton CPU le gère. Sur le BBB on a un processeur monothread donc ça revient à faire du séquentiel. Je pense qu'il faut mieux regarder du coté de la librairies asyncio (en python) qui permet de gérer une boucle d'évènements dans un seul thread. Cela permet de profiter des temps d'attentes dues aux I/O pour exécuter du code applicatif, et donc d'optimiser l'utilisation du CPU. L'idée d'une file d'attente de commande est bonne et compatible avec ce mécanisme.

[NicoJ]

juste pour rire, j'ai testé pour vous le branchement de l'alimentation du BBB à l'envers => ça marche moins bien, forcément...
Je suis bon pour en recommander un neuf ...

[Cede]

Dommage Eliane

C'est vrai qu'il n'y a pas de diode de protection