Voila, je me pose une question depuis quelque temps.
Plusieurs marques propose le même produit, sous des nom différent, et a des tarifs souvent différent.
Exemple, prix eibmarkt, pour le capteur de CO2/Temperature/Humidité:
Selon les marques, la documentation, mais surtout les programme knxprod sont soit en anglais / allemand (merten), soit proposé aussi en français (abb, theben).
Ma question est, puisque le materiel semble être le même, est-t-il possible d'utiliser un programme d'une marque pour le materiel d'une autre ??
Non, ce n'est pas possible, car chaque produit et chaque base de donnée à sa propre ID fabricant.
C'est à dire qu'un produit ABB ne peut être programmé avec la base de donnée de Theben car il n'y a pas de compatibilité au niveau de l'ID fabricant.
08/04/2016, 13:33:22 (Modification du message : 08/04/2016, 13:51:31 par condo4.)
Bonjour,
En effet, en regardant de plus près, les .knxprod ne sont que des fichiers zip contenant das XML, et potentiellement des msi (plugins).
Je voit qu'a l’intérieur on retrouve des clé publics RSA, il y a donc certainement un mécanisme de signature basé sur clé public/privé.
En revanche, il est peut être possible d'éditer l'XML contenant les traductions pour y ajouter celle d'une autre marque.
La procédure serait donc, de de-zipper le fichier correspondant a la marque A, d'y ajouter (en modifiant les racines des id) les traduction contenu dans l'XML de la marque B, de re-zipper le tout, et d'installer ce nouveau fichier...
Quelqu'un as-t-il déjà tester cette manipulation ?
Il faudra que je fasse quelques essais, mais je n'ai pas l'impression qu'il n'y ai de signature global sur le fichier, donc, en théorie, ça doit être jouable...
Bon, j'ai vérifier, malheureusement, y'a une signature global sur le fichier...
Donc, impossible...
J'ai fait des essais non concluants sur des knxprod présentant des bugs. il me semble me souvenir qu'il y a des checksum de vérification et que du coup toute modification du xml est immédiatement détectée par une non-concordance avec le checksum de vérif.
Le perfectionnement de soi et l'accession à sa légende personnelle passe obligatoirement par le partage de son savoir et de son expérience avec les profanes en demande d'initiation. (R. Bach)
08/04/2016, 21:08:36 (Modification du message : 08/04/2016, 21:10:32 par condo4.)
j'ai analysé d'un peu plus près le contenu du fichier...
Il y a effectivement un fichier M_*****.signature qui semble contenir une clé assez longue (base64 je suppose...)
La question est, cette clé est-t-elle une signature (genre RSA/DSA ou autre), et donc, impossible a reconstruire sans la clé privé, soit c'est un hash (checkum, genre sha1, md5...), et dans ce cas, on est capable de re-calculer le nouveau checksum après modification des fichiers...
Le truc, c'est que si c'était une signature, il faudrait que ETS connaisse la clé publique pour valider la signature, et donc, contienne la liste complète des fabricant (ce qui est possible), mais surtout nécessiterait une mise a jour, chaque fois qu'un nouveau fabricant apparaîtrait (et donc, ajouter une nouvelle clé public dans ETS), or il ne me semble pas qu'une vielle version d'ETS4 ne puisse pas ouvrir un fichier d'un nouveau constructeur, donc, il faut trouver la clé public autrement.
Dans le fichier knx_master.xml de chaque .knxprog, il y a effectivement la liste complète des fabriquant et certain on une clé RSA attaché.
Mais ça ne concerne que certains fabricant (Zennio, VIMAR et Buch dans mon fichier), et donc, tout les autres n'en ont pas.
Je pense donc que la "signature" n'est qu'un checksum, il faut donc trouver quel algo a été utilisé... et on pourrais refaire le fichier signature après ajout de la nouvelle traduction.
Et si c'est une signature, et qu'elle utilise la clé public du knx_master.xml, qu'est ce qui nous empêche de changer la clé public dans ce fichier ?
Bref, il faut que je creuse un peu plus, mais ça ne me semble pas infaisable...
Sinon, autre piste, quelqu'un a-t-il croisé un jour une documentation quelconque sur le format .knxprod, si ça se trouve, c'est documenté et normalisé...
Sauf erreur, le premier produit permet de créer la base de données ETS d'un produit KNX.
Le second ne permet que de réaliser les différentes traductions (EN, FR, DE...) pour une base de données existante (initiée avec le premier produit).
Et dans les deux cas, pour obtenir les dongles, il faut être référencé comme fabricant de produit KNX auprès du consortium...
J’utilise le Manufacturer Tool , voici quelques réponses:
Manufacturer Tool permet d'ouvrir les fichiers VD5 , knxprod etc...
ce qui permet de gérer le download du firmware entre ETS et ton produit.
car chaque fabriquant est libre sur beaucoup de chose : choix du BCU et donc du processeur. pagination mémoire etc...
Puis Manufacturer Tool va te permettre de créer un projet de test.
(sans signature) que ETS va accepté d'ouvrir et faire fonctionner.
limitation : un seul module KNX dans le projet "test"
mais qu'on peu dupliquer ! (si on a plusieurs module KNX identique)
Pour avoir la "signature", il faut envoyer le projet test à l'association KNX qui va te retourner le fameux fichier knxprod signé.
Un fabriquant à alors 6 mois pour faire les essais et prouver que son produit est conforme à la nomenclature.
une capture d'écran que j'ai faite du Manufacturer Tool
Merci philhp, ça explique tout, la signature n'est donc pas un checksum mais bien une signature...
Mais c'est pas chaque constructeur qui signe avec leur clé, mais KNX, et il y a donc bien 1 clé public dans ETS, la leur.
Pour un standard soit disant libre et ouvert, c'est quand même bien verrouillé de partout...
Quand j'aurais un peu de temps (après ma construction), ça vaudrait le coup de se pencher sur le protocole de programmation pour créer des outils indépendant de ETS.
Je ne serai pas aussi affirmatif
J'ai déjà avec succès poussé le soft d'une marque à la place d'une autre avec succès.
Ma station météo achetée hager TG053 présentait quelques bugs avec le soft Hager. Après un coup de fil au support Tébis, l'expert m'a non officiellement conseillé d'essayer le firmware Elsner (la TG053 est une Elsner rebadgée), ce que j'ai fais et effectivement ça fonctionne mieux.
J'ai juste gardé un dummy, car par contre le firmware Hager est mieux traduit et certains noms de fonction sur Elsner sont fantaisiste en français.
(08/04/2016, 12:50:31)Fifou a écrit : Bonjour,
Non, ce n'est pas possible, car chaque produit et chaque base de donnée à sa propre ID fabricant.
C'est à dire qu'un produit ABB ne peut être programmé avec la base de donnée de Theben car il n'y a pas de compatibilité au niveau de l'ID fabricant.
(28/06/2016, 10:02:25)Joffrey a écrit : Je ne serai pas aussi affirmatif
J'ai déjà avec succès poussé le soft d'une marque à la place d'une autre avec succès.
Ma station météo achetée hager TG053 présentait quelques bugs avec le soft Hager. Après un coup de fil au support Tébis, l'expert m'a non officiellement conseillé d'essayer le firmware Elsner (la TG053 est une Elsner rebadgée), ce que j'ai fais et effectivement ça fonctionne mieux.
Bonjour Joffrey,
Je cherche a faire cet upload, mais ne trouve pas la solution pour "sélectionner" la version Elsner a loader dans la Hager. Peux tu STP me guider sur la marche à suivre, j'utilise ETS5. ?
Ba il faut que tu ailles chez elsner récupérer le fichier du produit, et que tu ajoutes une station elsner dans ton projet.
C'est ce nouveau participant que tu vas configurer et telecharger.
KNX Partner Base / Avancé
Ma boite de MP est pleine, merci de créer un post si vous avez une question, cela profitera a tout le monde.
