Coupleurs de bus EIB/KNX
Marcha
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,
jef2000
http://www.opternus.de/opternus-components/Products.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.
Marcha
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...@gmail.com
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
jef2000
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...@gmail.com
C'est pour ça que je me suis dirigé vers les BIM13x.
Peut être que je fait fausse route...
jef2000
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"
Marc Assin
> 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...@gmail.com
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!!!
Marc Assin
<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...@gmail.com
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++
nulix
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.
jef2000
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.
nulix
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...@gmail.com
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...
Marc Assin
> 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.
mickg
> 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é)
@+
Marc Assin
> 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.
mickg
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...
@+
Marc Assin
> On s'écarte du sujet de départ, mais bon...
> 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)
mickg
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?
@+
Marc Assin
> 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
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 :-))
junior76
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
Marc Assin
> 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
Marc Assin
Ah, oui, j'oubliais...
Comme mentionné précédemment, si tu veux la db en français, il faut
commander via Schneider
mickg
On 4 août, 19:05, Marc Assin <raym...@warichet.com> wrote:
>
> 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 ?
Ce que j'en pense, c'est que depuis les début de l'EIB avec les BCU1,
on fait des retours d'état sur des entrées par une 2nde adresse de
groupe sur un objet de commande 1 bit. Cela sert à bien associer les
leds liées aux entrées (ton cas) et surtout à optimiser une fonction
télérupteur avec commande groupée (le BP inverse l'état de la sortie à
chaque appui)
Quand les 6226xx sont en fonction switch, on peut paramétrer les leds
pour qu'elles soient liées à l'objet de commande (on a à ce moment que
4 adresses de groupes en tout), ou les paramétrer pour que les leds
aient leur propre objet de com (soit en tout 8 adresses) et dans ce
cas on peux faire dire ce qu'on veut aux leds (le temps qu'il fait,
une alarme...)
Donc si je reprends ton exemple :
en sw objet input 1,2,3 ,4 tu mets 2 adresses de groupes. Dans l'ordre
1- les commandes, 2- les retours d'état et tu valides le flag E sur
ces objets.
Normalement les leds vont suivre l'état des sorties.
@+
Marc Assin
> Ce que j'en pense, c'est que depuis les début de l'EIB avec les BCU1,
> on fait des retours d'état sur des entrées par une 2nde adresse de
> groupe sur un objet de commande 1 bit. Cela sert à bien associer les
> leds liées aux entrées (ton cas) et surtout à optimiser une fonction
> télérupteur avec commande groupée (le BP inverse l'état de la sortie à
> chaque appui)
Je comprends bien ton idée et elle m'intéresse très fort, mais je n'y
arrivr pas :-(
Tu dis "Cela sert à bien associer les leds", oui mais je ne les vois
plus ! disparues dès l'instant ou je charge l'appli "dimmer".
Est-ce que tu vois ce que je veux dire ? ou bien est-ce que je suis à
côté de la plaque ?
> Quand les 6226xx sont en fonction switch,
Oui, oui, n'en parlons plus, çà a toujours marchè impec
> en sw objet input 1,2,3 ,4 tu mets 2 adresses de groupes. Dans l'ordre
> 1- les commandes, 2- les retours d'état et tu valides le flag E sur
> ces objets.
>
> Normalement les leds vont suivre l'état des sorties.
Ah, ce serais trop beau, mais je n'y arrive pas
Le Marc Assin rentre dans son trou.
mickg
comprendre (sorry...), c'est que si l'appli 3190/8.0 (dim/swtich) est
chargée, les leds ne fontionnent plus du tout??? Même avec un appui
réel sur le bouton???
@+
Marc Assin
> Ce que tu veux me dire depuis le début,
cabochard :-)))))
> et que j'ai du mal à comprendre (sorry...),
:-) pas de problème :-)
> c'est que si l'appli 3190/8.0 (dim/swtich) est
> chargée, les leds ne fontionnent plus du tout???
Bingo
Si tu veux, je t'envoie un exemplaire
>Même avec un appui réel sur le bouton???
Appui long, court, rien n'y fait. J'ai même failli le coller au mur,
mais vu le prix du bestiau, je me suis abstenu, les murs sont
fragiles :-)
Le plus râlant dans l'histoire, c'est que je trouve le System Design
Artec, très beau, il me convient parfaitement, ce back-lit est super,
je fais des pieds et des mains pour le garder, mais il n'y a pas
moyen. D'ou mon dilemme énoncé plus haut, tout revendre BCU / BCU
+appli, mais pour trouver quoi d'équivalent ???
Sans vouloir rentrer dans une polémique à propos des gouts et des
couleurs, j'ai rien vu qui me botte.
Pour en revenir à notre discussion de départ, j'avais un peu mal
formulé ma remarque, mais entretemps tu as compris: ce n'est pas le
fait de rajouter un dimmer, mais le fait de charger l'appli dimmer qui
est le fond du problème et donc du manque de mémoire qui ne permet
plus la gestion des LED de feed-back.
Est-ce qu'on a fait le tour du problème ?
Et donc la "solution" Merten (tu parles d'une @#?* de solution) reste
la seule alternative ? ( çà me fait quand même un peu mal quelque
part....)
Je suis électronicien de formation (il y a très lontemps) et plus du
tout équippé pour ce genre de truc, sinon, je tenterais bien une
opération à coeur ouvert. Mais c'est p'têt pas aussi simple que de
changer un chip, même en SMD, si l'adressage ne suit pas, c'est foutu
et changer le microcode est hors de ma portée.
Any taker ?
jef2000
> input 2, sw obj input 3, sw obj pour input 4.
Même si tu n'as plus qu'un seul objet par fonction, il est peut-être
toujours possible de faire un feedback.
En effet, supposons que tu as 2 boutons qui commande la même fonction.
Si tu mets la fonction ON avec l'un des boutons, l'autre bouton doit
en tenir compte pour envoyer un OFF at pas un ON si tu appuies dessus.
C'est la base de l'architecture d'objets distribuée EIB. Si ce n'est
pas le cas c'est un bug, pas une limitation des BCU1.
A partir du moment ou le bouton mets à jour son statut en fonction de
ce qui se passe sur le bus, il devrait aussi changer la couleur de la
led. Je peux comprendre que pour des raisons de place mémoire, ils ne
prévoient qu'un seul objet pour les deux fonctions, mais si on mets à
jour cet objet, il doit non seulement mettre à jour l'état de la
fonction mais également la led.
Vérifies quand même que le flag "Ecriture" est activé pour cet objet,
sinon c'est normal que la led ne soit pas mise à jour.
Marc Assin
> Même si tu n'as plus qu'un seul objet par fonction, il est peut-être
> toujours possible de faire un feedback.
> En effet, supposons que tu as 2 boutons qui commande la même fonction.
> Si tu mets la fonction ON avec l'un des boutons, l'autre bouton doit
> en tenir compte pour envoyer un OFF at pas un ON si tu appuies dessus.
Euuh, oui, mais c'est p'têt fait en HW (pas sous contrôle du
microcode)
> C'est la base de l'architecture d'objets distribuée EIB.
Ah bon, jamais entendu parler, ni lu dans les specs, tu me l'aprends.
Les objets distribués, c'est plutot un concept informatique, télécom,
du genre DCOM, non ?
> Si ce n'est
> pas le cas c'est un bug, pas une limitation des BCU1.
Oh oh, tu y vas un peu fort, je ne suis pas sûr que ton hypothèse de
départ est correcte.
> A partir du moment ou le bouton mets à jour son statut en fonction de
> ce qui se passe sur le bus, il devrait aussi changer la couleur de la
> led.
Ben non, je ne crois pas, c'est bien là le coeur de la discussion.
Comme je disais à Mickg, dès l'instant oú tu charges l'appli dimmer,
les obj LED ne sont plus exposés (invisibles dans ETS) et donc, plus
moyen de les attrapper pour y coller une fonction quelconque.
Je veux bien t'envoyer un PB+BCU pour essayer, si tu penses que tu as
une chance de le convaincre (par des moyens pacifiques :-)))
> Je peux comprendre que pour des raisons de place mémoire, ils ne
> prévoient qu'un seul objet pour les deux fonctions,
çà ne me dérange pas trop, c'est le résultat final qui me chagrine
très fort.
> mais si on mets à
> jour cet objet, il doit non seulement mettre à jour l'état de la
> fonction mais également la led.
Oui, mais c'est bien là que nos points de vue divergent, et j'aimerais
bien, ô combien, que tu aies raison.
> Vérifies quand même que le flag "Ecriture" est activé pour cet objet,
> sinon c'est normal que la led ne soit pas mise à jour.
Ce n'était pas le cas, je l'ai fait, sans conviction et sans succès,
snif :-(
jef2000
seconde page.
Effectivement, si avec l'appli dimmer il n'y a plus d'allumage de led
du tout alors c'est foutu. Ou alors tu développes ton programme toi
même qui fais ce que tu veux à l'aide du bcusdk mais bon, il faut
avoir du temps à passer...
Tiens, quelqu'un sait si quand une appli est dans une BCU, on peut
aller lire le code et le désassembler, ou alors il y a des
protections?
Marc Assin
> Ou alors tu développes ton programme toi
> même qui fais ce que tu veux à l'aide du bcusdk mais bon, il faut
> avoir du temps à passer...
genre d'aventure, d'où mon invite " Any taker "?
> Tiens, quelqu'un sait si quand une appli est dans une BCU, on peut
> aller lire le code et le désassembler, ou alors il y a des
> protections?
Si qq a "accés".... à un simulateur / in-line emulator du processeur,
il y a moyen, mais vu le prix de ce genre de bestiau, amha il n'y en
a pas 36 sur la planète. Ou éventuellement via le JTAG, mais ça
suppose l'outil ad-hoc côté PC (retour case départ). Une autre piste:
vu qu'on a accès au code appli, on pourrait le lire et le jouer sur un
émulateur et voir ce qu'il fait.
Marc Assin
dans les BCU ? si possible celui employé dans les Merten 690099.
J'ai pas trop envie de le dézinguer, ils sont toujours sous garantie
Merci
mickg
3190/8.0, il y a un paramètre de fonctionnement des leds (normal ou
inversé).
A quoi sert de mettre un paramètre de fonctionnement si la fonction
est indisponible?????
Il y a bien un bug quelque part (soit dans le programme, soit dans la
page paramètre)
@+
Marc Assin
> Ce qui est étrange c'est que même avec le programme Dim/Switch
> 3190/8.0, il y a un paramètre de fonctionnement des leds (normal ou
> inversé).
???
Je ne vois pas ce paramètre.
J'ai le 3190/1 ver 0.1
Je vais vérifier s'il n'y a pas plus récent, ce PB est toujours vendu
et toujours d'actualité.
> Il y a bien un bug quelque part (soit dans le programme, soit dans la
> page paramètre)
Oh, tu sais, avec un peu de recul, ce n'est pas çà qui me perturbe le
plus. On peut bien comprendre qu'il puisse y avoir un bug par ci par
là, même chez un leader du marché.
Là où je comprends moins, c'est que mon problème est toujours
d'actualité, càd que ce matos est toujours dans le catalogue. Et donc,
tout qui achète ce matos aujourd'hui et qui fait le même setup que
moi, aura le même problème, et la même bête réponse du support Merten
"pas assez de mémoire dans le BCU, nous avons d'autres BCU".
A la limite, je peux encore admettre, mais là où çà ne vas plus du
tout, et qui me rend fou furieux, c'est quand il n'y a aucune volonté
commerciale d'arranger le problème, par exemple via échange de
matériel et payment d'un supplément.
Vous avez sans doute remarqué que j'ai souvent vanté les mérites des
produits Merten et la qualité du support technique, de bonne foi, basé
sur mon expérience personelle. A ma curte honte, je dois faire marche
arrière.
Je ne suis pas prêt de le pardonner, j'ai la rancune tenace.
PS: j'ai escalé mon problème jusqu'au responsable du support
technique, je ne peux pas aller plus loin.
Marc Assin
> 3190/8.0, il y a un paramètre de fonctionnement des leds (normal ou
@mickg
Je viens de faire le download de la dernière db qui semble être
M350_D_GB_NL_E.VD3
OK ? on a la même ?
et je vois que pour le 6226xx l'appli 3190/1 est toujours à la version
0.1
Alors ? comment se fait-il qu'on a des résultats différents ?
J'ai p'têt merdé quelque part, mais je ne vois pas bien où. Tu as une
idée ?
Le paramètre que tu as mentionné est bien présent, mais dans l'appli
"switch", où il a, bien sûr, tout son sens.
Merci d'éclairer ma lanterne.
mickg
Manufacturer: Merten
Application program: Dim/Switch 3190/8.0
Device type: $3190
Program version: 8.0
Certification status: enregistré
Manufacturer: Merten
Name: 6226 xx 4-gang push button
Order Number: 6226 xx B1 TP PN RFN
BAU Type: BCU 1
DIN rail mounting: Non
Bus current (mA): 5
Nous n'avons pas les mêmes version????
Marc Assin
> Beh non pas ok, pour moi la version du prog est 8.0 (3190/8.0).
Aah !
Tu la tiens d'où ?
perso, c'est du site Merten M350_D_GB_NL_E.VD3
keldo
J'ai moi aussi :
1) installé un système EIB dans ma maison.
2) utilisé principalement des PB Merten/Artec
3) l'idée de réaliser mes montages/interfaces EIB parso
... bref, je ne pouvais pas ne pas écrire dans ce sujet !
Alors pour les PB Artec et les BCU, je ne pense pas que changer les
BCU1 en BCU2 apporte quoi que ce soit de plus si on ne change pas en
même temps les plaquettes ARTEC PB.
En effet, dans le catalogue Merten, il y a clairement 2 types de
plaquettes PB ARTEC :
- Les plaquettes à 2, 4, 6 et 8 boutons, qui utilisent des softwares
prévus pour BCU1.
- Les plaquettes MULTIFONCTION à 8 boutons (avec ou sans IR), qui
utilisent un software prévu pour BCU2.
Si on veut utiliser les objets "feedback" en même temps que
différentes fonctions sur les boutons, seules les plaquettes
MULTIFONCTION conviennent, car leur software d'application est prévu
pour utilser la mémoire supplémentaire des BCU2.
Comme les BCU2 sont compatibles (sauf rares exceptions) avec les
applications pour BCU1, placer une plaquette "simple" et son software
sur un BCU2 va fonctionner ... mais exactement comme sur un BCU1, c-à-
d sans la fonction feedback.
Bref, vu la faible différence de prix entre BCU1 et 2, moi je n'ai
finalament acheté que des BCU2 ... et des plaquettes multifonctions.
... Ce qui m'a permis de découvrir avec "joie" que le module info-
display n'est PAS compatible DU TOUT avec les BCU2, et aussi que le
module RS-232 standard (=pas FT1.2) ne fonctionne sur un BCU2 QUE si
le BCU2 a préalablement été programmé pour cela ... dur dur si on
comptait justement s'en servir pour programmer la nouvelle
installation. ;-(
Mais revenons au but premier de ce sujet : la fabrication d'une
interface EIB "perso".
Une recherche sur la toile montre que certains autrichiens se sont
déjà intéressé au problème :
---> voir "KNXcalibur" sur https://www.auto.tuwien.ac.at/projects/hba/
par exemple.
Il existe aussi un ou deux produits dérivés de ce projet mais, dans
tous les cas, il s'agit d'un montage et d'un software assez "lourd" :
- stack EIB complet écrit en C, avec module EIB/IP et divers autres
modules.
- interfaces serie / USB / Ethernet
- "gros" microcontroleur
et le tout documenté principalement en allemand.
Perso, je déchiffre un tout petit peu l'allemand mais pour le reste je
désire réaliser quelque chose de bcp plus simple.
Mon idée de base est la suivante : je possède une chaudière "Buderus"
avec un module de gestion "Ecomatic 3000", le système de gestion date
des années 80 mais, après vérification, on ne fait pas spécialement
mieux aujourd'hui (capteur de température extérieure, 2 circuits de
chauffe dont 1 avec vanne mélangeuse, optimiseur {= décaleur de courbe
de chauffe} pour chaque circuit de chauffe, modes jour/nuit/été,
etc...).
Buderus fabrique une interface EIB pour son nouveau système "Ecomatic
4000" mais ce module coute plus de 200 € et je devrais y ajouter le
prix du nouveau "Ecomatic 4000" - entre 800 et 1000 € ... à ce tarif
là on changerait bien toute la chaudière ... :-((.
Bref, bcp trop cher pour un système qui fonctionnera encore
parfaitement une dizaine d'années.
Je me suis donc mis en tête de fabriquer ma propre interface EIB<--
>Ecomatic 3000.
Comme je suis programmeur mais pas électronicien, je n'y connais pas
encore grand-chose en microcontroleurs.
Au départ, je pensais me lancer dans l'étude des 68-05 et 68-11, une
famille bien connue et documentée sur internet, mais l'apparition des
nouveaux BCU/BIM sur base des puces NEC ainsi que le cruel manque
d'information intéressante pour les débutants sur ces mêmes puces NEC
m'a fait reculer ; finalement l'abondance de projets, exemples et
exercices divers proposés pour la famille des PICs, ainsi que la
disponibilité des excellents cours de "Bigonoff" sur les PIC 16 et 18
m'a décidé pour les puces de Microchip.
Après une période de réflexion, les contours de mon projet "chaudière"
deviennent plus net :
- utiliser le PIC16F877A comme microcontroleur
- utiliser le TP-UART comme interface entre bus EIB et le PIC
- écrire en assembleur PIC16F une version simplifiée (et open-source)
du stack EIB
Le stack EIB simplifié ne supportera sur le bus EIB que la
communication par groupes et la programmation de l'adresse physique,
tout le reste (programmation de l'application, des paramètres, des
associations objets-groupes, ...) sera pour l'instant programmé
directement sur PIC à partir d'un PC car l'acces aux outils
"développeur" pour l'ETS n'est pas financièrement accessible pour
l'instant (tout comme l'ETS lui même, à mon avis ...) pour les
particuliers.
Pour l'instant, je réflèchi sur papier à la structure de ce "stack"
EIB et plus particulièrement à l'algorithme de réception, mais je peux
pas dire que la data-sheet de la puce TP-UART soit un modèle du genre,
surtout à coté des data-sheet de microchip.
Une fois le mini stack EIB fonctionnel, il sera assez simple de
développer n'importe quelle fonctionnalité classique comme un module
de sortie relais ou dimmer, un module d'entrées du type boutons
poussoirs ou capteurs de fenêtres, etc... mais aussi, et c'est bien le
but, d'interfacer des objets pour lesquels il n'existe aujourd'hui
aucune solution EIB correcte ou financièrement abordable (ma bonne
vieille chaudière ...).
Toute aide est bien sur la bienvenue mais je pense que ce sera plus
facile d'en discuter une fois que j'aurai publié une première version
de mon code (même incomplet) sur le web : dans les semaines à venir,
je ne manquerai pas de vous donner le lien.
Keldo.
Marc Assin
> Alors pour les PB Artec et les BCU, je ne pense pas que changer les
> BCU1 en BCU2 apporte quoi que ce soit de plus si on ne change pas en
> même temps les plaquettes ARTEC PB.
Faux
Si tu as lu le début du post tu comprendras pourquoi.
Si tu veux bien, laissons le point en suspens..... le temps de
recevoir le BCU2 et de faire le test. J'ai une quinzaine de ces 6226,
alors avant de tout jeter sur eBay....ce qui me ferais très mal....
> Si on veut utiliser les objets "feedback" en même temps que
> différentes fonctions sur les boutons, seules les plaquettes
> MULTIFONCTION conviennent, car leur software d'application est prévu
> pour utilser la mémoire supplémentaire des BCU2.
Oui, tu as raison
Mais j'ai oublié de mentionner le facteur "temps", mes premiers achats
Merten remontent à 3 ans (de toute façon, à l'époque, je n'avais pas
la connaissance nécessaire pour évaluer correctement les produits), et
puis j'ai toujours continue dans la famille System Design Artec.
Jusqu'au jour oû j'ai connecté un dimmer...bardaff.
Le but de toute cette demarche, c'est de trouver une solution la moins
chère possible: tout jeter et tout racheter n'est pas une solution
pour moi. Racheter rien que des BCU2 et garder les plaquettes est
quand même mieux.
> ... Ce qui m'a permis de découvrir avec "joie" que le module info-
> display n'est PAS compatible DU TOUT avec les BCU2,
J'ai egalement un info-display qui marche tres bien (commande de
Velux, fenêtre, volets, etc)
Je t'échange volontiers :-)) un BCU2 contre un BCU1 (neuf, dans la
boîte)
>et aussi que le
> module RS-232 standard (=pas FT1.2) ne fonctionne sur un BCU2 QUE si
> le BCU2 a préalablement été programmé pour cela .
Tiens, je ne suis pas tombé dans ce piège à con, j'ai dû le rater par
distraction :-))
Par contre j'avais commandé un FT1.2 de Gira, DOA, remplacé sur le
champ, mais quand même une semaine de retard :-(
>.. dur dur si on
> comptait justement s'en servir pour programmer la nouvelle
> installation. ;-(
On ne peut pas mieux dire
Et je ne suis pas sur que ce soint bien indique tel quel, dans les
specs.
Alors, les grand esprits qui recommandent de bien lire la doc....
> Buderus fabrique une interface EIB
qui a très bonne réputation sur les forums allemands
keldo
connecter sur les BCU "flush mount" (=montage en blochet dans le mur).
Je possède un 6813-xx de Merten que j'ai bien observé.
Le bestiau ne comporte que :
- 4 opto-coupleurs
- 4 circuits "discrets" pour l'adaptation des voltages entre TTL et
RS-232 V24 (c-à-d le passage de 0/5V à -12/+12V)
Bref, ce module est une sotre de MAX232 avec isolation optique, c'est
tout.
J'en ai aussi tiré une deuxième conclusion : la seule et unique
différence entre un Merten 6813-xx et un 6814-xx (module RS-232 pour
BCU1 et module RS-232 FT1.2 pour BCU2) doit tenir à la valeur d'une
simple minuscule résistance CMS pour indiquer le type PEI au BCU,
point final.
Et encore, dans le 6814-xx, Merten pourait enlever la moitié de son
montage optocoupleur et TTL<>V24, car en FT1.2 on n'utilise pas les
signaux RTS/CTS ...
Bon, moi je sens que je vais pas tarder à souder un petit switch et
une deuxième résitance dans ce bidule, histore de pouvoir choisir
entre mode série "ancien style" et mode FT1.2.
Keldo
keldo
> > Buderus fabrique une interface EIB
>
> qui a très bonne réputation sur les forums allemands
Oui, et bien elle peut l'avoir, bonne réputation, parce que avec mes
200 €, j'étais loin du compte ... après vérification sur eibmarkt,
elle est 405 € cette petite carte, toujours sans compter le prix d'une
nouvelle régulation ...
Bon, pour revenir à mon petit projet d'interface perso (c'est tout de
même ça le sujet premier de cette discussion), je viens de voir que
Stephane Herraiz a un projet similaire avec peut-être un PIC comme
CPU. ;-)
Alors Stephane, en plus de la datasheet pour la puce TP-UART, je
possède un livre sur le protocole EIB :
- EIB, installation Bus System
- Sauter Dietrich Kastner
- Edition Publicis
C'est le seul livre suffisement "technique" que j'ai pu trouvé sur
l'EIB traduit en anglais, il n'est pas d'une clarté limpide, surtout
pour moi qui n'aime pas particulièrement le langage C mais on peut en
tirer suffisement d'info pour décoder une bonne partie des télégrammes
qui passent sur le bus et avec un minimum de "capture" de télégrammes
sur un bus en fontionnement, je pense pouvoir réaliser mon stack EIB
simplifié sans trop de diffculté.
Si tu as des questions, n'hésite pas, je répondrai dans la limite de
mon temps disponible ... (bref pas bcp).
Je dis ça car tu sembles disposer d'encore bcp moins d'informations
que moi :
> Pour l'instant j'étudie le protocole EIB depuis mon pc afin de
> réaliser un simulateur... et après je me lance!!
Pour ce qui est de la place mémoire dans les microcontroleurs, je ne
pense pas que ce soit trop un problème quand on on voit la place
ridicule dont on dispose dans le 68HC05 des BCU 1 : 6K de rom, 176
bytes de ram ...
Mais bien sur, cela limite fortement le nombre d'objets, de groupes et
d'associations possibles.
Pour mon projet "chaudière", j'ai calculé qu'un 16F877A serait sans
doute suffisant (environ 30 objets de comm. et une centaine d'adresses
de groupe max) avec ses 8 K de rom et 368 bytes de ram, mais je ne
compte pas supporter certaines parties de la norme EIB, comme par
exemple les télégrammes "longs" qui peuvent comporter jusqu'à 62 bytes
de donnée.
Pour le futur, on peut aussi imaginer des projets un peu plus "lourds"
en mémoire mais il faudra alors passer sur des puces PIC18 voir PIC24
et dsPIC. J'y pense aussi mais pour l'instant c'est trop tôt.
Keldo
stephane...@gmail.com
internet!!!
C'est marrant j'ai passé commande de ce livre il y a une semaine mais
je ne l'ai pas encore reçu...
Je pense que cette idée est très intéressante parce qu'elle permettra
de développer un accès au bus "amateur"!
Pour l'instant, je connais assez bien le PIC 16F876. Je le programme
en C avec le compileur CCS mais celui-ci n'est pas gratuit...
Sur quel outil tu te bases pour développer sur les pics?
J'utilise aussi un bootloader.
Si j'ai bien compris ton projet est de développer une interface au bus
EIB en utilisant le protocole EIB et pas le protocole FT1.2? Je pense
que c'est une bonne chose malgré les remarques comme quoi c'est un
projet trop difficile...
A+
keldo
On 9 août, 10:05, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Je pense que cette idée est très intéressante parce qu'elle permettra
> de développer un accès au bus "amateur"!
système EIB aux hobbyistes que nous sommes.
La deuxième étape sera de décoder le format des
fichiers .vd2/.vd3/.vd4 afin de pouvoir les utiliser dans un futur
clone d'ETS open-source, ou bien de créer nos propres fichiers .vd*
pour nos interfaces faites maisons et pouvoir les configurer dans ETS.
Cette étape sera sans doute plus difficile si l'EIBA ne nous aide pas
mais on verra bien, je suis déjà curieux de voir leur réaction face à
l'apparition de petites interface faite maison.
> Pour l'instant, je connais assez bien le PIC 16F876. Je le programme
> en C avec le compileur CCS mais celui-ci n'est pas gratuit...
> Sur quel outil tu te bases pour développer sur les pics?
Entre un 876 et un 877, la transition est plus que facile, pour ma
part, j'ai préfèré prendre le modèle avec un petit peu plus de mémoire
car comme je n'ai pas beaucoup d'expérience je vais sans doute
gaspiller de la mémoire dans mes premières réalisations.
Je ne suis pas un grand copain du C que je trouve assez peu lisible,
alors, à tout prendre, je me suis lancé directement en assembleur.
J'utilise "bêtement" MPLAB IDE et l'assembleur inclus, le tout étant
gratuit - merci Microchip.
Je ne suis encore qu'un grand débutant avec les microcontroleurs, mais
avec les cours de Bigonoff (gratuits sur le web) cela me semble
vraiment facile à utiliser.
> J'utilise aussi un bootloader.
Oui, pourquoi pas, c'est sans doute très pratique, mais pour l'instant
je suis très content de la facilité de (re-)programmation des PIC in-
situ permise par l'ICD2 : on retire le montage du bus, on enlève 5
petits jumpers, on branche les 5 fils de l'ICD2 sur les pinoches des
jumpers et hop l'affaire est faite.
A terme, j'aimerais aussi pouvoir implémenter la programmation des
tables et de l'application via le bus EIB, à ce moment là le
bootloader ne sera plus très utile, mais dans un premier temps ce sera
sans doute une bonne idée d'utiliser un bootloader pour tous ceux qui
utilisent un programmateur avec socket ZIF, ce qui oblige de retirer
le PIC du montage à chaque fois.
> Si j'ai bien compris ton projet est de développer une interface au bus
> EIB en utilisant le protocole EIB et pas le protocole FT1.2? Je pense
> que c'est une bonne chose malgré les remarques comme quoi c'est un
> projet trop difficile...
Oui et non, cela dépend comment on relie le PIC au bus EIB.
Si on utilise un transceiver du type FZE 1065/1066 comme sur les bon
vieux BCU et BIM 11x, ou si l'on construit soit-même son transceiver
en composants discrets, le PIC doit alors tenir compte de nombreuses
contraintes temporelles afin de respecter toutes les règles de
priorité d'acces au bus et la résolution des conficts. Au total, cela
donne une gestion des interruptions et des timers très complexe et je
ne suis pas sur que la famille des PIC16F soit bien équipée pour cette
tâche (il y trop peu de timers disponibles et un seul niveau de
priorité dans les interruptions), pour ce genre de projet je prendrais
plutôt un PIC24 ou un dsPIC, mais c'est de tout façon trop complexe
pour moi actuellement.
Par contre, moi je pense utiliser un TP-UART comme interface avec le
bus, ce qui simplifie beaucoup les choses et reduit grandement les
contraintes temporelles. Je ne connais pas bien le protocol FT1.2 mais
à mon avis interfacer un PIC avec un TP-UART ou avec un BCU en mode
FT1.2 représente quasiment le même travail.
Je pense que du point de vue prix, l'option BCU est plus cher mais ce
n'est pas certain vu les quelques composants qu'il faut ajouter autour
de la puce TP-UART.
J'ai acheté 8 TP-UART chez Opternus mais je ne suis pas encore assez
loin dans mon projet pour commencer à souder quoi que ce soit pour
l'instant.
Dans un premier temps, je vais tester les réponses de mon PIC en
simulant le TP-UART (et donc le BUS EIB) avec le port série de mon PC,
ensuite je penserai au hardware.
Marc Assin
> Cette étape sera sans doute plus difficile si l'EIBA ne nous aide pas
> mais on verra bien,
Lors de la création de ce forum, j'ai invité plusieurs spécialistes du
monde EIB à visiter notre forum.
Steven fait partie de l'EIBA et nous fait le plaisir nous rendre
visite de temps et de nous prodiguer ses bons conseils.
keldo
> internet!!!
Vu que nous avons deux projets très proches, ce serait bête de ne pas
partager nos efforts alors, si tu es d'accord, je te propose le schéma
suivant :
1) On crée un nouveau sujet dans ce groupe de discussion, qui sera
dédié à la conception d'une couche de communication EIB pour
microcontroleur PIC 16Fxxx.
2) Dans les jours qui viennent je devrais avoir le temps de finir de
mettre par écrit mes premières idées d'algorithme ainsi que une
ébauche de programme pour PIC.
3) Durant cette période, j'espère que tu auras reçu ton exemplaire du
livre sur l'EIB, tu verras, dans notre cas, c'est clairement le
chapitre 3 qui est le plus utile.
4) Je compte ouvrir un mini site web ou je déposerai les quelques
fichiers de mes premiers essais afin que tu puisses tester, comparer
avec ta vision des choses et éventuellement modifier pour un usage
avec le protocol FT1.2.
OK pour toi ? Suggestions ?
> C'est marrant j'ai passé commande de ce livre il y a une semaine mais
> je ne l'ai pas encore reçu...
Oui, il est pas trop mal mais ce n'est pas encore le pied, il reste
beaucoup de zones d'ombre, qu'il faudra éclairer par un petit peu
d'analyse du contenu des télégrammes sur un bus en fonctionnement.
L'idéal serait peut-être la documentation officielle de l'EIBA, heuu
pardon KONNEX, mais je pense que l'acces est payant et trop cher pour
un particulier. Il faudrait voir, il y a peut-être moyen d'obtenir un
droit d'acces à la documentation à titre "scientifique/éducatif" vu
que notre démarche n'a pas de but commercial (enfin, pour l'instant,
en tout cas).
Le siège de KONNEX est à Bruxelles, il faudra que je passe leur rendre
une petite visite d'information un de ces jours.
Steven
Non, je n'ai pas le droit de vous passer les specifications.
En plus, il-y-a des fabricant dans le KNX Association qui vendent le
stack commercielle. Il ne m'est pas permis de faire concurrence,
evidemment.
Mais, vous posedez deja de beaucoup d'information et on peut trouver
beaucoup sur Internet.
Les fabricants KNX et le KNX Association sont naturellement des
societes commercielles, alors, le support vers eux a la priorite.
Quand-même, si vous avez des problemes, je peut ajouter quelques mots,
donner un lien, ... sans garanti naturellement, et peut-etre ca prend
quelques jours.
keldo
> Vous pouvez aussi bien poser les questions ici. Ca evite le voyage ;-)
>
> Non, je n'ai pas le droit de vous passer les specifications.
> En plus, il-y-a des fabricant dans le KNX Association qui vendent le
> stack commercielle. Il ne m'est pas permis de faire concurrence,
> evidemment.
Bonjour Steven et merci de votre réponse.
C'est assez normal pour une société dont le but premier est de faire
des bénéfice de ne pas tout donner gratuitement ...
De mon coté, je pensais plus au projet "EIB scientific partnership",
dont l'université TU Wien fait partie, et je me demandait ce qui se
cache derrière ce logo, quelles sont les conditions d'acces, etc.
Peut-être les conditions d'acces à titre "scientifique" sont elles
plus abordables financièrement (250€ ?), non pas pour un particulier
mais peut-être pour un groupe d'une dizaine de particuliers
(développeurs entousiastes) réunis en une petite association et prets
à mettre une petite somme d'argent (50€ chacun, par exemple) pour
avoir acces aux outils et à la documentation complète.
Reste encore à trouver la dizaine de développeurs entousiastes ...
pour l'instant il y en a peut-être 2 ou 3 ... :-/
> Mais, vous posedez deja de beaucoup d'information et on peut trouver
> beaucoup sur Internet.
Il y a aussi le reverse engeneering (=étudier les télégrammes sur le
bus) qui reste encore autorisé en Europe (merci mon dieu :-))) ), sauf
peut-être en France avec la loi DADVSI :-(( , j'en attends beaucoup
pour combler le manque d'information.
> Quand-même, si vous avez des problemes, je peut ajouter quelques mots,
> donner un lien, ... sans garanti naturellement, et peut-etre ca prend
> quelques jours.
Un tout grand merci pour cette proposition.
Ce que je me demande pour l'instant, c'est quel serait la position
"légale" d'un stack EIB/KNX complétement open-source?
Admettons que une ou plusieurs personnes écrivent un stack EIB "ex-
nihilo" à partir d'informations librement disponibles et de reverse
engeneering. (en gros, ce que je désire faire ... ;-)).
Tant qu'il s'agit d'une création purement logicielle, et vu que
l'union européenne ne reconnait pas (enfin, pas encore aujourd'hui,
merci mon dieu - bis ) les brevets sur les logiciels, je ne pense pas
que cela puisse poser un problème, mais je me demande tout de même
quelle serait la position de l'association KNX ?
Aux USA, je serais sans doute déjà en prison depuis longtemps pour
terrorisme intellectuel, mais bon c'est un autre débat... (ça y est,
ce groupe de discussion est maintenant sur la liste rouge de la NSA).
Vu que les participants et les logiciels "faits maisons" ne seraient
pas certifiés KNX, il serait assez logique que les fabricants
officiels de participants EIB/KNX se dégagent de toute responsabilité
en cas de problème sur le bus mais je me demande si il pourrait y
avoir d'autres conséquences "légales" ou techniques ?
Encore une chose : Je tiens particulièrement à dire un grand merci à
Steven de prendre la peine de participer à ce forum EIB/KNX en
français (je suis tout fou de l'avoir découvert, je me pensais
condamné à l'allemand) alors que, manifestement, sa langue maternelle
n'est pas le français.
Ludovic50750
celui ci tout de meme.
Voila, j'hesite encore entre EIB et solution "faite maison", basée sur
aucun protocole connu.
Ceci dit, l'investissement "temps" de la solution maison n'est pas
négligeable.
A l'heure actuelle, sans parler de l'investissement "temps", ma
solution maison me couterais environ 60-70 Euros pour une carte 8
entrées/ 8 Sorties variateur (900W par sortie, carte basée sur un PIC,
avec gestion par un PC voire une carte "maitre").
Je sais que ce n'est pas dutout le meme esprit que le KNX, mais j'y
vient.
Il est tout a fait envisageable dans ma solution "maison" de séparer
les parties entrées des parties "sorties" (ou commande , comme on
veut!).
Ceci dit, je viens vous parler de cela, car j'ai chiffré à environ
4500 euros une solution clé en mains EIB/KNX pour ma maison, avec
installation et parametrage par moi-meme.
La meme solution, me reviendrait à moins de 1000 euros en fait maison
(facteur "temps de developpement" non compris evidemment !).
Je me demandais donc dans quelle mesure les modules de developpement
BIM 12 (je crois qu'ils s'apellent comme celà), couplées à des
interfaces de puissance "maison" pourraient etre interessantes ?
(j'avoue, le KNX a un grand point fort, qui est son BUS facile a
installer et a priori fiable !!).
Si je remplace mon PIC par un BIM qui ,si j'ai bien compris, couterais
une 30aine d'euros, j'arrive à une carte de commande 8 sorties pour un
cout de 100 euros, ce qui reste plus que raisonnable par rapport aux
150 euros pour 3 sorties que demandent Siemens ou Hager ?
Enfin, il reste un facteur qui est totalement inconnu de moi : la
partie logicielle : comment s'interface donc une carte "perso" au bus
EIB (ou au BIM 12) ?
J'espere ne pas avoir été trop hors-sujet, et ne pas vous avoir
embetté avec mes soucis de porte-monnaie percé ;)
Steven
supporter le lein entre les écoles et unversités, mais ne permet pas
que les résultats sont utilisés pour des but commercials. De l'autre
côté, ç'est vraiment réservé pour les écoles et les universités, pas
pour des initiatives privés, même en groupe. Vous pouvez lire plus
sur: http://www.knx.org/knx-partners/scientific/about/.
Alors, je crains que ce n'est pas une possibilité pour vous. Reste le
fait comme indiqué qu'on peut trouver déjà pas mal d'information
online.
Reverse engineering ne doit pas être nécessaire. Si je me trompe pas,
le lien http://www.knx-developer.de/online/eitt22/disk1.exe (et allez
chercher aussi disk2) permet de télécharger l'outil EITT 'demo), qui
sait analyser chaque telegrame. Mais ETS 3 donne déjà le même detail.
Qule information est-ce qu'il vous manque?
Un stack entièrement open source ne poserait pas de problème. Notez
juste que:
- Ca n'existe pas encore aujourd'hui. Une grande parti du stack n'est
utilisé qu'au moment que ETS vas télécharger le produit. C'est a ce
moment que ça devient plus grands, plus difficile, et ou la pluspart
des initiatives abandonent.
- Un produit dévelopé comme ça, ne peut porter le logo KNX (trademark)
que après certification par KNX Association, qui garanti la
conformance aux specifications. Alors, sans logo, c'est possible.
- Maintenant, il faut être prudent. Sans certfication, pas de logo KNX
en naturellement pas de support par ETS. Ca n'évite pas de developer
quelque chose, et même pas de le lancer sur le marché. Mais ... pour
une implementation efficace du software et du hardware, il est
possible que vous prenez des solutions qui sont protégés par un
"intellectual property right". Chose pareille n'est pas particulier
pour KNX: mon PC et ma voiture en sont plain. Mais ce sont des aspects
dont chaque developeur doit être conscient, en KNX ou autre part.
Alors, du long que ça reste un initiative limité, pour propre usage,
je vois pas trop de problème. Pout une déclaration officielle quand-
même, veuillez vous addresser officiellement par écrit à
l'Assoication.
D'autres conséquence légales?
1. Si vous developez un actionneur de fenêtre qui écrase la petite
main de la copine de votre fille... les parents peuvent vous prendre
responsable...
2. Si vous developez un dimmer 230 V, qui devient trop chaud et met la
maison en feu ... les assurance peuvent vous prendre responsable...
Chaqu'un _peut_ developer des produit et du logiciel, mas pas tout le
monde a le drot de le fair. Moi, je peut pas faire le plan de ma
maison, car je ne suis pas architecte, et je ne le peus pas
construire, parce que je ne suis pas un enrtreprise de construction.
Alors, vous restez responsable.
Bonne continuation!
keldo
On 10 août, 14:21, Ludovic50750 <l.lemari...@gmail.com> wrote:
> Voila, j'hesite encore entre EIB et solution "faite maison", basée sur
> aucun protocole connu.
Pour une solution "maison" déjà bien aboutie, tu peux sans doute
jetter un oeil sur le projet "DomoCAN" de Bigonoff :
http://www.abcelectronique.com/bigonoff/index.php (il faut un tout
petit peu chercher sur son site).
Il a développé des modules dimmer, ON/OFF et boutons poussoir sur base
du bus CAN avec des PIC.
Il a aussi créé un logiciel de paramétrage et de controle.
Le tout est disponible gracieusement sur son site, avec le plan des
cartes, le code pour les PIC, le protocol, etc.
Le bus CAN est standardisé (mais pas la couche protocole domotique de
Bigonoff, évidement), il existe beaucoup de puces compatibles avec le
bus CAN et il est très fiable (développé à l'origine pour l'industrie
automobile, il est aussi utilisé pour les communications des éléments
"critiques" comme la gestion moteur ou le déclanchement des airbags).
Pour ma part, je préfère l'EIB pour sa grande flexibilité de cablage
(topology-free), alors le CAN est un bus au sens strict du terme (un
seul long cable avec résistance de fin de ligne à chaque extrémité) et
est donc beaucoup moins simple à installer dans une maison, mais il
reste toujours possible de relier plusieurs bus CAN ensemble avec des
passerelles actives.
> Ceci dit, je viens vous parler de cela, car j'ai chiffré à environ
> 4500 euros une solution clé en mains EIB/KNX pour ma maison, avec
> installation et parametrage par moi-meme.
Oui, l'EIb à beaucoup de qualité mais il reste encore assez cher pour
un particulier, par contre c'est un produit idéal (à mon avis) pour la
gestion de batiments administratifs (bureaux) car une installation est
dans ce cas très vite remboursée par les économie d'éclairage et de
chauffage.
D'un autre coté, il faut comparer des poires avec des poires :
Pour une maison unifamilliale, entre une installation électrique
traditionnelle et une install EIB, y a pas photo point de vue prix
mais les fonctionalités sont très différentes et l'installation
traditionelle sera quasi impossible à "upgrader" pour plus de
fonctions.
Parcontre, si l'on compare une installation EIB avec une installation
où toutes les lampes sont sur télérupteur, le cablage 230V est en
étoile et que l'on a ajouté 2 ou 3 fonctions "centrales" (= OFF
général pour chaque étage, pour le jardin et un OFF général pour la
maison) la différence au niveau facture diminue en dessous de 10 à
15%.
> Je me demandais donc dans quelle mesure les modules de developpement
> BIM 12 (je crois qu'ils s'apellent comme celà), couplées à des
> interfaces de puissance "maison" pourraient etre interessantes ?
> (j'avoue, le KNX a un grand point fort, qui est son BUS facile a
> installer et a priori fiable !!).
> Si je remplace mon PIC par un BIM qui ,si j'ai bien compris, couterais
> une 30aine d'euros, j'arrive à une carte de commande 8 sorties pour un
> cout de 100 euros, ce qui reste plus que raisonnable par rapport aux
> 150 euros pour 3 sorties que demandent Siemens ou Hager ?
Du point de vue développement perso sur base du bus EIB, il n'existe
pas encore grand chose aujourd'hui, pour la très bonne raison que tout
l'environnement de développement officiel n'est accessible que aux
membres de l'association Konnex (anciennement EIBA) et que l'acces est
payant à des tarifs prohibitifs pour un particulier.
Il existe depuis assez peu de temps un kit de développement pour BCU/
BIM open source mais je ne sais pas si beaucoup de francophones s'y
sont déjà essayés, donc il te faudra sans doute bien connaitre
l'anglais et/ou, beaucoup mieux, l'allemand.
Pour le kit, va voir sur le site : https://www.auto.tuwien.ac.at/projects/hba/
et regarde le projet "BCU SDK".
Le gros avantage des BCU/BIM est que se sont des composants officiels
de l'EIB/KNX et qu'une part du travail est donc déjà faite, mais cela
limite la place disponible en mémoire dans le microcontroleur embarqué
du BCU/BIM ainsi que les ports I/O disponibles. Dans ton cas, si tu
développe tes propres circuits imprimés, un BIM convientdra mieux que
un BCU, il y a plus de ports /IO disponibles.
Par contre, du point de vue prix, 30 euros me semble fort optimiste,
moi je dirais plutôt le double.
Deuxième option, développer avec un microcontroleur de son choix.
Le problème principal étant ici de coder le protocol EIB (qui est déjà
présent dans les BIM et BCU).
L'association Konnex (=KNX, = EIBA) ne vend pas le stack de
communication EIB aux particuliers.
Il existe au moins un firme qui vend un stack EIB en C pour quelques
microcontroleurs, je ne connais pas le prix.
Il existe aussi un stack EIB open source en C, tu peux regarder le
projet KNXCalibur, sur la page dont j'ai donné le lien précédement.
Enfin, il est aussi possible d'écrire soit même un stack EIB, c'est le
projet que je désire mener à bien.
MAIS, il y a un grand MAIS !!!
Le plus gros problème (actuel) avec les "fabrications maisons" EIB en
hadrware et/ou en software, c'est la partie implémentation de
l'installation, car jusqu'à preuve du contraire, toute la
configuration d'une installation EIB se fait avec le logiciel (payant
et relativement cher pour un particulier) ETS.
Certaines mauvaises langues diront que l'on trouve assez facilement
des versions "crackées" d'ETS mais le problème n'est pas vraiment la.
Le vrai problème, c'est que l'ETS a besoin pour fonctionner de petits
fichiers "xxx.vd2, ou xxx.vd3 ou xxx.vd4, ces petits fichiers
contiennent un description complète de chaque appareil connecté au bus
EIB, comment le programmer, quelles sont ses options, quel sont ses
objets de communications, etc.
Bref, pour chaque type d'appareil et/ou de logiciel "fait maison" que
tu fabriqueras, tu devras aussi créer un fichier .vd*
correspondant ... et bien entendu, la suite logicielle qui permet la
création des fichiers .vd* est uniquement disponible pour les membres
(payants) de l'association Konnex.
Au total, actuellement, fabriquer un ou deux module EIB "maison" et
les ajouter a une installation EIB "officielle" est possible moyennant
quelques petites limitations mais il est peu réaliste de faire toute
une installation avec des modules maisons.
Mais l'avenir n'est pas totalement plombé : toujours sur la même page
web donnée plus haut, il y a un lien vers "Basys 2003", qui est un
logiciel open source qui se propose de remplacer ETS, mais ses
fonctionalités sont encore fort maigres aujourd'hui ...
Keldo
keldo
On 10 août, 14:45, Steven <steven.debru...@konnex.org> wrote:
> Le "KNX Scientific Partnership" est naturellement établi pour
> supporter le lein entre les écoles et unversités, mais ne permet pas
> que les résultats sont utilisés pour des but commercials. De l'autre
> côté, ç'est vraiment réservé pour les écoles et les universités, pas
> pour des initiatives privés, même en groupe. Vous pouvez lire plus
> sur:http://www.knx.org/knx-partners/scientific/about/.
> Alors, je crains que ce n'est pas une possibilité pour vous. Reste le
> fait comme indiqué qu'on peut trouver déjà pas mal d'information
> online.
OK, tant pis pour nous...
> Reverse engineering ne doit pas être nécessaire. Si je me trompe pas,
> le lien http://www.knx-developer.de/online/eitt22/disk1.exe (et allez
> chercher aussi disk2) permet de télécharger l'outil EITT 'demo), qui
> sait analyser chaque telegrame. Mais ETS 3 donne déjà le même detail.
> Qule information est-ce qu'il vous manque?
Oui, j'ai installé le EITT en version demo. Je ne sais pas encore si
le programme nous sera utile mais le fichier d'aide contient beaucoup
d'informations intéressantes, dont le descriptif du télégramme pour
chaque type d'objet EIS, c'est justement ce que je cherchais avec
précision, merci beaucoup.
Marc Assin
> Alors pour les PB Artec et les BCU, je ne pense pas que changer les
> BCU1 en BCU2 apporte quoi que ce soit de plus si on ne change pas en
> même temps les plaquettes ARTEC PB.
Je viens de recevoir mes BCU 690299 et j'espèrais reprendre le fil de
cette discussion.
Premier test: bardaff :-((
Pas de status feedback object.
L'application envoyée par mail de la part du support Merten, ne
correspond pas à la procédure décrite par cette même personne....
Tout va bien: retour case départ, et râle un bon coup.
Marc Assin
La saga des BCU et PB Merten: suite & fin
> > Alors pour les PB Artec et les BCU, je ne pense pas que changer les
> > BCU1 en BCU2 apporte quoi que ce soit de plus si on ne change pas en
> > même temps les plaquettes ARTEC PB.
Après avoir insisté un peu .... je viens de recevoir une nouvelle
appli pour mes BCU 690299 et donc je reprend le fil de cette
discussion.
Premier test: OK
Il y bien status feedback object (lorsqu'il est demané au niveau des
param)
On peut donc mélanger un Switch et un Dimmer sur la même plaquette de
PB tout en conservant le feed-back. C'est Noël avant l'heure :-)
Yapluka acheter 13 autres 690299 et mettre mes 690099 aux riquettes :-
(
@Keldo
pour reprendre ton argument: ce serais quand même dommage s'il faut
tout changer à chaque fois. Je trouve que çà annule le but premier
d'un système modulaire. Mais là où tu avais raison, c'est qu'il faut
changer l'appli, sans doute pour bénéficier des avantages (mémoire)
des BCU2
keldo
> Après avoir insisté un peu .... je viens de recevoir une nouvelle
> appli pour mes BCU 690299 et donc je reprend le fil de cette
> discussion.
>
> Premier test: OK
> Il y bien status feedback object (lorsqu'il est demané au niveau des
> param)
> On peut donc mélanger un Switch et un Dimmer sur la même plaquette de
> PB tout en conservant le feed-back. C'est Noël avant l'heure :-)
Super, il m'intéresserait bien aussi, ce fichier d'appli ...
Mais alors, pour le coup , je ne comprends plus quelle différence il y
a entre les plaquettes 6227 avec 8 boutons "multi-fonctions" et les
plaquettes 6226 avec 8 boutons "tout court" ... mis à part les 10
euros en moins dans mon portefeuille, bien entendu.
Tu utilises quel modèle de plaquettes toi ? 6223/4/5/6/7ou 8 ?
Sais-tu par hasard si cette application spéciale est "toute neuve", ou
bien existe depuis longtemps mais n'est pas distribuée pas Merten sur
leur site Web ?
Moi, je trouve qu'il y a un manque criant d'un objet de communication
sur toutes ces plaquettes : un moyen d'allumer et d'éteindre par le
bus les leds vertes de rétroéclairage. Sur les 6227, on peut utiliser
le 9ième bouton (le rectangle sous le cadre transparent de
l'étiquette) à cet effet, mais par le bus : rien, schnoll, nada ...
c'est pas prévu.
Pourtant, en journée, ces petites leds vertes consomment pour rien et
j'aurais bien programmé mon horloge pour les allumer et les éteindre
selon les heures de lever et coucher du soleil ...
Réponse traditionnelle du service technique de Merten à ma requète :
"pas assez de place mémoire dans le BCU 2", ça me semble tout de même
bizarre, dans l'appli du 6227 il y a je ne sais combien d'objets de
comm. réservés pour des scènes, il suffirait de laisser l'utilisateur
choisir si il désire utiliser toutes les scènes ou non, et hop, on
gagnerait un objet ...
> Yapluka acheter 13 autres 690299 et mettre mes 690099 aux riquettes :-(
Pas trop vite, ça peut encore servir ces petites chose là ...
--> avce le BCU sdk, on peut sans doute les transformer en modules
logiques universels (sans ajouter de plaquette).
--> moi je veux bien en reprendre un ou deux, mais bon, faut voir le
cout du colis jusqu'en Belgique ...
--> ça se vend pas trop mal sur eBay
--> les info-displays ne sont pas compatibles avec les BCU2 alors tu
peux toujours acheter quelques info-displays ... ;-)
> @Keldo
> pour reprendre ton argument: ce serais quand même dommage s'il faut
> tout changer à chaque fois. Je trouve que çà annule le but premier
> d'un système modulaire. Mais là où tu avais raison, c'est qu'il faut
> changer l'appli, sans doute pour bénéficier des avantages (mémoire)
> des BCU2
Si les fabricants, comme Merten, publiaient les specs complètes de
leurs "plaquettes" à boutons, et pourquoi pas aussi le code source de
leurs applications, tout un chacun pourrait ré-écrire sa petite
application perso pour avoir les fonctionnalités de ses rêves.
Il y a la commande des leds "vertes" qui est manquante.
Personellement, je pense aussi que pouvoir programmer un
"clignotement" de chaque led rouge de "feed-back" serait une très
chouette fonction, on pourrait imaginer des applications liées à la
gestion d'alarmes par exemple.
Une autre idée serait un allumage conditionnel des leds rouges selon
la valeur reçue, ainsi on donnerait la même adresse de groupe à 4 leds
rouge "feed-back" mais avec une condition différent pour chaque
"valeur" (valeur= 1, ...=2, ...=3, ...=4), ce serait sympa pour
utiliser les 4 boutons comme contrôle du mode de chauffage (confort,
eco, nuit et hors-gel).
Tout ceci peut être actuellement réalisé à l'aide de modules logiques
(pour le clignotement, c'est la limite du possible...) mais ce serait
plus sympa de laisser cette petite tâche directement au module boutons-
poussoirs.
A mon sens, Merten (comme les autres fabriquants ...) garde ses codes
source par peur de se faire voler son travail par la concurrence, mais
c'est probablement stupide car les modules des autres fabricants sont
différents et leur code source existe déjà ; de plus, si le code
source était ouvert et modifiable par le public, il suffirait d'une
petite poignée de passionnés désirant quelques fonctions particulières
pour que Merten se retrouve tout à coup avec une liste impressionnante
d'applications aux fonctions les plus variées, ce qui rendrait ses
modules boutons-poussoirs encore plus intéressants ... et lui
donnerait sans doute un sérieux bonus en parts de marché.
jef2000
possèdent que 230 bytes de mémoire pour les appli. Avec un programme
de si petite taille, on peut envisager de le comprendre/modifier
directement en assembleur. Je ne suis même pas sûr qu'il existe un
code source autre que l'assembleur quelque part. En tout cas, si
j'étais à la place de Merten, vu la petite taille des BCU1, je ferai
les appli directement en assembleur.
Marc Assin
> Mais alors, pour le coup , je ne comprends plus quelle différence il y
> a entre les plaquettes 6227 avec 8 boutons "multi-fonctions" et les
> plaquettes 6226 avec 8 boutons "tout court" ... mis à part les 10
> euros en moins dans mon portefeuille, bien entendu.
Non, non, c'est pas comme çà qu'il faut le voir.
Je suis persuadé que tu as pris la bonne décision (sans doute, suite à
une analyse plus rigoureuse). De toute façon, qui peut le plus peut le
moins.
Dans mon cas de figure, il y a eu une grosse erreur de jugement dès le
départ, et, comme me l'a fait remarquer "abondamment" le support
Merten, j'ai mal choisi.
Je ne cherche pas à me disculper ou à minimiser ma connerie, mais il
faut se replacer dans le contexte du début: j'avais une excellente
expérience des interrupteurs Merten d'avant EIB (le modèle "touch
sensitiv" avec mémoire et IR, et mon expérience EIB était très modeste
(çà n'a pas beaucoup changé :-)) et donc j'ai tout naturellement opté
pour le matériel Merten, en me focalisant plus sur le design des
boutons que sur le nombre d'objets de communication.
Tout le restant de la saga consiste à ratrapper la mayonnaise. Je suis
un peu têtu (pour ne pas dire franchement cabochard :-)) et j'estime
qu'un device qui est toujours vendu et qui ne marche pas sous
certaines conditions d'utilisation: CE N'EST PAS NORMAL. Je n'ai vu
nulle part dans la doc que si on connecte un dimmer sur la plaquette,
on perd le feed-back sur TOUTE la plaquette. Oh oui bien sûr, on peut
argumenter BCU1-BCU2, mémoire etc, je campe sur mes positions: il
fallait le mettre clairement dans la doc. Autre argument invoqué par
les pros: il faut charger la db et essayer: OK dans mon cas, ce n'est
pas suffisant, il faut le hardware. Donc acheter UNE pièce qu'on
envisage d'employer et la tester, mwouais, encore faut'il penser à
tout les cas de figure, c'est pas gagné.
> Tu utilises quel modèle de plaquettes toi ? 6223/4/5/6/7ou 8 ?
Tous des 622644
> Sais-tu par hasard si cette application spéciale est "toute neuve", ou
> bien existe depuis longtemps
Je ne sais pas. C'est sans doute fort présomptueux de le dire comme
çà, mais je crois qu'elle a été développée à ma demande, pour que je
ferme ma grande .... J'en suis arrivé à cette conclusion, suite aux
échanges de mail (nombreux et houleux)
>n'est pas distribuée pas Merten sur leur site Web ?
Exact.
Néanmoins, malgré tout ces avatars, je persiste à dire que le support
Merten est un des meilleurs à qui j'ai eu affaire. Je ne vais pas
citer ici tout ceux qui sont nuls à c.....r, la liste serait trop
longue :-))
NB: je fais bien la différence entre le support technique et l'équipe
de design ou le marketing.
> Moi, je trouve qu'il y a un manque criant d'un objet de communication
> sur toutes ces plaquettes :
Oui, en effet, c'est dommage et çà m'attriste.
Cà refroidit l'enthousiasme, tant et si bien que je regarde ailleurs
> Pourtant, en journée, ces petites leds vertes consomment pour rien et
> j'aurais bien programmé mon horloge pour les allumer et les éteindre
> selon les heures de lever et coucher du soleil ..
Ha ! génial comme idée, ce serait gag :-)
> Réponse traditionnelle du service technique de Merten à ma requète :
> "pas assez de place mémoire dans le BCU 2",
ENCORE !!! le même argument que le BCU1, mildjû il le font exprès.
J'ai quand même du mal à croire. Dis-moi, toi qui est plus versé
développement, est-ce que l'espace mémoire adressable fait partie des
specs du BCU ?
Formulé autrement; est-ce que en BCU1 on a droit à max 256 bytes; en
BCU2 max 2K etc ???
Si tel n'est PAS le cas, qu'est ce qui empêche le contructeur de
mettre une mémoire plus grande ? quitte à avoir de l'espace perdu ? Le
prix ???, non faut pas rigoler.
> dans l'appli du 6227 il y a je ne sais combien d'objets de
> comm. réservés pour des scènes, il suffirait de laisser l'utilisateur
> choisir si il désire utiliser toutes les scènes ou non, et hop, on
> gagnerait un objet ...
Oui, tout à fait d'accord, c'est bien pour çà qu'ils proposent
plusieurs applis pour le même HW, mais malgré tout, comme tu le fait
remarquer, il y a des lacunes (c'est une lagune comme le golfe de
Gascogne :-))
> Pas trop vite, ça peut encore servir ces petites chose là ...
> --> avce le BCU sdk, on peut sans doute les transformer en modules
> logiques universels
Ah ?!? intéressant :-)
Pour les modules logiques universels, j'ai déjà mon "usine à gaz"
> --> moi je veux bien en reprendre un ou deux, mais bon, faut voir le
> cout du colis jusqu'en Belgique ...
On peut en parler
> --> ça se vend pas trop mal sur eBay
Oui, j'y pense, mais j'attends d'avoir sorti tout les BCU1 pour faire
une offre attractive. Pour l'instant, je n'ai acheté que 2 690299,
just pour valider la solution proposée par le support technique
(suspicion, when you take me...)
> --> les info-displays ne sont pas compatibles avec les BCU2 alors tu
> peux toujours acheter quelques info-displays ... ;-)
Merci, j'en ai déjà un.
> Si les fabricants, comme Merten, publiaient les specs complètes de
> leurs "plaquettes" à boutons, et pourquoi pas aussi le code source de
> leurs applications, tout un chacun pourrait ré-écrire sa petite
> application perso pour avoir les fonctionnalités de ses rêves.
> Il y a la commande des leds "vertes" qui est manquante.
> Personellement, je pense aussi que pouvoir programmer un
> "clignotement" de chaque led rouge de "feed-back" serait une très
> chouette fonction, on pourrait imaginer des applications liées à la
> gestion d'alarmes par exemple.
> Une autre idée serait un allumage conditionnel des leds rouges selon
> la valeur reçue, ainsi on donnerait la même adresse de groupe à 4 leds
> rouge "feed-back" mais avec une condition différent pour chaque
> "valeur" (valeur= 1, ...=2, ...=3, ...=4), ce serait sympa pour
> utiliser les 4 boutons comme contrôle du mode de chauffage (confort,
> eco, nuit et hors-gel).
> Tout ceci peut être actuellement réalisé à l'aide de modules logiques
> (pour le clignotement, c'est la limite du possible...) mais ce serait
> plus sympa de laisser cette petite tâche directement au module boutons-
> poussoirs.
Pffffiouu, hé ben
amha, çà vaudrais la peine de soumettre tes suggestions à Merten à
moins que Schneider soit plus réceptif, ce dont je doute très fort.
> A mon sens, Merten (comme les autres fabriquants ...) garde ses codes
> source par peur de se faire voler son travail par la concurrence, mais
> c'est probablement stupide car les modules des autres fabricants sont
> différents et leur code source existe déjà ;
Oui, c'est vrai, mais çà ouvre la porte au clonage hard et soft et on
change juste l'ID du fabricant
> de plus, si le code
> source était ouvert et modifiable par le public, il suffirait d'une
> petite poignée de passionnés désirant quelques fonctions particulières
> pour que Merten se retrouve tout à coup avec une liste impressionnante
> d'applications aux fonctions les plus variées, ce qui rendrait ses
> modules boutons-poussoirs encore plus intéressants ... et lui
> donnerait sans doute un sérieux bonus en parts de marché.
Oui (...soupir...) on peut rêver.
Mais si déjà ils pouvaient publier correctement et complètement toutes
les specs, je serais déjà pas mal.
Ma petite expérience avec ABB m'a ouvert les yeux, quand je vois la
doc d'un bête US/U, c'est impressionnant. De plus c'est en français,
(ce qui ne m'apporte rien, mais çà peut-être utile à d'autres
martiens).
Dfrog
Dans un monde aussi complexe et complet que KNX, la base d'une
instalation qui tiens la route et qui supportera correctement les
évolutions de vie dans la maison est :
1. une étude sérieuse de la structure de l'instalaltion (besoins,
passages stratégiques, etc...)
2. une recherche approfondie des appareils à mettre en place (ne peut
se faire que si le point 1 est ok et avec beaucoup de travail en
virtuel sur ETS)
3. être clair sur les objectifs attendus d'une telle installation
(faire de la domotique pour faire de la domotique n'est pas
suffisant!)
4. si ces points sont trop compliqués, prendre l'aide d'une
spécialiste (ça coûtera de toute manière moins cher que de devoir
remplacer des composants après quelques années déjà)
Pour l'ouverture éventuelle des contructeurs, il ne faut tout de même
pas oublier que pour offrir des composants de ce type, il a falu des
concepteurs, des programmeurs, des analystes, et pour en faire à des
prix concurrentiel, il faut en produire beaucoup, ce qui implique des
chaînes de procuctions, de la logistique, etc, etc,.. Tout ça se paie!
Je suis convaincu que ce monde va offrir de plus en plus de
possibilité, mais attention, je ne tiens personellement pas à ce qu'il
prenne la voie anarchique et très aproximative des Windows Microsoft
et consort !
Il faut être clair : dans un monde ou plus de 15'000 produits
existent, si une installation ne répond pas à ce qui est attendu, ce
n'est pas la faute des produits, c'est la faute du concepteur de
l'installation en question (ne le prennez pas mal, j'ai aussi mon cota
d'erreurs dans mes bagages !)
Conclusion : Une installation KNX, ça doit se réflechir avec soins, et
plutôt 4 fois qu'une ! Et les produits seornt choisi sur tous les
critères pris ensembles.
Marc Assin
Toujours dans la saga des BCU....
Je viens d'installer un Merten 6226xx programmé en toggle (càd chaque
BP séparément) hé ben, là non plus, pas de status feedback, même pas
pour un seul BP :-(
Donc, il n'y a pas que le dimmer qui empistrouille le bazar.
Conclusion: il faut mettre des BCU 690299 partout si on veut que la
Visu soit cohérente avec les LED.
Je viens de lire
" le retour de status via les
leds qui pose tant de problème à certain ;)"
Ho ! Je me demande qui çà peut bien être
David Aussillou
-----Message d'origine-----
De : domoti...@googlegroups.com [mailto:domoti...@googlegroups.com]
De la part de Marc Assin
Envoyé : jeudi 20 septembre 2007 19:59
À : domotique-EIB
Objet : Re: Coupleurs de bus EIB/KNX
Marc Assin
> qu'est ce BCU 690299 ???
En résumé, condensé, sucré:
C'est un appareil de la marque Merten
Le BCU Bus coupling Unit est (dans le cadre de cette discussion, il
s'agit de bouton poussoirs) le bidule qui fait l'interface entre les
bus EIB et la plaquette applicative (donc en l'occurence les BP).
Le BCU est la partie "intelligente" du système: il contient le
processeur et la mémoire, il est le détenteur de l'adresse physique.
C'est lui qu'on programme à travers ETS.
Historiquement, il y a eu les BCU1 (très limités) puis les BCU2 (plus
évolués) etc.
La discussion portait sur les effets indésirés des BCU1 dû à leur
manque de mémoire et des couillons qui s'acharnet à les faire marcher
quand même dans le cadre de la Visu, où on veut que le status des LED
des BP soit cohérent avec un superviseur domotique.
Si tu n'as pas de superviseur domotique (et n'a pas l'intention d'en
avoir) tu peux t'en foutre royalement.
Voilà: yapluka avaler :-))
David Aussillou
Mais l'explication est parfaite, c'est l'essentiel. Je peux m'endormir moins
bête et je progresse un tout tout tout petit peu dans l'exploration.
Merci
Et désolé d'avoir posé une question un peu stupide et naïve.
Je retiens qu'il faut éviter les BCU1
-----Message d'origine-----
De : domoti...@googlegroups.com [mailto:domoti...@googlegroups.com]
De la part de Marc Assin
Envoyé : jeudi 20 septembre 2007 20:18
À : domotique-EIB
Objet : Re: Coupleurs de bus EIB/KNX
Marc Assin
> Je retiens qu'il faut éviter les BCU1
Hé bé non. C'est pas aussi simple. Comme l'a très justement fait
remarquer Keldo, si tu veux un Merten Info Display, hé ben, tu n'as
pas le choix, çà ne marche qu'avec un BCU1, ce qui est d'ailleurs
recommandé par le fabricant, dans ses specs (je pense qu'il y a
d'autres cas de figure)
D'autre part .... (et c'était ce que je voulais dire dans le post
précédent, j'espère que tu ne l'as pas avalé de travers :-))
Suppose que tu ne veux contrôler des lampes QUE par On/Off, alors,
pourquoi payer 20€ de plus ?
Et si tu as une quinzaine de ces BP ??? 15x20, çà fait pas loin de
300€, éh :-)
Ou éventuellement... suppose que tu as un dimmer parmi les lampes On/
Off, tu perds le feed back sur le BP, oui OK, mais peut-être que çà
n'a aucune importance pour toi ? auquel cas... idem que ci-dessus,
pourquoi payer plus....
Evidemment, si tu fais partie des martiens (les verts à pois rouges),
et que tu as un superviseur domotique (écran de Visu) qui te montre
que la lampe est allumée (parce que le feed back de l'actuator est
couplé à un object de Visu, et donc il te dit la vérité, car la lampe
EST physiquement allumée) et lorsque tu regardes le BP, il te dit
qu'elle est éteinte, mhmmmm, tu risques de pas trop aimer ce bouzouff.
Perso, çà m'énerve au plus haut point, mettre en place un nouveau
système, qui est bancal depuis le départ.
keldo
@ Marc Assin
> > Sais-tu par hasard si cette application spéciale est "toute neuve", ou
> > bien existe depuis longtemps
> Je ne sais pas. C'est sans doute fort présomptueux de le dire comme
> çà, mais je crois qu'elle a été développée à ma demande, pour que je
> ferme ma grande .... J'en suis arrivé à cette conclusion, suite aux
> échanges de mail (nombreux et houleux)
Pfffiou, ça c'est du support ...
Ton expérience m'amène à penser que je devrais insister pour avoir
l'objet de contrôle pour mes petites leds vertes et aussi la
possibilité de faire clignoter les rouges, peut-être qu'ils finiraent
par craquer aussi. <;-))
> > Réponse traditionnelle du service technique de Merten à ma requète :
> > "pas assez de place mémoire dans le BCU 2",
>
> ENCORE !!! le même argument que le BCU1, mildjû il le font exprès.
> J'ai quand même du mal à croire. Dis-moi, toi qui est plus versé
> développement, est-ce que l'espace mémoire adressable fait partie des
> specs du BCU ?
> Formulé autrement; est-ce que en BCU1 on a droit à max 256 bytes; en
> BCU2 max 2K etc ???
Oui, tu as raison, les BCU1 et BCU2, au moins en format "UP" (donc les
6900 99 et 6902 99 à encastrer) sont tous (respectivement) identiques
tant qu'ils ont la même version de "masque" du stack EIB, et il n'y en
a pas 36 différentes ...
Donc, un BCU2, pour une version de masque donnée (il n'y a que la 2.0
et la 2.1), a toujours le même nombre x de bytes disponible en RAM et
en FLASH pour toute application que l'on désire y charger et, je
dirais même plus, ces bytes disponibles sont toujours exactement aux
mêmes adresses.
Mais attention, ce n'est pas vrai pour les modules avec coupleur de
bus intégré, comme le plupart des modules pour rail DIN récents, les
RAM713 Theben ou les nouveaux PB Merten 6283 44 par exemple.
Et l'introduction de la nouvelle gamme de BIM 13x (130,131,132, ...)
qui sont basés sur un tout autre micro-contrôleur (et donc totalement
incompatibles avec les applications existantes) ne va rien simplifier.
Rien ne dit que des BCU basés sur cette nouvelle gamme de BIM 13x
seront prévus d'ailleurs (ou alors ce sont déja les 6232 99 chez
Merten, peut-être...).
> Si tel n'est PAS le cas, qu'est ce qui empêche le contructeur de
> mettre une mémoire plus grande ? quitte à avoir de l'espace perdu ? Le
> prix ???, non faut pas rigoler.
Les BCU1 et 2 sont de modules très standardisés et la mémoire est
entièrement contenue dans le micro-contrôleur, ce n'est pas une option
envisageable ici ...
> > Pas trop vite, ça peut encore servir ces petites chose là ...
> > --> avec le BCU sdk, on peut sans doute les transformer en modules
> > logiques universels
> Ah ?!? intéressant :-)
Bien que ce soit assez ancien (lire : en train de disparaitre des
catalogues), il existe aussi des BCU (uniquement BCU1 je pense) pour
rail DIN, avec le connecteur 10 pins sur le coté.
Ces BCU sont à compléter avec un module applicatif (aussi sur rail
DIN) tel que un module de détection crépusculaire ou un module 4
entrées binaires, etc...
Mais, sauf erreur de ma part, il est aussi possible de les utiliser
seuls, tel quels, et d'y charger une application du type "4 portes ET/
OU", "éclater 1 byte sur 8 bits", etc ...
Chez Merten, le BCU sur rail DIN existe encore sous la ref. 6905 99.
Alors, vu qu'il s'agit du même hardware, il est sans doute possible de
"chipoter" une case mémoire pour transformer un 6900 99 en 6905 99
afin que ETS accepte d'y charger les petites applications logiques.
Et si le "chipotage" n'est pas possible, on peut toujours écrire sa
propre application avec le BCU-sdk, rien n'empèche en effet d'utiliser
un BCU sans plaquette applicative, mais ce sera moins "propre" au
niveau de la configuration par ETS.
> Pour les modules logiques universels, j'ai déjà mon "usine à gaz"
Ca a l'air intéressant, à l'occasion, il faudra que l'on en parle,
mais j'ai déja pas mal de fers au feu pour l'instant.
> Pffffiouu, hé ben
> amha, çà vaudrais la peine de soumettre tes suggestions à Merten à
> moins que Schneider soit plus réceptif, ce dont je doute très fort.
Vu la façon dont Schneider fait valoir ses droits sur des brevets
"logiciels" idiots, je doute en effet fort ; pour Merten je n'ai
aucune idée mais il viennent de se faire acheter, donc il n'ont sans
doute plus le pouvoir sur ce genre de décision.
> Ma petite expérience avec ABB m'a ouvert les yeux, quand je vois la
> doc d'un bête US/U, c'est impressionnant. De plus c'est en français,
> (ce qui ne m'apporte rien, mais çà peut-être utile à d'autres
> martiens).
Chez Theben, la doc est pas mal non plus je trouve, même leur folder
de présentation des produits est très complet.
keldo
@ jef2000
> Tu crois vraiment qu'il faut le code source pour ça? Les BCU1 ne
> possèdent que 230 bytes de mémoire pour les appli. Avec un programme
> de si petite taille, on peut envisager de le comprendre/modifier
> directement en assembleur. Je ne suis même pas sûr qu'il existe un
> code source autre que l'assembleur quelque part. En tout cas, si
> j'étais à la place de Merten, vu la petite taille des BCU1, je ferai
> les appli directement en assembleur.
Oui, pour les BCU1 et 2, la plupart des appli sont certainement
écrites en assembleur ; d'ailleurs la possibilité d'écrire les
applications en C est un des arguments de vente des BIM 13x ... (qui
ont franchement plus de mémoire).
Mais faire du désassemblage n'est pas le moyen le plus facile de
comprendre le protocole en entre le BCU et la plaquette boutons-
poussoirs ni la fonction des différents paramètres modifiables de
chaque appli et leur lien avec les option des objets dans ETS.
Quitte à faire du reverse-engineering, je serais plutôt partisan de
mettre un petit sniffer sur les pinoches du PEI pour voir comment
"parler" à la plaquette boutons-poussoirs et ensuite d'écrire une
application complètement originale, cela permet d'obtenir exactement
le résultat recherché (dans la limite des possibilités du BCU...) et
aussi d'éviter les probables problèmes de copyright d'une version
modifiée d'une appli "officielle" existante.
Reste encore et toujours le même problème au final (si ce n'est le
manque de temps pour faire tout cela) : comment générer un
fichier .vd3 ou .vd4 pour intégrer tout cela "joliment" et
"proprement" dans ETS. Vu le prix du kit officiel et du billet
d'entrée pour la certification pour une application, il y a intérêt à
être une sacrée tripotée de petits martiens (variante bleus, à fleurs
rose fluo 8-)) intéressés par le projet pour partager les frais.
Haaa si seulement il y avait un 50aine d'heures dans chaque
journée ....
Marc Assin
@Keldo
> Ton expérience m'amène à penser que je devrais insister
15 jours après ... bam... bam...bam...
1 mois après ... bam... bam...bam... çà commence à monter dans la
hierarchie du support ... bam... bam...bam...
(il y en a 1 des 2 qui casse avant l'autre).
> peut-être qu'ils finiraient par craquer aussi.
Pendant 20, j'ai été de l'autre côté de la barrière; j'en ai retiré
quelques enseignements dont la technique du pieux Franki... :-)
Que la demande soit fondée ou pas n'a que peu d'importance, il arrive
un moment où ils en ont tellement marre de toi qu'il font quelque
chose, pour ne plus t'entendre ;-)
> tant qu'ils ont la même version de "masque"
Tu as une idée de ce que c'est le "masque" ?
Ma vision du masque: c'est le dessin microscopique du µP (agencement
des pistes et des composants au niveau silicium) qui sert pour les
procédé photo de fabrication
> Chez Theben, la doc est pas mal non plus je trouve,
J'hésite pour Theben. J'ai encore en mémoire la saga des premières
stations météo, .... c'est pas à leur honneur (il y a des dizaines de
posts sur les forums allemands)
mickg
On 21 sep, 22:55, keldo <kelderm...@ibelgique.com> wrote:
> Reste encore et toujours le même problème au final (si ce n'est le
> manque de temps pour faire tout cela) : comment générer un
> fichier .vd3 ou .vd4 pour intégrer tout cela "joliment" et
> "proprement" dans ETS. Vu le prix du kit officiel et du billet
> d'entrée pour la certification pour une application, il y a intérêt à
> être une sacrée tripotée de petits martiens (variante bleus, à fleurs
> rose fluo 8-)) intéressés par le projet pour partager les frais.
Peut-être faut-il se tourner vers le projet BASys 2003
http://www.auto.tuwien.ac.at/~oalt/basys/ les fichiers .vdx sont
remplacés par des .xml
keldo
> J'emploie la technique du pieux Franki... bam... bam...bam...
Je vais m'y appliquer.
Dis, ça ne donne pas un peu mal à la tête, le "bam bam bam", à la
longue ? ;-)
> Tu as une idée de ce que c'est le "masque" ?
Dans le cas des BCU, c'est simplement le numéro de la révision
(=version) du logiciel/stack EIB.
Donc : 1.0, 1.1 et 1.2 pour la technologie BCU 1.
Et aussi : 2.0 et 2.1 pour la technologie BCU 2.
Le changement du numéro "majeur" (1.x vers 2.x) de la version du
logiciel s'étant accompagné d'un changement de type de microcontrôleur
(celui des BCU2 à plus de flash et plus de ram).
Donc BCU1=version 1.x , BCU2=version 2.X.
Jusque la, tout était simple car, le stack EIB occupait toujours les
même "cases" en mémoire et l'appel des fonctions du stack EIB par
l'application se faisait de la même manière, le processeur et le
logiciel des BCU2 est compatible avec les applications écrites pour le
BCU1 dans la quasi-totalité des cas (sauf quelques détails comme la
vitesse du cristal ) ; c'est pourquoi on peut presque toujours
utiliser un BCU2 à la place d'un BCU1 (mais les applications pour BCU1
qui tiennent compte du temps vont sans doute aller un peu trop
vite ...).
Le logiciel du BCU2 intègre bien sur des fonctions supplémentaires,
comme le protocol. FT1.2 par exemple.
Comme la place en mémoire des BCU1 était vraiment très limitée, les
programmeurs de l'époque ont pris de "mauvaises" habitudes, comme par
exemple de faire lire à l'ETS certaines informations directement à
certaines adresses mémoire du microcontrôleur au lieu d'appeler une
fonction du BCU pour y répondre (c'est le cas du numéro du vendeur, du
numéro de modèle de l'appareil et de la version du masque du stack
EIB, entre autre).
Mais voila, l'électronique et la société de consommation étant ce
qu'elles sont, le microcontrôleur vedette et bon marché d'il y a 10
ans est aujourd'hui totalement dépassé et leur fabriquant fait sans
doute payer bien cher le fait de devoir continuer à les fabriquer en
assez petite série pour quelques malheureux (enfin pas trop...)
vendeurs de matériel EIB.
Bref, une nouvelle gamme de BIM arrive aujourd'hui : la série des 13x.
Comme c'est un tout autre microcontrôleur, le stack EIB a du être
complètement réécrit pour ce nouveau support, mais - et c'est la que
cela se complique - les fonctionnalités de ce stack pour BIM 13x sont
restés les mêmes que celles de la dernière version sur les anciens
microcontroleurs, la version du masque est donc inchangée (2.1, sauf
erreur) ; de plus les informations que l'ETS lisait directement en
mémoire du BCU ne sont plus du tout sauvées dans les mêmes
emplacements mémoire, le stack EIB de ces nouveaux modules BIM 13x
contient donc sans doute des routines pour reconnaitre certains ordres
de lecture en mémoire et y "mentir" afin d'envoyer l'information
effectivement recherché par l'ETS. Voila pourquoi "bidouiller", avec
le BCU-SDK, la mémoire de modules EIB récents ne fonctionne sans doute
pas.
En gros, on aura peut-être bientôt un BCU3 mais avec le masque 2.X ...
Et il y aura peut-être plusieurs applications différentes pour les
même fonction du même module bouton-poussoir selon le type de BCU sur
lequel il est enfiché.
L'avenir risque bien d'être confus quant au choix du bon BCU pour tel
ou tel module applicatif ...
> J'hésite pour Theben. J'ai encore en mémoire la saga des premières
> stations météo, .... c'est pas à leur honneur (il y a des dizaines de
> posts sur les forums allemands)
J'aime bien Theben car ils ont souvent des applications très complètes
et de bonnes idées (la série Mix par exemple), mais je dois dire que
le coup du RAM-713 et 713S (il n'y a probablement aucune différence de
hardware entre les deux mais les nouvelles fonctions ne sont - pour
l'instant du moins - pas disponible pour le modèle sans "S") ne me
plait pas trop non plus.
J'ai vu qu'il y avait quelques petites variations entre la nouvelle et
l'ancienne station météo (le capteur de pluie par exemple) mais je ne
savais pas que les anciennes posaient problème ... je songeais même à
en installer une chez moi un de ces quatre ...
Y z'ont fait quoi comme bêtises avé leur vielle station météo ???
Marc Assin
> Dans le cas des BCU, c'est simplement le numéro de la révision
Pfiouu !
Merci pour l'explication
> J'aime bien Theben car ils ont souvent des applications très complètes
> et de bonnes idées (la série Mix par exemple),
J'ai regardé d'un peu plus près, c'est vrai que l'appli à l'air très
complète.
Ce concept de modules qui s'enfichent, c'est pas mal.
Perso, j'aime pas trop, parceque il faut pas mal d'espace DIN continu,
et donc le prévoir à l'avance (le planning est un gros problème en
rénovation).
Concrètement: tu installes un DMG 2 et un DME 2, impec. Six mois
après, tu changes d'avis et tu voudrais rajouter un 2ième DME 2, pas
de change, il y a déjà un autre module à droite du 1er DME 2, et tu
n'as pas envie de tout dézinguer...
> le coup du RAM-713 et 713S ne me plait pas trop non plus.
Décidément, tout les grands fabriquants ont l'un ou l'autre "couac" à
leur actif :-(
> Y z'ont fait quoi comme bêtises avé leur vielle station météo ???
Justement, le capteur de pluie.... qui a merdé lamentablement dans sa
première version. Il fallait y verser un seau d'eau pour que çà marche
(c'était un capeur de pluie pour baignoire :-)))