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 :langue2:

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:

---

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...

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)

Citation:

---

Envoyé par Matthieu Brucher

Tres interessant projet !

---

Merci :)

Citation:

---

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.

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.

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:

---

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:

---

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:

---

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...

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...

Citation:

---

Envoyé par Matthieu Brucher

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:

---

self.GAManager.find()...

---

Le self.GAmanager étant un lien vers le Borg GroupAddressManager. Ça éviterait un tas d'imports, non ? Qu'en penses-tu ?

Citation:

---

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 ;)

Citation:

---

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.

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 :(

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:

---

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:

---

1 2 3

from logger import Logger   Logger().debug(...)

---

Citation:

---

Envoyé par fma38

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...

:D

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.

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 ?

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).

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.

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.

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.

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).

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...

Pas sûr que ce soit normal. Quand tu publies ton code sous une licence libre, tu t'entends à ce que ton code soit modifié par d'autres, donc il n'y a plus de copyright.

Je pense que si : il faut bien savoir à qui appartient le fichier. Le fait que tu le publies sous une licence libre ne veut pas dire que tu n'as pas de droits dessus, bien au contraire...

Je vais quand même me renseigner.

Le fichier n'appartient à personne, c'est du code qui peut être modifié, intégré, découpé... Qui a écrit quoi est géré par le gestionnaire de version. Dans les grands projets, il n'y a pas de copyright dans un fichier. Tout est géré par la licence et par le gestionnaire de version si on doit changer la licence.
Si tu modifies la GPL pour inclure le copyright, il semble que les deux soient possibles, mais je ne le recommande pas parce que ça pose des problèmes de compatibilité avec d'autres licences (http://en.wikipedia.org/wiki/Open-source_license). Les compatibilités sont déjà assez complexes sans les restrictions pour un copyright qui est généralement inutile (je pense que parfois des entreprises ou des universités veulent garder cette mention, mais le commun des mortels ne devrait surtout pas le faire AMHA).

Le code appartient quand même à quelqu'un (1 ou plusieurs personnes, effectivement) ; c'est ce quelqu'un qui a le droit de regard sur ce code, en particulier sur un changement de licence éventuel.

Après, la compatibilité entre licences est régit par les licences en question.

Je pense que l'ajout des auteurs qui ont contribué au code dans le header, sous forme de (C) <moi> est pratique justement pour retrouver les auteurs, et les contacter si justement on veut changer la licence... C'est un copyright sur l'attribution de la licence au code. C'est comme ça que je le comprend.

Dans le cas de grands projets, je pense que les développeurs adhèrent globalement à une politique de licence qui régie l'ensemble du projet. Me goure-je ? Pour une boîte privée, le problème ne se pose pas, puisque le code appartient à la boîte. Même si le code est sous licence libre, non ?

Comme le lien que j'ai donné l'indique, si tu veux des informations de copyright, il faut modifier la licence !
Si tu veux faire passer du code d'une licence permissive à une licence restrictive (style GPL à BSD), tu dois demander l'accord de tous les contributeurs. Mais c'est facile, tu as cette information sur le repository. Parce que quelque chose marqué dans un fichier est sujet à caution : est-ce que tout le monde a modifié le fichier ? Est-ce que tout le monde a encore du code dans le fichier ? Toutes ces informations sont trackées correctement par un gestionnaire de version. Donc pas de texte à ajouter dans un fichier, et surtout pas un texte de copyright puisque ça nécessite une modification de la licence.

Bon, renseignements pris, je confirme que le copyright est nécessaire. En fait, les licences libres sont elles-même basées sur le copyright ; c'est le fondement qui leur permet d'exister. Le code que tu écris t'appartient : c'est le copyright qui te permet d'en être assuré.

Après, tu peux justement choisir la licence de diffusion de ton code. Ce n'est pas parce que tu utilise une licence libre que tu renonces aux droits sur ce code, bien au contraire ! C'est grâce à ça que la licence va s'appliquer et sera respectée. La GPL va t'assurer que ton code sera diffusé sous cette même licence.

Et comme tu le dis, si changement de licence il y a, ce sera avec ton accord, justement grâce au fait que le code est copyrighté, et t'appartient.

Sans copyright, c'est le domaine publique, qui n'impose/ne garantit plus rien.

Pour en revenir à la licence utilisée, laquelle préconiserais-tu, du coup, pour un tel ? LGPL ?

Bonjour à tous,

J'arrive un peu à la bourre (mieux vaut tard que jamais :mrgreen:), mais étant ancien ingénieur domotique, la technologie KNX a attirée mon attention, dans ton post fma38.

Je te conseillerais bien de prendre contact avec Patrice BARBEL de l'université de Rennes 1 (mail Ici), qui dirige le seul Master 2 Domotique de France (j'y suis passé personnellement).

Il aura peut etre des opportunités et/ou des collaborations qui pourrait t'intéresser, et pourquoi pas un projet partenaire avec des étudiants, qui disposeraient d'un certains nombre de matériels pour tests. :ccool:

Ah, ben merci pour cette info. Je vais essayer de le contacter...

Il est sans doute un peu tôt pour un projet partenaire avec des étudiants, mais je retiens l'idée.

Citation:

---

Envoyé par fma38

Bon, renseignements pris, je confirme que le copyright est nécessaire. En fait, les licences libres sont elles-même basées sur le copyright ; c'est le fondement qui leur permet d'exister. Le code que tu écris t'appartient : c'est le copyright qui te permet d'en être assuré.

Après, tu peux justement choisir la licence de diffusion de ton code. Ce n'est pas parce que tu utilise une licence libre que tu renonces aux droits sur ce code, bien au contraire ! C'est grâce à ça que la licence va s'appliquer et sera respectée. La GPL va t'assurer que ton code sera diffusé sous cette même licence.

Et comme tu le dis, si changement de licence il y a, ce sera avec ton accord, justement grâce au fait que le code est copyrighté, et t'appartient.

Sans copyright, c'est le domaine publique, qui n'impose/ne garantit plus rien.

Pour en revenir à la licence utilisée, laquelle préconiserais-tu, du coup, pour un tel ? LGPL ?

---

J'aimerai bien avoir tes sources car la majorité des projets OS que je connais n'ont pas de référence de copyright et pourtant on sait qui a écrit quoi et sous quelle licence... (et aussi comment tu comptes vérifier que ceux qui sont marqués dans l'en-tête d'un fichier sont bien les bons auteurs du fichier).

Sinon, oui, LGPL, c'est bien, Python licence ou BSD est plus ouvert.

Cf : http://www.gnu.org/licenses/gpl-faq.html#IWantCredit

Citation:

---

[...]La distribution d'un programme sous GPL doit aussi se traduire par la mention d'un copyright à votre propre nom (à supposer que vous déteniez ce copyright). La GPL requiert que chaque copie porte un avis de copyright approprié.

---

Pas dans chaque fichier, c'est lors de l'exécution de l'appli (classiquement dans un menu à propos), c'est complètement différent ;)
De plus, ton framework comporte des applis exemples, mais sera plus une bibliothèque utilitaire et dans ce cas, c'est à l'appli qui appelle ton framework de faire ces références si besoin.

Tu as raison, ce que j'ai cité fait référence au programme dans son ensemble.

Mais bon, il n'y a aucune contre-indication à mettre un copyright dans le code, bien au contraire. De toute façon, c'est bien la base de toute licence...

Cf la page sur l'explication des licences, tu ne mets pas de copyright dans le code ou dans la licence sauf à changer la licence (et donc potentiellement rencontrer des problèmes de compatibilité)
L'attribution du code est fait le gestionnaire de version, ne t'embête surtout pas à faire plus car ton copyright ne sera en fait jamais à jour. Et c'est l'attribution du code qui est importante.

Je ne vois vraiment pas où il est noté que le fait de mettre le copyright dans le code oblige à changer de licence !

Bien au contraire :

http://www.gnu.org/licenses/gpl-howto.html

Citation:

---

Quel que soit votre choix, la procédure comprend l'addition de deux éléments dans chaque fichier source : un avis de copyright (tel que « Copyright 1999 Marie Dupont ») et une déclaration de la permission de copier (avis de licence) précisant que le programme est distribué sous les termes de la licence publique générale GNU (ou de la GPL amoindrie).

---

hello
tu en es ou avec ton projet ?

Arnaud

Hello,

Je n'ai pas beaucoup bossé sur le projet dernièrement, mais bon, il est tout à fait fonctionnel. Après réflexion, je ne pense pas implémenter beaucoup d'autres choses (comme faire un serveur d'objet genre linknx ou smarthome ; ça ne sert à rien de refaire un truc similaire en moins bien), mais plutôt me concentrer sur des choses qui ne sont pas faites ailleurs.

Sa fonction de base est de créer des devices virtuels. Par exemple, je vais très rapidement implémenter une passerelle KNX vers les nouvelles régules Helios, EasyControl, qui font du modubus TCP/IP. Ça devrait se faire en un rien de temps. Et ça va me permettre d'étendre un peu les fonctionalités de la VMC, en ajoutant des règle de régulation plus fines.

Après, un autre truc que je voudrais faire, c'est supporter le module KNX BAOS 820 (http://www.weinzierl.de/index.php/en...-module-820-en). Là, c'est du boulot au niveau de la pile, et j'avoue ne pas encore tout maîtriser !

Enfin, j'ai aussi comme objectif de porter pKNyX sur micropython (http://www.micropython.org), en conjonction avec le module BAOS, ou directement sur IP (en utilisant une carte comme la Netduino+ 2).

Bref, plein de choses sympas en vue, mais pas beaucoup de temps pour les faire !