25/02/2014, 15:23:28
@mil3d, euh, ouais, c'est pas trivial, ton truc ! Tout est faisable, hein, mais c'est clair que ça va demander du boulot.
En fait, la philosophie KNX, que j'ai essayé de suivre avec mon framework, c'est de décomposer un Device en Functional Blocs ; ces blocs doivent être vus comme des boîtes noires, possédants des entrées, des sorties, et éventuellement des paramètres. Plus, bien sûr, un état et un comportement (ce modèle se traite très bien avec une approche objet). Les entres/sorties/paramètres sont ce qu'on appelle les Datapoint ; il sont généralement accessibles à travers des Group Object associés (y'a d'autres types d'accès, mais pas utiles en usage courant). Ces Group Object sont liés entre eux via les Group Address.
Un Device est donc généralement composé des plusieurs Functional Bloc, dont certains Datapoint sont reliés en interne (et également dispos via un Group Object) ; c'est par exemple le cas d'un détecteur de présence, qui intègre aussi une mesure de lumière, le tout permettant de piloter un actionneur pour maintenir un niveau de luminosité constant. On peut utiliser chaque composant de manière indépendante, ou de manière globale.
Tout ça pour dire que dans ton cas, il faut déjà arriver à faire cette décomposition en plusieurs Functional Bloc, voir en plusieurs Device si ça devient trop lourd. C'est par exemple ce que j'ai fait pour un début de gestion de VMC ; faudrait que je poste le code quelque part pour te donner une idée...
@RemyB, l'accès 1-wire est intéressant ; ce n'est pas trop compliqué, et illustre bien le but de pKNyX : créer un pseudo-device KNX permettant d'étendre les fonctionalités d'une installation. Si tu as un peu de temps, je serais preneur de quelques liens sur le 1-wire en python (owfs ou autre)... Le but est de s'appuyer sur des choses existantes, et les mapper dans le monde KNX. Tout en permettant de faire des choses plus complexes, comme le log en base de données, l'envoi de courriels, etc...
Tiens, d'ailleurs, l'envoi de courriels en cas d'alerte peut tout à fait faire l'objet d'un exemple à part entière ; un truc un peu générique, ou très facile à adapter en fonction des besoins.
Hop, je vais commencer pas là
En fait, la philosophie KNX, que j'ai essayé de suivre avec mon framework, c'est de décomposer un Device en Functional Blocs ; ces blocs doivent être vus comme des boîtes noires, possédants des entrées, des sorties, et éventuellement des paramètres. Plus, bien sûr, un état et un comportement (ce modèle se traite très bien avec une approche objet). Les entres/sorties/paramètres sont ce qu'on appelle les Datapoint ; il sont généralement accessibles à travers des Group Object associés (y'a d'autres types d'accès, mais pas utiles en usage courant). Ces Group Object sont liés entre eux via les Group Address.
Un Device est donc généralement composé des plusieurs Functional Bloc, dont certains Datapoint sont reliés en interne (et également dispos via un Group Object) ; c'est par exemple le cas d'un détecteur de présence, qui intègre aussi une mesure de lumière, le tout permettant de piloter un actionneur pour maintenir un niveau de luminosité constant. On peut utiliser chaque composant de manière indépendante, ou de manière globale.
Tout ça pour dire que dans ton cas, il faut déjà arriver à faire cette décomposition en plusieurs Functional Bloc, voir en plusieurs Device si ça devient trop lourd. C'est par exemple ce que j'ai fait pour un début de gestion de VMC ; faudrait que je poste le code quelque part pour te donner une idée...
@RemyB, l'accès 1-wire est intéressant ; ce n'est pas trop compliqué, et illustre bien le but de pKNyX : créer un pseudo-device KNX permettant d'étendre les fonctionalités d'une installation. Si tu as un peu de temps, je serais preneur de quelques liens sur le 1-wire en python (owfs ou autre)... Le but est de s'appuyer sur des choses existantes, et les mapper dans le monde KNX. Tout en permettant de faire des choses plus complexes, comme le log en base de données, l'envoi de courriels, etc...
Tiens, d'ailleurs, l'envoi de courriels en cas d'alerte peut tout à fait faire l'objet d'un exemple à part entière ; un truc un peu générique, ou très facile à adapter en fonction des besoins.
Hop, je vais commencer pas là