Exporter les types des adresses de groupes avec ETS ?

[Pascal]

Bonjour,

Je découvre KNX (avec l'aide précieuse des archives de ce groupe) et
j'essaie de superviser mon installation avec un logiciel fait maison.

Lorsque j'exporte au format OPC avec ETS 3.0f, le fichier ".esf" ne
contient pas les types des adresses de groupes, dont j'ai besoin pour
décoder correctement les télégrammes. Par exemple :

prod.env.3/3/3 heure_dcf Uncertain (3 Byte) Low

J'ai pourtant sélectionné le type 10.001 (heure) dans la fenêtre
'Propriétés" de chaque objet lié à 3/3/3.

Est-ce normal ? J'ai vu des documents qui disent que c'est un bug
d'ETS, et d'autres qui suggèrent de le contourner en numérotant les
adresses en fonction de leur type...

C'est certainement un problème courant. Comment récupérez-vous les
types des adresses de vos installations configurées avec ETS ?
En décodant directement les fichiers Sybase ?
En relisant la mémoire des appareils une fois qu'ils sont configurés ?

[fred]

La solution standard est de reconfigurer les addresses dans la
solution cible, je pense. Je ne vois pas le problème ?


On Apr 21, 11:00 am, Pascal <pb115...@pabr.org> wrote:
> Bonjour,
>
> Je découvre KNX (avec l'aide précieuse des archives de ce groupe) et
> j'essaie de superviser mon installation avec un logiciel fait maison.
>
> Lorsque j'exporte au format OPC avec ETS 3.0f, le fichier ".esf" ne
> contient pas les types des adresses de groupes, dont j'ai besoin pour
> décoder correctement les télégrammes. Par exemple :
>
> prod.env.3/3/3  heure_dcf       Uncertain (3 Byte)      Low
>
> J'ai pourtant sélectionné le type 10.001 (heure) dans la fenêtre
> 'Propriétés" de chaque objet lié à 3/3/3.
>
> Est-ce normal ?  J'ai vu des documents qui disent que c'est un bug
> d'ETS, et d'autres qui suggèrent de le contourner en numérotant les
> adresses en fonction de leur type...
>
> C'est certainement un problème courant. Comment récupérez-vous les
> types des adresses de vos installations configurées avec ETS ?
> En décodant directement les fichiers Sybase ?
> En relisant la mémoire des appareils une fois qu'ils sont configurés ?

[Pascal]

fred wrote:
> La solution standard est de reconfigurer les addresses dans la
> solution cible, je pense. Je ne vois pas le problème ?

Donc un groupe pour les interrupteurs (1 bit), un groupe pour les
variateurs (8 bits), un groupe pour les thermostats (16 bits), etc ?

Ça résout le problème en effet, mais je n'ai aucune envie de
déstructurer mon plan d'adressage juste pour contourner une limitation
d'un outil. Si personne n'a mieux à proposer, je compte plutôt
utiliser des conventions de nommage ; par exemple :

temperature_salon_9_001
vitesse_vent_9_005
heure_dcf_10_001

[fred]

> Donc un groupe pour les interrupteurs (1 bit), un groupe pour les
> variateurs (8 bits), un groupe pour les thermostats (16 bits), etc ?

Non, non, je voulais dire, la visu "sait" que 1/33/42 est une
temperature. C'est-à-dire que l'info n'est pas transmise par le
fichier, mais répliquée "à la main".

Je ne vois pas ca comme un gros problème car, en général, l'objectif
principal d'un système de visualisation ou de supervision est de
présenter l'information du bus ajoutée à des méta-données spécifiques
qui permettent de l'évaluer dans le contexte. Et donc, le type de la
donnée est soit une chose mineure à indiquer, soit même implicite en
fonction des autres méta-données associées.

Par exemple, dans le cas d'une visu, on va par exemple vouloir un
petit logo thermomètre placé hors du plan de la maison pour indiquer
la température extérieure. Il n'y a plus qu'à indiquer l'adresse de
groupe et voila. Le fait que c'est une température est implicite,
après avoir fait tout ca. Autrement dit, pour temperature_salon_9_001,
la visu va pas comprendre toute seule que c'est dans le salon, donc
c'est pas trop un problème qu'elle comprenne pas toute seule que c'est
une température...

Pour la supervision, c'est pareil. Tu veux par exemple comparer deux
valeurs pour indiquer une alarme (par exemple: temperature interieure
> temperature exterieure). Dans ce cas on pourrait imaginer qu'il n'y
ait qu'à indiquer l'opérateur de comparaison (>) et la supervision
trouverait le type toute seule. Mais tu voudras probablement une
alarme explicite, un message style "Bizarre: la température interieure
est plus faible que la temperature exterieure", pas un message "GA
1/23/443 est plus faible que 23/23/632"....

Dans les deux cas, c'est la même idée: le fait que tu veuilles
associer des méta-données riches aux adresses (la raison de la
visualisation ou de la supervision) rends le problème du fichier avec
adresses sans types mineur. Ajouter le type "à la main" dans la
supervision ou visualisation est un effort mineur comparé au reste des
méta-données à indiquer.

Voila ce que je voulais dire

Fred

On Apr 23, 12:17 pm, Pascal <pb115...@pabr.org> wrote:
> fred wrote:
> > La solution standard est de reconfigurer les addresses dans la
> > solution cible, je pense. Je ne vois pas le problème ?
>
> Donc un groupe pour les interrupteurs (1 bit), un groupe pour les
> variateurs (8 bits), un groupe pour les thermostats (16 bits), etc ?
>
> Ça résout le problème en effet, mais je n'ai aucune envie de
> déstructurer mon plan d'adressage juste pour contourner une limitation
> d'un outil. Si personne n'a mieux à proposer, je compte plutôt
> utiliser des conventions de nommage ; par exemple :
>
> temperature_salon_9_001
> vitesse_vent_9_005
> heure_dcf_10_001

[Pascal]

fred wrote:
> Par exemple, dans le cas d'une visu, on va par exemple vouloir un
> petit logo thermomètre placé hors du plan de la maison pour indiquer
> la température extérieure. Il n'y a plus qu'à indiquer l'adresse de
> groupe et voila.

Et si ETS voulait bien exporter les types, le logiciel de visu
pourrait créer automatiquement un logo thermomètre pour chaque adresse
dont le type est "température", et l'utilisateur n'aurait plus qu'à le
placer sur le plan en fonction de son nom :-) Avec les autres méta-
données déjà disponibles dans ETS, le logiciel de visu pourrait même
déterminer quelle adresse physique est la source de cette température,
et à quelle pièce elle est rattachée.

> Ajouter le type "à la main" dans la
> supervision ou visualisation est un effort mineur comparé au reste des
> méta-données à indiquer.

OK je comprends. Pour l'instant j'expérimente encore beaucoup, et le
coût de la synchronisation manuelle entre les outils à chaque
modification n'est pas négligeable. Par exemple je veux enregistrer
tout le trafic bus 24h/24 en clair dans un fichier texte, et pour ça
il me faut les types de *toutes* les adresses. Il doit bien y avoir
des outils commerciaux qui font ça ; comment s'en tirent t-ils ?

[yannick]

Bonjour,

Tout d'abord, merci au créateur de ce forum que je lis depuis un
moment et qui très interressant.

Je suis en train d'étudier la mise en place de la même chose
(developpement de mon logiciel de supervision).
Peut être pourriez vous me donner 2, 3 conseils sur la façon d'aborder
les choses :
- Quelle solution de communication avec le bus avez vous retenue :
USB ou ethernet
- Avez vous utilisé le "SDK" Falcon ou avez vous choisie une solution
de communication bas niveau ?
- Quel langage avez vous choisi pour développer votre application ?

Merci

On 21 avr, 11:00, Pascal <pb115...@pabr.org> wrote:
> Bonjour,
>
> Je découvre KNX (avec l'aide précieuse des archives de ce groupe) et
> j'essaie de superviser mon installation avec un logiciel fait maison.
>
> Lorsque j'exporte au format OPC avec ETS 3.0f, le fichier ".esf" ne
> contient pas les types des adresses de groupes, dont j'ai besoin pour
> décoder correctement les télégrammes. Par exemple :
>
> prod.env.3/3/3  heure_dcf       Uncertain (3 Byte)      Low
>
> J'ai pourtant sélectionné le type 10.001 (heure) dans la fenêtre
> 'Propriétés" de chaque objet lié à 3/3/3.
>
> Est-ce normal ?  J'ai vu des documents qui disent que c'est un bug
> d'ETS, et d'autres qui suggèrent de le contourner en numérotant les
> adresses en fonction de leur type...
>
> C'est certainement un problème courant. Comment récupérez-vous les
> types des adresses de vos installations configurées avec ETS ?
> En décodant directement les fichiers Sybase ?
> En relisant la mémoire des appareils une fois qu'ils sont configurés ?

[jef2000]

Bonjour,

Concernant le logiciel de supervision, j'aimerais avoir une idées des
fonctionalités que vous projetez d'y inclure. Est-ce uniquement pour
la visualisation de l'installation? Pour l'automatisation de tâches
(timers, réactions à des événements, ...)? Les deux, ou autres....
Je suis à la recherche de nouvelles idées pour ajouter à ce que j'ai
déjà développé.

> - Quelle solution de communication avec le bus avez vous retenue :
> USB ou ethernet
> - Avez vous utilisé le "SDK" Falcon ou avez vous choisie une solution
> de communication bas niveau ?
Pour communiquer avec le bus, j'utilise EIBD (
http://www.auto.tuwien.ac.at/~mkoegler/index.php/eibd ) qui fournit
une interface unique pour mon application tout en supportant l'USB,
l'ethernet, le port série etc...

> - Quel langage avez vous choisi pour développer votre application ?
C++ pour l'application de gestion (Linknx)
et JavaScript/AJAX pour la partie visualisation (KnxWeb)
Plus d'info sur: http://sourceforge.net/projects/linknx/

Merci,

Jean-François

[Pascal]

yannick wrote:
> - Quelle solution de communication avec le bus avez vous retenue :

Ethernet (N148/21), pour la fiabilité (un switch est moins souvent en
panne qu'un PC) et l'isolation galvanique supplémentaire.

> - Avez vous utilisé le "SDK" Falcon ou avez vous choisie une solution
> de communication bas niveau ?
> - Quel langage avez vous choisi pour développer votre application ?

Je travaille sous Linux avec pour l'instant un eibd modifié et des
shell-scripts.

Applications envisagées:
- Automatismes complexes (par exemple dépendant de données récupérées
sur Internet).
- Contrôle à distance
- Monitoring (voir si les thermostats font bien leur boulot, calculer
les flux thermiques, etc).

linknx et knxweb ont l'air très bien, mais je tiens à mettre les mains
dans le cambouis afin de savoir où sont les difficultés et de pouvoir
juger en connaissance de cause. Et puis mon téléphone mobile ne
supporte pas AJAX

[jef2000]

> Applications envisagées:
> - Automatismes complexes (par exemple dépendant de données récupérées
> sur Internet).
Ca je doit encore l'ajouter, mais ce n'est pas facile trouver une
solution qui couvre tous les cas possibles d'utilisation. Je pense que
je vais commencer par l'HTTP, avec un système à base d'expressions
régulières pour extraire l'info utile des pages.
> - Contrôle à distance
> - Monitoring (voir si les thermostats font bien leur boulot, calculer
> les flux thermiques, etc).
Tu comptes faire du logging et analyser les données a postériori ou
bien avoir une application qui tourne en permanence et qui détecte les
anomalies en temps réel?

> linknx et knxweb ont l'air très bien, mais je tiens à mettre les mains
> dans le cambouis afin de savoir où sont les difficultés et de pouvoir
> juger en connaissance de cause. Et puis mon téléphone mobile ne
> supporte pas AJAX
Le mien non, plus. Pour ça j'ai également une interface plus simple en
PHP avec juste du texte et des liens qui permettent de tout commander.
Je l'utilise sur mon téléphone et le PDA qui sert de télécommande.

A+

Jean-François

[Pascal]

> Tu comptes faire du logging et analyser les données a postériori ou
> bien avoir une application qui tourne en permanence et qui détecte les
> anomalies en temps réel?

Là je pensais surtout à produire des courbes de température sur
plusieurs mois pour étudier le comportement des régulations PID et
autres, mesurer la corrélation entre température extérieure et
consommation de chauffage, etc.

Evidemment ça n'interdit pas d'avoir des alarmes sur seuils pour être
prévenu lorsque les thermostats et/ou les vannes et/ou les relais et/
ou la chaudière sont en panne.