Dal progetto verificato al build Composer
Il video mostra revisione del progetto, export .codu e build nel driver Composer.
Contesto da rendere visibile prima di Composer
Se la logica KNX arriva direttamente in Composer, ogni correzione diventa più lenta. Una revisione precedente rende più chiare le decisioni.
Flusso di lavoro consigliato
Il flusso è import, lavorazione IA, revisione, export .codu e poi build in Composer con report.
- Controllare stanze, dispositivi e nomi prima dell import Composer.
- Generare un export .codu con struttura tracciabile.
- Leggere il build report prima della creazione definitiva.
Controllo prima dell export .codu
Prima del build bisogna vedere conflitti di nomi, duplicati potenziali, stanze vuote e dispositivi non supportati.
Errori evitati con questo approccio
Senza report e revisione si rischiano duplicati, nomi incoerenti e modifiche ripetute dentro Composer.
Strumenti e documentazione correlati
FAQ
Che cosa contiene il file .codu?
La struttura Control4 verificata che il driver userà in Composer.
A cosa serve il build report?
Mostra cosa verrà creato e dove esistono conflitti o nomi già presenti.
Composer viene sostituito?
No. Composer resta il punto finale per importare e creare il progetto.
Avvia Composer con una struttura pronta
Esporta solo dopo aver verificato nomi, stanze e mapping.