Le forum ⇒ Pico open source

[NicoJ]

Tu penses que ça peut servir à quoi les sorties analogiques ?

Je sais plus, mais je crois qu'on en avait parlé, ce qui justifiait la présence de convertisseur DAC...

[NicoJ]

PS : Est-ce que tu pourrais pousser tes dernières modifs sur git ?

[jean-jean]

J'ai du mal à participer en ce moment car je suis assez pris mais je vous suis toujours.
Voici une rapide contribution d'un panneau de contrôle glané sur pinterest :





Source: http://www.homebrewtalk.com/f11/automat ... dex37.html

[Cede]

Jean-jean: je me rapellemavoir vu ça, un vrai panneau d'avion

J'ai poussé les schémas, simples, de la carte principale et de celle des relais.

Quand je passerais une commande pour le boulot, j'y rajouterais quelques bricoles histoire de vérifier les empreintes des composants. Ça m'évitera quelques surprises comme la semaine dernière sur un proto

[NicoJ]

Pour moi l'interface n'a pas pour objectif de permettre la construction d'un tel panneau. Les ports de la carte doivent servir essentiellement aux capteurs et aux actionneurs. Il faut simplement prévoir quelques contacts pour les fonctions essentielles (marche/arrêt général, BAU, voyant de fonctionnement). Le reste sera accessible via l'IHM de la partie logicielle et accessible depuis un navigateur.

[jean-jean]

Oui c'est plus simple, moins cher et super évolutif.
Je l'ai plus mis pour le schéma.

Vous comptez traiter ce sujet ou vous faites juste une plate-forme adaptable pour toute configuration ?

[NicoJ]

J'aimerais qu'on arrive à construire quelque chose qui impose le moins de contraintes possible et qui soit le plus souple en terme d'interface et de fonctionnalités.
En tout cas niveau hardware c'est bien parti. Pour le reste je pense qu'il faudrait des retours sur les besoins des utilisateurs potentiels pour orienter le projet.

[gremlinz]

Au niveau ihm je pense que l on peut faire comme un wordpress ou autre crm, c est a dire créer un moteur et développer des plugins qui gérerons les différents capteur que l on peut installer, ce qui permet d avoir une interface qui est adapte à ce que l on a.

[dickymoe]

Effectivement il faut gérer au maximum en modules indépendant.
Chacun pourra, en fonction de sa pico, ses capteurs, son architecture activer les modules qu'il a besoin. En domotique jeedom a fait ça plutôt pas mal : https://jeedom.fr/

Je pense qu'il faudrait qu'un maximum de personne expriment leur besoin sur le coté logiciel. Le pad en résume déjà plusieurs (https://lite4.framapad.org/p/beerfactory).
On pourra établir un cahier des charges plus précis et une architecture plus détaillée : type de serveur (python, c++, nodejs, ...), ihm web (serveur php, python, ...), logiciel client lourd / appli Mobile...

@NicoJ : Peux tu donner plus de détail sur ce que tu entends par "interface Agent" et son rôle ?

[NicoJ]

@NicoJ : Peux tu donner plus de détail sur ce que tu entends par "interface Agent" et son rôle ?

C'est ce que j'ai essayé de faire figurer sur ce schéma.
Pour faire "tourner" l'IHM il faut une module serveur. Ce module dialogue avec la carte pour récupérer les données des capteurs et piloter les actionneurs. Plutot que de piloter directement, je pensais développer un "agent" qui serait chargé de cette tâche. Ainsi sur la carte BBB, on n'installe que l'agent. Le serveur peut-être installé n'importe où et ne gère "que" de l'IHM et le dialogue avec l'agent.
Ca permet également de gérer plusieurs agents, et donc plusieurs cartes. Concrètement on pourrait imaginer d'avoir une carte pour piloter une pico et une carte pour piloter une chambre de fermentation. Chacune hébergerait un agent, le tout supervisé par un seul module serveur.