Re: [OpenplacOS] Openplacos, driver XBee

Le 4 décembre 2012 16:40, rom .. <lsdark73@xxxxxxxxx> a écrit :

ok ok bon ca a l'air pas mal tout ça :)
j'avoue que je n'ai pas encore eu le temps de m'y remettre, ca m'a pris pas mal de temps avec les xbee lol
tout le monde sur le même bus si je comprends bien, et l'interfacage avec l'exterieur en webservice je crois ?
aussi juste pour être sûr,
les acces aux objets se font toujours seulement avec read/write comme méthodes, et c'est l'interface qui fixe le type d'arguments/réponse ?
il ya une liste d'interfaces standards ?

Le 4 décembre 2012 16:21, flagos <flagospub@xxxxxxxxx> a écrit :

C'est exactement ca :-)

La seule petite nuance, c'est qu'on a inversé le sens de communication entre les modules et le serveur:
1. Le serveur demande aux modules ce dont ils ont besoin, retour de l'info via un yaml. Les modules sont juste lancés en --introspect et meurent.

2. Le serveur créé les objets dbus dont le module a besoin pour fonctionner
3. Le serveur relance les modules en mode normal et leur exposent les objets dont ils ont besoin (entrées + sorties).
4. A l’exécution, c'est le serveur qui va se charger de balancer une requête a un module, de récupérer la sortie et de la renvoyer au second module. En clair, le serveur gère le dispatch entre les modules.

Enfin voila, j'éclaircis tous ces points parce que c'est des questions que tu risques de te poser...

Le 4 décembre 2012 15:55, rom .. <lsdark73@xxxxxxxxx> a écrit :

en fait c'est :
j'ai un xbee branché sur le port série du pc
j'ai plusieurs noeuds xbee+arduino dont je veux fixer les capacités "définitivement" dans un yaml en eprom
je démarre le server, le driver opos-xbee interroge chaque noeud xbee+arduino pour connaitre ses capacités
j'expose ces capacités sur le bus
les autres composants utilisent les objets exposés, le driver opos-xbee positionne la bonne adresse du xbee concernée, traduit la commande (déduite du yaml) suivant le protocole série, le module concerné reçoit la commander, répond

Le 4 décembre 2012 15:47, flagos <flagospub@xxxxxxxxx> a écrit :

Si j'essaie de résumer ce que j'ai compris de ton problème:

Tu as un réseau de Xbee que tu vas introspecter a partir d'un arduino. Comme ce réseau il depend un peu de ce que l'utilisateur a branché dessus, pour moi tu ne savais pas trop quoi exposer a opos depuis ton driver.

En fait, vu que désormais dans opos unstable ce sont les drivers qui disent a opos ce dont ils ont besoin, tu peux creer un driver qui exposera autant d'objets que tu as trouvé au moment de ton introspect xbee.

Le 4 décembre 2012 15:39, rom .. <lsdark73@xxxxxxxxx> a écrit :

Pareil je sui spas sûr d'avoir bien compris, mais en fait, presque il me suffirai de copier le yaml dans l'eprom de l'arduino ?

Le 4 décembre 2012 15:26, flagos <flagospub@xxxxxxxxx> a écrit :

Salut,

Je suis pas bien sur d'avoir compris ton problème mais je vais essayer de répondre, dis moi si je suis a coté de la plaque:

Dans la branche unstable, on a changé la facon dont les modules se declare. En fait, désormais, les modules (et donc els drivers) au démarrage, envoie un yaml qui déclare les entrees sorties dont ils ont besoin. Comme ces modules sont parametrables et peuvent faire des checks au démarrage, tu peux très bien lancer un introspect et retourner un yaml specifique a ton réseau.

Pour faire ca, le serveur lance une première fois les modules avec l'option --introspect pour récupere le yaml sur la sortie standard. Comme on est des gens biens, il y a une lib pour faire ca :-)

Par contre, c'est quelque chose de figé une fois le serveur démarré, on autorise pas le remapping dynamique, mais je crois pas que c'était ce que tu cherchais.

Le 4 décembre 2012 15:09, rom .. <lsdark73@xxxxxxxxx> a écrit :

Pour le protocole série, une commande de ping pour savoir si le noeud répond bien, une commande d'introspect qui permet d'obtenir le yaml de l'arduino, et des c

--
Tapé depuis mon clavier

--
Tapé depuis mon clavier

--
Tapé depuis mon clavier