KNX Keypad Cross-Check
Das Video zeigt KNX Quelle und Control4 Struktur nebeneinander, damit Keypads und Devices vor Export geprueft werden.
Kontext, der vor Composer sichtbar sein muss
Keypad Labels, ComObjects und Binaereingaenge helfen, Raumlogik und Szenen zu verstehen. Nicht jedes Signal sollte automatisch ein Control4 Device werden.
Empfohlener Arbeitsablauf
Nach dem ETS Import bleiben Keypads und Taster sichtbar. Der Installer kann entscheiden, ob sie nur Kontext sind oder projektspezifische Composer Programmierung brauchen.
- Keypads und Taster als ETS Kontext sichtbar halten.
- Trigger Intent von Licht-, Jalousie- und Gateway-Erstellung trennen.
- Den CoduWorks Lizenz-Tier nicht wegen vieler Taster erhoehen.
Prüfung vor dem .codu Export
Pruefe DPT, Transmit Flag, Statusobjekte, Gateway Sichtbarkeit und ob der Button wirklich ein Trigger fuer Control4 sein soll.
Fehler, die dadurch vermieden werden
Wenn Keypads in den Bulk Build gemischt werden, entstehen oft Rauschen, Fake Devices oder doppelte Controls statt klarer Programmierung.
Geprüfte offizielle Quellen
Technische Aussagen auf dieser Seite bleiben nah an offizieller KNX-, Control4- oder Herstellerdokumentation.
Verwandte Tools und Dokumentation
FAQ
Zaehlen KNX Keypads als Lizenzgeraete?
Nein. Der Core zaehlt Licht, Jalousien, Thermostate und KNX/IP Gateways. Keypads und Taster bleiben Kontext oder separater Scope.
Kann ein KNX Taster Control4 triggern?
Das kann moeglich sein, haengt aber von Driver, DPT, Transmit Flags und Composer Modell ab.
Sollten Keypads automatisch erstellt werden?
Nicht im Core Workflow. Sie gehoeren meist in Review Kontext oder projektspezifische Programmierung.
Keypad Kontext vor Export pruefen
Importiere ETS, halte Taster sichtbar und exportiere ein klares .codu Paket fuer unterstuetzte Devices.