Bonjour, je viens de poster un article à ce sujet sur le groupe Google https://groups.google.com/forum/#!forum/domotique-eib, je le reproduis ici.
Ce week-end, j'ai (enfin !) KNXisé mon module UAP1 (de façon un peu provisoire car le garage concerné doit encore faire l’objet d’aménagements).
J’ai connecté :
* un module de sortie SA/S4.6.1.1 sur les 4 commandes (montée, descente, mise en position intermédiaire, lumière) en utilisant, dans les paramètres de l’application via ETS, une fonction "Temps / Clignotement" qui permet de transformer un télégramme en une impulsion (dans mon cas, un seul cycle de clignotement d’une durée d’une seconde / Ça marche). J'ai ainsi :
- un objet montée/descente : Je l’ai paramétré de telle sorte qu’une valeur "Ouvert" agisse sur la sortie A (connecté à la commande de montée), et un télégramme "Fermé" agisse sur la sortie B (connecté à la commande de descente). Cela me permet de commander tout ça un peu comme des stores / volets. Il me semble (j'ai un doute) avoir constaté qu'on pouvait interrompre la course en envoyant, par exemple, un nouveau télégramme "Ouvert" pendant que le moteur est en train de monter. Même chose à la descente... Par contre, envoyer un "Descente" pendant que le moteur monte, inverse immédiatement le sens de fonctionnement du moteur. Mais tout ça, c'est à cause des principes de fonctionnement du module UAP1... (On obtiendrait la même chose avec des boutons poussoirs montés directement dessus.)
- un objet de commande de position d'ombrage/ventilation. Lui, il fait aller la porte en position entrouverte (position qui se règle sur le moteur, menu 43 du moteur). Dans mon cas, il faut un télégramme "On" sur l'objet. Sur un Off, il ne fait rien (nota : je pourrais pu facilement faire en sorte que ce Off referme la porte...).
- un objet de commande d'éclairage. Là, sur l'UAP1, une impulsion inverse l'état de la lampe (comme un télérupteur). Du coup, c'est pareil lorsque que j'envoie un télégramme "On" sur l'objet correspondant... : ça inverse l'état de la lampe. Le problème avec ça, c'est qu'on ne sait pas dans quel état se trouve la lampe, mais bon, cette lampe s'éteint par défaut au bout de 5 minutes (voir menus 19-20-21 dans la config du moteur). Je n'ai pas vraiment l'intention de m'en servir...
* Un module d’entrée US/U4.2.1 sur les trois sortie indiquant l'état de la porte. (en fait, il y en pourrait y en avoir 6 car les relais ont un contact repos, mais personnellement, j'ai estimé que je n'en avais pas vraiment besoin, que l'absence de contact travail était une suffisamment fiable). Et j'ai mis 3 objets "tout ou rien" :
- un objet Etat position ouverte, qui est sur "On" lorsque le garage est en position ouverte et Off sinon
- un objet Etat position fermée : même chose avec la position fermée
- un objet Etat commande lumière de sécurité. Celui-là, il pourrait servir à savoir que le moteur est en mouvement... cela se paramètre dans le moteur (menu 29). ou à prévenir que le moteur va se mettre en mouvement tout seul (menu 27)
Sinon, quelques réflexions : c'est bien beau cet UAP1, mais c'est encore bien limité en termes de contrôle/commande, par rapport à ce qu'on arrive à faire avec des modules pour volets/stores. Il manque essentiellement une capacité à connaitre ou commander la position absolue de la porte (en %). C'est la base : une fois qu'un module sait faire ça, le reste c'est de l'enrobage... à défaut, on aura beau développer tout ce qu'on veut, à moins d'aller désosser le moteur pour le commander directement (et donc contourner les sécurités... bof), je trouve que tout ça reste assez artisanal. Pourtant, un moteur Hörmann sait manifestement dire "où il est" puisqu'il ajuste des fins de course automatiquement et a une position de ventilation qui se programme, se commande et se contrôle très bien.
Je reste toujours étonné que Hörmann n'ait pas encore développé un module KNX universel qui se brancherait sur son bus et qui offrirait des fonctionnalités "complètes". C'est probablement pas possible, compte tenu de l'architecture de la commande du moteur.
Pour info, une petite société indépendante a développé un module KNX pour moteur Hörmann : https://ing-budde.de/?product=hm-knx
Sauf que, excepté de revenir moins cher que UAP1 + US/U + SA/S et d'éviter des bricolages, ça offre peu près les mêmes fonctionnalités...avec les même limites. En plus, quand je vois apparaître du Falcon, EIBD/KNXD pour le paramétrage, je me dis ouhlàlà, ETS est déjà assez lourdingue, n'en rajoutons pas
Ce week-end, j'ai (enfin !) KNXisé mon module UAP1 (de façon un peu provisoire car le garage concerné doit encore faire l’objet d’aménagements).
J’ai connecté :
* un module de sortie SA/S4.6.1.1 sur les 4 commandes (montée, descente, mise en position intermédiaire, lumière) en utilisant, dans les paramètres de l’application via ETS, une fonction "Temps / Clignotement" qui permet de transformer un télégramme en une impulsion (dans mon cas, un seul cycle de clignotement d’une durée d’une seconde / Ça marche). J'ai ainsi :
- un objet montée/descente : Je l’ai paramétré de telle sorte qu’une valeur "Ouvert" agisse sur la sortie A (connecté à la commande de montée), et un télégramme "Fermé" agisse sur la sortie B (connecté à la commande de descente). Cela me permet de commander tout ça un peu comme des stores / volets. Il me semble (j'ai un doute) avoir constaté qu'on pouvait interrompre la course en envoyant, par exemple, un nouveau télégramme "Ouvert" pendant que le moteur est en train de monter. Même chose à la descente... Par contre, envoyer un "Descente" pendant que le moteur monte, inverse immédiatement le sens de fonctionnement du moteur. Mais tout ça, c'est à cause des principes de fonctionnement du module UAP1... (On obtiendrait la même chose avec des boutons poussoirs montés directement dessus.)
- un objet de commande de position d'ombrage/ventilation. Lui, il fait aller la porte en position entrouverte (position qui se règle sur le moteur, menu 43 du moteur). Dans mon cas, il faut un télégramme "On" sur l'objet. Sur un Off, il ne fait rien (nota : je pourrais pu facilement faire en sorte que ce Off referme la porte...).
- un objet de commande d'éclairage. Là, sur l'UAP1, une impulsion inverse l'état de la lampe (comme un télérupteur). Du coup, c'est pareil lorsque que j'envoie un télégramme "On" sur l'objet correspondant... : ça inverse l'état de la lampe. Le problème avec ça, c'est qu'on ne sait pas dans quel état se trouve la lampe, mais bon, cette lampe s'éteint par défaut au bout de 5 minutes (voir menus 19-20-21 dans la config du moteur). Je n'ai pas vraiment l'intention de m'en servir...
* Un module d’entrée US/U4.2.1 sur les trois sortie indiquant l'état de la porte. (en fait, il y en pourrait y en avoir 6 car les relais ont un contact repos, mais personnellement, j'ai estimé que je n'en avais pas vraiment besoin, que l'absence de contact travail était une suffisamment fiable). Et j'ai mis 3 objets "tout ou rien" :
- un objet Etat position ouverte, qui est sur "On" lorsque le garage est en position ouverte et Off sinon
- un objet Etat position fermée : même chose avec la position fermée
- un objet Etat commande lumière de sécurité. Celui-là, il pourrait servir à savoir que le moteur est en mouvement... cela se paramètre dans le moteur (menu 29). ou à prévenir que le moteur va se mettre en mouvement tout seul (menu 27)
Sinon, quelques réflexions : c'est bien beau cet UAP1, mais c'est encore bien limité en termes de contrôle/commande, par rapport à ce qu'on arrive à faire avec des modules pour volets/stores. Il manque essentiellement une capacité à connaitre ou commander la position absolue de la porte (en %). C'est la base : une fois qu'un module sait faire ça, le reste c'est de l'enrobage... à défaut, on aura beau développer tout ce qu'on veut, à moins d'aller désosser le moteur pour le commander directement (et donc contourner les sécurités... bof), je trouve que tout ça reste assez artisanal. Pourtant, un moteur Hörmann sait manifestement dire "où il est" puisqu'il ajuste des fins de course automatiquement et a une position de ventilation qui se programme, se commande et se contrôle très bien.
Je reste toujours étonné que Hörmann n'ait pas encore développé un module KNX universel qui se brancherait sur son bus et qui offrirait des fonctionnalités "complètes". C'est probablement pas possible, compte tenu de l'architecture de la commande du moteur.
Pour info, une petite société indépendante a développé un module KNX pour moteur Hörmann : https://ing-budde.de/?product=hm-knx
Sauf que, excepté de revenir moins cher que UAP1 + US/U + SA/S et d'éviter des bricolages, ça offre peu près les mêmes fonctionnalités...avec les même limites. En plus, quand je vois apparaître du Falcon, EIBD/KNXD pour le paramétrage, je me dis ouhlàlà, ETS est déjà assez lourdingue, n'en rajoutons pas