Workflow liste drivers Control4 KNX
La video montre categories KNX, pieces et contexte device avant export Composer.
Le contexte à rendre visible avant Composer
La categorie driver ne suffit pas. Noms ETS, ComObjects, DPT, pieces, feedback et gateway decident si un appareil Control4 peut etre cree proprement.
Flux de travail recommandé
AI Assistant lit le .knxproj, montre categories, patterns connus et objets ambigus, puis exporte un .codu apres revue.
- Separer drivers reseau ou routing des drivers visibles.
- Verifier switch, dimmer, store, thermostat et capteurs contre ETS.
- Utiliser la liste comme checklist, pas comme generation automatique de chaque objet KNX.
Contrôle avant export .codu
Verifier d abord network ou routing gateway, puis lumieres, dimmers, stores, thermostats scopes et contexte gateway. HVAC, RGB, DALI et capteurs doivent etre revus separement.
Erreurs évitées avec cette approche
Une liste de drivers sans revue ETS cree trop de devices, de mauvaises categories et du travail manuel dans Composer.
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
Ou trouver la liste officielle?
Control4 renvoie vers documentation KNX et knowledgebase dealer. Pour un projet, il faut quand meme verifier contre ETS.
CoduWorks replique-t-il toute la liste?
Non. CoduWorks prepare une structure verifiable et cible le build compte sur lumieres, dimmers, stores, thermostats et gateways KNX/IP.
Chaque categorie doit-elle devenir un device?
Non. Certaines categories sont infrastructure, contexte ou signaux de programmation.
Utiliser la liste comme checklist
Importez ETS, verifiez les categories KNX pertinentes et exportez un package Composer plus propre.