Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Problème pour passer de Merten à Schneider
#1
Bonjour,

J'ai des BP Merten que j'ai programmé à partir
de vdb Merten (en utilisant la langue Anglaise).
Récemment, tout content de trouver des vdb en
français sur le site Schneider France, je les
rapatrie.
Mais là, déception, quand je veux télécharger
le programme sur mes BP, bien que les versions
du programme d'application soient bien les mêmes,
il refuse, car le "code fabricant" est différent
(Merten <> Schnedeir Electric ...)

J'ai le vague souvenir d'avoir vus un fil où on parlait
de la manière de changer ce code fabricant,
mais plus moyen de le retrouver :o(

Help...

Bruno
#2
On 20 jan, 09:29, bde <bruno.delco...@fundp.ac.be> wrote:
> J'ai le vague souvenir d'avoir vus un fil où on parlait
> de la manière de changer ce code fabricant,
> mais plus moyen de le retrouver :o(

Voir les post de Keldo, mot clé: SDK

" This re-programming is normally possible with the BCU-SDK (free
software) but
I never did it myself. -"
#3
> " This re-programming is normally possible with the BCU-SDK (free
> software) but
> I never did it myself. -"

J'ai un petit peu feuilleté la doc du BCU-SDK, et on ne peut pas dire
que cela s'adresse au profane ... il y a peut-être moyen de faire plus
simple.

En gros, tout ce qu'il faut, c'est :
1) Trouver un moyen technique d'écrire un télégramme "arbitraire/
quelconque" sur le bus (et pas seulement vers une adresse de groupe),
en principe il devrait y a voir moyen de faire cela avec le driver
"eibd" sous linux. Personellement, j'essaye de le faire faire par un
microcontroleur.
2) Envoyer un télégramme "ouverture de session" vers le device Merten.
3) Envoyer les télégrammes "écriture dans la mémoire EEPROM" à la
bonne adresse mémoire et avec les bons ID vendeur/fabriquant et ID de
modèle.
4) Envoyer un télégramme "fermeture de session" vers le device Merten.

Le contenu des télégrammes nécessaires est calculable sur base de la
doc librement disponible sur le net, voir à ce sujet un de mes posts
dans la discussion "développement de module à base de PIC", 3ième ou
4ième page je crois.

Cette méthode devrait fonctionner mais UNIQUEMENT avec les module
utilisant un coupleur de bus "classique" BCU1 ou BCU2, donc les Merten
6900-99 et 6902-99.


Une autre méthode est evisageable : modifier le fichier .vd3/4 pour y
mettre les ID des appareils Merten à la place des Schneider. Le
provblème est de "rentrer" dans le fichier .vd3/4 qui est plus ou
moins verrouillé.
Une variante est sans doute plus facile : la base de donnée "générale"
du projet en ETS est gèrée par un moteur Sybase SQL anywhere version
8, donc, à l'aide d'une version complète de Sybase SQL Anywhere 8, il
est sans doute possible d'adapter certaines valeur plus facilement.


Attention, toutes ces méthodes restent du "bidouillage" de haut vol,
au risques et périls de celui ou celle qui désire l'appliquer, la
seule bonne méthode officielle et sans risque étant de faire le siège
du service clientèle des sociétés concernées (Merten et Schneider dans
ce cas-ci) en exigeant de leur part une traduction des bases de
données dans toutes les langues pour tous leurs appareils ...

P.S. : Si quelqu'un applique une des méthodes décrite, je suis
intéressé par les commentaires et le résultat éventuel.
#4
Mes BP sont des modèle 628xxx (avec BCU intégrée).
Ce qui me laisse perplexe, c'est que cela concerne le même
produit.
Si chaque fois qu'un firme se fait racheter, cet ID change,
bonjour les dégats...
Donc, si je comprends bien, il suffirait à Schneider de mettre à dispo
une version des fichiers .vd3/4 avec l'ID Merten.
Je m'en vais leur envoyer un email, et je vous
tiens au courant de l'éventuelle réponse.

En tout cas, grand merci pour la clarté de vos réponses.

Bruno

P.S: Existe-t-il une doc donnant le format des fichiers .vd3/4?

On 20 jan, 14:43, keldo <kelderm...@ibelgique.com> wrote:
> > " This re-programming is normally possible with the BCU-SDK (free
> > software) but
> > I never did it myself. -"
>
> J'ai un petit peu feuilleté la doc du BCU-SDK, et on ne peut pas dire
> que cela s'adresse au profane ... il y a peut-être moyen de faire plus
> simple.
>
> En gros, tout ce qu'il faut, c'est :
> 1) Trouver un moyen technique d'écrire un télégramme "arbitraire/
> quelconque" sur le bus (et pas seulement vers une adresse de groupe),
> en principe il devrait y a voir moyen de faire cela avec le driver
> "eibd" sous linux. Personellement, j'essaye de le faire faire par un
> microcontroleur.
> 2) Envoyer un télégramme "ouverture de session" vers le device Merten.
> 3) Envoyer les télégrammes "écriture dans la mémoire EEPROM" à la
> bonne adresse mémoire et avec les bons ID vendeur/fabriquant et ID de
> modèle.
> 4) Envoyer un télégramme "fermeture de session" vers le device Merten.
>
> Le contenu des télégrammes nécessaires est calculable sur base de la
> doc librement disponible sur le net, voir à ce sujet un de mes posts
> dans la discussion "développement de module à base de PIC", 3ième ou
> 4ième page je crois.
>
> Cette méthode devrait fonctionner mais UNIQUEMENT avec les module
> utilisant un coupleur de bus "classique" BCU1 ou BCU2, donc les Merten
> 6900-99 et 6902-99.
>
> Une autre méthode est evisageable : modifier le fichier .vd3/4 pour y
> mettre les ID des appareils Merten à la place des Schneider. Le
> provblème est de "rentrer" dans le fichier .vd3/4 qui est plus ou
> moins verrouillé.
> Une variante est sans doute plus facile : la base de donnée "générale"
> du projet en ETS est gèrée par un moteur Sybase SQL anywhere version
> 8, donc, à l'aide d'une version complète de Sybase SQL Anywhere 8, il
> est sans doute possible d'adapter certaines valeur plus facilement.
>
> Attention, toutes ces méthodes restent du "bidouillage" de haut vol,
> au risques et périls de celui ou celle qui désire l'appliquer, la
> seule bonne méthode officielle et sans risque étant de faire le siège
> du service clientèle des sociétés concernées (Merten et Schneider dans
> ce cas-ci) en exigeant de leur part une traduction des bases de
> données dans toutes les langues pour tous leurs appareils ...
>
> P.S. : Si quelqu'un applique une des méthodes décrite, je suis
> intéressé par les commentaires et le résultat éventuel.
#5
On 20 jan, 15:06, bde <bruno.delco...@fundp.ac.be> wrote:
> Ce qui me laisse perplexe, c'est que cela concerne le même
> produit.
En effet, il y a de quoi. Même si Schneider avait cet ID avant le
rachat, ils n'avaient aucune raison de l'appliquer. C'est donc une
décision délibérée de se démarquer.

> Si chaque fois qu'un firme se fait racheter, cet ID change,
> bonjour les dégats...
Je me suis fait exactement la même remarque.

> Je m'en vais leur envoyer un email, et je vous
> tiens au courant de l'éventuelle réponse.
Ca m'étonnerais fort que tu arrives à quoi que ce soit, on touche ici
à des arguments qui n'ont plus rien à voir avec la technique KNX.
Perso, je n'ai jamais rien pu tirer de Schneider, ils ne se donnent
pas la peine de répondre.
Peut-être que tu as plus de chances chez Merten, encore que .... mais
enfin, mon expérience avec le support est très positive (Dieu sait que
je leur ai cassé les pieds.... )

Infoline@merten.de

> Existe-t-il une doc donnant le format des fichiers .vd3/4?
Je pense que non.
J'ai quelques fois vu des demandes dans ce sens, avec toujours les
même bête réponses
"vous n'avez pas besoin de çà",
"yaka employer ETS"

Peut-être que un des martiens spéce (variante bleue, à fleurs rose
fluo) peut nous bidouiller une solution ? .... de préférence sous
Windows ?
#6
Mmouais...
Moi qui suis plutôt familier des approches "open source",
ici (je veux dire avec certaines marques) nous sommes vraiment aux
antipodes.

Bruno

(qui reste convaincu que "l'union fait la force" - ce groupe de
discussion en est d'ailleurs
une belle preuve - vive les martiens! ;o)

On 20 jan, 16:07, Marc Assin <raym...@warichet.com> wrote:
> On 20 jan, 15:06, bde <bruno.delco...@fundp.ac.be> wrote:> Ce qui me laisse perplexe, c'est que cela concerne le même
> > produit.
>
> En effet, il y a de quoi. Même si Schneider avait cet ID avant le
> rachat, ils n'avaient aucune raison de l'appliquer. C'est donc une
> décision délibérée de se démarquer.
>
> > Si chaque fois qu'un firme se fait racheter, cet ID change,
> > bonjour les dégats...
>
> Je me suis fait exactement la même remarque.
>
> > Je m'en vais leur envoyer un email, et je vous
> > tiens au courant de l'éventuelle réponse.
>
> Ca m'étonnerais fort que tu arrives à quoi que ce soit, on touche ici
> à des arguments qui n'ont plus rien à voir avec la technique KNX.
> Perso, je n'ai jamais rien pu tirer de Schneider, ils ne se donnent
> pas la peine de répondre.
> Peut-être que tu as plus de chances chez Merten, encore que .... mais
> enfin, mon expérience avec le support est très positive (Dieu sait que
> je leur ai cassé les pieds.... )
>
> Infol...@merten.de
>
> > Existe-t-il une doc donnant le format des fichiers .vd3/4?
>
> Je pense que non.
> J'ai quelques fois vu des demandes dans ce sens, avec toujours les
> même bête réponses
> "vous n'avez pas besoin de çà",
> "yaka employer ETS"
>
> Peut-être que un des martiens spéce (variante bleue, à fleurs rose
> fluo) peut nous bidouiller une solution ? .... de préférence sous
> Windows ?
#7
Mmouais...
Moi qui suis plutôt familier des approches "open source",
ici (je veux dire avec certaines marques) nous sommes vraiment aux
antipodes.

Bruno

(qui reste convaincu que "l'union fait la force" - ce groupe de
discussion en est d'ailleurs
une belle preuve - vive les martiens! ;o)

On 20 jan, 16:07, Marc Assin <raym...@warichet.com> wrote:
> On 20 jan, 15:06, bde <bruno.delco...@fundp.ac.be> wrote:> Ce qui me laisse perplexe, c'est que cela concerne le même
> > produit.
>
> En effet, il y a de quoi. Même si Schneider avait cet ID avant le
> rachat, ils n'avaient aucune raison de l'appliquer. C'est donc une
> décision délibérée de se démarquer.
>
> > Si chaque fois qu'un firme se fait racheter, cet ID change,
> > bonjour les dégats...
>
> Je me suis fait exactement la même remarque.
>
> > Je m'en vais leur envoyer un email, et je vous
> > tiens au courant de l'éventuelle réponse.
>
> Ca m'étonnerais fort que tu arrives à quoi que ce soit, on touche ici
> à des arguments qui n'ont plus rien à voir avec la technique KNX.
> Perso, je n'ai jamais rien pu tirer de Schneider, ils ne se donnent
> pas la peine de répondre.
> Peut-être que tu as plus de chances chez Merten, encore que .... mais
> enfin, mon expérience avec le support est très positive (Dieu sait que
> je leur ai cassé les pieds.... )
>
> Infol...@merten.de
>
> > Existe-t-il une doc donnant le format des fichiers .vd3/4?
>
> Je pense que non.
> J'ai quelques fois vu des demandes dans ce sens, avec toujours les
> même bête réponses
> "vous n'avez pas besoin de çà",
> "yaka employer ETS"
>
> Peut-être que un des martiens spéce (variante bleue, à fleurs rose
> fluo) peut nous bidouiller une solution ? .... de préférence sous
> Windows ?
#8
On 20 jan, 17:11, bde <bruno.delco...@fundp.ac.be> wrote:

Et s'il fallait en remettre une couche ....

Citation :Manufacturer code change

° When you change the manufacturer code of a BCU or device, then you
have altered the device and may loose all warranty by the
manufacturer.
° Changing the manufacturer code was possible with little risk in the
past, when all BCUs used the same processor and memory map, and were
OEM products of Siemens. Nowadays, this may still be the situation,
but more and more manufacturers have own BCUs, not from Siemens, with
own processors and a different memory image. There is thus an
increasing risk that changing the manufacturer code is not possible
and will if possible not have the expected effect, or may even be
harmful.
__________________
Mr. Steven De Bruyne
System Department - KNX Association
#9
Pour ce qui est de perdre la garantie sur un BCU "altéré", si la manip
à bien fonctionné il n'y a rien qui empèche de remettre les ID
d'origine de la même façon ... et hop ni vu ni connu !
Par contre, pour le coup des processeurs qui ont changés, c'est tout à
fait vrai, c'est pourquoi j'ai limité le champs d'application de la
première manip aux deux BCUs Merten précités ; cela fonctionne
évidement aussi avec tout BCU équivallent d'une autre marque vu que
c'est le même hardware ET logiciel dans la ROM, seules les données en
EEPROM sont différentes. Si le BCU est intégré dans le module bouton
poussoir, il y a de fortes chances que le processeur ne soit plus le
classique 68HC05, et alors cela ne va peut-être plus fonctionner.

... c'est pourquoi l'approche logicielle "Sybase SQL Anywhere 8" me
semble la plus simple à mettre en oeuvre pour les non-électroniciens.

Pour ce qui est fichiers .vd2/3/4, il s'agit d'un fichier ZIP
légérement modifié qui contient d'autres fichiers, ces derniers sont
probablement des petites DB que ETS fusionne avec sa DB de travail.
L'équipe du projet BASYS-2003 semble en avoir au moins partiellement
percé le secret.
#10
Mouais, ca m'a l'air bien compliqué tout ca. Vous allez me traiter
d'hérétique... mais quid de la solution de faire l'effort nécéssaire à
maîtriser le vocabulaire allemand (très limité) utilisé par le bidule
en question? En général, on configure une fois au début, puis on
tripote un peu, puis on y touche plus pendant des mois voir des
années. Je veux dire, c'est pas comme si ca vous braillait en allemand
dans les oreilles tous les matins...

Je suis certain que certains membres du groupe sont même pret à aider
pour traduire si nécéssaire (dont moi).

Fred
#11
Ce qui est simple pour certains peux être compliqué
pour d'autres, et vice versa. En ce qui me concerne,
apprendre l'allemand est plus compliqué que changer
un code fabricant par un autre dans une base de donnée.
Mais j'en conviens, ce n'est pas une généralité.

Quand au fait que je n'en mourrais pas, c'est aussi très clair.
Simplement, j'ai du hager et du siemens avec des vdx en français.
Ayant trouvé récemment trouvé des vdx schneider en français,
qui donnent des entrées catalogues différents des équivalents merten
j'ai (naivement, je le concède) effacé toutes les merten et recréés/
configuré
les schneider. Puis je veux faire les download, et là nada.
C'est pas la cata, j'ai des backups, mais c'est frustrant.

Effectivement, je ne toucherai plus très souvent à ma config, mais
justement, si je dois relire celà dans un an, je prérérerais que ce
soit
en francais.

D'une manière plus globale, cela m'inquiète plus pour l'avenir, car,
dois-je
maintenant considérer que mon matériel à un code fabricant qui a
disparu?

D'un point vue plus "humain", j'ai l'habitude dans mon boulot
d'utiliser
(d'un point vue professionnel) des produits "open source". La TRES
grande majorité du temps je ne fais pas de modification dans le code.
Mais si j'ai un problème spécifique, j'ai la possibilité de "soulever
le capot",
d'appliquer une correction et de partager mon expérience sur les
forums.
Et je trouve cela bien qu'entre personnes, l'on puisse s'aider.

Donc je suis perplexe quand je bute sur des problèmes comme celui-ci.

Le monde n'est pas simple, sinon celà se saurait, et je veux éviter
les jugements
à l'emporte pièce, mais je vous invite à réfléchir sur le point de
vue
(et les actes qui le valide) d'une personne comme Richard Stallman.

http://www.april.org/articles/intro/gnu.html
l'example de l'imprimante, qui est cité, est intéressant

Bruno

P.S.: Apprendre l'allemand serait quand même un bonne chose, ainsi je
pourrais
déchanger avec nos voisins d'allemagne. ;o)



On 23 jan, 11:04, fred <frederic.thomas...@gmail.com> wrote:
> Mouais, ca m'a l'air bien compliqué tout ca. Vous allez me traiter
> d'hérétique... mais quid de la solution de faire l'effort nécéssaire à
> maîtriser le vocabulaire allemand (très limité) utilisé par le bidule
> en question? En général, on configure une fois au début, puis on
> tripote un peu, puis on y touche plus pendant des mois voir des
> années. Je veux dire, c'est pas comme si ca vous braillait en allemand
> dans les oreilles tous les matins...
>
> Je suis certain que certains membres du groupe sont même pret à aider
> pour traduire si nécéssaire (dont moi).
>
> Fred
#12
> apprendre l'allemand est plus compliqué que changer
> un code fabricant par un autre dans une base de donnée.

Moui, il y a aussi les mises à jour, la reprise de l'installation par
un tiers (vente de la maison?), le risque d'effets de bords
imprévisible (pas nécéssairement pour *ce* cas en particulier mais en
général si on "bricole"), etc. Les bricoleurs que nous sommes (moi le
premier) avons souvent tendance à minimiser le temps total que coûtent
nos bricolages Smile

> (d'un point vue professionnel) des produits "open source". La TRES

Oui. Sans aller jusque là, simplement permettre aux utilisateurs de
fournir des traductions (non officielles) serait déjà un bon moyen de
faire avancer le schmilblic.

> P.S.: Apprendre l'allemand serait quand même un bonne chose

Oui, il y a d'autres bénéfices que juste la programmation de son
installation électrique Smile

Fred
#13
Petit retour sur le changement de Vendor ID dans la mémoire des
modules avec BCU classique : après avoir un peu fouillé dans le
protocole EIB, je me rends compte que nous disposons quasiment tous
déjà de l'outil nécessaire : avec ETS3 est distribué un petit logiciel
appelé "Device Editor" qui est justement fait pour lire et écrire dans
la mémoire des BCUs.
Le vrai problème est en réalité que l'accès aux cases mémoires ou
propriétés qu'il faudrait modifier est protégé par une "clef" sur 4
octets - en gros, un mot de passe - que bien sur nous ne possèdons
pas.

Bref, il reste à trouver un moyen d'obtenir cette clef.
#14
Petit précision, cette clef est gérée par le BCU et non par le soft
"Device Editor", donc ce n'est pas trop la peine d'essayer d'envoyer
en direct sur le BUS (via un bricolage quelconque) les ordres
d'écriture dans la mémoire du BCU, car l'action sera de toute manière
bloquée par le BCU.
#15
Merci pout l'info, qui soulève d'autres questions:

- Est-ce la même procédure qui est utilisée losrque l'on
"download" une application sur une BCU?

- si oui, comment ETS3 se procure-t-il cette clé?
- en interrogeant le BCU?

- le device editor es-il capable d'aller "lire" ce code?

Existe-t-il un document "public" qui décrit le le protocole EIB à ce
niveau
de détails.


Bruno

P.S: En somme le plus "propre" serait de pouvoir créer un fichier
vdx "agréé".
#16
On 26 jan, 13:49, bde <bruno.delco...@fundp.ac.be> wrote:
> P.S: En somme le plus "propre" serait de pouvoir créer un fichier
> vdx "agréé".

Hé oui, mais ces specs là ne sont pas publiques. Elles sont réservées
aux fabriquants / développeurs, moyennant license ad hoc.


Atteindre :


Utilisateur(s) parcourant ce sujet : 5 visiteur(s)