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.
@+
On 4 août, 21:30, mickg <mickael.gaut...@wanadoo.fr> wrote:
> 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.
Ce que tu veux me dire depuis le début, et que j'ai du mal à
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???
@+
On 5 août, 09:04, Marc Assin <raym...@warichet.com> wrote:
> On 4 août, 21:30, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > 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.
On 5 août, 09:36, mickg <mickael.gaut...@wanadoo.fr> wrote:
> Ce que tu veux me dire depuis le début,
:-) oui, je suis un peu têtu :-) pour ne pas dire franchement
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 ?
> 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.
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.
On 5 août, 10:54, jef2000 <jef2...@ouaye.net> wrote:
> Même si tu n'as plus qu'un seul objet par fonction, il est peut-être
> toujours possible de faire un feedback.
Merci de t'intéresser à mon problème
> 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 :-(
Oups, j'ai raté quelques messages... J'avais pas vu qu'il y avait une
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?
On 5 août, 16:13, Marc Assin <raym...@warichet.com> wrote:
> On 5 août, 10:54, jef2000 <jef2...@ouaye.net> wrote:> Même si tu n'as plus qu'un seul objet par fonction, il est peut-être
> > toujours possible de faire un feedback.
>
> Merci de t'intéresser à mon problème
>
> > 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 :-(
On 5 août, 17:19, jef2000 <jef2...@ouaye.net> wrote:
> 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...
Ben oui, on est bien d'accord. Je ne suis pas du tout armé pour ce
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.
Est-ce qq peut me dire le / les type(s) de microcontroller employés
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
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é).
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)
@+
On 5 août, 18:13, Marc Assin <raym...@warichet.com> wrote:
> Est-ce qq peut me dire le / les type(s) de microcontroller employés
> 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
On 6 août, 10:53, mickg <mickael.gaut...@wanadoo.fr> wrote:
> 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.
On 6 août, 10:53, mickg <mickael.gaut...@wanadoo.fr> wrote:
> 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
@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.
Beh non pas ok, pour moi la version du prog est 8.0 (3190/8.0).
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????
On 6 août, 17:07, Marc Assin <raym...@warichet.com> wrote:
> On 6 août, 10:53, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > 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
>
> @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.
On 6 août, 17:37, mickg <mickael.gaut...@wanadoo.fr> wrote:
> 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
Bonjour à tous.
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.
On 8 août, 02:15, keldo <kelderm...@ibelgique.com> wrote:
> 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
Tiens, en passant, un petit commentaire sur les modules RS-232 à
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
>
> > 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.herraiz@gmail.com
Unregistered
Super de pouvoir trouver des gens motivés par la même idée!! vive
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+
On 8 août, 16:06, keldo <kelderm...@ibelgique.com> wrote:
> > > 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
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"!
Oui, c'est une première étape importante pour réellement ouvrir le
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.
On 9 août, 15:42, keldo <kelderm...@ibelgique.com> wrote:
> 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.
On 9 août, 10:05, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Super de pouvoir trouver des gens motivés par la même idée!! vive
> internet!!!
Tout a fait d'accord avec toi.
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.
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.
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.
On 10 août, 09:10, Steven <steven.debru...@konnex.org> wrote:
> 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
Unregistered
Je sais pas si mon post sera hors sujet, mais il est en relation avec
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é 
|
