IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Python Discussion :

Framework pour bus KNX


Sujet :

Python

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut Framework pour bus KNX
    Bonjour,

    Je viens de commencer le développement d'un framework pour le bus domotique KNX, et j'aimerais avoir votre aide concernant l'architecture.

    Dans ce premier message, je vais me contenter de décrire un peu le fonctionnement du bus KNX, histoire que vous compreniez de quoi je cause J'exposerai ensuite ce que je cherche à faire, et les points sur lesquels j'aimerais avoir vos lumières.

    Le bus KNX n'est pas un bus propriétaire, mais est le fruit d'un regroupement de plusieurs constructeurs (quelques centaines, je crois). Il n'est pas super connu en France, mais très utilisé en Allemagne, surtout dans le tertiaire, étant donné son coût (et sa fiabilité). Il existe une association KNX, qui gère tout ça.

    Techniquement parlant, c'est un bus où l'intelligence est répartie entre les différents participants (bouton, détecteur, actionneur...), ce qui le rend très robuste : la perte d'un participant n'empèche pas le reste de l'installation de fonctionner ; seule la fonctionnalité associé à ce participant sera perdue.

    Chaque participant peut envoyer une valeur sur le bus lorsqu'un événement externe survient (bouton), ou inter-agir avec l'environnement lorsqu'une certaine valeur est reçue sur le bus (actionneur). En fait, les participant disposent d'un certain nombre d'objets de communication qui vont lire/écrire sur le bus. Par exemple, un bouton simple peut avoir les objets de communication suivants :

    - appui court toggle
    - appui long off
    - led d'état

    Déjà, on comprend qu'il y a des objets qui vont écrire sur le bus (appuis), et d'autres qui vont réagir aux données du bus (led d'état). La complexité des objets de communication dépend des participants, et suivant les constructeurs, on peut avoir des choses très touffues. En plus, les objets de communication disponibles sont aussi fonction de la configuration du participant ; certains permettent de faire beaucoup de choses différentes, juste en les paramétrant, ou en changeant le firmware.

    Prenons un autre exemple de participant, un actionneur (simple relais) :

    - activation sortie
    - état sortie

    Ici, "activation sortie" est un objet qui va permettre de changer l'état du relais en fonction d'une valeur reçue sur le bus. L'objet "état sortie", lui, reflète l'état du relais, et va écrire sur le bus lorsque celui-ci changera. C'est utile lorsqu'on peut modifier l'état du relais par un bouton manuel directement sur l'actionneur.

    L'association KNX a développé un gros logiciel, ETS, qui permet de programmer tout ce beau monde et faire en sorte que ça fonctionne comme on le souhaite. L'idée va être de lier les différents objets de communication entre eux, pour arriver au fonctionnement souhaité. Pour faire cette liaison, on définie des "Groupes d'Addresses" (GA dans le jargon). Par exemple, on va définir une GA "lumière couloir", dans laquelle on va lier l'objet "appui court toggle" de notre bouton et "activation sortie" de notre actionneur. Le relais de cet actionneur étant bien sûr connecté à la lumière du couloir.

    Une fois les participants programmés (via ETS), ils fonctionnent en autonome : si j'appuie sur le bouton, celui-ci va émettre sur le bus la GA "lumière couloir" et la valeur valeur (0 ou 1 suivant l'état précédent, puisque c'est un toggle). Notre actionneur va voir arriver cette GA, et va changer l'état de son relais en fonction de la valeur associée à cette GA.

    La beauté du truc, c'est qu'on peut programmer plusieurs boutons qui vont émettre une valeur sur cette GA, ce qui permet de réaliser des va-et-vient avec autant de points que l'on souhaite. Et si l'un des boutons ne marche plus, les autres continuent, eux, de fonctionner (sauf grosse défaillance du bus, bien sûr).

    On a vu que notre bouton avait aussi une petite led. Ce serait intéressant de faire en sorte qu'elle reflète l'état réel de notre lumière. C'est très simple : l'objet de communication qui permet de changer l'état de la led fonctionne exactement comme l'objet "activation sortie" de l'actionneur. Il suffit donc de lier cet objet "led d'état" à l'objet "état sortie" de l'actionneur, comme on l'a fait pour le bouton et le relais. Pour ça, on créé une autre GA "état lumière couloir", qu'on associe à nos 2 objets. Et voilà ! Que l'on change l'état du relais via l'appui sur un bouton, ou directement sur l'actionneur lui-même, une GA sera émise avec l'état réel du relais, et la led changera d'état en fonction.

    Dernier exemple : le bouton a un objet "appui long off". Si on lie cet objet de communication à une GA "tout éteindre", dans laquelle on va également lier l'objet "activation sortie" de plusieurs actionneurs, il sera alors possible, par un simple appui long sur le bouton, d'éteindre toutes les lumières. Le bouton forçant cette fois la valeur off sur cette GA, les lumières déjà éteintes ne vont bien sûr pas se rallumer.

    Voili en gros comment ça marche. Il y a bien sûr des siouxeries, des choses plus complexes, mais le coeur du métier est là. J'ai juste omis de dire qu'il n'est possible de lier entre eux que des objets de communication de même type (bit, integer, float). Logique.

    Certains constructeurs proposent des participants très complexes, aux fonctionalités vraiment impressionantes, même pour simple bouton. Ceux-ci peuvent en effet avoir plusieurs touches, des leds, et même des capteurs de température, associé à une logique de type thermostat ! J'en ai chez moi, et c'est vraiment cool de pouvoir réguler le chauffage dans chaque pièce via le bouton. Ces boutons ont des objets de communication qui vont permettre de changer la consigne, et de piloter des participants de type relais. Il en existe même avec des petits affichages, eux aussi pilotables, toujours via le même principe d'association d'objets de communications via les GA.

    Au dessus de tout ça, on trouve aussi des supervisions. C'est là que ça devient intéressant ! Il existe tout un tas de choses, de modules hard+firmware à des choses purement logicielles. Et il existe des projets libres, comme les très connus eibd/linknx/knxweb. linknx s'appuie sur eibd, un démon qui dialogue directement sur le bus (via diverse types de passerelles). Il est développé en C++, et permet d'écrire des rules qui vont réagir suivant l'activité du bus. Dans linknx, on décrit toutes les GA. knxweb, lui, s'appuie sur linknx, et propose une visu web. Il est développé en php/javascript.

    L'équipe linknx/knxweb (francophone) a aussi proposé à la vente une box avec tout pré-installé (plus d'autres ervices, comme Asterisk). La box tourne sur une carte ALIX, sous voyage linux.

    Il existe également un gros framework java, Calimero, développé par des allemands. C'est surtout de ce projet que je m'inspire, car il est vraiment très puissant. Ils ont poussé très loin le niveau d'abstraction, pour essayer de coller à toutes les spécifications du bus. Et elles sont plutôt complexes ! Du coup, ça le rend assez lourd, pas forcément facile à utiliser.

    Voilà pour les généralités. Dans mon prochain post, je décrirai ce que je souhaite faire, et poserai des questions plus précises sur certains points. Si vous avez des questions sur ce bus, n'hésitez pas.

    Merci de m'avoir lu

  2. #2
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    Bon, il est temps de parler un peu python ! Je jette ici quelques idées, pas forcément très ordonnées...

    Contrairement au projet linknx, où la configuration se fait via un fichier xml, dans lequel on décrit l'installation (mapping des GA) et où l'on crée des rules (avec possiblité d'écrire des script en Lua), je voudrais utiliser le plus possible des scripts pythons.

    Les points clés de ce que je compte faire sont :

    - robustesse ;
    - légèreté (embarqué) ;
    - facililté de déploiement, configuration et maintenance ;
    - évolutivité ;
    - réutilisation ;
    - puissance.

    Je souhaite que les utilisateurs (qui seront de toute façon des passionnés, car le bus KNX lui-même n'est pas forcément à la portée de toutes les bourses, et demande quand même des compétences pour le déployer) profitent de la puissance du langage pour créer leur supervision. Tant qu'à faire à apprendre quelque chose, autant que ce soit quelque chose de ré-utilisable ! Mais il faut quand même proposer des outils pratiques, pour se concentrer sur la finalité (installation KNX), et non sur l'outil.

    Voici un exemple de ce que j'ai en tête pour la création d'une 'rule' :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    from pknyx import Rule, RuleManager, Scheduler
     
    scheduler = Scheduler()
     
    class SimpleRule(Rule):
     
        @scheduler.every(hours=2)
        def simpleEvent(self):
            ga = self.getGA("1/1/1")
            ga.write(1)
     
    myRule = SimpleRule()
    RuleManager().register(myRule)
    En tant que développeur python, c'est assez clair, mais je ne sais pas si c'est le mieux pour quelqu'un qui découvre le framework et le langage !

    Même si je n'ai encore jamais vraiment développé avec les décorateurs, je trouve leur utilisation assez pratique, rendant le code compact et lisible (à condition que ce soit bien foutu). Dans cet exemple, le scheduler est issu du package Advanced Python Scheduler que je compte l'utiliser dans mon projet.

    Déjà dans ce simple exemple, j'ai plusieurs points sur lesquels je voudrais votre avis (pour/contre, suggestions, amélioration, alternatives...) :

    - utilisation des décorateur ?
    - services globaux (managers, loggers...) : classes à instancier, instances des objets du framework, Borg/Singleton ?
    - utilisation des classes pour les scripts utilisateurs, ou simples fonctions ? Ou possibilité d'utiliser les 2 (encapsulation automatique des fonctions) ?
    - nom des modules (noms explicites et longs, ou compacts) ?

    Le framework proposera des outils de plus ou moins haut niveau : il sera possible d'utiliser directement les backends pour lire/écrire/monitorer le bus (niveau trame), ou des objets de plus haut niveau qui feront du décodage de valeurs ; il y aura des objets pour décrire/utiliser le mapping des GA, d'autres pour créer des rules, ou même des participants virtuels complets, avec un état et un comportement...

    J'aimerais aussi essayer de minimiser le nombre de concepts différents, et les réutiliser le plus possible pour construire les couches supérieures, comme le fait python. La logique doit être vite acquise, et les concepts doivent 'obliger' à une certaine rigueur dans la création de l'appli, pour que ça reste propre et lisible. J'imagine aussi que ça passe par une bonne documentation et des tutoriaux...

    Merci d'avance pour vos conseils éclairés sur ces quelques premiers points.

    PS : si vous avez des liens sur le concept de framework, avec des conseils pour en créer, je suis preneur...

  3. #3
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Hey,

    Tres interessant projet !
    Ma question ets de savoir comment tu te places par rapport au projet Domogik qui a pour but d'unifier les interfaces vers ces bus et qui a un morceau de support KNX, mais pas complet. Ne serait-il pas plus interessant de developper ce plugin ?
    Je suis un grand fan de KNX, mais un support KNX tout seul n'est pas suffisant si aucun outil de suivi et de programmation n'est disponible (un linknx ou domogik en fait)

  4. #4
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par Matthieu Brucher Voir le message
    Tres interessant projet !
    Merci

    Ma question est de savoir comment tu te places par rapport au projet Domogik qui a pour but d'unifier les interfaces vers ces bus et qui a un morceau de support KNX, mais pas complet. Ne serait-il pas plus interessant de developper ce plugin ?

    Je suis un grand fan de KNX, mais un support KNX tout seul n'est pas suffisant si aucun outil de suivi et de programmation n'est disponible (un linknx ou domogik en fait)
    Concernant Domogik, sa faiblesse est justement de vouloir tout unifier. Du coup, ce n'est pas optimisé pour KNX, et le plugin doit faire des pirouettes pour s'adapter.

    Ce que je souhaite faire se rapproche plus de linknx, en fait, car il sera possible, en plus des rules, de créer des participants virtuels complets. À travers ces participants, il sera possible d'étendre encore plus les fonctionalités de l'installation. En créant par exemple une station météo basée soit sur des infos provenant du web, soit venant de capteurs réels. Ou d'un mix des 2 (genre pour avoir les tendances sur la semaine).

    Il y aura bien sûr tous les services classiques : persistence, logging, etc...

    Le framework permettra donc de créer une appli complète qui tournera en tant que démon, comme linknx. Après, pour la partie graphique, ça se fera comme pour knxweb : en s'appuyant sur l'appli. J'ai dans l'idée de faire un mode compatible linknx, histoire de pouvoir utiliser knxweb dans un premier temps. J'ai aussi des idées pour une alternative à knxweb, mais bon, le web et moi, ça fait 2 !

    Comme dit, le but est de faire quelque chose de simple, robuste et facilement déployable. Je vois trop de gens se faire chier à cross-compiler linknx sur des plateformes type NAS. Rares sont les plateformes où python ne tourne pas en standard, maintenant. Je vise principalement OpenWRT sur une carte ALIX. Avec dans l'idée d'écrire des modules LUCI pour la config via le web.

    Voili-voilou. Tout n'est pas encore clair dans ma tête, c'est pour ça que je lance cette discussion. Même si ça part dans tous les sens au début, ça permettra d'alimenter le moulin ; je ferai le tri plus tard. Mais c'est clair que l'utilisation finale va conditionner la façon de bâtir le framework.

  5. #5
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Ah cool ! Clair que la compilation de eib + linknx est un gros frein. Si tu arrives a ameliorer la situation et a ne pas faire un monstre (Domogik est lent il parait), ca sera genial.

  6. #6
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    Le but est clairement d'avoir quelque chose de léger, et facile à prendre en main, même pour des non développeurs. Je pense que le challenge est là. C'est pour ça que j'ai besoin de vos lumières.

    Concernant l'exemple que j'ai donné, voici 3 versions :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    from pknyx import GroupAddressManager, Rule, RuleManager, Scheduler
     
    # Création d'une instance du scheduler (problement un Borg ou un truc du genre)
    scheduler = Scheduler()
     
    # Création d'une classe rule
    class SimpleRule(Rule):
     
        # Création d'une méthode qui sera appelée toutes les 2 heures
        @scheduler.every(hours=2)
        def simpleEvent(self):
            ga = GroupAddressManager().find("1/1/1")
            ga.write(1)
     
    # Instanciation de la rule
    myRule = SimpleRule()
     
    # Enregistrement de la rule
    RuleManager().register(myRule)
    ou

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    from pknyx.services import group, schedule, log, manager
    from pknyx.elements import Rule
     
    # Création d'une classe rule
    class HeatingRules(Rule):
     
        # Création d'une méthode qui sera appelée toutes les 2 heures
        @schedule.every(hours=2)
        def bathroom(self):
            group.write("1/1/1", 0)
     
    # Enregistrement de la rule (c'est le manager qui crée l'instance)
    manager.registerRule(HeatingRules)
    ou

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    from pknyx.rule import Rule
     
    # Création d'une classe rule
    class Heating(Rule):
     
        # Création d'une méthode qui sera appelée toutes les 2 heures (pas de décorateur)
        def bathroom(self, every="2h"):
            ga = self.findGA("1/1/1")
            ga.write(0)
     
    # Erengistrement de la rule (c'est elle qui s'auto-enregistre)
    Heating()
    Qu'est-ce qui est bien/pas bien dans ces versions ? On peut bien sûr mixer les diverses propositions. J'hésite à tout cacher, comme dans la dernière solution, car l'utilisateur n'apprendra pas grand chose sur python. D'une autre côté, devoir tout faire comme dans la première solution est lourdingue si on a une grosse installation...

    Il est peut-être également possible de ne définir que des fonctions (avec leur décorateur) ; c'est le manager de rules qui créera une instance de Rule, en bindant la fonction en tant que méthode... L'intérêt d'écrire une classe est que ça permet d'avoir une persistence entre 2 appels si besoins. Mais si on veut faire un truc simple, c'est lourd. Est-ce une bonne idée d'avoir les 2 formules ?

    Quid également des import ? Généralement, je ne fais que des imports de classes, quitte à avoir des Borg. Mais c'est une question d'habitude, et je ne sais pas ce qui est le mieux (plus facile à maintenir, faire évoluer...). L'import d'instance, ou l'utilisation de simples fonctions dans les modules est sans doute aussi très bien, mais il y a certainement des cas plus adaptés pour l'un ou pour l'autre...

    Encore une fois, je cherche à ce que les utilisateurs apprennent à se servir du langage python, mais de manière assez transparente, plus par l'exemple que de façon académique. Leur but sera clairement de faire marcher une installation KNX. Mais je ne veux pas non plus que ce ne soit utilisé que par des développeurs python, parce que les autres auront été rebutés...

  7. #7
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Je trouve la derniere plus pythonesque que les 2 premieres. Mais bon, je ne sais pas comment les choses sont faites derrieres et si le fait d'avoir un self.find est logique ou pas.

    A terme, le site wen devrait permettre de faire la config, 99% des utilisateurs ne voudront pas faire de Python, mais c'est grace a eux que les 1% qui t'interessent viendront.

    Si tu veux que ca marche, il faut aussi releaser souvent et avec une licence qui va bien, avoir un repository sur github...

  8. #8
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par Matthieu Brucher Voir le message
    Je trouve la derniere plus pythonesque que les 2 premieres. Mais bon, je ne sais pas comment les choses sont faites derrieres et si le fait d'avoir un self.find est logique ou pas.
    Ben, moyennement logique, justement. C'est plus pour faire un raccourci d'écriture, mais d'un point de vue architecture, le findGA() a plus sa place dans le manager de GA (comme dans la second solution). Après, ça peut aussi être :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    self.GAManager.find()...
    Le self.GAmanager étant un lien vers le Borg GroupAddressManager. Ça éviterait un tas d'imports, non ? Qu'en penses-tu ?

    A terme, le site web devrait permettre de faire la config, 99% des utilisateurs ne voudront pas faire de Python, mais c'est grace a eux que les 1% qui t'interessent viendront.
    Ben, en fait, j'hésite à faire une config super sioux via le web. Car si on veux présenter ça de façon sympa, dans un tableau, il faut que derrière la config soit sauvée dans un fichier xml, ini ou équivalent ; ça ne peut plus être un script python (il faudrait générer du python depuis l'interface web, ce qui est un peu con)... Par contre, un simple éditeur de code embarqué dans le navigateur, ça peut le faire. Alors OK, faut pas cliquer comme un sauvage... Mais bon, une installation KNX n'est pas non plus à mettre entre les mains des bricoleurs du dimanche qui cliquent à tout va

    Si tu veux que ca marche, il faut aussi releaser souvent et avec une licence qui va bien, avoir un repository sur github...
    Yep, c'est prévu, dès que j'ai un truc un peu fonctionnel. Pour l'instant, j'ai toute la partie des DatapointType d'écrite, qui permet de gérer une grosse partie des DPT de la norme Il me manque la partie mapping des GA et dispatching des trames du bus pour faire une petite démo qui affichera ce qui transite sur le bus. Dans un premier temps, je vais utiliser eibd ou eibnetmux pour la partie backend.

  9. #9
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Faudra attendre que j'ai du matos de test pour tester ton truc, j'espere que ca va marcher !

    Si tes gestionnaires sont des singletons, il faudra passer par les imports, je le crains, sauf si tu mets des fonctions d'acces un peu plus haut niveau.

    Le pb de eidb, c'est qu'il faut aussi le compiler

  10. #10
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    Pourquoi faut-il passer par les imports ? Ils peuvent être faits dans le module qui décrit la classe Rule, non ?

    En fait, je n'utilise même plus de Borg ; je fais ça au niveau du module :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    logger = None
     
    class LoggerObject(object):
        """ Logger object.
        """
        ...
     
    # Logger factory
    def Logger(defaultStreamHandler=True, defaultFileHandler=True):
        global logger
        if logger is None:
            logger = LoggerObject(defaultStreamHandler, defaultFileHandler)
     
        return logger
    Et pour utiliser, je fais :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    from logger import Logger
     
    Logger().debug(...)

  11. #11
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Citation Envoyé par fma38 Voir le message
    Pourquoi faut-il passer par les imports ? Ils peuvent être faits dans le module qui décrit la classe Rule, non ?
    Oui, c'est ce que je pensais (je crois). Je passe trop de temps en Angleterre, c'est pour ca...

  12. #12
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut

  13. #13
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    Bonjour,

    Juste un petit mot pour vous dire que j'ai créé un site pour mon projet, qui se nomme donc pKNyX.

    Le projet avance tout doucement, mais il n'y a encore rien d'utilisable ; je n'arrête pas de tout casser pour essayer de trouver une architecture qui colle le plus possible à la spécification. Même si je ne compte pas tout implémenter, loin de là !, autant être le plus propre et ouvert possible, si un jour quelqu'un veut étendre les fonctionalités.

    À noter également que le vecteur de discussion pour ce projet ce fera principalement sur le forum¹ knx-fr.com et knx-en.com ; on vient en effet de créer une section anglaise, pour essayer de fédérer les non francophone et non germanophones ; il s'avère qu'il n'y avait pas vraiment de forum en anglais sur le KNX ! C'est chose faite

    ¹ les 2 adresses knx-fr.com et knx-en.com tombent sur le même forum, où il y a une section pour chaque langue.

  14. #14
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Donc tu es passé en licence GPL (pas top pour du Python et un projet qui sert de base à d'autres choses :/) avec SVN ?
    Tu en es où en find e compte ? Tu te bases toujours encore sur eibd ?

  15. #15
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    Pourquoi pas top pour du python, la GPL ? Comme je m'inspire beaucoup d'autres projets libres (voir portage complet de classes), je n'ai pas trop le choix.

    Oui, pour l'instant, j'ai besoin d'eibd (avec l'option --Router) ; ou alors d'un module routeur IP (dans ce cas, pas besoin d'eibd).

  16. #16
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Le problème est que les briques qui se baseront sur toi seront obligatoirement en GPL, ce qui limite fortement les possibilités
    Une BSD ou licence Python serait bien plus pertinent.

  17. #17
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    D'ailleurs, vu la licence de APScheduler et celle de PySerial, tu peux être en BSD ou en Python license.
    Sinon, si tu as d'autres codes dans ton module, ce n'est pas marqué sur ton site web, ce qui est limite :/ Il te faut normalement reprendre les licences de ces bouts dans ton code et demander à l'auteur si c'est OK de les mettre dans la licence que tu as choisie si la licence originale n'est pas la même.

  18. #18
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    J'ai déjà contacté les auteurs. Comme le code est en gros mouvement, pour l'instant, je n'ai pas encore pris le temps de le faire, mais il y a déjà quelques fichiers avec le copyright original.

  19. #19
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Dans ce cas, il y a fort à parier que tu ne puisses pas mettre le module en GPL. Il te faut l'autorisation de chaque contributeur de passer le code en GPL (pas copyright, comme ces licences sont justement copyleft).

  20. #20
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 117
    Points : 33
    Points
    33
    Par défaut
    Euh, pas sûr de comprendre... Tu peux avoir un code ne GPL, et mettre un copyright <ton nom>, non ?

    En tout cas, la plupart des codes sont comme ça...

Discussions similaires

  1. Framework pour applications web
    Par amin1425 dans le forum ASP.NET
    Réponses: 3
    Dernier message: 07/02/2007, 12h55
  2. Quel framework pour une application !
    Par Seth77 dans le forum Framework .NET
    Réponses: 8
    Dernier message: 26/01/2007, 11h32
  3. Création d'un Framework pour les jeux
    Par alex6891 dans le forum UML
    Réponses: 2
    Dernier message: 04/05/2006, 15h27
  4. [Frameworks] pour Gestion des utilisateurs...
    Par blackhorus dans le forum Bibliothèques et frameworks
    Réponses: 2
    Dernier message: 04/04/2006, 06h25
  5. [1.x] [Librairies] recherche d'un framework pour debuter
    Par amin1425 dans le forum Symfony
    Réponses: 8
    Dernier message: 06/12/2005, 15h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo