Control4 KNX Build Report Vorschau
Das Video zeigt ein geprueftes .codu Paket, das in Composer geladen wird. Der Driver zeigt den Buildplan vor der Erstellung.
Kontext, der vor Composer sichtbar sein muss
Der Build Report ist die letzte Pause zwischen gepruefter KNX Struktur und realen Aenderungen in Composer.
Empfohlener Arbeitsablauf
ETS importieren, mit AI verarbeiten, Control4 Struktur pruefen, .codu exportieren und den Build Report im Driver lesen, bevor Erstellung gestartet wird.
- Raeume, Lichter, Jalousien, Thermostate und KNX/IP Gateways gegen das gepruefte .codu Paket vergleichen.
- Action Summary lesen, bevor der Create-only Lauf startet.
- Bei falschen Zahlen oder Warnungen zur Review Ebene zurueckgehen.
Prüfung vor dem .codu Export
Zu pruefen sind Buildings, Floors, Rooms, gezaehlte Lichter, Jalousien, Thermostate, Gateways, gematchte Devices, uebersprungene Eintraege und Duplikatwarnungen.
Fehler, die dadurch vermieden werden
Ohne sichtbare Action Summary kann ein falscher Name oder Raum viele doppelte Geraete erzeugen.
Geprüfte offizielle Quellen
Technische Aussagen auf dieser Seite bleiben nah an offizieller KNX-, Control4- oder Herstellerdokumentation.
Verwandte Tools und Dokumentation
FAQ
Was ist der Build Report?
Die Composer Driver Zusammenfassung dessen, was das .codu Paket erstellen, ueberspringen oder melden will.
Ist das Projekt PDF dasselbe?
Nein. Das PDF dokumentiert die Review. Der Build Report ist der letzte Check vor Erstellung in Composer.
Was tun bei falschem Report?
Build nicht starten, Struktur korrigieren, neu exportieren und erneut pruefen.
Build Report als letzten Composer Check nutzen
Verarbeite ETS mit AI, exportiere .codu und pruefe den Build Report vor dem Driver Lauf.