Apercu Control4 driver editor
La video montre des appareils Control4 modifies avec contexte KNX avant export vers Composer.
Le contexte à rendre visible avant Composer
Control4 DriverEditor sert au developpement de drivers. CoduWorks modifie la structure projet issue de KNX: pieces, appareils, noms, sous-types et contexte mapping avant export .codu.
Flux de travail recommandé
Apres import et traitement IA, les noms, pieces, sous-types et mappings sont nettoyes dans l editeur puis exportes.
- Verifier la structure projet, pas lancer un flux SDK DriverWorks.
- Ajuster pieces, noms, sous-types et lignes avant export.
- Voir le contexte source KNX pendant la modification Control4.
- Envoyer au driver Composer un package .codu ferme.
Contrôle avant export .codu
Avant export, les appareils supportes, mappings ambigus et modifications bulk doivent etre visibles.
Erreurs évitées avec cette approche
Si chaque correction arrive seulement apres creation dans Composer, doublons, noms et pieces demandent plus de nettoyage.
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
Est-ce Control4 DriverEditor ou DriverWorks?
Non. DriverEditor et DriverWorks servent au developpement driver. Ce flux modifie la structure Control4 issue de KNX avant le build Composer.
L editeur remplace-t-il Composer?
Non. Composer reste l environnement final. L editeur prepare et verifie avant le build driver.
Que peut-on modifier avant export?
Pieces, noms, sous-types, contexte mapping et modifications en masse.
Pourquoi garder le contexte KNX visible?
Pour verifier que chaque appareil Control4 correspond a sa source, ses adresses et ses datapoints KNX.
Preparer le build driver Control4 avec revue
Nettoyez la structure generee et exportez un .codu pour le driver Composer.