Bon, quelques news, et, surtout, quelques questions/reflexions, pour lesquelles j'aimerais avoir votre avis (même si vous n'êtes pas développeur ; l'avis de futurs utilisateurs potentiels est tout aussi important), avant de trop coder de choses qui ne seront pas adaptées.
Déjà, comme vous pouvez le voir, j'ai renommé le fil en "Framework KNX en python", car pour l'instant, ce que je fais n'a rien à voir avec une stack KNX, et ce sera sans doute un des derniers points que j'aborderai. Ce qui m'intéresse, dans un premier temps, c'est de pouvoir faire ce que fait linknx. Mais en poussant le concept un peu plus loin...
Ce qui suit est issu de mes reflexions, et n'est pas forcément encore très bien structuré, faute de bien maîtriser les dessous du bus KNX. J'ai lu pas mal de papiers, épluché pas mal de codes sources, et j'avoue que les concepts ne sont pas si évidents que ça à digérer. En plus, tout le monde n'utilise pas le même vocabulaire, ce qui n'arrange pas les choses ! Comme dit plus haut, ma principale source d'inspiration est le framework java Calimero, qui est pas mal foutu. Ils ont poussé assez loin le niveau d'abstraction, ce qui leur permet de s'adapter à beaucoup de cas de figures. Par exemple, ils peuvent gérer plusieurs types de media (TP0, TP1, RF...), utiliser le concept de 'Properties' (concept que je n'ai pas encore bien pigé), de commandes, etc... Cela conduit à pas mal de classes qui s'articulent les unes avec les autres. Comme il n'y a pas beaucoup d'exemples, ce n'est pas évident de bien comprendre les tenants et les aboutissants. Pour quelqu'un qui maîtrise l'architecture du bus KNX sur le bout des doigts, ça doit couler de source ; mais ce n'est pas mon cas ! J'ai donc décidé d'adapter tout ça à mes besoins, avec ce que je comprend du KNX à l'instant t ; il sera toujours temps de ré-organiser le code pour répondre à plus de choses lorsque le besoin s'en fera sentir.
Voici donc ce que j'imagine...
0) Interaction directe avec le bus
L'idée est de pouvoir lire/écrire directement une valeur d'une GA. Comme la couche bas niveau sera dans un premier temps basée sur eibd ou eibnetmux, c'est par ces outils que ça se fera, avec juste une API python par dessus.
1) Supervision simple
Ici, on a une simple image de l'architecture des GA définie dans ETS, et on surveille l'état de ces GA. Pour ça, on a un process à l'écoute du bus, qui va dispatcher les trames aux différents objets qui représentent les GA au niveau du soft. On peut logger ces changements dans un fichier, une base de données ou tout autre mécanisme. Si on veut changer des GA, c'est via les outils 0).
2) Supervision avancée
En plus de la supervision simple, qui ne fait que refléter l'état des GA de l'installation, on pourra créer des rules pour réagir aux changements qui surviennent sur le bus, ou même déclencher des actions en fonction d'autres évènements (temporels, externes...). C'est en gros ce que fait linknx. Il est possible de créer des GA supplémentaires (purement virtuelles ou qui émettront sur le bus), qui permettront aux rules de communiquer entre elles et/ou avec le bus.
3) Participants virtuels
Là, on va pouvoir aller plus loin, en créant des participants purement virtuels (ou pas !), qui fonctionneront comme de vrais participants : ils auront un état et un comportement propres, et on les 'programmera' comme on le fait avec ETS, c'est à dire en liant leurs objets de communication (Datapoint, si j'ai bien compris l'utilisation de ce terme) aux GA. Il sera par exemple possible de créer une passerelle complète vers un appareil externe qui dialogue en RS232 (genre video-projecteur). Ou de créer une station météo virtuelle, station qui récupérera ses infos sur un site météo. Ou encore de créer une horloge hebdomadaire pour la gestion du chauffage (soit par changement de consigne, soit par activation d'un mode du fil pilote ,etc...).
Je voudrais que tout ceci puisse se construire brique par brique. C'est pour ça que je parle de framework. L'utilisateur aura à sa disposition plein de choses, de plus ou moins haut niveau, qu'il pourra utiliser selon ses besoins. Voir mixer pour affiner des choses. L'idée est quand même que ce que l'utilisateur fera soit robuste, facile à faire, facile à maintenir, évolutif, et puissant.
Déjà, il écrira du python ! Je ne vois pas l'intérêt d'utiliser autre chose (genre Lua), alors que python est déjà un langage de script. Le but du framework sera de rendre la programmation simple pour ceux qui ne veulent pas se casser la tête, tout en laissant la possibilité d'aller très loin pour ceux qui maîtrisent. Voici un simple exemple de ce que j'ai en tête :
On crée une classe SimpleRule qui dérive de Rule (cette dernière faisant partie du framework, et encapsule tout un tas de fonctionalités). Cette classe a juste une fonction simpleEvent() qui sera exécutée toutes les 2 heures (via le décorateur @scheduler.every(hours=2) ). Lorsque la fonction s'exécute, elle récupère la GA 1/1/1, et écrit la valeur 1 dessus. Les 2 dernère lignes créent la rule et l'enregistrent dans le gestionnaire. Il y aura des outils permettant de voir les rules créer, d'en ajouter/supprimer dynamiquement, ou de les activer/désactiver. À voir selon les besoins. Il sera également possible de retrouver la GA par son Id, si une table GA/Id a bien été créée (pas obligatoire, mais fortement recommandé).
La syntaxe exacte est bien sûr encore à définir, mais l'idée est là. Est-ce que ça parle aux non développeurs python ?
Après, il y a plein de questions : faut-il faire un seul gros process ? Découper en plusieurs process (1 par rule/participant) ? Dans ce dernier cas, comme dialoguer entre process ? Comment gérer les ajouts/modifications ? Faire un mécanisme qui recharge la config, ou tout relancer ? Je suis ouvert à toute suggestion.
Concernant le vocabulaire, je voudrais rester très proche de ce que définie le standard KNX, plutôt que d'inventer de nouveaux termes, car il devient ensuite difficile de se faire comprendre (utilisateurs/développeurs non francophones).
N'hésitez donc pas à proposer des choses, même si ça n'a pas de lien direct avec python ; pour le moment, c'est surtout à l'architecture que je cogite...
Merci d'avance.
Une autre source d'inspiration est la Logic Machine 2, que je trouve aussi vraiment sympa :
http://openrb.com/wp-content/uploads/201...l_v3.0.pdf
Déjà, comme vous pouvez le voir, j'ai renommé le fil en "Framework KNX en python", car pour l'instant, ce que je fais n'a rien à voir avec une stack KNX, et ce sera sans doute un des derniers points que j'aborderai. Ce qui m'intéresse, dans un premier temps, c'est de pouvoir faire ce que fait linknx. Mais en poussant le concept un peu plus loin...
Ce qui suit est issu de mes reflexions, et n'est pas forcément encore très bien structuré, faute de bien maîtriser les dessous du bus KNX. J'ai lu pas mal de papiers, épluché pas mal de codes sources, et j'avoue que les concepts ne sont pas si évidents que ça à digérer. En plus, tout le monde n'utilise pas le même vocabulaire, ce qui n'arrange pas les choses ! Comme dit plus haut, ma principale source d'inspiration est le framework java Calimero, qui est pas mal foutu. Ils ont poussé assez loin le niveau d'abstraction, ce qui leur permet de s'adapter à beaucoup de cas de figures. Par exemple, ils peuvent gérer plusieurs types de media (TP0, TP1, RF...), utiliser le concept de 'Properties' (concept que je n'ai pas encore bien pigé), de commandes, etc... Cela conduit à pas mal de classes qui s'articulent les unes avec les autres. Comme il n'y a pas beaucoup d'exemples, ce n'est pas évident de bien comprendre les tenants et les aboutissants. Pour quelqu'un qui maîtrise l'architecture du bus KNX sur le bout des doigts, ça doit couler de source ; mais ce n'est pas mon cas ! J'ai donc décidé d'adapter tout ça à mes besoins, avec ce que je comprend du KNX à l'instant t ; il sera toujours temps de ré-organiser le code pour répondre à plus de choses lorsque le besoin s'en fera sentir.
Voici donc ce que j'imagine...
0) Interaction directe avec le bus
L'idée est de pouvoir lire/écrire directement une valeur d'une GA. Comme la couche bas niveau sera dans un premier temps basée sur eibd ou eibnetmux, c'est par ces outils que ça se fera, avec juste une API python par dessus.
1) Supervision simple
Ici, on a une simple image de l'architecture des GA définie dans ETS, et on surveille l'état de ces GA. Pour ça, on a un process à l'écoute du bus, qui va dispatcher les trames aux différents objets qui représentent les GA au niveau du soft. On peut logger ces changements dans un fichier, une base de données ou tout autre mécanisme. Si on veut changer des GA, c'est via les outils 0).
2) Supervision avancée
En plus de la supervision simple, qui ne fait que refléter l'état des GA de l'installation, on pourra créer des rules pour réagir aux changements qui surviennent sur le bus, ou même déclencher des actions en fonction d'autres évènements (temporels, externes...). C'est en gros ce que fait linknx. Il est possible de créer des GA supplémentaires (purement virtuelles ou qui émettront sur le bus), qui permettront aux rules de communiquer entre elles et/ou avec le bus.
3) Participants virtuels
Là, on va pouvoir aller plus loin, en créant des participants purement virtuels (ou pas !), qui fonctionneront comme de vrais participants : ils auront un état et un comportement propres, et on les 'programmera' comme on le fait avec ETS, c'est à dire en liant leurs objets de communication (Datapoint, si j'ai bien compris l'utilisation de ce terme) aux GA. Il sera par exemple possible de créer une passerelle complète vers un appareil externe qui dialogue en RS232 (genre video-projecteur). Ou de créer une station météo virtuelle, station qui récupérera ses infos sur un site météo. Ou encore de créer une horloge hebdomadaire pour la gestion du chauffage (soit par changement de consigne, soit par activation d'un mode du fil pilote ,etc...).
Je voudrais que tout ceci puisse se construire brique par brique. C'est pour ça que je parle de framework. L'utilisateur aura à sa disposition plein de choses, de plus ou moins haut niveau, qu'il pourra utiliser selon ses besoins. Voir mixer pour affiner des choses. L'idée est quand même que ce que l'utilisateur fera soit robuste, facile à faire, facile à maintenir, évolutif, et puissant.
Déjà, il écrira du python ! Je ne vois pas l'intérêt d'utiliser autre chose (genre Lua), alors que python est déjà un langage de script. Le but du framework sera de rendre la programmation simple pour ceux qui ne veulent pas se casser la tête, tout en laissant la possibilité d'aller très loin pour ceux qui maîtrisent. Voici un simple exemple de ce que j'ai en tête :
Code :
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)On crée une classe SimpleRule qui dérive de Rule (cette dernière faisant partie du framework, et encapsule tout un tas de fonctionalités). Cette classe a juste une fonction simpleEvent() qui sera exécutée toutes les 2 heures (via le décorateur @scheduler.every(hours=2) ). Lorsque la fonction s'exécute, elle récupère la GA 1/1/1, et écrit la valeur 1 dessus. Les 2 dernère lignes créent la rule et l'enregistrent dans le gestionnaire. Il y aura des outils permettant de voir les rules créer, d'en ajouter/supprimer dynamiquement, ou de les activer/désactiver. À voir selon les besoins. Il sera également possible de retrouver la GA par son Id, si une table GA/Id a bien été créée (pas obligatoire, mais fortement recommandé).
La syntaxe exacte est bien sûr encore à définir, mais l'idée est là. Est-ce que ça parle aux non développeurs python ?
Après, il y a plein de questions : faut-il faire un seul gros process ? Découper en plusieurs process (1 par rule/participant) ? Dans ce dernier cas, comme dialoguer entre process ? Comment gérer les ajouts/modifications ? Faire un mécanisme qui recharge la config, ou tout relancer ? Je suis ouvert à toute suggestion.
Concernant le vocabulaire, je voudrais rester très proche de ce que définie le standard KNX, plutôt que d'inventer de nouveaux termes, car il devient ensuite difficile de se faire comprendre (utilisateurs/développeurs non francophones).
N'hésitez donc pas à proposer des choses, même si ça n'a pas de lien direct avec python ; pour le moment, c'est surtout à l'architecture que je cogite...
Merci d'avance.
Une autre source d'inspiration est la Logic Machine 2, que je trouve aussi vraiment sympa :
http://openrb.com/wp-content/uploads/201...l_v3.0.pdf