Bonjour,
Cherchant une alternative à ETS pour le paramétrage de mon
installation, je m'interesse à EIBD et au BCU SDK.
Après pas mal d'heures de recherche, il me semble que EIBD ne peut pas
permettre le paramètrage d'une installation KNX, on peut l'utiliser
pour superviser une installation, mais quant est il du paramètrage des
BCU ?
Ne me dites pas que l'on est obligé d'utiliser ETS ?!
Merci d'avance :-)
Thierry
> Cherchant une alternative à ETS pour le paramétrage de mon
> installation
Il y a quelques anciens fils dans lesquels ce sujet est discuté ad
nauseam - je te propose un peu plus de recherche  sur ce forum et de
lire les messages en question
> Ne me dites pas que l'on est obligé d'utiliser ETS ?!
Oui, on est obligé. Il n'y a pas d'autre solution "générale" - en
particulier car les fabriquants livrent leurs données de paramétrage
au format ("propriétaire") ETS. Donc il possible de fabriquer un
machin pour configurer des modules "open source" ou "home made", mais
pour les modules commerciaux, ca le fait pas. Utilité limité donc.
La question subsidiaire - celle qui déchaine les passions - est "et
alors ?". Car en fin de compte, pour un particulier:
* ETS est fiable et solide
* Son prix est raisonable en rapport au montant total investi en
équipement EIB, électricité, bâtiment
* Une fois le bus mis en service, l'usage d'ETS est très épisodique
Restent des considérations philosophiques sur le logiciel libre, la
gratuité, le choc insurmontable pour un particulier de planter 1000e
dans un logiciel, le fait qu'ETS tourne pas sur Leopard ou Linux, etc.
En fin de compte, tous les utilisateurs de EIB utilisent ETS -
certains sont heureux de cet état de fait et d'autres moins.
Si utiliser ETS est exclu, alors il faut se tourner vers des solutions
plus ouvertes comme X10/LON/INSTEON...
Fred
Il existe une alternative, c'est BASyS 2003 http://www.auto.tuwien.ac.at/~oalt/basys/
Malheureusement ce projet n'est pas fini et surtout n'est pas suivi
par les fabricants pour fournir des bases de données produits sous
format non proprio (.xml)
@+
On 23 sep, 10:25, Geb07 <t.gebe...@laposte.net> wrote:
> Bonjour,
>
> Cherchant une alternative à ETS pour le paramétrage de mon
> installation, je m'interesse à EIBD et au BCU SDK.
> Après pas mal d'heures de recherche, il me semble que EIBD ne peut pas
> permettre le paramètrage d'une installation KNX, on peut l'utiliser
> pour superviser une installation, mais quant est il du paramètrage des
> BCU ?
> Ne me dites pas que l'on est obligé d'utiliser ETS ?!
> Merci d'avance :-)
> Thierry
On 23 sep, 13:16, fred <frederic.thomas...@gmail.com> wrote:
> > Cherchant une alternative à ETS pour le paramétrage de mon
> > installation
>
> Il y a quelques anciens fils dans lesquels ce sujet est discuté ad
> nauseam - je te propose un peu plus de recherche sur ce forum et de
> lire les messages en question
>
Je les ai lu...
> > Ne me dites pas que l'on est obligé d'utiliser ETS ?!
>
> Oui, on est obligé. Il n'y a pas d'autre solution "générale" - en
> particulier car les fabriquants livrent leurs données de paramétrage
> au format ("propriétaire") ETS. Donc il possible de fabriquer un
> machin pour configurer des modules "open source" ou "home made", mais
> pour les modules commerciaux, ca le fait pas. Utilité limité donc.
>
Ils pratiquent effectivement une politique de monopole, grand bien
leur fasse, mais je pense pas que cela soit bénéficiable au standard
KNX.
> La question subsidiaire - celle qui déchaine les passions - est "et
> alors ?". Car en fin de compte, pour un particulier:
> * ETS est fiable et solide
> * Son prix est raisonable en rapport au montant total investi en
> équipement EIB, électricité, bâtiment
> * Une fois le bus mis en service, l'usage d'ETS est très épisodique
>
> Restent des considérations philosophiques sur le logiciel libre, la
> gratuité, le choc insurmontable pour un particulier de planter 1000e
> dans un logiciel, le fait qu'ETS tourne pas sur Leopard ou Linux, etc.
>
Ce ne sont pas des considérations philosophiques pour moi, dépenser
1000€ représente le quart de mon budget pour la domotique, cela est
donc loin d'être négligeable, je ne trouve donc pas leur tarif
raisonnable pour un particulier.
Je ne demande pas la gratuité mais simplement une politique de licence
ouverte à tous, aux particuliers, comme aux professionnels.
Cordialement,
Thierry
On 23 sep, 13:17, mickg <mickael.gaut...@wanadoo.fr> wrote:
> Il existe une alternative, c'est BASyS 2003http://www.auto.tuwien.ac.at/~oalt/basys/
>
> Malheureusement ce projet n'est pas fini et surtout n'est pas suivi
> par les fabricants pour fournir des bases de données produits sous
> format non proprio (.xml)
>
> @+
>
C'est effectivement dommage, mais cela ne m'étonne pas trop que les
fabricants ne veuillent pas créer de base de données au format XML.
Je me demande ce qu'il y a dans ces bases de données...
Cordialement,
Thierry
> C'est effectivement dommage, mais cela ne m'étonne pas trop que les
> fabricants ne veuillent pas créer de base de données au format XML.
> Je me demande ce qu'il y a dans ces bases de données...
Ca, c'est assez facile à deviner :
Pour les modules EIB "simples".
-----------------------------------------------
- le code objet de/des l'application(s) destinée(s) au module.
- un applet windows s'intégrant dans ETS pour la configuration des
différents paramètres de(s) l'application(s).
- un tableau expliquant à ETS quels bytes il doit modifier dans le
code objet de chaque application pour l'adapter selon les paramètres
choisis par le configurateur via l'applet citée ci-avant.
- une "carte de la mémoire" du module pour expliquer à ETS comment et
où programmer le code de l'application, les adresses de groupe, les
communication flags, ... dans le module.
- les différents codes "ID fabricant", "ID application", "ID modèle du
module", etc. pour permettre à ETS de vérifier que le hardware qu'il
va programmer convient pour l'application choisie.
- diverses infos permettant le classement cette / ces application(s)
dans la base de données générale de ETS.
Pour les modules EIB "complexes".
---------------------------------------------------
En gros, la même chose que pour les modules simples, sauf que l'applet
est remplacé par un plug-in plus complet qui possède sa propre
interface graphique de configuration ainsi que, généralement, une
routine autonome de programmation du module EIB complexe, qui "discute
en direct" avec le module plutôt que laisser ETS faire la
programmation. C'est nécessaire car le processeur au cœur des ces
modules complexes n'a généralement rien à voir avec les cœurs de BCU1
et BCU2.
Pour les modules simples, en théorie, un "sniffer" sur le bus EIB et
un travail de Bénédictin devrait permettre de retrouver toutes les
informations nécessaires à la réalisations de "base de données" pour
Basys2003, mais ... on manque de Bénédictins bénévoles, disponibles et
maitrisant bien le sujet. ;-)
Pour les modules complexes, c'est totalement à la discrétion des
fabricants ... jusqu'au jour où l'OS de ces modules complexes sera un
petit Linux et alors ... 8-))
> Je me demande ce qu'il y a dans ces bases de données...
Les fichiers XML sont le résultat de la traduction des bases de
données ETS dans un format défini par Basys2003.
Les bases ETS sont des fichiers zippés avec mot de passe qui
contiennent un fichier ayant l'extension "vd_". Ce dernier est un
fichier texte contenant entre autres les image mémoires pour
programmer les BCU, les paramètres modifiables dans ETS et l'endroit
ou il faut aller patcher les images mémoires pour que le paramètres
soit modifié dans le BCU.
Comment récupérer les fichiers vd_ sans avoir le mot de passe:
http://groups.google.be/group/domotique-...c3afb8617f
A+
Jean-François
On 23 sep, 16:55, keldo <kelderm...@ibelgique.com> wrote:
> > C'est effectivement dommage, mais cela ne m'étonne pas trop que les
> > fabricants ne veuillent pas créer de base de données au format XML.
> > Je me demande ce qu'il y a dans ces bases de données...
>
> Ca, c'est assez facile à deviner :
>
> Pour les modules EIB "simples".
> -----------------------------------------------
> - le code objet de/des l'application(s) destinée(s) au module.
> - un applet windows s'intégrant dans ETS pour la configuration des
> différents paramètres de(s) l'application(s).
> - un tableau expliquant à ETS quels bytes il doit modifier dans le
> code objet de chaque application pour l'adapter selon les paramètres
> choisis par le configurateur via l'applet citée ci-avant.
> - une "carte de la mémoire" du module pour expliquer à ETS comment et
> où programmer le code de l'application, les adresses de groupe, les
> communication flags, ... dans le module.
> - les différents codes "ID fabricant", "ID application", "ID modèle du
> module", etc. pour permettre à ETS de vérifier que le hardware qu'il
> va programmer convient pour l'application choisie.
> - diverses infos permettant le classement cette / ces application(s)
> dans la base de données générale de ETS.
>
> Pour les modules EIB "complexes".
> ---------------------------------------------------
> En gros, la même chose que pour les modules simples, sauf que l'applet
> est remplacé par un plug-in plus complet qui possède sa propre
> interface graphique de configuration ainsi que, généralement, une
> routine autonome de programmation du module EIB complexe, qui "discute
> en direct" avec le module plutôt que laisser ETS faire la
> programmation. C'est nécessaire car le processeur au cœur des ces
> modules complexes n'a généralement rien à voir avec les cœurs de BCU1
> et BCU2.
>
Merci pour tous ces renseignements, cela rassasie un peu ma
curiosité. :-)
> Pour les modules simples, en théorie, un "sniffer" sur le bus EIB et
> un travail de Bénédictin devrait permettre de retrouver toutes les
> informations nécessaires à la réalisations de "base de données" pour
> Basys2003, mais ... on manque de Bénédictins bénévoles, disponibles et
> maitrisant bien le sujet. ;-)
> Pour les modules complexes, c'est totalement à la discrétion des
> fabricants ... jusqu'au jour où l'OS de ces modules complexes sera un
> petit Linux et alors ... 8-))
Surement et je comprend fort bien, j'ai déjà passé pas mal d'années à
développer un logiciel de gestion. bien content d'avoir terminé et
d'avoir cesser de passer des heures et des heures le matin ou le soir
ainsi qu'une partie du week end.
Surtout qu'il faut être certain d'aboutir.
Dommage que le site de Basys est en allemand car moi pas connaitre
malheureusement leur langue. :-)
> on manque de Bénédictins bénévoles, disponibles et
> maitrisant bien le sujet. ;-)
Pas étonnant. ETS ce n'est pas Firefox. Faire le bénédictin pour avoir
la satisfaction *une fois par an* d'avoir pourfendu d'une ligne de XML
les volontés soit disant monopolistiques de KNX, c'est pas bien payé.
Fred
On 23 sep, 20:16, fred <frederic.thomas...@gmail.com> wrote:
> > on manque de Bénédictins bénévoles, disponibles et
> > maitrisant bien le sujet. ;-)
>
> Pas étonnant. ETS ce n'est pas Firefox. Faire le bénédictin pour avoir
> la satisfaction *une fois par an* d'avoir pourfendu d'une ligne de XML
> les volontés soit disant monopolistiques de KNX, c'est pas bien payé.
>
> Fred
Et bien être le seul à proposer un logiciel permettant de paramétrer
tous les participants de KNX, je suis désolé mais c'est être en
situation de monopole.
Mais bon, je ne cherche pas du tout à polémiquer, c'est simplement que
je suis trés déçu, cela fait 25 ans que je suis intéressé par la
domotique, auparavent, il n'y avait que des systèmes propriétaires qui
ne garantissaient aucune pérennité des produits.
KNX est une superbe idée et un super standard, garantissant beaucoup
d'avantages, lorsque j'en ai entendu parler, j'ai cru qu'enfin on
allait voir plus de domotique à l'intérieur de nos maisons, mais je
crains bien que ce ne soit pas encore le cas...
J'aurais aimé que ce standard ouvre ces specs au domaine publique,
cela amènerait plus de concurrence et en même temps, ils pourraient
continuer à vendre leur certification afin qu'ils puissent continuer à
vivre et faire évoluer le standard.
A l'heure ou l'immobilier connait sa plus forte hausse ou le pouvoir
d'achat est en baisse, la domotique ne peut être vu que comme un
gadget pour les plus fortunés ou pour les passionés que nous sommes.
Thierry
|
