23/04/2014, 14:40:00
Intéressant !
Je pense comprendre ton souci : pour l'instant, tu as du mal à voir les tenants et aboutissants du tout ça. Il faut arriver à comprendre l'architecture des divers composants et outils à ta disposition, et voir comment les utiliser... Au début, on est largué, et petit à petit, les choses se mettent en place. C'est un processus que tu rencontreras tout au long de ta carrière pro, ainsi que dans ta vie privée. C'est d'ailleurs souvent passionnant !
Pour répondre à ta question concernant linknx : il s'agit d'une couche logicielle qui sert essentiellement de supervision (sans interface graphique). On y définit les objets du bus physique, mais on peut aussi créer des objets purement logiciels. Un des intérêts de linknx est l'utilisation de 'rules', qui vont permettre de réagir de manière automatique à ce qui se passe sur le bus. Par exemple, tu peux modifier une consigne de température en fonction de l'heure. Ou encore faire de la logique (ET, OU...). Et plein d'autres choses.
Il permet aussi d'enregistrer dans une base de données les valeurs de certains objets (pratique pour faire du suivi de conso, ou du monitoring de température).
Etc.
Il sert beaucoup en conjonction avec knxweb, qui, lui, est une couche graphique, permettant de visualiser l'état des objets de linknx, et de modifier ceux-ci en cliquant sur des icônes depuis un navigateur.
À contrario de linknx qui est une appli monolithique, qui se configure par le biais d'une fichier xml, j'ai développé pKNyX pour être plus modulaire. C'est un framework python, c'est à dire que ce n'est pas une appli à proprement parler, mais un ensemble de classes et d'outils qui inter-agissent et facilitent le développement d'applis finales. Ces applis sont clairement orientées KNX. En fait, l'idée est de pouvoir développer des devices logiciels, chaque device étant un process (programme) à part entière, autonome, exactement comment les devices physiques. Ils peuvent tourner sur la même machine, ou pas. Ça correspond à la partie 'rules' de linknx, mais avec une approche très similaire aux vrais devices physiques (ce sont des boîtes avec des entrées et des sorties, ayant un état et un comportement).
Un des buts premiers de pKNyX était également de fournir une stack KNX complète, mais je n'ai implémenté qu'une toute petite partie, car c'est quelque chose de beaucoup plus complexe que je ne le pensais. La partie implémentée permet de faire tourner ces devices softs, mais nécessite encore eibd (ou un routeur KNX physique, qui coûte cher).
Dans ton cas, pKNyX est plus indiqué, puisque tu dois développer en python ; ce sera donc assez simple à intégrer. En gros, tout est dans le script pknyx-group.py ; il faudra juste ré-organiser ça en fonction du framework Nao.
Est-ce que tu as la doc pour développer les 'boîtes noires' de Nao, en particulier la 'structure du squelette défini par Aldebaran' ? Est-elle partageable ?
Bon, on n'est bien sûr pas là pour faire le boulot à ta place, hein, mais pas de problème pour te conseiller
Au passage, je trouve ton projet génial !
Je pense comprendre ton souci : pour l'instant, tu as du mal à voir les tenants et aboutissants du tout ça. Il faut arriver à comprendre l'architecture des divers composants et outils à ta disposition, et voir comment les utiliser... Au début, on est largué, et petit à petit, les choses se mettent en place. C'est un processus que tu rencontreras tout au long de ta carrière pro, ainsi que dans ta vie privée. C'est d'ailleurs souvent passionnant !
Pour répondre à ta question concernant linknx : il s'agit d'une couche logicielle qui sert essentiellement de supervision (sans interface graphique). On y définit les objets du bus physique, mais on peut aussi créer des objets purement logiciels. Un des intérêts de linknx est l'utilisation de 'rules', qui vont permettre de réagir de manière automatique à ce qui se passe sur le bus. Par exemple, tu peux modifier une consigne de température en fonction de l'heure. Ou encore faire de la logique (ET, OU...). Et plein d'autres choses.
Il permet aussi d'enregistrer dans une base de données les valeurs de certains objets (pratique pour faire du suivi de conso, ou du monitoring de température).
Etc.
Il sert beaucoup en conjonction avec knxweb, qui, lui, est une couche graphique, permettant de visualiser l'état des objets de linknx, et de modifier ceux-ci en cliquant sur des icônes depuis un navigateur.
À contrario de linknx qui est une appli monolithique, qui se configure par le biais d'une fichier xml, j'ai développé pKNyX pour être plus modulaire. C'est un framework python, c'est à dire que ce n'est pas une appli à proprement parler, mais un ensemble de classes et d'outils qui inter-agissent et facilitent le développement d'applis finales. Ces applis sont clairement orientées KNX. En fait, l'idée est de pouvoir développer des devices logiciels, chaque device étant un process (programme) à part entière, autonome, exactement comment les devices physiques. Ils peuvent tourner sur la même machine, ou pas. Ça correspond à la partie 'rules' de linknx, mais avec une approche très similaire aux vrais devices physiques (ce sont des boîtes avec des entrées et des sorties, ayant un état et un comportement).
Un des buts premiers de pKNyX était également de fournir une stack KNX complète, mais je n'ai implémenté qu'une toute petite partie, car c'est quelque chose de beaucoup plus complexe que je ne le pensais. La partie implémentée permet de faire tourner ces devices softs, mais nécessite encore eibd (ou un routeur KNX physique, qui coûte cher).
Dans ton cas, pKNyX est plus indiqué, puisque tu dois développer en python ; ce sera donc assez simple à intégrer. En gros, tout est dans le script pknyx-group.py ; il faudra juste ré-organiser ça en fonction du framework Nao.
Est-ce que tu as la doc pour développer les 'boîtes noires' de Nao, en particulier la 'structure du squelette défini par Aldebaran' ? Est-elle partageable ?
Bon, on n'est bien sûr pas là pour faire le boulot à ta place, hein, mais pas de problème pour te conseiller
Au passage, je trouve ton projet génial !