Bonjour tous le monde,
Je cherche à programmer mes propres modules EIB/KNX
J'ai trouvé tout ce qu'il faut au niveau software (compilateur 6805
etc...)
Mais pour le hardware, si j'ai bien compris, il faut au minimum des
coupleur de bus ? BCU1 ou BCU2
Savez-vous où on peut les acheter dans leur version minimaliste (juste
le circuit) ?
merci,
Le fournisseur officiel:
http://www.opternus.de/opternus-componen...ducts.html
les BIM-M113 (version "minimaliste" de la BCU2.1) sont à 45EUR, pour
les frais de port je sais pas trop ce qu'ils demandent.
J'ai également entendu parler de personnes qui se les procurent via Mr
Dehof ( http://www.dehof.de/eib/) mais son site est en allemand.
Comme je n'en avais besoin que d'un ou deux, j'ai préféré acheter des
BCU2.1 Siemens 5WG1 114-2AB02 chez EibMarkt et retirer la plaque
métallique.
Si quelqu'un les commande en plus grande quantité (plus de 20) pour
avoir des prix plus intéressant, je suis intéressé pour lui en
racheter 2 ou 3.
Pour info, je compte également un jour ou l'autre me mettre au
développement de programmes pour coupleurs de bus mais je n'ai pas
encore eu le temps d'y regarder de plus près. Toute info ou retour
d'expérience est donc la bienvenue.
On 26 juil, 18:42, Marcha <ludome...@gmail.com> wrote:
> Bonjour tous le monde,
>
> Je cherche à programmer mes propres modules EIB/KNX
>
> J'ai trouvé tout ce qu'il faut au niveau software (compilateur 6805
> etc...)
>
> Mais pour le hardware, si j'ai bien compris, il faut au minimum des
> coupleur de bus ? BCU1 ou BCU2
>
> Savez-vous où on peut les acheter dans leur version minimaliste (juste
> le circuit) ?
>
> merci,
Salut,
Merci beaucoup
> Pour info, je compte également un jour ou l'autre me mettre au
> développement de programmes pour coupleurs de bus mais je n'ai pas
> encore eu le temps d'y regarder de plus près. Toute info ou retour
> d'expérience est donc la bienvenue.
c'est ce document qui m'a donné envie.
http://www.auto.tuwien.ac.at/~gneugsch/etfa05-rad.pdf
stephane.herraiz@gmail.com
Unregistered
Salut,
Si j'ai bien compris tu veux coupler un uC 6805 avec un coupleur de
bus (type BIM M113)? La liaison se faisant graçe au protocole FT1.2?
Je travail aussi dans ce sens. Moi j'utilise les uC Microchip PIC.
Pour l'instant j'étudie le protocole FT1.2 pour réaliser l'interface
la plus simple et la moins coûteuse en mémoire...
Cependant les BIM1xx peuvent être aussi programmés mais le
programmateur vaut très cher (voir opternus.com). le uC est un NEC
inconnu pour moi...
En quel language comptes tu programmer ton uC (C,Basic,
Assembler,...)?
Bon courage et tiens nous au courant de tes avancés!
BR
Je pense que le but de Marcha n'est pas de coupler un 6805 à la BCU
mais d'utiliser le 6805 contenu dans la BCU pour faire tourner ses
propres applications.
Les BIM M13x sont à base d' uC NEC et je n'ai pas encore entendu
parler de développement 'artisanal' sur ce type de platforme.
Les BIM M11x par contre, sont à base de 6805 et il existe un SDK
opensource permettant de développer des applications ( bcusdk )
L'approche consistant à utiliser le programme standard de la BCU2 pour
communiquer en FT1.2 avec un second uC est tout aussi valable que
celle consistant à développer une application directement pour la BCU.
Le choix de l'une ou l'autre approche dépend de ce qu'on veut en
faire.
On 30 juil, 10:14, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Salut,
> Si j'ai bien compris tu veux coupler un uC 6805 avec un coupleur de
> bus (type BIM M113)? La liaison se faisant graçe au protocole FT1.2?
> Je travail aussi dans ce sens. Moi j'utilise les uC Microchip PIC.
> Pour l'instant j'étudie le protocole FT1.2 pour réaliser l'interface
> la plus simple et la moins coûteuse en mémoire...
> Cependant les BIM1xx peuvent être aussi programmés mais le
> programmateur vaut très cher (voir opternus.com). le uC est un NEC
> inconnu pour moi...
> En quel language comptes tu programmer ton uC (C,Basic,
> Assembler,...)?
> Bon courage et tiens nous au courant de tes avancés!
> BR
stephane.herraiz@gmail.com
Unregistered
D'après Opternus les BIM 11x sont obsolètes.
C'est pour ça que je me suis dirigé vers les BIM13x.
Peut être que je fait fausse route...
On 30 juil, 12:43, jef2000 <jef2...@ouaye.net> wrote:
> Je pense que le but de Marcha n'est pas de coupler un 6805 à la BCU
> mais d'utiliser le 6805 contenu dans la BCU pour faire tourner ses
> propres applications.
> Les BIM M13x sont à base d' uC NEC et je n'ai pas encore entendu
> parler de développement 'artisanal' sur ce type de platforme.
> Les BIM M11x par contre, sont à base de 6805 et il existe un SDK
> opensource permettant de développer des applications ( bcusdk )
>
> L'approche consistant à utiliser le programme standard de la BCU2 pour
> communiquer en FT1.2 avec un second uC est tout aussi valable que
> celle consistant à développer une application directement pour la BCU.
> Le choix de l'une ou l'autre approche dépend de ce qu'on veut en
> faire.
>
> On 30 juil, 10:14, "stephane.herr...@gmail.com"
>
> <stephane.herr...@gmail.com> wrote:
> > Salut,
> > Si j'ai bien compris tu veux coupler un uC 6805 avec un coupleur de
> > bus (type BIM M113)? La liaison se faisant graçe au protocole FT1.2?
> > Je travail aussi dans ce sens. Moi j'utilise les uC Microchip PIC.
> > Pour l'instant j'étudie le protocole FT1.2 pour réaliser l'interface
> > la plus simple et la moins coûteuse en mémoire...
> > Cependant les BIM1xx peuvent être aussi programmés mais le
> > programmateur vaut très cher (voir opternus.com). le uC est un NEC
> > inconnu pour moi...
> > En quel language comptes tu programmer ton uC (C,Basic,
> > Assembler,...)?
> > Bon courage et tiens nous au courant de tes avancés!
> > BR
Je ne pense pas que tu fasses fausse route, Le protocole FT1.2 a de
grande chances d'être supporté dans toutes les BIM ou BCU à venir,
donc si tu choisis de connecter un PIC en FT1.2 derrière une BCU, tu
ne devrais pas avoir trop de problèmes dans le futur.
Avec l'autre approche, il y a un risque qu'un jour on ne puisse plus
se procurer de BIM M1xx et il faudra migrer le code vers un autre type
de BCU pour peu que le kit de développement soit abordable pour un
particulier. Le seul avantage que je vois dans cette seconde approche,
est de réduire la complexité hardware. Si les quelques broches
utilisables sur l'interface PEI sont suffisantes, pourquoi aller
ajouter un second uC et tout ce qui va avec alors que l'on peut
programmer directement la BCU
On 30 juil, 13:36, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> D'après Opternus les BIM 11x sont obsolètes.
> C'est pour ça que je me suis dirigé vers les BIM13x.
> Peut être que je fait fausse route...
>
> On 30 juil, 12:43, jef2000 <jef2...@ouaye.net> wrote:
>
> > Je pense que le but de Marcha n'est pas de coupler un 6805 à la BCU
> > mais d'utiliser le 6805 contenu dans la BCU pour faire tourner ses
> > propres applications.
> > Les BIM M13x sont à base d' uC NEC et je n'ai pas encore entendu
> > parler de développement 'artisanal' sur ce type de platforme.
> > Les BIM M11x par contre, sont à base de 6805 et il existe un SDK
> > opensource permettant de développer des applications ( bcusdk )
>
> > L'approche consistant à utiliser le programme standard de la BCU2 pour
> > communiquer en FT1.2 avec un second uC est tout aussi valable que
> > celle consistant à développer une application directement pour la BCU.
> > Le choix de l'une ou l'autre approche dépend de ce qu'on veut en
> > faire.
>
> > On 30 juil, 10:14, "stephane.herr...@gmail.com"
>
> > <stephane.herr...@gmail.com> wrote:
> > > Salut,
> > > Si j'ai bien compris tu veux coupler un uC 6805 avec un coupleur de
> > > bus (type BIM M113)? La liaison se faisant graçe au protocole FT1.2?
> > > Je travail aussi dans ce sens. Moi j'utilise les uC Microchip PIC.
> > > Pour l'instant j'étudie le protocole FT1.2 pour réaliser l'interface
> > > la plus simple et la moins coûteuse en mémoire...
> > > Cependant les BIM1xx peuvent être aussi programmés mais le
> > > programmateur vaut très cher (voir opternus.com). le uC est un NEC
> > > inconnu pour moi...
> > > En quel language comptes tu programmer ton uC (C,Basic,
> > > Assembler,...)?
> > > Bon courage et tiens nous au courant de tes avancés!
> > > BR
On 30 juil, 17:00, jef2000 <jef2...@ouaye.net> wrote:
> Le protocole FT1.2 a de
> grande chances d'être supporté dans toutes les BIM ou BCU à venir,
Oui, je crois bien, d'autant plus que FT 1.2a est le protocole de
choix pour les BCU2 et supérieurs.
stephane.herraiz@gmail.com
Unregistered
Effectivement utilisé 2 uC alors qu'un pourrait suffire est un peu
bête...
Je pense que la meilleure idée, mais la plus compliquée, est
d'utiliser un TP-UART (opternus) avec un uC que tout le monde utilise.
La difficulté est d'implémenter tout le protocole EIB dans le uC.
Le TP-UART vaut 10€ et un uC type 18F852 vaut moins de 10€!!! Cela
fait tout compris un module EIB/KNX au alentour de 50€ et avec des
potentialités infinies.
Donc à vos montages!!!
On 31 juil, 09:57, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Cela > fait tout compris un module EIB/KNX au alentour de 50€ et avec des
> potentialités infinies.
Tu es sûr que tu n'as pas pris un raccourci ?
Cela fait quand même un investissment "temps" considérable. Même, si
du point de vue du bricoleur "bricoler" et travailler se confondent
dans un même plaisir. (quand je vois le temps qu'il faut rien que pour
faire une visu +/- correcte...)
Ne pas oublier l'aspect production, car une fois le montage terminé,
il faudra p'têt en fabriquer 20-30... voir 50, qui sait.
Ce commentaire n'est en aucun une critique, que du contraire, tout au
plus un rappel des contraintes matérielles de la vie de tout les jours
dans le cadre d'un projet à long terme.
Ceci dit, vous avez toutes mes sympathies et encouragements.
stephane.herraiz@gmail.com
Unregistered
Oui je suis d'accord c'est très long c'est pour ça que je cherche des
aides un peu partout... :-)
Je travaille depuis 4 ans sur mon projet domotique donc le temps me
fait pas peur! J'ai appris énormément de chose en informatique (j'ai
une formation électronique). J'ai testé plein de techniques, plein de
directions et je pense que je suis plus très loin de LA solution
économique et fonctionnelle.
Je reste très motivé malgrès tout ce temps parce que pour moi c'est
l'avenir et cela sera comparable à l'arrivée de l'ADSL en France...
Donc si quelqu'un a du temps... pour m'aider...
Et puis j'en ai marre de payer un "pauvre relais" EIB 70€!!!! C'est
pas bon pour la démocratisation de la domotique!!!
a++
On 31 juil, 10:30, Marc Assin <raym...@warichet.com> wrote:
> On 31 juil, 09:57, "stephane.herr...@gmail.com"
>
> <stephane.herr...@gmail.com> wrote:
> > Cela > fait tout compris un module EIB/KNX au alentour de 50€ et avec des
> > potentialités infinies.
>
> Tu es sûr que tu n'as pas pris un raccourci ?
> Cela fait quand même un investissment "temps" considérable. Même, si
> du point de vue du bricoleur "bricoler" et travailler se confondent
> dans un même plaisir. (quand je vois le temps qu'il faut rien que pour
> faire une visu +/- correcte...)
> Ne pas oublier l'aspect production, car une fois le montage terminé,
> il faudra p'têt en fabriquer 20-30... voir 50, qui sait.
>
> Ce commentaire n'est en aucun une critique, que du contraire, tout au
> plus un rappel des contraintes matérielles de la vie de tout les jours
> dans le cadre d'un projet à long terme.
>
> Ceci dit, vous avez toutes mes sympathies et encouragements.
Bravo pour ta motivation.
Je ne peut que t'encourager dans ta quête du Graal!!! 
C'est en tout cas un sujet fort intéressant.
A ce propos, si tu n'as pas déjà eu l'occasion de contacter des
responsables de la suite BCU SDK, n'hésites pas ils sont très bien.
J'ai eu notamment l'occasion d'échanger quelques mails avec Martin
Koegler.
A+
Bon courage.
Si tu comptes développer ton propre stack EIB et arriver à un niveau
de fiabilité équivalent à l'existant, je crois qu'il te faudra compter
en mois de travail (et pas en temps que hobby, à temps plein, 8 heures
par jour)
Une fois le travail achevé, il faudra encore voir si le résultat est
assez stable et résistant aux conditions extérieures (température,
humidité, décharges électro-statiques, .... ) pour rivaliser avec un
produit commercial. Une fois installée, la domotique remplit une
fonction tellement indispensable que la fiabilité est primordiale.
Sans compter qu'installer de la domotique dans un bâtiment est une
plus value lors de la revente, alors qu'installer un système fait-
maison est souvent vu comme une "moins-value".
Conclusion, pour les fonctions vitales de l'installation, je
privilégierai toujours des composants standard soigneusement choisis
pour leur rapport qualité/prix par rapport à un développement fait-
maison. Pour moi, le fait-maison reste un hobby qui peut avoir une
utilité et ajouter du confort à l'installation mais ne doit pas
impacter les fonctions de base en cas de panne.
Enfin, c'est mon opinion personnelle.
Par contre, développer une plateforme (pourquoi pas à base de 18F852)
qui connectée en FT1.2 à une BIM ou BCU peut être facilement adaptée à
toutes sortes d'utilisation serait très intéressant. il serait alors
possible de combiner une série de fonctionnalités dans un seul
participant et de rentabiliser l'achat de la BIM en le répartissant le
coût entre toutes les fonctionnalités qu'elle fournit. Si sur un seul
BIM tu peux connecter un circuit qui pilote plusieurs relais, leds,
capteurs de température, de pression ou je ne sait quoi, tu arrives à
un coût nettement inférieur à tout ce qu'on peut trouver dans le
commerce.
On 31 juil, 11:02, nulix <florent.lesa...@gmail.com> wrote:
> Bravo pour ta motivation.
>
> Je ne peut que t'encourager dans ta quête du Graal!!!
>
> C'est en tout cas un sujet fort intéressant.
>
> A ce propos, si tu n'as pas déjà eu l'occasion de contacter des
> responsables de la suite BCU SDK, n'hésites pas ils sont très bien.
>
> J'ai eu notamment l'occasion d'échanger quelques mails avec Martin
> Koegler.
>
> A+
>
> Bon courage.
Il ne faut pas oublier que tout ceci étant libre, il peut y avoir
plusieurs contributeurs au projet.
Et dans ce cas ceci est réalisable.
Il suffit de mobiliser une communauté autour de cet aspect et un petit
projet ouvert sur une forge...
Et le deuxième avantage est que dans ce cas le produit sera testé,
validé, modifié et approuvé par de nombreuses personnes, ce qui doit
permettre de le rendre sur.
A+
Florent.
stephane.herraiz@gmail.com
Unregistered
Je suis bien d'accord BIM + uC est le plus intéressant!!
Pour un petit projet sous forge je suis d'accord c'est une bonne
idée!!
Pour l'instant j'étudie le protocole EIB depuis mon pc afin de
réaliser un simulateur... et après je me lance!!
Le problème viendra sûrement de la place limitée dans les uC...
On 1 août, 11:30, "stephane.herr...@gmail.com"
> Le problème viendra sûrement de la place limitée dans les uC...
En effet, il y a de fortes chances....
J'ai cru comprendre que c'est une des grosses différences (+ FT 1.2)
entre les BCU1 et BCU2.
Ce manque de mémoire des BCU1 (Merten 690099) m'enpoisonne la vie en
ce sens que le status feed-back est sacrifié lorsqu'on ajoute un
dimmer sur une plaquette de BP Merten. Tant et si bien que j'envisage
de revendre tout mes BCU1 pour racheter des BCU2. Tout çà pour avoir
une Visu cohérente !?! ben oui.
Evidemment le problème ne se voit pratiquement pas en utilisation
manuelle, mais en Visu, c'est foutu.
On 1 août, 15:44, Marc Assin <raym...@warichet.com> wrote:
> Ce manque de mémoire des BCU1 (Merten 690099) m'enpoisonne la vie en
> ce sens que le status feed-back est sacrifié lorsqu'on ajoute un
> dimmer sur une plaquette de BP Merten. Tant et si bien que j'envisage
> de revendre tout mes BCU1 pour racheter des BCU2. Tout çà pour avoir
> une Visu cohérente !?! ben oui.
> Evidemment le problème ne se voit pratiquement pas en utilisation
> manuelle, mais en Visu, c'est foutu.
Je ne comprends pas pourquoi tu as besoin sur une visu d'indication
d'état sur des objets d'entrée. Et je pense que tu peux obtenir la
fonction désirée en collant une seconde adresse de groupe (indication
d'état) sur ton objet d'entrée. Attention il faut qu'elle soit en
seconde position (sans le Envoi=S dans le navigateur d'adresse de
groupe de l'objet concerné)
@+
On 1 août, 17:58, mickg <mickael.gaut...@wanadoo.fr> wrote:
> Je ne comprends pas pourquoi tu as besoin sur une visu d'indication
> d'état sur des objets d'entrée.
Je me suis (encore) mal expliqué.
Ma remarque était à propos des BP 6226xx de Merten. Les BP ont un très
beau backlit vert/rouge suivant l'état du status feedback. Ce status
peut être commandé par le BP lui même (c'est ce que j'ai fait au
début, comme tout débutant) ou bien par l'état de l'actuator commandé
par ce BP (ce qui est nettement plus intelligent, comme me l'a fair
remarquer BVO, en effet, dans ce cas de figure, si l'actuator n'a PAS
fait son travail (DJ en amont sauté) tu le vois sur le BP)
> Et je pense que tu peux obtenir la
> fonction désirée en collant une seconde adresse de groupe (indication
> d'état) sur ton objet d'entrée. Attention il faut qu'elle soit en
> seconde position (sans le Envoi=S dans le navigateur d'adresse de
> groupe de l'objet concerné)
Très intéressant ! à essayer ! mais j'ai peu d'espoir.
J'ai soumis mon problème au support Merten, et après avoir beaucoup
tourné autour du pot, le problème se résume à un manque de mémoire des
BCU1. Ce problème n'est visible QUE dans le cas ou on veux le status
feed-back dans la Visu ET que qu'on a installé un dimmer sur le même
BCU.
D'où ma remarque ci-dessus.
Et la "solution" suggèrée par le support Merten est de remplacer tout
mes BCU1 par des BCU2..... à mes frais :-((( (j'en ai une quinzaine)
Je ne sais pas si je vais vendre les BCU séparément ou les ensembles
complets BCU+BP. Il se trouve que j'aime beaucoup la famille System
Design Artec et que çà me ferais mal de m'en défaire sans trouver une
meilleure alternative.
Merci beaucoup pour ta suggestion.
On s'écarte du sujet de départ, mais bon...
On 2 août, 09:35, Marc Assin <raym...@warichet.com> wrote:
> Ma remarque était à propos des BP 6226xx de Merten. Les BP ont un très
> beau backlit vert/rouge suivant l'état du status feedback. Ce status
> peut être commandé par le BP lui même (c'est ce que j'ai fait au
> début, comme tout débutant) ou bien par l'état de l'actuator commandé
> par ce BP (ce qui est nettement plus intelligent, comme me l'a fair
> remarquer BVO, en effet, dans ce cas de figure, si l'actuator n'a PAS
> fait son travail (DJ en amont sauté) tu le vois sur le BP)
Là, effectivement, je comprends mieux
> Très intéressant ! à essayer ! mais j'ai peu d'espoir.
Essaie quand même. Si la l'état de la led est liée à l'objet 1bit, çà
doit fonctionner
> J'ai soumis mon problème au support Merten, et après avoir beaucoup
> tourné autour du pot, le problème se résume à un manque de mémoire des
> BCU1. Ce problème n'est visible QUE dans le cas ou on veux le status
> feed-back dans la Visu ET que qu'on a installé un dimmer sur le même
> BCU.
Pour une indication d'état dans la visu (tu parles bien d'un
superviseur???), seule l'état de l'objet de sortie importe...
@+
On 2 août, 10:12, mickg <mickael.gaut...@wanadoo.fr> wrote:
> On s'écarte du sujet de départ, mais bon...
On va peut étre nous pardonner :-)
> Essaie quand même. Si la l'état de la led est liée à l'objet 1bit, çà
> doit fonctionner
Ben je crois que c´est le coeur du probleme, pour les dimmers on
utilise 4 bit ou plus et donc on provoque le probleme memoire dans le
BCU
> Pour une indication d'état dans la visu (tu parles bien d'un
> superviseur???), seule l'état de l'objet de sortie importe...
Oui, exact, tu as tout a fait raison.
On peut donc arriver dans une situation ou la Visu dit "allume" et le
PB dit "eteint" (par manque de feed-back)
On 2 août, 14:53, Marc Assin <raym...@warichet.com> wrote:
> Ben je crois que c´est le coeur du probleme, pour les dimmers on
> utilise 4 bit ou plus et donc on provoque le probleme memoire dans le
> BCU
J'ai regardé la db des 6226xx; en fonction dimmer tu as bien 2 objets
par bouton : 1 objet 1 bit ON/OFF et 1 objet 4 bits Variation. Je
pense que l'état de la led est lié à l'objet 1 bit donc si tu mets en
2nde adresse de groupe le retour d'état de la sortie concernée (avec
le flag écriture E activé) la led changera d'état en fonction de la
sortie
> Oui, exact, tu as tout a fait raison.
> On peut donc arriver dans une situation ou la Visu dit "allume" et le
> PB dit "eteint" (par manque de feed-back)
Oui, donc avec ou sans visu, çà ne change rien. Au contraire la visu
donne bien le résultat attendu. Le problème vient de la led du BP.
D'autre part si tu ne fais pas ce retour d'état de la sortie, et que
tu as une commande centrale (groupée) d'éclairage, tu dois te
retrouver certaine fois à appuyer 2 fois sur ton BP pour allumer ou
éteindre ta lampe. Non?
@+
On 2 août, 15:21, mickg <mickael.gaut...@wanadoo.fr> wrote:
> J'ai regardé la db des 6226xx; en fonction dimmer tu as bien 2 objets
> par bouton : 1 objet 1 bit ON/OFF et 1 objet 4 bits Variation. Je
> pense que l'état de la led est lié à l'objet 1 bit donc si tu mets en
> 2nde adresse de groupe le retour d'état de la sortie concernée (avec
> le flag écriture E activé) la led changera d'état en fonction de la
> sortie.
Je crois qu'on ne se comprend pas bien, et d'autre part, le problème
n'était plus très clair dans mon esprit, depuis le temps qu'il
m'enpoisonne la vie.....
alors: RESET, on recommence:
On parle bien des Merten 6226xx montés sur des BCU 690099 (BCU1)
Premier cas de figure: On/Off
On charge l'appli 1540/1 (switch). On configure 1 GA pour On/Off et 1
GA pour le status. Le 6226 montre bien *8* CO (4 pour switch, 4 pour
status). On configure les liens comme il se doit, et çà fonctionne
comme prévu, càd, on appuie sur le PB, la lampe s'allume, et le status
feedback du PB ad-hoc devient rouge. Super, j'aime bien :-)
Deuxième de figure: Dimmer (le sujet de la discussion)
On désire installer un dimmer, commandé par un des PB de la plaquette
On charge l'appli 3190/1 (dim/switch). On paramètre le 6226 pour:
input 1,3,4=switch,
input 2=dim.
Le 6226 montre *5* CO !!! (sw obj pour input 1, sw & dim obj pour
input 2, sw obj input 3, sw obj pour input 4.
IL N'Y A PLUS DE STATUS pour les input 1,3,4 !!!
Ben c'est foutu ! comment veux tu encore configurer quoi que ce soit ?
On ne peut pas accrocher une fonction s'il n'y a pas le CO
correspondant. On est d'accord ?
Donc, ce que je voulais dire: dès l'instant oú tu veux installer un
dimmer sur le PB, tu es obligé de charger l'appli ad-hoc qui prend
toute la place mémoire dans le BCU et donc il n'y a plus de place pour
le status feed-back, et c'est merdu :-(
Qu'est-ce que tu en penses ?
On dirait que je suis le seul Martien à vouloir un status feed-back
cohérent qui colle bien à la Visu.
Du moins chez Merten, ils ont quand même bien tourné autour du pot
avant de livrer leur "solution".
Commercialement parlant, cette "solution" n'est absolument pas
acceptable. Car enfin, voilà un fabricant de grande renommée, qui
avoue une lacune dans son produit (dans un cas de figure bien
particulier, OK, mais quand même) et qui ne veux rien faire pour moi !
J'avais espéré un deal du genre: on échange tout les BCU1 par des BCU2
et vous payez la différence + le transport. Nada.
Chez Gira, ils sont plus sympa, j'avais reçu un BCU FT1.2, DOA ! Ils
m'en ont envoyé un autre DE SUITE, par DHL. J'avais 15 jours pour
renvoyer l'autre, sinon, facturation, alors ... ben j'ai apprécié
(j'ai quand même râlé un peu pour le DOA)
J'ai commandé un BCU2, pour voir la "solution" ;-)
Mais avec Schneider, tout va aller mieux :-))
Bonjour,
je vais installer des boutons Merten sous peu.
Pouvez-vous me donner la référence des BCU2 pour être sur de ne pas me
tromper de référence à la commande.
Merci d'avance
Junior76
On 4 août, 19:05, Marc Assin <raym...@warichet.com> wrote:
> On 2 août, 15:21, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > J'ai regardé la db des 6226xx; en fonction dimmer tu as bien 2 objets
> > par bouton : 1 objet 1 bit ON/OFF et 1 objet 4 bits Variation. Je
> > pense que l'état de la led est lié à l'objet 1 bit donc si tu mets en
> > 2nde adresse de groupe le retour d'état de la sortie concernée (avec
> > le flag écriture E activé) la led changera d'état en fonction de la
> > sortie.
>
> Je crois qu'on ne se comprend pas bien, et d'autre part, le problème
> n'était plus très clair dans mon esprit, depuis le temps qu'il
> m'enpoisonne la vie.....
> alors: RESET, on recommence:
> On parle bien des Merten 6226xx montés sur des BCU 690099 (BCU1)
>
> Premier cas de figure: On/Off
> On charge l'appli 1540/1 (switch). On configure 1 GA pour On/Off et 1
> GA pour le status. Le 6226 montre bien *8* CO (4 pour switch, 4 pour
> status). On configure les liens comme il se doit, et çà fonctionne
> comme prévu, càd, on appuie sur le PB, la lampe s'allume, et le status
> feedback du PB ad-hoc devient rouge. Super, j'aime bien :-)
>
> Deuxième de figure: Dimmer (le sujet de la discussion)
> On désire installer un dimmer, commandé par un des PB de la plaquette
> On charge l'appli 3190/1 (dim/switch). On paramètre le 6226 pour:
> input 1,3,4=switch,
> input 2=dim.
> Le 6226 montre *5* CO !!! (sw obj pour input 1, sw & dim obj pour
> input 2, sw obj input 3, sw obj pour input 4.
> IL N'Y A PLUS DE STATUS pour les input 1,3,4 !!!
> Ben c'est foutu ! comment veux tu encore configurer quoi que ce soit ?
> On ne peut pas accrocher une fonction s'il n'y a pas le CO
> correspondant. On est d'accord ?
>
> Donc, ce que je voulais dire: dès l'instant oú tu veux installer un
> dimmer sur le PB, tu es obligé de charger l'appli ad-hoc qui prend
> toute la place mémoire dans le BCU et donc il n'y a plus de place pour
> le status feed-back, et c'est merdu :-(
>
> Qu'est-ce que tu en penses ?
>
> On dirait que je suis le seul Martien à vouloir un status feed-back
> cohérent qui colle bien à la Visu.
> Du moins chez Merten, ils ont quand même bien tourné autour du pot
> avant de livrer leur "solution".
> Commercialement parlant, cette "solution" n'est absolument pas
> acceptable. Car enfin, voilà un fabricant de grande renommée, qui
> avoue une lacune dans son produit (dans un cas de figure bien
> particulier, OK, mais quand même) et qui ne veux rien faire pour moi !
>
> J'avais espéré un deal du genre: on échange tout les BCU1 par des BCU2
> et vous payez la différence + le transport. Nada.
>
> Chez Gira, ils sont plus sympa, j'avais reçu un BCU FT1.2, DOA ! Ils
> m'en ont envoyé un autre DE SUITE, par DHL. J'avais 15 jours pour
> renvoyer l'autre, sinon, facturation, alors ... ben j'ai apprécié
> (j'ai quand même râlé un peu pour le DOA)
>
> J'ai commandé un BCU2, pour voir la "solution" ;-)
>
> Mais avec Schneider, tout va aller mieux :-))
On 4 août, 19:14, junior76 <afix...@gmail.com> wrote:
> Pouvez-vous me donner la référence des BCU2 pour être sur de ne pas me
> tromper de référence à la commande.
Attention les vélos !
Perso, je ne pense pas que c'est pas comme çà qu'il faut s'y prendre !
Il faut d'abord choisir l'application et ensuite regarder dans le
dernier catalogue, ce qu'il faut pour le faire marcher. Cà se trouve à
la fin de la description du PB désiré.
Le BCU2 est le 690299. Rien ne dit que çà marcher dans ton cas de
figure.
Si tu donnes la ref des PB, on peut vérifier, et il se pourrait bien
qu'il n'y aie que des BCU1 supportés avec une certaine application
On 4 août, 19:14, junior76 <afix...@gmail.com> wrote:
> je vais installer des boutons Merten
Ah, oui, j'oubliais...
Comme mentionné précédemment, si tu veux la db en français, il faut
commander via Schneider
|
