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
	 
	
	
	
		
	 
 
 
	
	
		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. -"
	 
	
	
	
		
	 
 
 
	
	
		> " 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.
	 
	
	
	
		
	 
 
 
	
	
		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.
	 
	
	
	
		
	 
 
 
	
	
		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 ?
	 
	
	
	
		
	 
 
 
	
	
		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 ?
	 
	
	
	
		
	 
 
 
	
	
		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 ?
	 
	
	
	
		
	 
 
 
	
	
		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 
	 
	
	
	
		
	 
 
 
	
	
		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.
	 
	
	
	
		
	 
 
 
	
	
		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
	 
	
	
	
		
	 
 
 
	
	
		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
	  
	
	
	
		
	 
 
 
	
	
		> 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   
> (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   
Fred
	  
	
	
	
		
	 
 
 
	
	
		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.
	 
	
	
	
		
	 
 
 
	
	
		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.
	 
	
	
	
		
	 
 
 
	
	
		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éé".
	 
	
	
	
		
	 
 
 
	
	
		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.
	 
	
	
	
		
	 
 
 
	 
 |