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.
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!
Bonjour Ludovic.
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
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.
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.
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.
> On 8 août, 02:15, keldo <kelderm...@ibelgique.com> wrote:
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
> 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é.
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.
On 18 sep, 01:40, keldo <kelderm...@ibelgique.com> wrote:
> > 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é.
On 18 sep, 01:40, keldo <kelderm...@ibelgique.com> wrote:
> Super, il m'intéresserait bien aussi, ce fichier d'appli ...
No problem
> 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).
Toutes ces remarques me poussent à en faire une autre :
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.
On 18 sep, 01:40, keldo <kelderm...@ibelgique.com> wrote:
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
Unregistered
Euh pardon d'etre novice ... qu'est ce BCU 690299 ???
-----Message d'origine-----
De : domotique-EIB@googlegroups.com [mailto:domotique-EIB@googlegroups.com]
De la part de Marc Assin
Envoyé : jeudi 20 septembre 2007 19:59
À : domotique-EIB
Objet : Re: Coupleurs de bus EIB/KNX
On 18 sep, 01:40, keldo <kelderm...@ibelgique.com> wrote:
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
On 20 sep, 20:03, "David Aussillou" <da...@aussillou.com> wrote:
> 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
Unregistered
Désolé ... je sens qu'au ton de ta réponse, je suis un grand ignorant.
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 : domotique-EIB@googlegroups.com [mailto:domotique-EIB@googlegroups.com]
De la part de Marc Assin
Envoyé : jeudi 20 septembre 2007 20:18
À : domotique-EIB
Objet : Re: Coupleurs de bus EIB/KNX
On 20 sep, 20:03, "David Aussillou" <da...@aussillou.com> wrote:
> 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 :-))
On 20 sep, 21:04, "David Aussillou" <da...@aussillou.com> wrote:
> 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.
@ 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.
@ 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 ....
On 21 sep, 22:28, keldo <kelderm...@ibelgique.com> wrote:
@Keldo
> Ton expérience m'amène à penser que je devrais insister
J'emploie la technique du pieux Franki... bam... bam...bam...
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)
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
> J'emploie la technique du pieux Franki... bam... bam...bam...
Oui, je vois, excellente image.
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 ???
On 24 sep, 23:33, keldo <kelderm...@ibelgique.com> wrote:
> 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 :-)))
|
