Workflow von Review zu Composer Build
Das Video zeigt den Übergang vom überprüften Projekt zum .codu Export und Build im Composer Driver.
Kontext, der vor Composer sichtbar sein muss
Wenn die KNX Logik erst in Composer sichtbar wird, wird jede Korrektur langsamer. Ein vorgelagerter Review macht Räume, Geräte und Mapping-Entscheidungen früher kontrollierbar.
Empfohlener Arbeitsablauf
Der Ablauf ist Import, KI Verarbeitung, manuelle Prüfung, Export und danach Composer Build mit Report. So bleibt der Driver der Erzeuger, aber nicht der erste Prüfpunkt.
- Räume, Geräte und Namen vor dem Composer Import prüfen.
- Einen .codu Export mit nachvollziehbarer Struktur erzeugen.
- Build Report lesen, bevor Geräte endgültig erstellt werden.
Prüfung vor dem .codu Export
Vor dem Build sollten Namenskonflikte, potenzielle Duplikate, leere Räume und nicht unterstützte Geräte sichtbar sein.
Fehler, die dadurch vermieden werden
Ohne Build Report und Vorabprüfung können vorhandene Geräte überschrieben, doppelt erstellt oder unklar benannt werden.
Verwandte Tools und Dokumentation
FAQ
Was enthält der .codu Export?
Er enthält die geprüfte Control4 Struktur, die der Composer Driver für die Erstellung nutzen kann.
Warum ist ein Build Report wichtig?
Er zeigt, was erstellt wird und wo Konflikte oder vorhandene Namen erkannt werden.
Wird Composer ersetzt?
Nein. Composer bleibt der finale Import- und Build-Ort.
Composer Build vorbereitet starten
Exportiere erst, wenn Struktur, Namen und Gerätezuordnung geprüft sind.