Je viens de recevoir mon premier produit KNX équipé d'un BCU modulaire
(détecteur de présence). Je n'avais jusqu'à présent que des modules
sur rail DIN.
Qu'on se comprenne bien, j'appelle BCU un appareil, encastrable dans
une boite de 62/65 mm standard à vis, et comportant d'une part deux
bornes pour le bus KNX et, d'autre part, un connecteur à 10 contacts
femelle (2 lignes de 5 contacts).
Là-dessus, je viens clipser mon détecteur de présence qui comporte,
lui, 10 broches mâles. Manifestement c'est complètement modulaire et
je crois comprendre qu'il y a compatibilité d'une marque à l'autre...
Questions :
Y'a-t-il vraiment compatibilité ?
Peut-on associer n'importe quel accessoire à n'importe quel BCU,
quelle que soit la marque des deux morceaux ? Qui fait quoi entre
l'accessoire (ici un détecteur de présence, mais ça pourrait être des
boutons, un thermostat...) et le BCU ?
Qu'est ce qui se passe dans cette interface à 10 contacts (bus 8
bits ?)
Où est le micrologiciel (dns le BCU ?)
On 11 juil, 08:24, Dibou <doc.bou...@neuf.fr> wrote:
> Je viens de recevoir mon premier produit KNX équipé d'un BCU modulaire
> (détecteur de présence).
Félicitations Dibou, tu vas bien t'amuser :-)
Ma vision (simpliste)
> Y'a-t-il vraiment compatibilité ?
L'interface hardware/software est défini et standardisé par EIB/KNX
> Peut-on associer n'importe quel accessoire à n'importe quel BCU,
> quelle que soit la marque des deux morceaux ?
Oui et non
Dans certains cas, çà peut marcher (modules similaires), dans d'autres
pas
Perso, je trouve que c'est pas une bonne idée (sauf cas extrème pour
se dépanner temporairement)
> Qui fait quoi entre
> l'accessoire (ici un détecteur de présence, mais ça pourrait être des
> boutons, un thermostat...) et le BCU ?
C'est le BCU qui fait l'I/F avec le bus. C'est lui la partie
"intelligente" avec le microcontroler et la mémoire.
C'est lui qui est le détenteur de la PA. J'en veux pour preuve que tu
dois enlever la plaquette applicative pour appuyer sur le petit bouton
pour programmer la PA.
C'est bien dans le BCU que tu download l'applicatif en fonction du
module applicatif (Tu as remarqué que parfois le fournisseur propose
2-3 appli pour un même module, et donc on change complètement la
personnalité / fonctionnalité du module en fonction de la db chargée)
> Qu'est ce qui se passe dans cette interface à 10 contacts (bus 8
> bits ?)
Je crois que c'est le PEI, Programmable External I/F, faudrais que je
relise les specs.
> Où est le micrologiciel (dns le BCU ?)
Oui, c'est bien çà.
Et donc, pour en revenir a ta question, il faut qu'il y aie cohérence
entre le BCU (il y a plusieurs types, 1,2,3,4,5) l'applicatif chargé
dans le BCU et la plaquette enfichée dans le connecteur 10pin.
Contre-exemple: tu ne pourrais pas charger dans un BCU1 (pas beaucoup
de mémoire) une application thermostat prévue pour BCU2 enficher une
plaquette de détecteur de présence. Ca ne marchera pas, tu ne pourras
même pas downloader, mais tu ne casses rien.
Voilà la vue simpliste d'un béotien. Merci de me corriger
D'après une discussion avec un fournisseur, bien qu'il y ait moyen
d'enficher n'importe (?) quel accessoire sur un bcu, la compatibilité
entre marques est inexistante et au sein d'une même marque il y a des
restrictions. Les problèmes de compatibilité au sein d'une marque sont
en général abordés dans le catalogue ("à utiliser en combinaison avec
le bcu ref. xxxx").
Personnelement je n'ai pas fait de tests en situation réelle. Il se
pourrait que la situation soit moins "fermée" dans la pratique et que
des produits soient compatibles sans que cela soit garanti par les
fabricants.
On Jul 11, 8:57 am, Marc Assin <raym...@warichet.com> wrote:
> On 11 juil, 08:24, Dibou <doc.bou...@neuf.fr> wrote:> Je viens de recevoir mon premier produit KNX équipé d'un BCU modulaire
> > (détecteur de présence).
>
> Félicitations Dibou, tu vas bien t'amuser :-)
>
> Ma vision (simpliste)> Y'a-t-il vraiment compatibilité ?
>
> L'interface hardware/software est défini et standardisé par EIB/KNX
>
> > Peut-on associer n'importe quel accessoire à n'importe quel BCU,
> > quelle que soit la marque des deux morceaux ?
>
> Oui et non
> Dans certains cas, çà peut marcher (modules similaires), dans d'autres
> pas
> Perso, je trouve que c'est pas une bonne idée (sauf cas extrème pour
> se dépanner temporairement)
>
> > Qui fait quoi entre
> > l'accessoire (ici un détecteur de présence, mais ça pourrait être des
> > boutons, un thermostat...) et le BCU ?
>
> C'est le BCU qui fait l'I/F avec le bus. C'est lui la partie
> "intelligente" avec le microcontroler et la mémoire.
> C'est lui qui est le détenteur de la PA. J'en veux pour preuve que tu
> dois enlever la plaquette applicative pour appuyer sur le petit bouton
> pour programmer la PA.
> C'est bien dans le BCU que tu download l'applicatif en fonction du
> module applicatif (Tu as remarqué que parfois le fournisseur propose
> 2-3 appli pour un même module, et donc on change complètement la
> personnalité / fonctionnalité du module en fonction de la db chargée)
>
> > Qu'est ce qui se passe dans cette interface à 10 contacts (bus 8
> > bits ?)
>
> Je crois que c'est le PEI, Programmable External I/F, faudrais que je
> relise les specs.
>
> > Où est le micrologiciel (dns le BCU ?)
>
> Oui, c'est bien çà.
> Et donc, pour en revenir a ta question, il faut qu'il y aie cohérence
> entre le BCU (il y a plusieurs types, 1,2,3,4,5) l'applicatif chargé
> dans le BCU et la plaquette enfichée dans le connecteur 10pin.
> Contre-exemple: tu ne pourrais pas charger dans un BCU1 (pas beaucoup
> de mémoire) une application thermostat prévue pour BCU2 enficher une
> plaquette de détecteur de présence. Ca ne marchera pas, tu ne pourras
> même pas downloader, mais tu ne casses rien.
>
> Voilà la vue simpliste d'un béotien. Merci de me corriger
Salut.
> Personnelement je n'ai pas fait de tests en situation réelle. Il se
> pourrait que la situation soit moins "fermée" dans la pratique et que
> des produits soient compatibles sans que cela soit garanti par les
> fabricants.
Oui, oui, mais non !
En réalité,quand on reste dans un type de BCU (le 1 ou le 2), le
hardware et le software (l'OS EIB) sont quasi toujours les même quelle
que soit la marque du bidule et seuls changent quelques paramètres en
mémoire comme :
- l'ID du fabricant
- le numéro de série
- le numéro de commande
...
En théorie, rien n'empèche d'utiliser un module applicatif (plaquette
PB, detecteur IR, thermostat, ...) d'une marque sur un BCU d'une autre
marque ... SAUF que au moment de la programmation du BCU, le logiciel
ETS va lire l'ID du fabricant dans le BCU, se rendre compte que cet ID
est différent de celui de l'application qui doit être téléchargée dans
le BCU et va bloquer tout le processus.
--> voila comment les fabricants protègent artificiellement leur
marché.
Je possède d'ailleurs plusieurs acteurs Merten et Jung qui sont bien
identifiés comme tel (Merten et Jung) par l'ETS lors d'une
interrogation de leurs propriétés via le BUS mais quand on ouvre le
boitier, on trouve - oh, surprise - une étiquette et un numéro de
série Siemens sur le module BCU/BIM ...
De la à penser que Siemens (l'inventeur de l'EIB, rapellons le ...)
fabriquerait la pluspart des BCUs en service, y compris pour le autres
marques qui vendent des produits EIB ?
C'était sans doute une pratique courante il y a quelques années mais
ce n'est pas toujours le cas.
Maintenant, pour les techniciens, voici une petite liste de ce que les
BCU ont réellement dans le ventre :
BCU1 pour cable TP1
- CPU 68HC05B6 (6kB ROM, 256 B EEPROM, 176 B RAM) @ 2 MHz (interne)
- EIB BUS tranciever "FZE 1065 IC" (+transfo) ou "FZE 1066 IC" (sans
transfo)
- EIB OS software version 1.1 ou 1.2
BCU2 pour cable TP1
- CPU 68HC05BE12 (12 kB ROM, 1 kB EEPROM, 384 B RAM) @ 4,9152 MHz
(interne)
- a programmable I/O controller (= bit engine)
- EIB BUS tranciever "FZE 1065 IC" (avec transfo) ou "FZE 1066
IC" (sans transfo)
- EIB OS software version 2.0 ou 2.1
Si quelqu'un connait réellement bien les CPU 68HC05, il y a sans doute
moyen de bidouiller dans leur ROM (si elle est du type effaçable, bien
sur) pour modifier certaines valeur comme l'ID fabricant mais c'est au
dela de mes connaissances actuelles.
Encore un petit mot à propos du connecteur 10 pins.
Il s'agit bien du connecteur PEI (= Physical External Interface),
c'est à dire de quelques pins I/O du processeur 68HC05 qui sont mises
à disposition pour la connection d'un module applicatif externe.
La pluspart du temps, il y a 10 pins :
- une alim +5v
- une alim +24V
- deux masses (GND)
- cinq GPIO (=general purpose I/O) dont la fonctionalité est
programmable dans le CPU
- une entrée "PEI type"
Il existe aussi une variante avec 12 pins, qui ajoute :
- une sortie ON/OFF
- une sortie PWM (modulation en largeur d'impulsion)
L'entrée "PEI type" permet au BCU de savoir quel type de communication
il doit utiliser pour "parler" avec le module d'application qui est
enfiché, et aussi de détecter quand il n'y a aucun module enfiché.
Du coté du module applicatif, la pin "PEI type" est simplement
connecté à la pin +5v avec une résistance très précise (type +/- 1%),
la valeur de la résistance détermine le type de communication à
adopter.
Pour info :
- en mode de communication série asynchrone du type RS-232 (9600 bps)
= connection d'un PC sur un module BCU1, on travaille en mode PEI-16
et la résistance est de 11 kOhms
- en mode de communication série asynchrone du type RS-232 (19200
bps) = connection d'un PC sur un module BCU2 en FT1.2, on travaille en
mode PEI-10 et la résistance est de 45,3 kOhms.
Keldo
On 8 août, 14:32, keldo <kelderm...@ibelgique.com> wrote:
> Siemens (l'inventeur de l'EIB, rapellons le ...)
???
J'aurais juré que c'était la société Insta (rejoint rapidement par
Siemens et Merten, il est vrai). Chez Siemems, ne dit on pas souvent
instabus ?
> Maintenant, pour les techniciens, voici une petite liste de ce que les
> BCU ont réellement dans le ventre :
Ah mais voilà justement ce que je cherchais. Tu l'as "trouvé" où ?
Merciiii !
> Si quelqu'un connait réellement bien les CPU 68HC05, il y a sans doute
> moyen de bidouiller
Faut être vachement bien équipé, ou bien être un spécialiste de la
branche
> pour modifier certaines valeur comme l'ID fabricant mais c'est au
> dela de mes connaissances actuelles.
Ce thème (qui abonde dans ton sens) apparait parfois sur les forums
allemands. Et donc, suite à une fausse manip à l'usine, on recoit un
device qui a la mauvaise ID du fabricant. Seule solution: renvoyer
pour reprogrammation, c'est gratuit
> On 8 août, 14:32, keldo <kelderm...@ibelgique.com> wrote:> Siemens (l'inventeur de l'EIB, rapellons le ...)
>
> ???
> J'aurais juré que c'était la société Insta (rejoint rapidement par
> Siemens et Merten, il est vrai). Chez Siemems, ne dit on pas souvent
> instabus ?
Ah, oui, c'est possible, je ne suis pas 100% sur de mon info mais il
me semblait que l'instabus était une version légèrement modifiée d'un
bus industriel de Siemens ... mais bon je peux aussi me tromper.
Il n'empèche, sauf erreur, l'ID constructeur 0000 = Siemens, pas
Insta ?
Oui, chez Siemens, instabus est la marque commerciale de la gamme EIB/
KNX.
Chez ABB, c'est I-Bus.
Chez Hager, c'est TEBIS.
Etc. Les commerciaux ne savent pas quoi inventer pour segmenter le
marcher et désinformer leurs clients.
> > Maintenant, pour les techniciens, voici une petite liste de ce que les
> > BCU ont réellement dans le ventre :
>
> Ah mais voilà justement ce que je cherchais. Tu l'as "trouvé" où ?
> Merciiii !
>
Moi je sors l'info d'un livre en anglais :
- EIB installation Bus System
- Sauter Dietrich Kastner
- Editions PUBLICIS
que j'ai acheté sur Amazon,
mais tu trouveras sans doute une info plus complète en lisant les
datasheet des différentes BIM (=BCU sans boitier) sur le site web du
revendeur de composants EIB "Opternus" :
http://www.opternus.de/opternus-componen...1-115.html
> Ce thème (qui abonde dans ton sens) apparait parfois sur les forums
> allemands. Et donc, suite à une fausse manip à l'usine, on recoit un
> device qui a la mauvaise ID du fabricant. Seule solution: renvoyer
> pour reprogrammation, c'est gratuit
Donc cela signifie que la rom des 68HC dans les BCU est une EPROM ...
chouette, ça laisse une porte ouverte aux bidouilles pour les cas
désespérés comme celui-ci par exemple :
Je possède un module "4 entrées pour contacts d'alarme avec
monitoring" de la firme "Robert Bosch Domotik" qui n'existe plus. La
database pour l'ETS des produits "Domotik" est absolument introuvable
(bien que finalement les gens de l'EIBA aient pu m'aider, merci à
eux ...).
Ce module est en tout point identique au module ABB MT/S 4.12.1, il y
même une étiquette avec un numéro de série ABB collée dessus, seul un
chiffre change par rapport au numéro de commande chez ABB ...
MAIS, quand j'essaye de programmer mon module "Domotik" avec une
database ABB, he bien "schnoll broket que dalle" comme on dit chez
moi, bref nada, l'ETS m'envoit sur les roses.
J'ai bien pensé tromper l'ETS en bidouillant sa database et lui faire
croire que l'ID Bosch Domotik = L'ID ABB pour ce produit en
particulier mais je n'ai pas encore trouvé la bonne version de SGBD
pour effectuer la manip.
Si quelqu'un connait un moyen de modifier un fichier .vd2/.vd3/.vd4
sans l'ETS pour développeur, faites moi signe, merci.
Non, la rom de la BCU n'est pas un EEPROM. C'est la même dans touts
les appareils qui ont la même version de mask.
Par contre, d'après l'aide des BCU1 ( http://www.auto.tuwien.ac.at/~mkoegler/e...u1help.pdf
) , l'ID du fabriquant se trouve à l'adresse 0x103-0x104 qui elle se
trouve bien en EEPROM. Je serais curieux de voir si on sait la
reprogrammer simplement à l'aide des mêmes opération d'écriture qui
permettent d'écrire l'application , ses paramètres et les adresses de
groupes. Si c'est le cas, il serait possible de reprogrammer l'ID
fabricant à l'aide de eibd et les programmes examples fournis avec. Ca
m'a l'air trop simple pour être possible mais on serait parfois
étonnés...
On 8 août, 16:37, keldo <kelderm...@ibelgique.com> wrote:
> > On 8 août, 14:32, keldo <kelderm...@ibelgique.com> wrote:> Siemens (l'inventeur de l'EIB, rapellons le ...)
>
> > ???
> > J'aurais juré que c'était la société Insta (rejoint rapidement par
> > Siemens et Merten, il est vrai). Chez Siemems, ne dit on pas souvent
> > instabus ?
>
> Ah, oui, c'est possible, je ne suis pas 100% sur de mon info mais il
> me semblait que l'instabus était une version légèrement modifiée d'un
> bus industriel de Siemens ... mais bon je peux aussi me tromper.
> Il n'empèche, sauf erreur, l'ID constructeur 0000 = Siemens, pas
> Insta ?
>
> Oui, chez Siemens, instabus est la marque commerciale de la gamme EIB/
> KNX.
> Chez ABB, c'est I-Bus.
> Chez Hager, c'est TEBIS.
> Etc. Les commerciaux ne savent pas quoi inventer pour segmenter le
> marcher et désinformer leurs clients.
>
> > > Maintenant, pour les techniciens, voici une petite liste de ce que les
> > > BCU ont réellement dans le ventre :
>
> > Ah mais voilà justement ce que je cherchais. Tu l'as "trouvé" où ?
> > Merciiii !
>
> Moi je sors l'info d'un livre en anglais :
> - EIB installation Bus System
> - Sauter Dietrich Kastner
> - Editions PUBLICIS
> que j'ai acheté sur Amazon,
> mais tu trouveras sans doute une info plus complète en lisant les
> datasheet des différentes BIM (=BCU sans boitier) sur le site web du
> revendeur de composants EIB "Opternus" :
> http://www.opternus.de/opternus-componen...1-115.html
>
> > Ce thème (qui abonde dans ton sens) apparait parfois sur les forums
> > allemands. Et donc, suite à une fausse manip à l'usine, on recoit un
> > device qui a la mauvaise ID du fabricant. Seule solution: renvoyer
> > pour reprogrammation, c'est gratuit
>
> Donc cela signifie que la rom des 68HC dans les BCU est une EPROM ...
> chouette, ça laisse une porte ouverte aux bidouilles pour les cas
> désespérés comme celui-ci par exemple :
> Je possède un module "4 entrées pour contacts d'alarme avec
> monitoring" de la firme "Robert Bosch Domotik" qui n'existe plus. La
> database pour l'ETS des produits "Domotik" est absolument introuvable
> (bien que finalement les gens de l'EIBA aient pu m'aider, merci à
> eux ...).
> Ce module est en tout point identique au module ABB MT/S 4.12.1, il y
> même une étiquette avec un numéro de série ABB collée dessus, seul un
> chiffre change par rapport au numéro de commande chez ABB ...
> MAIS, quand j'essaye de programmer mon module "Domotik" avec une
> database ABB, he bien "schnoll broket que dalle" comme on dit chez
> moi, bref nada, l'ETS m'envoit sur les roses.
> J'ai bien pensé tromper l'ETS en bidouillant sa database et lui faire
> croire que l'ID Bosch Domotik = L'ID ABB pour ce produit en
> particulier mais je n'ai pas encore trouvé la bonne version de SGBD
> pour effectuer la manip.
> Si quelqu'un connait un moyen de modifier un fichier .vd2/.vd3/.vd4
> sans l'ETS pour développeur, faites moi signe, merci.
Ha ah, on va finir par y arriver, je le sens ...
Mais ne soyons tout de même pas trop optimiste, ce type d'information
en EEPROM est sans doute protégée en écriture tant que le BCU n'aura
pas reçu la bonne "security key" depuis le bus EIB, c-à-d un mot de
passe pour passer en mode priviliégié.
Pour ma part, je pense qu'il serait plus facile de court-circuiter le
bus EIB ici et de reprogrammer l'EEPROM avec un programmateur de
68HC05 "in-situ".
Mais bon, ici j'extrapole à partir de ce que je ferais sur un
processeur du type PIC, c-à-d brancher les 5 fils de mon programmateur/
debuggeur ICD2 et ensuite intervenir directement dans l'EEPROM du PIC
avec le logiciel de debuggage sur PC. Je n'ai aucune idée si une
possibilité ou du matériel équivallent existe pour la famille 68HC05.
On 8 août, 16:37, keldo <kelderm...@ibelgique.com> wrote:
> Etc. Les commerciaux ne savent pas quoi inventer pour segmenter le
> marcher et désinformer leurs clients.
:-))))
On 8 août, 18:40, keldo <kelderm...@ibelgique.com> wrote:
> Pour ma part, je pense qu'il serait plus facile de court-circuiter le
> bus EIB ici et de reprogrammer l'EEPROM avec un programmateur de
> 68HC05 "in-situ".
Cà implique de désouder / resouder le bestiau !?!
Avec du SMD, ce n'est pas à la portée de tout le monde
Sur le plan légal, je sais pas trop ce qui est permis de faire ou pas,
mais sur le plan purement technique, je confirme qu'il est possible de
modifier l'ID du fabricant sans rien dessouder du tout.
On 8 août, 21:01, Marc Assin <raym...@warichet.com> wrote:
> On 8 août, 18:40, keldo <kelderm...@ibelgique.com> wrote:
>
> > Pour ma part, je pense qu'il serait plus facile de court-circuiter le
> > bus EIB ici et de reprogrammer l'EEPROM avec un programmateur de
> > 68HC05 "in-situ".
>
> Cà implique de désouder / resouder le bestiau !?!
> Avec du SMD, ce n'est pas à la portée de tout le monde
Sur le plan légal, la modification du code de fabricant va être
interpreté comme usage non-documentée, donc on-permis du produit. Ca
veut dire qui - en cas de problème - le fabrican peut refuger chaque
responsabilité!
Faites quand-même attention aussi sur le plan technique: de plus en
plus, d'autre processeurs sont utilisés que le HC05. Il se peut alors
très bien que le code du fabricant est située autr-part que sur
l'adresse 0x0104, m^eme si ETS va le lire a travers cette adresse.
L'ecriture de 0x0104 peut donc pas fonctioner et même resulter dans un
malfonction.
On 9 août, 14:45, Steven <steven.debru...@konnex.org> wrote:
> Sur le plan légal, la modification du code de fabricant va être
> interpreté comme usage non-documentée, donc on-permis du produit. Ca
> veut dire qui - en cas de problème - le fabrican peut refuger chaque
> responsabilité!
Bon, c'est clair que si on tripote le BCU à ce niveau là et qu'il
tombe en panne, ce ne sera pas la peine d'aller pleurer chez le
fabricant pour la garantie ==> à ne tenter que sur du vieux
matériel ... pour l'instant.
> Faites quand-même attention aussi sur le plan technique: de plus en
> plus, d'autre processeurs sont utilisés que le HC05. Il se peut alors
> très bien que le code du fabricant est située autr-part que sur
> l'adresse 0x0104, m^eme si ETS va le lire a travers cette adresse.
> L'ecriture de 0x0104 peut donc pas fonctioner et même resulter dans un
> malfonction.
Avec un BCU1, je ne pense pas qu'il y ait de risque de trouver autre
chose que des 68HC05, mais pour les modèles plus récents je pense
qu'il serait en effet sage de faire un backup complet de la mémoire
avec un programmateur avec de tenter nos petites expériances ; ce qui
implique d'ouvrir le boitier, verifier le type de processeur, etc ...
Tiens, en passant, une info amusante :
Dans mes thermostats Theben RAM713 achetés il y a environ 18 mois, le
microcontroleur principal est un NEC D78F9177A, le même type que celui
trouvé dans les nouveau BCU/BIM13x, et vu le nombre de connexion
soudées, c'est clairement lui qui fait le travail, accompagné d'une
petite EEPROM i2c.
Mais devinez donc ce qui fait l'interface entre le NEC et le bus EIB ?
Et bien tout simplement un bon gros MC68HC05B6 - ZC441016CFN,
accompagné d'un transceiver FZE 1066.
Sur les 52 pattes du 68HC05, une dizaine seulement sont connectées,
bref, il n'est la que pour faire l'interface avec le bus.
Si ce n'est pas du gaspillage ça !
On 8 août, 21:01, Marc Assin <raym...@warichet.com> wrote:
> On 8 août, 18:40, keldo <kelderm...@ibelgique.com> wrote:
>
> > Pour ma part, je pense qu'il serait plus facile de court-circuiter le
> > bus EIB ici et de reprogrammer l'EEPROM avec un programmateur de
> > 68HC05 "in-situ".
>
> Cà implique de désouder / resouder le bestiau !?!
> Avec du SMD, ce n'est pas à la portée de tout le monde
Ben non, justement, quand j'écris "in-situ" je veux dire que l'on
laisse le CPU sur sa plaque de circuit imprimé mais que l'on connecte
(temporairement avec de fines pinces) sur les "bonnes" pattes du CPU
quelques fils en provenance d'un programmateur/debugger.
Ce type de programmateur, sans "socket de programmation", existe pour
les PIC mais je ne sais pas si cela existe pour 68HC05.
|
