29/01/2009, 21:01:00
Bon, mes essais ont été sans succès.
Avec le moniteur port série donné plus haut, je vois bien les trames
au format décrit dans le doc en lien.
Par contre avec l'extender de ma téléco, en rentrant les mêmes codes
hexa, rien ne passe sur le bus.
Je pense que l'interface FT1.2 attend des réponses et des acquits pour
transférer sur le bus les commandes RS232, et çà, mon extender ne sait
pas le faire.
Donc, a première vue, la solution fonctionnelle est l "eib ascii
terminal", mais 550€ çà fait cher pour cette appli.
Je vais donc sans doute me tourner vers l'IR, avec ses limites
quantitatives et unidirectionnelle.
Si quelqu'un à d'autres solutions, je suis preneur
Merci à tous pour votre aide
@+
On 29 jan, 08:04, mickg <mickael.gaut...@wanadoo.fr> wrote:
> Oups, désolé Cyrille, je n'avais pas vu ton post plus haut, qui pointe
> sur le même doc.
>
> Merci
>
> On 28 jan, 23:23, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > Merci à tous.
>
> > En fouillant un peu, grâce à vos indices, j'ai trouvé çà :
>
> >http://bbs-os-brinkstr.com/Doc/EIB_RS232/FT12-Message-Format.pdf
>
> > j'essaie demain...
>
> > @+
>
> > On 28 jan, 22:51, jef2000 <jef2...@ouaye.net> wrote:
>
> > > Pour le protocole FT1.2, tout est spécifié dans la spec KNX (le
> > > fichier volume3.zip , j'espère qu'il est toujours possible de le
> > > trouver quelque part sur le net). Dans la partie "Physical External
> > > Interface", la section 6.4 décrit le protocole.
> > > Je ne pense pas qu'il soit possible d'envoyer simplement des messages
> > > prédéfinis.
>
> > > Pour comprendre le protocole, le plus simple est d'installer EIBD sur
> > > la machine, de connecter l'interface sur un port série, de le démarrer
> > > en FT1.2 avec les traces activées (option -t65535) et regarder ce qui
> > > se passe.
>
> > > Voici un example de ce que ça donne quand on envoie un OFF pour
> > > l'adresse 1/1/1 :
> > > Layer 4(004FCF18,386D450F) OpenGroup 1/1/1 WO
> > > Layer 4(004FCF18,386D450F) Send Group T_DATA_XXX_REQ
> > > A_GroupValue_Write (small) 00
> > > Layer 3(004FCD48,386D450F) Send L_Data low from 0.0.0 to 1/1/1 hops:
> > > 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
> > > Layer 2(004ECA18,386D450F) Send L_Data low from 0.0.0 to 1/1/1 hops:
> > > 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
> > > Layer 1(004DC688,386D450F) Send(009): 11 0C 00 00 09 01 F1 00 80
> > > Layer 0(004DC688,386D450F) Send(016): 68 0A 0A 68 53 11 0C 00 00 09 01
> > > F1 00 80 EB 16
> > > Layer 2(004ECA18,386D450F) Recv L_Data low from 0.0.0 to 1/1/1 hops:
> > > 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
> > > Layer 3(004FCD48,386D450F) Recv L_Data low from 0.0.0 to 1/1/1 hops:
> > > 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
> > > Layer 0(004DC688,386D450F) Recv(005): 68 0A 0A 68 53
> > > Layer 4(004FCF18,386D450F) CloseGroup
> > > Layer 3(004FCD48,386D450F) deregisterGroupCallBack 004FCF18 = 0
> > > Layer 0(004DC688,386D450F) Recv(011): 11 0C 00 00 09 01 F1 00 80 EB 16
> > > Layer 0(004DC688,386D450F) Send Ack(001): E5
> > > Layer 0(004DC688,386D450F) Recv(001): E5
>
> > > Les lignes commençant par "Layer1" correspondent plus ou moins à ce
> > > qu'on voit dans ETS.
> > > Les lignes "Layer0" contiennent les mêmes données encapsulées dans le
> > > protocole FT1.2
>
> > > Au démarrage de EIBD, celui-ci envoie également un reset à l'interface
> > > EIB, ça ressemble à ça:
> > > Layer 1(080BD6C0,475AD78C) Open
> > > Layer 1(080BD6C0,475AD78C) Opened
> > > Layer 2(080BD668,475AD78C) Open
> > > Layer 2(080BD668,475AD78C) Opened
> > > Layer 3(080DDE00,475AD78C) Open
> > > Layer 2(080BD668,475AD78C) OpenL2
> > > Layer 1(080BD6C0,475AD78C) SendReset
> > > Layer 1(080BD6C0,475AD78C) Send(007): A9 1E 12 34 56 78 9A
> > > Layer 0(080BD6C0,475AD78C) Send(004): 10 40 40 16
> > > Layer 1(080BD6C0,475AD78C) Send(007): A9 00 18 34 56 78 0A
> > > Layer 0(080BD6C0,475AD78C) Recv(001): E5
> > > Layer 0(080BD6C0,475AD78C) Send(014): 68 08 08 68 73 A9 1E 12 34 56 78
> > > 9A E8 16
> > > Layer 0(080BD6C0,475AD78C) Recv(001): E5
> > > Layer 0(080BD6C0,475AD78C) Send(014): 68 08 08 68 53 A9 00 18 34 56 78
> > > 0A 20 16
> > > Layer 0(080BD6C0,475AD78C) Recv(001): E5
>
> > > Si on regarde les lignes "layer0", on retrouve bien les ACK (valeur
> > > E5) et les trames de longueur variable décrites dans la spec. Ces
> > > dernières commencent par 68 suivi de la longueur du message répétée 2
> > > fois, ensuite encore un 68, un byte de controle, le message proprement
> > > dit, un byte de checksum et 16 pour terminer. La signification du byte
> > > de contrôle ('control field') est décrite dans la spec.
>
> > > A+
>
> > > Jean-François
>
> > > On 28 jan, 20:44, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > > > J'explique un peu plus mon problème.
>
> > > > Je souhaite à partir d'une télécommande programmable + 1 extender
> > > > RS232 commander une instal KNX.
>
> > > > Je dispose pour cela d'une interface RS232/KNX standard ou FT1.2
> > > > (modèle de chez EIBMarkt).
>
> > > > Via le soft de la télécommande, je peux créer les codes RS232 en hexa
> > > > ou en ASCII.
>
> > > > Jusqu'à présent impossible de faire scintiller la led de l'interface
> > > > RS/KNX.
>
> > > > Voilà
>
> > > > PS : as tu un lien à me donner pour un "sniffeur" RS232
>
> > > > Merci
>
> > > > On 28 jan, 20:19, Kylia <morvillez_anto...@hotmail.com> wrote:
>
> > > > > Bonjour,
>
> > > > > Il faudrait que tu précises ton besoin : tu veux piloter ton bus via
> > > > > un logiciel PC que tu réalises toi même?
>
> > > > > Je peux néanmoins t'apporter quelques éléments de réponses:
>
> > > > > Ton interface permettant d'accéder au bus est un produit KNX. Le
> > > > > protocole entre ton PC et ce périphérique est normalisé, et ne
> > > > > ressemble pas à ce que tu peux voir via l'analyseur de bus de ETS.
>
> > > > > Deux possibilités dans ton cas
>
> > > > > - Tu intègres le driver Falcon à ton développement. Tu peux récupérer
> > > > > les libraires (payantes et onéreuses) auprès de EIBA. Cela te propose
> > > > > une interface pour pouvoir envoyer des trames sur le bus. Tu as toutes
> > > > > la doc qu'il te faut quand tu l'achètes, trés facile à mettre en
> > > > > oeuvre. c'est la solution la plus simple et la plus fiable.
>
> > > > > - Si tu sais faire un peu d'électronique, il existe un composant que
> > > > > l'on nomme TP_UART (de siemens) qui coute une dizaine d'euros, mais la
> > > > > il y a un peu plus de développement à faire. Le TP_UART (tu trouveras
> > > > > la datasheet sur le net), se pilote par une liaison série TTL (pour le
> > > > > Rs232, rajouter un max232). En ajoutant quelques composants classiques
> > > > > (cf. datasheet) tu accèdes directement au bus. Le TP_UART couvre les
> > > > > couches 1 et 2 du modèle OSI, ce qui implique qu'il faut que tu
> > > > > développes les autres couches... Si c'est juste pour toi, c'est rapide
> > > > > à mettre en oeuvre, si c'est pour être labelisé knx, il y a la
> > > > > certification et la c'est bcp plus complexe...
>
> > > > > Si tu ne souhaites pas réaliser l'interface avec le TP_UART toi même,
> > > > > il existe des modules tout fait (mais assez cher)...Tu peux aussi
> > > > > regarder de ce qui se fait pour linux.
>
> > > > > Il reste tout de même une methode pour t'en sortir : c'est de mettre
> > > > > un espion Rs232 et regarder ce qui passe quand tu fais des actions ON/
> > > > > OFF, et faire l'analogie avec ce que tu vois sur le moniteur de
> > > > > bus...mais la ca relève un peu de la bidouille et de l'incertitude.
>
> > > > > Voila voila.
>
> > > > > On 28 jan, 18:57, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > > > > > Bonjour,
>
> > > > > > Je cherche le moyen d'envoyer des trames en Hexadecimal par RS232 via
> > > > > > une interface RS232/KNX FT1.2 vers le bus.
> > > > > > Quelqu'un connait-il la structure des trames?
> > > > > > J'ai essayé en recopiant bêtement les trames récupérées par le
> > > > > > moniteur de bus d'ETS, mais sans succès.
>
> > > > > > Merci
Avec le moniteur port série donné plus haut, je vois bien les trames
au format décrit dans le doc en lien.
Par contre avec l'extender de ma téléco, en rentrant les mêmes codes
hexa, rien ne passe sur le bus.
Je pense que l'interface FT1.2 attend des réponses et des acquits pour
transférer sur le bus les commandes RS232, et çà, mon extender ne sait
pas le faire.
Donc, a première vue, la solution fonctionnelle est l "eib ascii
terminal", mais 550€ çà fait cher pour cette appli.
Je vais donc sans doute me tourner vers l'IR, avec ses limites
quantitatives et unidirectionnelle.
Si quelqu'un à d'autres solutions, je suis preneur
Merci à tous pour votre aide
@+
On 29 jan, 08:04, mickg <mickael.gaut...@wanadoo.fr> wrote:
> Oups, désolé Cyrille, je n'avais pas vu ton post plus haut, qui pointe
> sur le même doc.
>
> Merci
>
> On 28 jan, 23:23, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > Merci à tous.
>
> > En fouillant un peu, grâce à vos indices, j'ai trouvé çà :
>
> >http://bbs-os-brinkstr.com/Doc/EIB_RS232/FT12-Message-Format.pdf
>
> > j'essaie demain...
>
> > @+
>
> > On 28 jan, 22:51, jef2000 <jef2...@ouaye.net> wrote:
>
> > > Pour le protocole FT1.2, tout est spécifié dans la spec KNX (le
> > > fichier volume3.zip , j'espère qu'il est toujours possible de le
> > > trouver quelque part sur le net). Dans la partie "Physical External
> > > Interface", la section 6.4 décrit le protocole.
> > > Je ne pense pas qu'il soit possible d'envoyer simplement des messages
> > > prédéfinis.
>
> > > Pour comprendre le protocole, le plus simple est d'installer EIBD sur
> > > la machine, de connecter l'interface sur un port série, de le démarrer
> > > en FT1.2 avec les traces activées (option -t65535) et regarder ce qui
> > > se passe.
>
> > > Voici un example de ce que ça donne quand on envoie un OFF pour
> > > l'adresse 1/1/1 :
> > > Layer 4(004FCF18,386D450F) OpenGroup 1/1/1 WO
> > > Layer 4(004FCF18,386D450F) Send Group T_DATA_XXX_REQ
> > > A_GroupValue_Write (small) 00
> > > Layer 3(004FCD48,386D450F) Send L_Data low from 0.0.0 to 1/1/1 hops:
> > > 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
> > > Layer 2(004ECA18,386D450F) Send L_Data low from 0.0.0 to 1/1/1 hops:
> > > 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
> > > Layer 1(004DC688,386D450F) Send(009): 11 0C 00 00 09 01 F1 00 80
> > > Layer 0(004DC688,386D450F) Send(016): 68 0A 0A 68 53 11 0C 00 00 09 01
> > > F1 00 80 EB 16
> > > Layer 2(004ECA18,386D450F) Recv L_Data low from 0.0.0 to 1/1/1 hops:
> > > 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
> > > Layer 3(004FCD48,386D450F) Recv L_Data low from 0.0.0 to 1/1/1 hops:
> > > 07 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
> > > Layer 0(004DC688,386D450F) Recv(005): 68 0A 0A 68 53
> > > Layer 4(004FCF18,386D450F) CloseGroup
> > > Layer 3(004FCD48,386D450F) deregisterGroupCallBack 004FCF18 = 0
> > > Layer 0(004DC688,386D450F) Recv(011): 11 0C 00 00 09 01 F1 00 80 EB 16
> > > Layer 0(004DC688,386D450F) Send Ack(001): E5
> > > Layer 0(004DC688,386D450F) Recv(001): E5
>
> > > Les lignes commençant par "Layer1" correspondent plus ou moins à ce
> > > qu'on voit dans ETS.
> > > Les lignes "Layer0" contiennent les mêmes données encapsulées dans le
> > > protocole FT1.2
>
> > > Au démarrage de EIBD, celui-ci envoie également un reset à l'interface
> > > EIB, ça ressemble à ça:
> > > Layer 1(080BD6C0,475AD78C) Open
> > > Layer 1(080BD6C0,475AD78C) Opened
> > > Layer 2(080BD668,475AD78C) Open
> > > Layer 2(080BD668,475AD78C) Opened
> > > Layer 3(080DDE00,475AD78C) Open
> > > Layer 2(080BD668,475AD78C) OpenL2
> > > Layer 1(080BD6C0,475AD78C) SendReset
> > > Layer 1(080BD6C0,475AD78C) Send(007): A9 1E 12 34 56 78 9A
> > > Layer 0(080BD6C0,475AD78C) Send(004): 10 40 40 16
> > > Layer 1(080BD6C0,475AD78C) Send(007): A9 00 18 34 56 78 0A
> > > Layer 0(080BD6C0,475AD78C) Recv(001): E5
> > > Layer 0(080BD6C0,475AD78C) Send(014): 68 08 08 68 73 A9 1E 12 34 56 78
> > > 9A E8 16
> > > Layer 0(080BD6C0,475AD78C) Recv(001): E5
> > > Layer 0(080BD6C0,475AD78C) Send(014): 68 08 08 68 53 A9 00 18 34 56 78
> > > 0A 20 16
> > > Layer 0(080BD6C0,475AD78C) Recv(001): E5
>
> > > Si on regarde les lignes "layer0", on retrouve bien les ACK (valeur
> > > E5) et les trames de longueur variable décrites dans la spec. Ces
> > > dernières commencent par 68 suivi de la longueur du message répétée 2
> > > fois, ensuite encore un 68, un byte de controle, le message proprement
> > > dit, un byte de checksum et 16 pour terminer. La signification du byte
> > > de contrôle ('control field') est décrite dans la spec.
>
> > > A+
>
> > > Jean-François
>
> > > On 28 jan, 20:44, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > > > J'explique un peu plus mon problème.
>
> > > > Je souhaite à partir d'une télécommande programmable + 1 extender
> > > > RS232 commander une instal KNX.
>
> > > > Je dispose pour cela d'une interface RS232/KNX standard ou FT1.2
> > > > (modèle de chez EIBMarkt).
>
> > > > Via le soft de la télécommande, je peux créer les codes RS232 en hexa
> > > > ou en ASCII.
>
> > > > Jusqu'à présent impossible de faire scintiller la led de l'interface
> > > > RS/KNX.
>
> > > > Voilà
>
> > > > PS : as tu un lien à me donner pour un "sniffeur" RS232
>
> > > > Merci
>
> > > > On 28 jan, 20:19, Kylia <morvillez_anto...@hotmail.com> wrote:
>
> > > > > Bonjour,
>
> > > > > Il faudrait que tu précises ton besoin : tu veux piloter ton bus via
> > > > > un logiciel PC que tu réalises toi même?
>
> > > > > Je peux néanmoins t'apporter quelques éléments de réponses:
>
> > > > > Ton interface permettant d'accéder au bus est un produit KNX. Le
> > > > > protocole entre ton PC et ce périphérique est normalisé, et ne
> > > > > ressemble pas à ce que tu peux voir via l'analyseur de bus de ETS.
>
> > > > > Deux possibilités dans ton cas
>
> > > > > - Tu intègres le driver Falcon à ton développement. Tu peux récupérer
> > > > > les libraires (payantes et onéreuses) auprès de EIBA. Cela te propose
> > > > > une interface pour pouvoir envoyer des trames sur le bus. Tu as toutes
> > > > > la doc qu'il te faut quand tu l'achètes, trés facile à mettre en
> > > > > oeuvre. c'est la solution la plus simple et la plus fiable.
>
> > > > > - Si tu sais faire un peu d'électronique, il existe un composant que
> > > > > l'on nomme TP_UART (de siemens) qui coute une dizaine d'euros, mais la
> > > > > il y a un peu plus de développement à faire. Le TP_UART (tu trouveras
> > > > > la datasheet sur le net), se pilote par une liaison série TTL (pour le
> > > > > Rs232, rajouter un max232). En ajoutant quelques composants classiques
> > > > > (cf. datasheet) tu accèdes directement au bus. Le TP_UART couvre les
> > > > > couches 1 et 2 du modèle OSI, ce qui implique qu'il faut que tu
> > > > > développes les autres couches... Si c'est juste pour toi, c'est rapide
> > > > > à mettre en oeuvre, si c'est pour être labelisé knx, il y a la
> > > > > certification et la c'est bcp plus complexe...
>
> > > > > Si tu ne souhaites pas réaliser l'interface avec le TP_UART toi même,
> > > > > il existe des modules tout fait (mais assez cher)...Tu peux aussi
> > > > > regarder de ce qui se fait pour linux.
>
> > > > > Il reste tout de même une methode pour t'en sortir : c'est de mettre
> > > > > un espion Rs232 et regarder ce qui passe quand tu fais des actions ON/
> > > > > OFF, et faire l'analogie avec ce que tu vois sur le moniteur de
> > > > > bus...mais la ca relève un peu de la bidouille et de l'incertitude.
>
> > > > > Voila voila.
>
> > > > > On 28 jan, 18:57, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > > > > > Bonjour,
>
> > > > > > Je cherche le moyen d'envoyer des trames en Hexadecimal par RS232 via
> > > > > > une interface RS232/KNX FT1.2 vers le bus.
> > > > > > Quelqu'un connait-il la structure des trames?
> > > > > > J'ai essayé en recopiant bêtement les trames récupérées par le
> > > > > > moniteur de bus d'ETS, mais sans succès.
>
> > > > > > Merci