Test scénarios et commandes ON OFF SET ASKDATA

[PtitKev]

Hello tous,
J'ai pu effectuer les tests samedi en compagnie de Xylerk et j'ai réussi à faire fonctionner assez facilement le master-plugins (voir si on peut le renommer node-master si on veut conserver la logique de l'architecture).
Xylerk si tu disposes des logs pourrait tu enrichir le premier post pour simplifier l'installation de nouveaux testeurs ?

La configuration du réseau de node est par contre à revoir : actuellement la structure est détaillée dans la configuration. Elle devrait être fournie par le hub qui est l'interface de contrôle et de paramétrage de notre réseau domotique.

J'ai proposé la solution d'un fichier JSON que le hub fournirait au node-master au moment de son lancement puis lors des mises à jour.

Par contre je persiste à dire que le master doit servir uniquement de passerelle : il doit donc gérer uniquement les protocoles des nodes.

Pour le coté features c'est au hub de gérer les données des nodes.

Du coup : qui travaille sur le hub ? Je n'ai pas vraiment trouvé d'info sur le hub concernant l'organisation des fichiers sur symfony.

[Xylerk]

(voir si on peut le renommer node-master si on veut conserver la logique de l'architecture)

Le node-master n'est que l'atmega, le master-plugin est un programme en C++

Xylerk si tu disposes des logs pourrait tu enrichir le premier post pour simplifier l'installation de nouveaux testeurs ?

Je vais regarder mais sinon il y a deux personnes qui peuvent nous les fournir...

La configuration du réseau de node est par contre à revoir : actuellement la structure est détaillée dans la configuration. Elle devrait être fournie par le hub qui est l'interface de contrôle et de paramétrage de notre réseau domotique.

J'ai proposé la solution d'un fichier JSON que le hub fournirait au node-master au moment de son lancement puis lors des mises à jour.

Voilà en partie ce qu'il faudrait modifier...

Par contre je persiste à dire que le master doit servir uniquement de passerelle : il doit donc gérer uniquement les protocoles des nodes.

Pour le coté features c'est au hub de gérer les données des nodes.

C'est donc au hub de décoder les trames qui sont sous cette forme?

Code : Tout sélectionner

0x1 0x7b 0x1 0x3 0x21 0x90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xde

[PtitKev]

C'est vrai que j'ai regroupé la node et le programme associé. On oublie donc

Pour moi :
- Le node-master reçois les ondes et les transmet au master-plugin comme un changement de statut 0->1 et 1->0.
- Le master-plugin dispatch sur les plugins protocols qui s'occupent de constituer une trame
- Le hub est appelé en REST avec les infos de la trame.

Pourrais tu m'expliquer comment la problématique des ressources pour la haute disponibilité a été contournée sur cette version du master ?

Dans un des plugins j'ai bien trouvé la gestion des interruptions (plugins/i2crf/protocol.cpp:429 cf http://raspberrypihobbyist.blogspot.fr/ ... ingpi.html) mais rien dans serial-rf, juste usleep(50000); qui à priori se déclenche quand il y a rien à faire ce qui réduit la disponibilité d'écoute de 50ms ce qui me semble énorme, non ?

Bon, je fatigue un peu là mais je continue demain

[Yaug]

Hello

Cette logique ou le master se charge de la communication et le hub de gérer le tout est celle que je veux suivre depuis le début.

C'est moi qui travaille sur le hub pour info.
Et bonne nouvelle, je peux recommencer à bosser dessus dès ce mois ci \o/

Rappelez moi de tuer le prochain presta qui fou le bordel au boulot... ça m'a couté 4 mois :'(


Super vos tests du coup.
Est ce qu'il y a moyen d'en faire un tuto très détaillé pour que tout le monde puisse le suivre ?
Merci !

[PtitKev]

Je finis mes tests sur le master mais je bute un peu sur le concept d'une Frame : vis à vis du master doit on uniquement gérer l'expéditeur et la data ou il faut inclure d'autres infos ?

En gros actuellement la node Ydle envois des infos (sender, targer) et comment la traiter (type, size) : du coup l'IHM communication thread parse les types et fait une requête par info sur le master.

Je n'ai aucun recule pour savoir si les autres protocoles RF utilisent un mode similaire : faut il se dire que le protocole Ydle segmente de lui même les types de données et les envois un par un au hub (version actuelle) ou envoyer TOUT au hub et il se démerde ?

De toute façon j'ai aussi conservé la communication avec l'IHM : c'est le protocole qui communique l'info, pas la node.

L'idée est que j'ajoute une interface pour une frame et tous les protocoles se reposent dessus pour gérer la communication en fournissant pour la communication avec l'IHM les champs obligatoires.