ETS Export Quellen Review
Die Vorschau zeigt ETS Projektkontext vor AI Verarbeitung. Teil-Exporte koennen helfen, ersetzen aber nicht die Projektquelle.
Kontext, der vor Composer sichtbar sein muss
Teil-Exporte liefern Adressen und Namen, aber oft weniger Projektlogik. Control4 braucht nicht nur Adressen, sondern den Zusammenhang zwischen Command, Feedback, DPT, Raum und Quelle.
Empfohlener Arbeitsablauf
OPC, ESF oder CSV fuer Lookup und Vergleich verwenden, dann wenn moeglich zur .knxproj Quelle zurueckkehren und erst nach Review .codu exportieren.
- OPC/ESF/CSV als Referenz nutzen, nicht als Standardquelle.
- Weniger Topologie, Geraete und ComObject Kontext als .knxproj erwarten.
- DPT, Feedback und Raumabsicht vor Composer pruefen.
Prüfung vor dem .codu Export
Pruefe, ob DPTs, Feedback Adressen, Raeume, Gateway Kontext und die Gruppierung mehrerer Adressen zu einem Control4 Device klar sind.
Fehler, die dadurch vermieden werden
Eine flache Adressliste kann falsche Devices, fehlendes Feedback, doppelte Controls oder manuelle Korrektur in Composer verursachen.
Geprüfte offizielle Quellen
Technische Aussagen auf dieser Seite bleiben nah an offizieller KNX-, Control4- oder Herstellerdokumentation.
Verwandte Tools und Dokumentation
FAQ
Kann Control4 aus OPC oder ESF gebaut werden?
Nur als Referenz nutzen. Fuer CoduWorks ist .knxproj besser, weil mehr Kontext moeglich ist.
Reicht CSV fuer Mapping?
CSV hilft beim Audit, zeigt aber oft nicht, welche Adressen zusammengehoeren.
Wann nutze ich OPC, ESF oder CSV?
Fuer Lookup, Diagnose oder Vergleich. Fuer .codu Build besser eine prozessierbare .knxproj nutzen.
Teil-Exporte als Checks nutzen
Importiere .knxproj wenn moeglich, vergleiche OPC/ESF/CSV nur als Referenz und exportiere .codu nach Review.