27/03/2013, 01:35:13
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
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