Cross-check keypads KNX
La video montre source KNX et structure Control4 cote a cote avant export.
Le contexte à rendre visible avant Composer
Les labels, ComObjects et entrees binaires aident a comprendre la logique de piece et les scenes. Tous les signaux ne doivent pas devenir des devices Control4.
Flux de travail recommandé
Apres import ETS, keypads et boutons restent visibles. L installateur decide s ils sont contexte ou programmation Composer specifique.
- Garder keypads et boutons visibles comme contexte ETS.
- Separer intention de trigger et creation de lumieres, stores, thermostats et gateways.
- Ne pas changer le tier CoduWorks a cause de nombreux boutons.
Contrôle avant export .codu
Verifier DPT, transmit flag, objets de statut, visibilite gateway et intention reelle de trigger Control4.
Erreurs évitées avec cette approche
Melanger les keypads dans le bulk build cree souvent du bruit, des faux devices ou des controles en double.
Références officielles vérifiées
Les affirmations techniques de cette page restent proches de la documentation officielle KNX, Control4 ou fabricant.
Outils et documentation liés
FAQ
Les keypads KNX comptent-ils comme devices licence?
Non. Le scope compte lumieres, stores, thermostats et gateways KNX/IP. Keypads et boutons restent contexte ou scope separe.
Un bouton KNX peut-il trigger Control4?
Cela peut etre possible selon driver, DPT, transmit flags et modele Composer.
Faut-il creer automatiquement les keypads?
Pas dans le core workflow. Ils sont plutot contexte de revue ou programmation specifique.
Verifier le contexte keypad avant export
Importez ETS, gardez les boutons visibles et exportez un .codu clair pour les devices supportes.