Forum KNX francophone / English KNX forum

Pages : 1 2

Bonjour,

Voilà un moment que ça me démange d'écrire une stack KNX complète en python, pour avoir quelque chose de facilement portable, qui ne nécessite aucune cross-compilation (autre que l'interpréteur, qui est maintenant dispo sur la quasi totalité des distributions embarquées).

Le hic, c'est que j'avoue ne pas savoir trop par où commencer ! L'idée à terme est vraiment de ne dépendre d'aucune autre librairie/logiciel ; cela implique donc de savoir dialoguer directement avec une interface IP, série ou usb.

Mais je pense aussi qu'il serait bon de faire ça par étapes. Voici à quoi je songe :

1) utiliser eibd pour la partie bas niveau, et écrire un linknx-like (et light), qui permettrait de faire quelques trucs de base, en particulier des rules asynchrones (directement écrites en python). Pour ça, il 'suffirait' d'utiliser l'API python de eibd. Que je ne connais pas (encore).

2) ré-écrire eibd en python. Là, ça se corse ! D'après ce que j'ai vu, eibd est bien découpé pour implémenter chaque layer. Tout en bas, on trouve les couches matériels (série, usb, IP). Il est alors possible de faire aussi par étapes :

2.1) implémenter le protocole KNX/IP (routing, tunneling, NAT...)

2.2) implémenter le protocole série FT1.2 (+ PEI16 ?)

2.2) implémenter le protocole usb

Bon, pour l'instant, j'ai récupéré divers sources (eibd, linknx, calimero, smarthome.py...), mais se plonger là dedans, à froid, c'est coton !

Déjà, dans un premier temps, je voudrais essayer de bien comprendre les divers niveaux/couches d'eibd, qui me semble quand même bien foutu, et voir comment l'utiliser, pour létape 1). Pour entrer dans le concrêt, quelles sont les fonctions importantes de l'API qu'il faut bien piger pour communiquer sur le bus (émettre et recevoir des GA) ?

Je suis donc preneur de toute info/conseil/tuto.

Merci d'avance.

Bonne idée!

J'aurais tendance à oublier les acrobaties (un peu académiques) de EIBD et à me focaliser sur l'interfaçage direct d'un routeur, c-a-d être capable de traiter et envoyer des trames sur une adresse IP multicast. Pas de connexion, pas de ack, pas de protocole série alambiqué, ...

L'avantage c'est qu'on peut avoir autant de clients que l'on veut, qu'on a pas besoin de EIBD et autres "vieilleries" en serie/usb, qu'on est "compatible" KNX/IP, et que c'est super simple.

L'inconvénient c'est qu'il faut un routeur et que c'est un peu cher, ou alors l'implémenter via EIBD (mais le code python est toujours super simple)

Ensuite, ben en gros il y a 2 trames cEMI à recevoir/envoyer (read group et write group) + écrire les routines de transformation des formats EIS en format Python (pour température, etc).
A noter que notre appareil devra être configuré hors ETS, car avec la gestion ci-dessus il ne connait pas les trames physique de configuration et on a pas de "driver" dans ETS. Il serait par contre conseillé d'utiliser des devices "dummy" dans ETS pour signaler les groupes gérés par notre appareil.

Il est également possible d'imaginer une couche qui pourrait se nourrir d'un export de ETS (à la place de devoir se re-raper toutes les GA à la main) -- mais c'est clairement d'un niveau plus "élevé" que la gestion simple "read/write" imaginée ci-dessus (i.e. un autre module/couche).

Fred

Tiens, je viens de tomber là dessus :

http://nullege.com/codes/show/src@o@p@op...Gate@trunk
http://openautomation.svn.sourceforge.ne...PyWireGate

Très intéressant, ce projet !!! Dommage que ce soit planqué au fin fond d'un forum, uniquement en allemand Wink

Tiens, par exemple, il utilise ce package :

http://pythonhosted.org/APScheduler/index.html

Je ne connaissais pas, et c'est tout à fait le genre de truc que je souhaitais implémenter. Pour écrire une rule qui doit s'exécuter de manière régulière, il suffit d'écrire :

Code :
from apscheduler.scheduler import Scheduler

sched = Scheduler()

@sched.interval_schedule(hours=1)

def my_rule():

    print "My rule"

sched.start()

Le genre de code que j'aime bien Smile

Avec, bien sûr, un système qui permet de n'avoir à écrire que la fonction avec le décorateur (le @xxx au dessus du def), le tout rangé dans un répertoire bien défini, et qui sera chargé/rechargé dynamiquement par le bignou...

Beau projet ... même si je ne comprends pas forcément tout puisque je ne connais pas suffisamment le protocole KNX ni les différentes couches nécessaires pour le faire fonctionner.

Maintenant s'il y a besoin d'un export depuis ETS je suis prêt à filer un coup de main ... j'ai commencé à regarder ça un peu plus précisément mais je manque de temps pour faire quelques chose d'abouti pour l'intégration dans KnxWeb ... mais je ne désespère pas d'y arriver.

Ben, en fait, moi non plus, je ne connais pas le protocole KNX ! La première étape, c'est donc de se plonger dans les docs Wink

Bon, après avoir regardé différents projets, je pense que je vais m'inspirer très fortement de Calimero, qui a une architecture vraiment bien foutue. Sans faire un portage classe-pour-classe, je pense reprendre certains des designs. Je suis juste en train de voir pour les problèmes de license.

il y a un post sur le groups google qui parle d'un projet python.. ca peut vous interresser..

https://groups.google.com/forum/?fromgro...830aFaatgs

Yep, je l'ai vu passer ; j'ai discuté avec Cyrille, en privé. Mais son truc est une surcouche à linknx, donc pas tout à fait la même optique.

PS : j'avance doucement ; pour l'instant, j'ai commencé à implémenter les convertisseurs de données. Mon design, très inspiré de calimero, n'est pas encore satisfaisant (calimero a ses limites !) ; j'essaye de le blinder avant d'aller plus loin.

Joli projet ! Bon courage !!

Merci-merci Smile

Je progresse... J'espère pouvoir faire tester la partie conversion de données d'ici peu.

Pour pouvoir faire des tests de manière plus simple, j'ai commencé à écrire un dispatcher qui va se mettre à l'écoute du bus, et afficher les valeurs qui transitent via les classes de conversions. Pour ça, il faut aussi que je définisse la structure et la configuration des Datapoint.

Mais j'aimerais faire ça avec un bus virtuel : y a-t-il moyen de lancer eibd en mode simulation ? L'idée serait d'utiliser les commandes groupwrite/groupread et autres pour générer du traffic. Pour l'instant, je n'arrive pas à ce qu'il se lance sans bus physique derrière...

Merci de vos lumières.

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 :

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

Alors, pas de commentaires sur mes délires ?

suis dépassé... manque de connaissances dans le domaine Undecided

pourtant j'essaie de suivre...

Dans le domaine python, ou dans le domaine KNX ? Car l'avis de personnes non développeurs m'intéresse. Comme dit, le but est de créer un outil qui puisse être utilisé (et déployé, en particulier sur des plateformes embarquées) par des non spécialistes en programmation. Faut bien sûr connaître le fonctionnement du bus KNX...

Je ne connais pas du tout python (même si habitué d'autres langages en autodidacte, donc un peu nul quand même) et encore trop peu en protocole KNX... Je lis et relis ton post, mais c'est pas évident d'arriver à tout comprendre tout ce que tu penses par la simple lecture de ton écrit (rien de tel que le brainstorming en face à face pour ce cas de figure, ce qui n'est pas vraiment possible ici !).

Bon, c'est vrai que je viens encore de relire, et je commence à comprendre.

- je trouve que le découpage brique par brique est très intéressant, si tout est bien séparé (objet).
- la syntaxe me parle, avec les explications, c'est bien sûr bien mieux !
- joli projet, mais est-ce réalisable? C'est quand même un gros travail (courageux!).
- comment rendre ça facilement utilisable? Un bon mode d'emploi, sinon point de salut ! Ce qui ajoute encore du boulot !
- je ne suis pas sûr d'avoir encore tout bien compris sur les moyens que tu envisages pour l'utilisation du framework (je suis nul en LINUX), mais est-ce aussi envisageable de le rendre utilisable à partir d'un programme extérieur ou un via un "langage" universel (pour certaines fonctionnalités tout du moins)? Socket, XML, HTML,... mais ça demande alors la mise en place et l'écoute d'un serveur j'imagine..

Je ne sais pas a quel point tu veux intégrer ton framework, mais si tu veux on peu en discuté une peut.

Maintenant j'ai une petite expérience en python et en KNX

Merci pour vos retours. Voici quelques compléments d'explication ; je dois admettre que tout n'est pas encore clair dans ma tête, même si j'ai des idées pour l'essentiel.

En fait, je ne cherche pas à ré-inventer la roue. On a des projets existants très aboutis, mais très différents par leur approche. Il y a bien sûr linknx, qui est en fait le déclencheur de mon projet. On a aussi Calimero, très chouette d'un point de vue architecture logicielle, mais qui ne fait rien de clé en main ; et d'autres projets, comme Domogik, qui est beaucoup plus généraliste.

linknx ne répond pas à 100% de mes besoins, pour 2 raisons principales : il est écrit en C++, qui nécessite une compilation, toujours pénible et laborieuse sur les systèmes embarqués ; il est trop monolithique, et ne permet pas d'étendre ses possibilités facilement. Il est conçu comme une appli finale, avec juste du paramétrage (fichiers xml).

Domogik, lui, permet de mixer plein de technos, chose dont je n'ai pas forcément besoin. C'est un atout pour la domotique DIY, où l'on essaye d'utiliser des composants pas trop chers (1-wire, CPL...), mais du coup, je pense qu'on ne peut pas exploiter les possibilités d'un bus plus industriel comme le KNX.

Il y a plein d'autres superviseurs, mais qui tiennent plus du gadget, pour frimer avec son iPhone/bidule Android (je n'ai ni l'un ni l'autre !!!). Ce n'est pas du tout ce que je cherche.

Je pense qu'il y a réellement la place pour un nouveau truc tel que je le conçois : à mi-chemin entre Calimero (purement une librairie), et une appli finale comme linknx. Ça s'adressera clairement à des gens qui ont envie de faire un peu de développement : rien ne se fera directement depuis une interface web clickodrome pour la mise en oeuvre/configuration (le web permettra, en fait, d'éditer directement les scripts ; c'est hyper simple à faire, et ne souffrira d'aucune limitation). Il faudra coder (en python, langage vraiment très abordable pour des non spécialistes ; il est maintenant au programme découverte info en 2nde !). Mais pas coder from scratch : on aura à sa disposition des briques de très haut niveau, très proche du fonctionnement du bus KNX, et qui permettront de construire principalement une sorte d'automate intelligent pour étendre les fonctionnalités d'une installation KNX.

La première brique sera les rules, comme je l'ai grossièrement présenté . L'idée c'est de pouvoir faire une sorte de petit programme autonome, simple et robuste, pour déclencher des évènements (en fonction du temps, de l'activité sur le bus, d'un signal sur bus série ou IR). Ce sera donc à l'utilisateur décrire un script python qui s'exécutera en tâche de fond pour répondre à un problème précis (genre gestion du chauffage, avec modification des consignes en fonction des heures et jours de la semaine). À priori, les rules seront state-less (pas de mémorisation d'état d'un appel sur l'autre).

Un autre aspect sera de pouvoir créer des participant virtuels, genre station météo utilisant des infos web. linknx permet de dialoguer avec le monde extérieur, mais c'est trop limité. Là, on pourra écrire un bout de programme qui ira chercher des infos sur le web, et qui les présentera sur le bus KNX. Ce nouveau participant aura des objets de communication, qui devront être liés à des GA, comme on le fait sous ETS. Mais là, ça se fera en codant (toujours très simplement, genre juste un appel à un gestionnaire avec 2 ou 3 paramètres). Le tout restant très lisible : la lisibilité du code résultant sera pour moi une priorité ; même sans tout piger, il sera facile pour un non initié de modifier un script pour aller changer quelques paramètres, comme il le ferait via un clickodrome (changer les température, par exemple).

Je pense que les gens qui ont choisi le bus KNX sont des gens qui ont un peu plus de moyens, et qui ne cherchent généralement pas à faire du 1-wire ou du CPL. Le KNX sera dont l'épine dorsale du projet, pour l'échange d'infomations. La majorité des pariticipants seront réels, et le framwork permettra juste d'étendre les possibilités de l'installation ; il n'aura pas vocation à créer une installation de toute pièce, avec uniquement des trucs virtuels. Je pense que ça n'aurait pas de sens d'utiliser KNX, dans ce cas (mieux vaut se tourner vers xPL, comme le fait Domogik).

Voili. J'espère être plus clair. Encore une fois, simplicité, robustesse et maintenance seront mes priorités. Python est très bien pour ça. Pour info, j'ai développé pendant quelques années un logiciel de pilotage pour gros instrument (diffraction neutronique) : on a une partie sur des cartes embarquées, et une partie sur un PC sous linux. Ça tourne 24/24, pendant de longues périodes. Et on n'a vraiment aucun souci de stabilité (vu le coût des neutrons, faut que ça marche !).

Je n'ai pas beaucoup avancé sur le dev, ces derniers temps, mais je suis en train de m'y remettre. J'ai pour le moment besoin de bien comprendre comme s'articule Calimero par rapport aux divers fonctionalités du bus KNX, pour faire du tri et ne conserver que ce qui est pertinent. Calimero permet par exemple d'aller taper directement sur les participants réels, pour voir les propriétés de ceux-ci. Ou de programmer un participant. Ce n'est pas du tout mon but !

python, jamais fait. Perl me plait plus pour du "gros" script (voir très très gros) en interprété. php pour du web. Je suis parti pour créer des trucs en utilisant linknx comme interface. Et un peu de Java pour un dev sous android qui permet la commande vocale - ça sert à *rien* :-)

Je ne connaissais pas calimero, je vais regarder... Echéance à loooooonnnggg terme pour moi..

(12/05/2013, 18:08:42)fma38 a écrit : [ -> ]Domogik, lui, permet de mixer plein de technos, chose dont je n'ai pas forcément besoin. C'est un atout pour la domotique DIY, où l'on essaye d'utiliser des composants pas trop chers (1-wire, CPL...), mais du coup, je pense qu'on ne peut pas exploiter les possibilités d'un bus plus industriel comme le KNX.

Quel possibilité pense tu qu'il n'est pas possible d'exploiter via domogik? (pour ma culture et aussi pourquoi pas l'inclure)

(12/05/2013, 18:08:42)fma38 a écrit : [ -> ]La première brique sera les rules, comme je l'ai grossièrement présenté . L'idée c'est de pouvoir faire une sorte de petit programme autonome, simple et robuste, pour déclencher des évènements (en fonction du temps, de l'activité sur le bus, d'un signal sur bus série ou IR). Ce sera donc à l'utilisateur décrire un script python qui s'exécutera en tâche de fond pour répondre à un problème précis (genre gestion du chauffage, avec modification des consignes en fonction des heures et jours de la semaine). À priori, les rules seront state-less (pas de mémorisation d'état d'un appel sur l'autre).

Pour moi la 1er brique serai plutôt d'arrive a ce connecter au bus et décodé les trames et d'en envoyer.

(12/05/2013, 18:08:42)fma38 a écrit : [ -> ]Je pense que les gens qui ont choisi le bus KNX sont des gens qui ont un peu plus de moyens, et qui ne cherchent généralement pas à faire du 1-wire ou du CPL. Le KNX sera dont l'épine dorsale du projet, pour l'échange d'infomations. La majorité des pariticipants seront réels, et le framwork permettra juste d'étendre les possibilités de l'installation ; il n'aura pas vocation à créer une installation de toute pièce, avec uniquement des trucs virtuels. Je pense que ça n'aurait pas de sens d'utiliser KNX, dans ce cas (mieux vaut se tourner vers xPL, comme le fait Domogik).

Ouais... pas convaincu, personnellement mon installation est en KNX sur l'ensemble de ma maisson, mais le prix de reviens d'une techno comme le Onewire met a ma disposition des fonctions que je n'aurais jamais pus me payer en KNX , par exemple des capteurs d'ouverture sur les 11 fenetres et 9 portes de ma maison ou la 20ene de sonde de température prevu qui en KNX m'aurais couté plus cher que le reste de l'installation (gestion volet, lumiére, chauffage, porte de garage), ce sont pour moi des fonctions annexe, tous comme je n'ai pas les moyen de me payer un modules de logique pour crée des scenarii intégrer au bus.

PS: ma proposition était bien de participé en dehors de cadre de domogik (pour une applicatino pourquoi pas aussi dans domogik, mais pas forcement)

J'ai déjà fait via EIBD en utilisant groupsocketlisten et les groupwrite des petite scripts de logique (simulation de commande groupé, etc...)

(15/05/2013, 16:48:20)Baslic a écrit : [ -> ]Quel possibilité pense tu qu'il n'est pas possible d'exploiter via domogik? (pour ma culture et aussi pourquoi pas l'inclure)

Il m'avait semblé que la structure de Domogik n'était pas très adaptée au KNX... Tout est toujours possible, mais lorsqu'on fait trop de galipettes, ça devient vite difficile ensuite de faire évoluer les choses.

Citation :Ouais... pas convaincu, personnellement mon installation est en KNX sur l'ensemble de ma maisson, mais le prix de reviens d'une techno comme le Onewire met a ma disposition des fonctions que je n'aurais jamais pus me payer en KNX , par exemple des capteurs d'ouverture sur les 11 fenetres et 9 portes de ma maison ou la 20ene de sonde de température prevu qui en KNX m'aurais couté plus cher que le reste de l'installation (gestion volet, lumiére, chauffage, porte de garage), ce sont pour moi des fonctions annexe, tous comme je n'ai pas les moyen de me payer un modules de logique pour crée des scenarii intégrer au bus.

Je comprend tout à fait, et je partage ton point de vue. Mais il n'en reste pas moins vrai que ces fonctions annexes ne sont pas fondamentales. La partie KNX gère vraiment le coeur de l'installe, et c'est pour ça que je préfère que le framework se base sur cette architecture. Le reste viendra se greffer autour, sous forme de plugins, et les échanges se feront en KNX (ce qui ne veut pas dire que tout se propagera sur le bus physique ; je réfléchis à une façon de leur permettre de communiquer entre eux sans mettre à jour le bus).

Bon, je suis en train de creuser l'implémentation de la stack OSI, que reprend assez fidèlement le bus KNX. Ce n'est pas forcément pour tout implémenter maintenant, mais pour essayer de mettre en place l'architecture qui permettra de le faire plus tard, et de n'implémenter que ce qui est utile pour l'instant. Le fait d'utiliser l'API d'eibd va en court-circuiter une bonne partie, puisqu'elle travaille au niveau application (layer 7), si j'ai bien compris.

Les points qui me sont plus obscures, c'est justement l'utilisation de la trame cEMI ; je ne comprend pas où elle se situe dans le modèle OSI ? C'est un truc purement KNX, et j'ai l'impression que c'est une structure transversale, qui permet justement les échanges entre les couches OSI. Me goure-je ?

Sinon, autre point : la notion de Datapoint et de Communication Object. S'agit-il de 2 concepts différents, ou de la même chose ?

Calimero utilise les 'Datapoint' comme entité pouvant être liée à une ou plusieurs GA. Certaines GA mettent à jour le Datapoint, d'autres invalident la valeur courante du Datapoint (je ne sais pas dans quel cas ça peut être utile, mais pourquoi pas ?). Un Datapoint est identifié par une GA principale. Cf :

http://calimero.sourceforge.net/docs204/...index.html

J'ai trouvé la doc de l'API d'une autre librairie qui utilise les 'CommObject'. Cf :

http://dz.prosyst.com/pdoc/mbs_ext_6.1/u...mmary.html

Votre avis ?

Bon, j'avance à grands pas, mais le but me semble toujours aussi éloigné Wink

Sans rire, j'ai finalement décidé d'implémenter la pile complète, plutôt que de me faire chier avec l'API moche d'eibd... Bon, pour le moment, je me restreins aux échanges de types multicast (group address) ; c'est la partie la plus simple de la pile. Pour le reste, on verra plus tard si ça en vaut la peine. En tout cas, la structure est là, donc il suffira de remplir les trous.

Du coup, j'ai une question concernant le multicast. Puisqu'il s'agit d'un mode non connecté (UDP), je suppose que les passerelles anciennes Siemens N148, qui ne supportent qu'une connexion, peuvent quand même envoyer/recevoir des télégrammes de type GroupData à plusieurs hosts ?

Or, j'essaye en vain de sniffer ces trames avec un bout de code implémentant un socket UDP. Je fait un join sur le group "224.0.23.12" en utilisant le port 3671, mais je ne vois rien passer...

Où me goure-je ? Est-ce que je me fourvoie complètement dans ma compréhension du bidule ?

D'ailleurs, pourquoi est-ce que je ne vois même pas passer ces trames dans wireshark ?

Je ne serais t'aidé mais j'ai hâte de voir le resultat

Oui, moi aussi !!! Smile

(11/04/2013, 10:16:31)fma38 a écrit : [ -> ]Mais j'aimerais faire ça avec un bus virtuel : y a-t-il moyen de lancer eibd en mode simulation ?

En mode multicast/Routing IP, tu peux faire un script qui envoie des trucs sans eibd ni bus ni rien.

Pages : 1 2

fma38

silverrcx

fma38

Weevil

fma38

flop

fma38

Suricat

fma38

fma38

fma38

fma38

mil3d

fma38

mil3d

Baslic

fma38

Suricat

Baslic

fma38

fma38

fma38

Mika-nt28

fma38

silverrcx