Intégration de modules fait-maison dans une installation KNX

[jef2000]

Bonjour,

Je voudrais avoir votre opinion sur la meilleure manière de gérer la
configuration d'une installation comportant des modules commerciaux et
quelques modules faits-maison.

Etant donné qu'il n'est pas possible (ou en tout cas pas simple) de
créer des fichiers "bases de données produit" pour ETS. Je vois
plusieures solutions:
1) gérer les 2 parties de la config dans 2 outils différents. ETS pour
la partie commerciale et une interface basée sur bcusdk (ou autre)
pour la partie faite maison.
Dans ce cas, on n'a pas vraiment de vue globale de la configuration

2) on peut également tenter d'améliorer la solution 1 en ajoutant des
devices proches de ceux qui sont faits-maison (au niveau des objets de
communication) dans ETS. On ne peut dans ce cas pas les programmer
directement, mais on à une meilleure vue de la config globale et on
peut toujours exporter leur config vers un fichier texte qui pourra
éventuellement être importé par un autre outil pour programmer le
device.

3) reverse-engineerer le format de bases de données ETS au nom du
principe d'interopérabilité et fournir ainsi l'information nécessaire
à d'autres projets pour utiliser les bases de données fournies par les
fabricants de matériel. (si ils ont réussi à forcer Micro$oft à
dévoiler certaines interfaces de son OS au nom de l'interoperabilité,
je ne vois pas pourquoi ETS pourrait se permettre de garder tout le
marché pour lui seul)
A partir du moment ou l'information sur le format des DB produits est
disponible, on pourrait se passer d'ETS et utiliser uniquement d'autre
outils de configuration.
En fait, il suffirait que tous les fabricants fournissent une spec de
leurs produit en expliquant ce qu'il faut aller changer où dans la
mémoire du device pour modifier les paramètres de celui-ci.
Bien sûr, pour un installateur, il sera toujours plus intéressant
d'utiliser ETS et profiter de la garantie qu'offre l'association
konnex que tous le matériel et logiciel utilisé à été testé et agréé
par eux, mais pour les particuliers qui en font un hobby, ça ouvre la
voie a de nombreuses possibilités supplémentaire.

Qu'en pensez vous?

Jean-François

[Dfrog]

> 3) reverse-engineerer le format de bases de données ETS au nom du
> principe d'interopérabilité et fournir ainsi l'information nécessaire
> à d'autres projets pour utiliser les bases de données fournies par les
> fabricants de matériel. (si ils ont réussi à forcer Micro$oft à
> dévoiler certaines interfaces de son OS au nom de l'interoperabilité,
> je ne vois pas pourquoi ETS pourrait se permettre de garder tout le
> marché pour lui seul)

Salut Jf,

il y a tout de même une différence de taille entre Microsoft et KNX:
Microsoft est propriétaire, KNX ne l'est pas ! Ce n'est pas KNX (ou
ETS) qui est visé par ton idée, mais tous les fabricants qui se
rendent compatible avec la norme KNX. Immagine un peu si tu fais la
même proposition pour IP... tu voudrais que tous les fabricants qui
proposent des produits avec la technologie IP te fournissent gratos
leurs spec ? ...

Il faut faire la différence entre la propriété intelectuelle d'un
fabricant face à ses produits, et la liberté de dévelloper ses
produits ou soft sous une technologie normalisée. L'interopérabilité,
tu l'as déjà avec la norme KNX. Pourquoi vouloir recopier ce que fait
un constructeur ? C'est précisément la richesse de KNX que de laisser
libre chaque constructeur nous offrir ce qu'il sait faire de mieux.
Perso, je n'aimerais pas un monde KNX avec 20'000 produits qui font
tous la même chose de la même manière...

Question complémentaire : une fois que tu a passé 15 mois à dévelloper
un produits KNX et que tu auras dépensé toutes tes économies pour
cela, serais-tu d'accord de partager gratuitement tes sources ?
particulièrement si c'est ton gagne-pain ?

Une bonne idée trouvera toujours un marché. Si en plus c'est pour KNX,
le succès est assuré ;-))

[jef2000]

> il y a tout de même une différence de taille entre Microsoft et KNX:
> Microsoft est propriétaire, KNX ne l'est pas ! Ce n'est pas KNX (ou
> ETS) qui est visé par ton idée, mais tous les fabricants qui se
> rendent compatible avec la norme KNX. Immagine un peu si tu fais la
> même proposition pour IP... tu voudrais que tous les fabricants qui
> proposent des produits avec la technologie IP te fournissent gratos
> leurs spec ? ...
Bonjour,

Ma réflexion ne portait pas sur le standard KNX mais sur le monopole
sur le logiciel de configuration de l'installation que garde
jalousement l'association Konnex. C'est un peu comme si le fabricant
de ton modem ADSL t'obligeait à acheter un programme à une autre
société pour pouvoir en configurer l'adresse IP.

> Il faut faire la différence entre la propriété intelectuelle d'un
> fabricant face à ses produits, et la liberté de dévelloper ses
> produits ou soft sous une technologie normalisée. L'interopérabilité,
> tu l'as déjà avec la norme KNX. Pourquoi vouloir recopier ce que fait
> un constructeur ? C'est précisément la richesse de KNX que de laisser
> libre chaque constructeur nous offrir ce qu'il sait faire de mieux.
> Perso, je n'aimerais pas un monde KNX avec 20'000 produits qui font
> tous la même chose de la même manière...
Il n'est aucunement question de recopier ce que fait un autre
fabricant, le format des bases de données ETS que j'aimerais voir
publier n'a rien à voir avec le code source des application
développées par les fabricants. Il est évident que chaque constructeur
à le droit de protéger sa propriété intellectuelle.
De ce que j'en sais, les fichiers DB ETS contiennent juste une image
binaire de la mémoire du device et les informations décrivant ce qu'il
faut modifier à quel endroit pour modifier les paramètres de
l'application.


> Question complémentaire : une fois que tu a passé 15 mois à dévelloper
> un produits KNX et que tu auras dépensé toutes tes économies pour
> cela, serais-tu d'accord de partager gratuitement tes sources ?
> particulièrement si c'est ton gagne-pain ?
Comme expliqué plus haut, il n'a jamais été question de partager les
sources, juste de donner la possibilité aux utilisateurs de configurer
les appareils qu'ils ont achetés.

A+

Jean-François

[Dfrog]

> Bonjour,
>
> Ma réflexion ne portait pas sur le standard KNX mais sur le monopole
> sur le logiciel de configuration de l'installation que garde
> jalousement l'association Konnex. C'est un peu comme si le fabricant
> de ton modem ADSL t'obligeait à acheter un programme à une autre
> société pour pouvoir en configurer l'adresse IP.

Le vrais problème, avouons-le, n'est pas sur le principe d'une
organiation faîtière pour le standard KNX, mais sur le prix du
logiciel en question ;-). Ce prix est, je suis d'accord, trop élevé.
Mais il ne faut pas non plus vouloir le beurre, l'argent du beurre, et
le fil à couper le beurre ! KNX est un protocol ouvert et rien de
t'empêche de dévelloper une autre manière d'attaquer le protocole,
preuve en est le nouveau router IP de Normelec, et les prochains
produits KNX qui pourront être IP full. Mais, depuis la nuit des
temps, tout effort de dévelloppement n'est pas gratuit. Les sources du
protocole KNX sont disponibles pour tous, les royalties, même si elles
sont élevées pour tout un chacun, sont là non pour faire de KNX un
nouveau Microsoft, mais au contraire pour que KNX reste fiable, malgré
la toujours plus grande quantité de constructeurs et produits qui
tournent sur ce protocole. Ce n'est pas une mince affaire, et ça coûte
aussi !

Clin d'oeil : KNX est en train de réussir ce que Apple a raté en
informatique: faire un système robuste et fiable, et en faire un
standard normalisé pour qu'il soit disponible au plus grand nombre.

>
> Il n'est aucunement question de recopier ce que fait un autre
> fabricant, le format des bases de données ETS que j'aimerais voir
> publier n'a rien à voir avec le code source des application
> développées par les fabricants. Il est évident que chaque constructeur
> à le droit de protéger sa propriété intellectuelle.
> De ce que j'en sais, les fichiers DB ETS contiennent juste une image
> binaire de la mémoire du device et les informations décrivant ce qu'il
> faut modifier à quel endroit pour modifier les paramètres de
> l'application.
>
Perso, je préfère que KNX garde jalousement ses sources ETS , afin
d'éviter précisément ce qui se passe dans le monde de l'informatique :
des produits IP ou autres développés "à la pelle" et "au rabais" qui
ne fonctionnent que les années bissextiles, quand tout va bien ! avec
des connexions Internet dont la fiabilité nous donnent l'occasion de
faire de fréquentes pauses-café... ;-))

[jef2000]

> Le vrais problème, avouons-le, n'est pas sur le principe d'une
> organiation faîtière pour le standard KNX,
C'est exactement ce que je viens de dire.
> mais sur le prix du
> logiciel en question ;-). Ce prix est, je suis d'accord, trop élevé.
Justement, ce prix élevé est la conséquence du fait qu'il n'y a pas de
concurrence pour ETS
Si un concurrent veut développer son propre outil de config, il à le
choix entre 2 solutions:
1) "créer un outil qui ne fonctionne qu'avec ses propres produits" et
on tombe dans un système à la TX100 pour lequel on perds tous les
avantages du KNX puisqu'on est limité à une marque.
2) convaincre tous les fabricants de lui fournir des DB de produits
similaires à celles d'ETS, mais dans son propre format puisque celui
d'ETS n'est pas publique. Premièrement c'est un peu stupide puisque ça
obligerait chaque fabricant à fournir ses DB dans plusieurs formats,
ensuite je pense qu'il y a peu de chances que ces concurrents
potentiels arrivent à convaincre tous les fabricants.
==> Donc la concurrence qui obligerait ETS à revoir le prix de son
logiciel à la baisse et qui le pousserait à l'innovation pour défendre
ses parts de marché n'est pas possible tant que le format des DB
n'est pas publique.

> Mais il ne faut pas non plus vouloir le beurre, l'argent du beurre, et
> le fil à couper le beurre ! KNX est un protocol ouvert et rien de
> t'empêche de dévelloper une autre manière d'attaquer le protocole,
> preuve en est le nouveau router IP de Normelec, et les prochains
> produits KNX qui pourront être IP full. Mais, depuis la nuit des
> temps, tout effort de dévelloppement n'est pas gratuit.
La question n'est pas de savoir si c'est gratuit ou pas gratuit. C'est
de savoir si c'est possible ou pas possible.

> Les sources du
> protocole KNX sont disponibles pour tous, les royalties, même si elles
> sont élevées pour tout un chacun, sont là non pour faire de KNX un
> nouveau Microsoft, mais au contraire pour que KNX reste fiable, malgré
> la toujours plus grande quantité de constructeurs et produits qui
> tournent sur ce protocole. Ce n'est pas une mince affaire, et ça coûte
> aussi !
Justement, pour reprendre ton exemple de Microsoft, c'est depuis que
la concurrence des OS libres à réellement démarré que Microsoft a
progressé le plus en matière de sécurité et de fiabilité.

> Perso, je préfère que KNX garde jalousement ses sources ETS , afin
> d'éviter précisément ce qui se passe dans le monde de l'informatique :
> des produits IP ou autres développés "à la pelle" et "au rabais" qui
> ne fonctionnent que les années bissextiles, quand tout va bien ! avec
> des connexions Internet dont la fiabilité nous donnent l'occasion de
> faire de fréquentes pauses-café... ;-))
Avec cette approche, on pourrait purement et simplement interdire tous
les produits bas-de-gamme. Si ils existent, c'est parce qu'il y a une
demande de la part des clients.
Moi je suis pour donner le choix au client de déterminer jusqu'ou il
est disposé à payer plus pour avoir mieux.

Et puis on s'éloigne du problème initial. Si je développe mes propres
programmes qui tournent sur des BCU2 en utilisant bcusdk, je peux les
programmer et les configurer uniquement avec bcusdk. Pour le reste de
la configuration, je peux le faire uniquement avec ETS et il ne m'est
donc pas possible de gérer la configuration complète à l'aide d'un
seul outil.


A+

Jean-François

[Pascal]

On May 30, 10:47 am, jef2000 <jef2...@ouaye.net> wrote:
> Si un concurrent veut développer son propre outil de config, il à le
> choix entre 2 solutions:
> 1) "créer un outil qui ne fonctionne qu'avec ses propres produits" [...]
> 2) convaincre tous les fabricants de lui fournir des DB de produits
> similaires à celles d'ETS, mais dans son propre format puisque celui
> d'ETS n'est pas publique. [...]

La situation est-elle si dramatique ? En achetant le SDK pour
constructeurs de knx.org, n'a t-on pas accès au format des DB ?
http://www.knx.org/knx-tools/manufacture...scription/
http://www.knx.org/knx-tools/manufacture.../features/
Je lis notamment :
> Translation Import/Export function: this makes it possible to export
> product data as text files (csv) and to import them again after translation.

Par ailleurs ce format n'est-il pas spécifié dans le KNX Handbook ?
(Après avoir dépensé plusieurs centaines d'euros en spécifications
EN 50090 qui se sont révélées complètement inutiles, je n'ai pas
l'intention d'acheter le Handbook pour vérifier...)

[jef2000]

> La situation est-elle si dramatique ? En achetant le SDK pour
> constructeurs de knx.org, n'a t-on pas accès au format des DB ?http://www.knx.org/knx-tools/manufacturer-tool/description/http://www.knx.org/knx-tools/manufacturer-tool/features/
Bonjour,

En achetant le SDK, tu auras juste le droit d'utiliser leur boite-
noire pour créer tes propres DB et ensuite, ça te donnera le droit de
payer encore plus cher pour les faire certifier avant de pouvoir les
utiliser dans ETS.
Je ne pense pas qu'un particulier qui développe ces propres modules à
les budgets pour s'offrir ce genre de choses.

> Je lis notamment :
>
> > Translation Import/Export function: this makes it possible to export
> > product data as text files (csv) and to import them again after translation.
Ca c'est juste pour pouvoir traduire le texte qui apparaît dans ETS en
différentes langues.

> Par ailleurs ce format n'est-il pas spécifié dans le KNX Handbook ?
Ca m'étonnerait, mais comme je ne l'ai pas, je ne peut pas le jurer.


A+

Jean-François

[fred]

* Les outils nécéssaires pour créer une DB ETS sont fournis aux
fabriquants de matériel KNX. Pas la spec, l'outil.

* Le cout pour obtenir des outils et les specs sont très acceptables
pour toute utilisation pro (même commentaire pour ETS lui-même).

* Les fabriquants membres peuvent obtenir de l'info pour s'interfacer
avec ETS, p.ex. obtenir une liste de GA pour un projet - je veux dire
par la que KNX semble d'accord de dévoiler les "secrets" d'ETS pour
les partenaires.

* Il n'est pas dans l'intéret de KNX de laisser de développer un
marché de l'ETS -> cela induirait une confusion qui irait à l'encontre
de l'objectif de diffusion la plus large possible chez les
électriciens.

Il est vrai que cette méthode ne laisse pas de place aux amateurs.
Dommage. Mais en gardant ETS propriétaire et en testant soigneusement
tous les modules, l'association KNX obtient une solution ouverte,
solide et stable qu'elle peut promouvoir de manière claire auprès des
installateurs électriciens, éléments clefs pour vendre KNX, mais pas
vraiment informaticiens et geeks. En deux mots, leur méthode maximise
la qualité et minimise l'entropie.

Fred

[keldo]

Utiliser le SDK "manufacturer" d'ETS signifie l'acheter ($$$) et aussi
se faire membre de l'assoc. KNX ($$$$). C'est tout simplement
inabordable pour un particulier !
Alors, à moins de trouver un généreux mécène, la seule solution pour
suivre cette voie là, c'est de se regrouper pour payer ensemble, et
pour cela il faudrait une masse critique d'au minimum 10 à 15
personnes motivées par l'idée de développer leurs propres modules EIB.
Jusqu'ici, sur le forum, j'en vois 4 ou 5 intéressées par l'idée, mais
je ne suis même pas sur qu'elles seraient près à y investir disons 300
euros chacune ... et il en manquerait encore une dizaine.
Mais, c'est certain, c'est la voie la plus "propre".

Maintenant, je vois plusieurs autres solutions.

1) Basys2003 (http://www.basys2003.org)
C'est un logiciel open source développé pour pouvoir remplacer ETS.
En principe, il possède certaines capacités à importer les
fichiers .vdx (les DB).
A tester.
Mais si cela fonctionne, il y a moyen de :
- soit se passer de ETS
- soit lire le code source pour comprendre la structure des
fichiers .vdx
- soit contacter les développeurs de Basys2003 pour qu'ils nous
donnent l'info qu'ils possèdent sur le format des fichiers .vdx
- soit une combinaisons de tout cela

2) Sachant que le logiciel SGBD sur lequel s'appuie ETS est Sybase SQL
Anywhere, on peut tenter de faire un petit peu de reverse engineering
et de comprendre le format .vdx.

3) Pour certains types de modules, on peut tenter une approche "à la
Freebus", c'est à dire de faire en sorte que le module "maison" simule
le comportement d'un module commercial existant ; il suffit alors de
mettre dans ETS la base de donnée du module existant simulé.
Cette méthode est néanmoins limitative, car elle ne convient pas pour
les modules maisons basés sur un BCU ou un BIM "officiel" (rien que le
"vendor ID" poserait déjà problème ...) ; et de plus il n'est pas
possible d'utiliser cette méthode pour les modules maisons qui
n'auraient pas d'équivalent dans la gamme de produits officiels (par
exemple un module "gestion de sauna + hamam" avec 8 capteurs de
température, 6 capteurs d'humidité, 4 entrées binaires SELV, 4 sorties
binaires 16AC et 2 sorties PWM 24V --- une pure invention de ma
part ...).

4) On peut lancer, en temps que "user group" un lobbying intense sur
l'association KNX afin qu'elle baisse les prix pour les particuliers
et initiatives privées.

5) On peut tenter de s'associer avec une des différentes écoles et
universités qui proposent KNX dans leur programme d'étude et ont de ce
fait accès aux outils et informations en temps que "KNX scientific
partner".

6) On peut tenter de s'associer avec un petit fabricant de modules KNX
"officiel", dans le cadre d'un échange "donnant donnant", du style
"ils peuvent utiliser et vendre une partie de nos idées et, en
échange, ils nous laissent accès à leurs outils KNX officiels et
payent pour la certification de nos modules les plus aboutis".

Mais dans tous les cas; je pense qu'il est urgent d'apprendre
l'allemand afin de pouvoir dialoguer avec nos amis germaniques qui se
sont surement déjà posé la question avant nous !