openhabforum.de

Ja, wenn Du Trigger für Drücken und Loslassen der Taste hast, kannst Du in openHAB die Zeit zwischen Drücken und Loslassen bestimmen und darüber auch einen Dimmer steuern.

ABER:

Die Rule dafür ist komplex. Beim Drücken muss ein Zeitstempel gesetzt werden. Beim Loslassen muss geprüft werden, ob dieser Zeitstempel weniger als x Millisekunden alt ist (dann war es ein kurzer Tastendruck, welcher den Dimmer entweder gezielt einschaltet/ausschaltet oder auch einfach toggelt).
Die erste Rule muss aber zusätzlich noch einen Timer starten, der nach x Millisekunden ein Increase oder Decrease gegen den Dimmer sendet. Alternativ muss openHAB das nächste Dimmlevel berechnen und diesen Wert als Absolutwert senden. Dieser Timer muss immer weiter wiederholt werden, bis das Loslassen der Taste erkannt wurde. Es gibt diverse Möglichkeiten, dass so eine Rule (eigentlich sind es ja zwei) Blödsinn macht, und es ist kein Spaß, solche Fehler zu finden. Und ja, Du brauchst dann für jeden Dimmer (nein, für jeden Taster!!!) zwei solche Rules. Und es ist sehr wahrscheinlich, dass sich die Rules gegenseitig ins Gehege kommen, falls mal mehrere Taster zeitgleich betätigt werden.

Wie ich oben erwähnt habe, kann man das natürlich so machen, aber es ist halt gequirlte Kacke. Hol Dir die kostenlose ETS Lite und programmiere das alles komplett innerhalb des knx Systems, Du wirst sonst sehr enttäuscht von der Zuverlässigkeit des knx Systems sein. Die Programmierung über ETS ist auch nicht komplizierter als so etwas über openHAB zu lösen.

knx ist ein offener Industriestandard. Wenn es um Gebäudesteuerung geht, führt kein Weg an knx vorbei (es sei denn, es ist eine kleine Klitsche... sorry).
Beispiel: Gerätehaus unserer freiwilligen Feuerwehr (vierzehn Stellplätze für Großfahrzeuge). Dort wurde vieles falsch gemacht, aber das Gebäudemanagement wurde korrekt umgesetzt. Bei Alarmierung werden in allen relevanten Räumen automatisch die Lichter eingeschaltet, interne Türen werden geöffnet, Schranken fahren auf. Wenn die ersten berechtigten Personen eintreffen, fahren automatisch die Tore der Fahrzeughalle auf usw.
Und dieses Zeug muss immer(!) funktionieren, unter allen Umständen, da geht es oftmals buchstäblich um Menschenleben. Deshalb knx, von einer zertifizierten Firma installiert und eingerichtet.
Klar gibt es auch andere Bussysteme, die man verwenden kann, aber knx ist mit weitem Abstand das verbreitetste System, es gibt zehntausende Komponenten von mehreren hundert Herstellern (ausnahmslos alle großen europäischen Hersteller sind dabei), und es spielt absolut keine Rolle, wie man die Geräte mischt, alles spielt mit allem (solange es um die gleiche Bustechnologie geht und wir nicht mit secure knx anfangen, aber innerhalb secure knx reden auch wieder alle Geräte aller Hersteller uneingeschränkt miteinander).
Es gibt gute Gründe, warum Bürogebäude, Hotels, ja ganze Firmenstandorte oder gar standortübergreifend ganze Firmen mit knx vernetzt werden, das Zeug ist einfach zuverlässig und es wird auf absehbare Zeit immer uneingeschränkt Ersatz geben.
Stell Dir vor Siemens geht pleite (... ) und Du hast Siemens Aktoren im Einsatz. Erstmal spielt es natürlich keine Rolle, weil die Aktoren ja laufen, aber sollte nach der Pleite ein Aktor kaputt gehen, kaufst Du halt einen von Gira oder MDT oder was weiß ich, es ist scheißegal, weil alles mit allem spielt.

Wenn Du aber jetzt hin gehst, und dieses dezentrale System kastrierst, indem Du die interne Kommunikation zwangsumleitest, nämlich über openHAB (oder auch jede beliebige andere Zentrale, inklusive z.B. Homeserver von Gira, der wurde extra für knx entwickelt), dann verliert das System an Zuverlässigkeit, weil plötzlich alles davon abhängt, dass die Zentrale sauber mit allen Komponenten kommunizieren kann. So etwas macht man nicht!

Oder Du lässt die teure Hardware entfernen und baust etwas anderes wie z.B. Homematic IP ein, wo das Verwaltungstool grundsätzlich kostenfrei ist. Du hast dann halt ein Nischenprodukt, und falls ELV mal keine Lust mehr hat, bekommst Du auch keine Komponenten mehr.

int5749 hat geschrieben: ↑7. Jun 2022 18:32
openHAB wird kein KNX ersetzen, openHAB dient als Ergänzung => Automatisierung und Kombinierung unterschiedllicher System
Aber dies hatte ja Udo schon erklärt

Ich glabue wir reden hier einander vorbei oder ich kann es (noch) nicht gut erklären. Nun es geht mir nicht darum ein KNX-System durch OH zu ersetzen. Was ich schon habe sind mehrere Taster bzw. mehrere Aktoren welche via einem KNX-Bus angeschlossen sind und die entsprechenden Adressen vollständig zugewiesen haben. Dazu habe ich eine SW (ähnlich wie OH nur viel schlechter und nicht mehr Win10/11 kompatibel) mit der ich die Zuweisungen (Programmierungen) gemacht habe. Das heisst man kann dann jedem Taster eine Rule zuweisen wie zum Beispiel schalte Licht im Bad ein oder setze Dimmer auf 60% etc.
Nun möchte ich diese alte SW eben durch OH ersetzten mit bestehender Infrastruktur (KNX) bzw. Taster, Aktoren, Dimmer etc. ICh habe bis jetzt alle Taster, Aktoren etc. in OH funktionsfähig. Das heisst der Taster reagiert auf einen physischen Druck oder ich kann in OH das Licht ein- oder ausschalten.

Was noch nicht funktioniert und ich hier schildern möchte, ist folgendes: Wie kriege ich nun einen Taster xy mit einer Rule dazu dass sich Licht xy ein- bzw. ausschalten lässt wenn ich den Taster physisch drücke? Diesen Schritt habe ich nicht kapiert bzw. wüsste jetzt nicht wieso ich eine ETS benötige wenn doch schon alles vorhanden ist und OH auf Taster bzw. Licht schon reagiert?!

Vielen Dank nochmals

Hallo Norick,

Um es mal mit einem Sprichwort zu sagen: Kannste somachen, ist dann halt kacke!
Aber dies hat ja so ähnlich auch schon Udo geschrieben.

Ich vermute (immer noch) Du interpretierst openHAB falsch oder möchtest diesen eben zweckentfremden.

Wie es gehen könnte auch dies hat Udo bereits geschrieben und da ist auch nichts hinzuzufügen.
Da kann ich auch nicht im detail helfen, da ich so etwas noch nie gemacht habe (und auch nicht würde).

Wie gesagt, zum einfachen Schalten eines Aktors reicht eine Rule, die auf received comamnd ON reagiert. Handelt es sich um Zweiflächenbedienung (eine für ein, eine weitere für aus), so legst Du zwei Rules an, eben für die beiden Tastflächen.
Zum Dimmen wird es, wie oben erwähnt wesentlich komplizierter.

Norick hat geschrieben: ↑8. Jun 2022 06:57 wüsste jetzt nicht wieso ich eine ETS benötige wenn doch schon alles vorhanden ist und OH auf Taster bzw. Licht schon reagiert?!

Die Lösung, die Du bisher eingesetzt hast, war von Anfang an Müll. Du kannst jetzt die Softwarekomponente austauschen, aber es bleibt Müll (vollkommen egal, was Du als Ersatz nimmst). Du kannst das so machen, ohne Frage, aber es ist und bleibt Müll.

Der Weg über die ETS ist der korrekte Weg, um knx zu administrieren, und da wir alle verstehen, dass man ungern 1190 € für eine Software mit Dongle ausgibt, nur um ein vorhandenes System sauber zu konfigurieren, gibt es den etwas sperrigen, aber gangbaren Weg über die ETS lite.

Ich kann Dir auch anbieten, mit meiner ETS per Fernzugriff zu konfigurieren, aber der Aufwand dafür ist nicht unerheblich, man muss mindestens ein VPN einrichten und ein paar Routen eintragen, damit aus der Ferne Zugriff auf das Interface möglich ist. Und am Ende bist Du von mir abhängig (auch wenn ich Dir das Projekt gebe, fehlt Dir dann ja noch immer die ETS)

Aber um Dir auch den schlechten Weg zu zeigen...

Gegeben: Taster, der beim Drücken auf 1/1/1 eine 1 sendet und beim loslassen eine 0. Aktor, der auf 2/1/1 auf einen Schaltbefehl reagiert. Dimmaktor, der auf 3/1/2 Dimmbefehle mit Telegrammwiederholung annimmt und auf 2/1/2 den Befehl zum Schalten erhält.

In openHAB ein generic knx Thing, in dem alle Channel angelegt sind: Die drei Channel sind jeweils mit einem Item gekoppelt: Nun ein paar Rules (zwingend als DSL Rule über Textdateien, über die UI geht das nicht wegen des Timers): Der Code ist als Minimalcode zu verstehen. Die erste Rule toggelt einen Schaltaktor. Die zweite Rule schaltet einen Schaltakor ein. Die dritte Rule schaltet einen Schaltaktor aus. Das wäre dann natürlich nur mit einem weiteren Taster sinnvoll...

Die vierte und fünfte Rule steuern einen Dimmer. Dabei ist Wallswitch1 für Einschalten und aufdimmen zuständig, Wallswitch2 ist für abdimmen und ausschalten zuständig.
Die Variable tWallSwitch1 speichert einen Handle auf den Timer. Dieser wird benötigt, um den Timer erneut verwenden zu können oder auch den Timer entfernen zu können.
Die Variable nDimmer1 zählt die Timer Durchläufe, dies ist wichtig, um ein Ausschaltkriterium zu haben. Da nur entweder der eine oder der andere Taster gedrückt werden kann, sollte auch ein Zähler ausreichen. Das Gleiche gilt eigentlich auch für den Timer...

Die Rule triggert sowohl beim Drücken (ON) als auch beim Loslassen (OFF).
Zunächst wird ein eventuell laufender Timer beendet.
Nun wird geprüft, ob der empfangene Befehl OFF lautete und der Zähler = 0 ist. Ist das der Fall, so handelte es sich um einen kurzen Tastendruck (weniger als 400 Millisekunden) und entsprechend wird der Befehl ON zum Dimmer geschickt.
Jetzt wird geprüft, ob der empfangene Befehl ON war. Ist das der Fall, so wird ein Timer angelegt.
Zum Schluss wird noch die Zählervariable auf 0 gesetzt und die Rule ist beendet.

Läuft der Timer ab, so startet der Scheduler den Code, welcher in der Rule an den Scheduler übergeben wurde. (der Block zwischen [| und ])
Dieser Code erhöht den Rundenzähler, sendet ein INCREASE Kommando und plant anschließend den Timer erneut.

Der Ablauf ist also folgender: Beim Drücken der Taste wird ON gesendet, woraufhin die Rule die Variablen initialisiert und den Timer startet. Wird die Taste unmittelbar wieder losgelassen, wird OFF gesendet, woraufhin die Rule erkennt, dass es sich um einen kurzen Tastendruck handelte und die entsprechende Aktion auslöst.
Wird Die Taste hingegen gehalten, so läuft der Timer ab, sendet den Befehl zum Dimmen und ruft sich selbst erneut auf. Das geht so lange, bis der Taster losgelassen wird. Nun erkennt die Rule, dass es sich um einen langen Tastendruck handelte und tut nichts weiter (außer natürlich, den Timer abzubrechen).

Die Dimmer Rules werden nur funktionieren, wenn die Dimmer mit Telegrammwiederholung funktionieren. Sollte das nicht der Fall sein, so benötigst Du zwingend eine GA zum Absolutwert Setzen des Dimmers.

Auch sind hier keinerlei Rückmeldungen berücksichtigt.

Vielen Dank für das Angebot auf deine ETS zuzugreifen.!

udo1toni hat geschrieben: ↑8. Jun 2022 10:30
Ich kann Dir auch anbieten, mit meiner ETS per Fernzugriff zu konfigurieren, aber der Aufwand dafür ist nicht unerheblich, man muss mindestens ein VPN einrichten und ein paar Routen eintragen, damit aus der Ferne Zugriff auf das Interface möglich ist. Und am Ende bist Du von mir abhängig (auch wenn ich Dir das Projekt gebe, fehlt Dir dann ja noch immer die ETS)

Aber wie schon sagst hätte ich zwar das Projekt aber eben noch keine ETS. Wie ich sehe gibt es 3 verschieden ETS zum Demodownload. von 250-1000 Euro. Die 350er Version bietet 64 KNX-Geräte an. Die Frage ist hier was wird als ein Gerät bezeichnet. Ist ein Gerät zum Beispiel eine Tastereinheit welche zwei unabhängige Tastwippen hat oder wären das nun schon zwei Geräte?

Sehe ich das richtig dass mit einer ETS die ganze Programmierung der Taster für Licht, Dimmer gemacht wird sodass dies dann einfach mit OH benutzt werden kann? Das heisst man muss dann keine Rules mehr in OH zum Beispiel für einen Dimmer machen weil schon alles mit ETS erledigt wurde?

Wenn ja, kann ich die ETS Demo benutzen um mal einen Dimmer zu konfigurieren um diesen dann in OH zu testen?



Ist jetzt sicher auch eine einfache Frage wenn man es weiss, aber wie lege ich in openHAB ein generic knx Thing an? Ich habe das so probiert über: KNX-Binding -> New KNX Device

Dann ist der Code:
ersetze ich nun diesen Code durch: korrekt?

Norick hat geschrieben: ↑12. Jun 2022 10:42 Aber wie schon sagst hätte ich zwar das Projekt aber eben noch keine ETS. Wie ich sehe gibt es 3 verschieden ETS zum Demodownload. von 250-1000 Euro. Die 350er Version bietet 64 KNX-Geräte an. Die Frage ist hier was wird als ein Gerät bezeichnet. Ist ein Gerät zum Beispiel eine Tastereinheit welche zwei unabhängige Tastwippen hat oder wären das nun schon zwei Geräte?

Sehe ich das richtig dass mit einer ETS die ganze Programmierung der Taster für Licht, Dimmer gemacht wird sodass dies dann einfach mit OH benutzt werden kann? Das heisst man muss dann keine Rules mehr in OH zum Beispiel für einen Dimmer machen weil schon alles mit ETS erledigt wurde?

Klasisches Jain.

Zur Hardware: Ein Gerät ist ein physikalisches Stück Hardware. Also ein AKtor oder ein Sensor, aber auch "passive" Geräte wie eine Schnittstelle (USB, IP oder Seriell) Somit kommen die meisten privaten Haushalte mit der Limitierung von 64 Geräten hin. Alternativ erstellt man ein 2. oder 3. Projekt mit den Geräten ab dem 65. Dies ist für private Anwender in der Regel akzeptabel und dort wird eine ETS ja nicht regelmäßig genutzt (zumindest in der Regel). Als Fachfirma ist dies sicher komplett anders zu betrachten aber hier zu vernachlässigen.

Ja: Man verknüpt dann "einfach" einen Sensorkanal mit dem entsprechenden Aktor Kanal über eine Gruppenadresse.
Wichtig ist hierbei: Sensor sendet den Befehl, Aktor empfängt. Beim Status ist es dann umgekehrt.

Den Sensor musst Du dann in der ETS entsprechend konfigureren (sofern der Sensor und die Software dazu (auch Applikation oder Produktdatenbank genannt) unterstützt). Hier als z.B. Taste 1 als Dimm-Objekt, welches dann automatisch die Objekte erstelle (in der Regel Kurz und Langzeit). Gleiches gilt dann für den Aktor.
Nun wird eine Gruppenadresse erstellt (z.B. Wohnzimmer_Lampe_dimmen) und die Objekte von Sensor und Aktor dort hinneingezogen. Der Status bekommt dann eine eigene GA und wird analog verknüpt. Tip: Das erste Objekt, welches in eine GA gezogen wird, sendet in der Regel. Sonst muss es ggfs angepasst werden. Für das direkte setzen einer Helligkeit (um beim Dimmer zu bleiben) gibt es häufig weitere Objekte => neue GA notwendig

Hint: Man sollte direkt eine gewisse Hierarchie in der ETS umsetzen, damit z.B. GAs eine Struktur wiederspiegeln. Hierzu gibt es aber ganz viele Beispiele im Internet und man sollte das für sich passende nutzen oder eben anpassen um den Überblick zu halten.
Ich habe z.B. meine Lichter in einen Bereich, Statis in einem anderen, Security Objekte wie Fehler und Störmeldung wieder woanders und dann eben nach Etagen separiert. <<= Jeder wie er sich zurecht findet.

Nein: Dies ist immer noch nicht für openHAB notwendig, denn openHAB ist immer noch eine Ergänzung und Automatisierung.

Eigentlich könntest Du ein Haus/Wohnung komplett ohne Schalter über openHAB betreiben, wenn Du (wieder in einer ETS) alle Aktoren mit entsprechenden GAs verknüpft und diese dann über openHAB ansprichst. Entweder komplett automatisiert über Präsenzmelder etc. oder über eine Sitemap oder UI Oberfläche oder entpsrechende Sprachsteuerung (ALexa, Siri, oder anderes) <<== So wie auf der Enterprise oder Voyager und sicher in einigen Jahren standard. PS: Wird sicher auch schon solche Häuser/Wohnungen geben

Fazit: Was eine Physik (Sensor) schalten soll, wird (bei KNX) in einer ETS verknüpt und kann dann mit openHAB ergänzt werden. Dazu müsste man die use-cases kennen, was erreicht werden soll. => Einen Sensor über Rules gesteuert einen Aktor (Dimmer) zu betreiben ist kein use-case (aber dies ist ja mittlerweile evtl. klar)

Finally

Norick hat geschrieben: ↑12. Jun 2022 10:42 Dann ist der Code:

Code: Alles auswählen

UID: knx:device:d041ec5f62:9c9b3d0bcb
label: KNX Device - Test
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:d041ec5f62

ersetze ich nun diesen Code durch:

Code: Alles auswählen

UID: knx:device:d041ec5f62:9c9b3d0bcb
label: KNX Device - Test
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:d041ec5f62

korrekt?

Wo ist der Unterschied bei diesen Beiden Code-Schnipseln?? ODer wo willst Du dieses ersetzen??

Viele Grüße und einen entspannten Sonntag

Ergänzend:

knx Geräte: hier sind Busankoppler gemeint. Jedes Gerät, welches am Bus betrieben wird, hat einen Busankoppler. Es mag Geräte geben, die so umfangreich sind, dass ein einzelner Busankoppler nicht ausreichend war, mir wäre aber keines bekannt. Wenn in Deinem Schaltschrank REG (Reiheneinbaugerät) verbaut sind, so hat jedes dieser Geräte einen eigenen Busankoppler. Jeder knx Wandtaster hat ebenfalls einen eigenen Busankoppler. Es kann aber durchaus sein, dass die Taster über Klingeldraht (oder auch ganz konventionell NYM-J 5x1.5) in den Schaltschrank geführt und dort auf Binäreingänge geklemmt sind. Dazu muss man halt die komplette Anlage betrachten, welche Taster sind verbaut usw.

GA senden/empfangen: ein knx Gerät kommuniziert über Kommunikationsobjekte (KO). Für jedes KO gibt es eine Liste von Flags, welche kontrollieren, wie das KO genutzt werden kann. Neben der Option, die Kommunikation überhaupt zu erlauben (K) kann ein KO lesbar (L) und/oder schreibbar (S) sein, es kann von sich aus senden (Ü) oder auch auf Antworten eines Read Requests reagieren (A). Wenn ein KO sendet, dann tut es das ausschließlich auf der ersten eingetragenen GA. Es ist aber möglich, mehrere GA pro KO einzutragen, das kann man verwenden, um z.B. ein Zentral-Aus zu realisieren.
Es ist also nicht so, dass das erste Gerät sendet, welches mit einer GA verknüpft wird, sondern alle KO, welche senden dürfen und bei denen die GA an erster Stelle eingetragen ist senden. Typischer Aufbau einer einfachen Schaltung:

Schaltaktor 1 (S1) schaltet das Flurlicht. KO zum steuern: 1, KO für den Status: 2
Schaltaktor 2 (S2) schaltet das Badlicht. KO zum steuern: 11, KO für den Status: 12
Taster 1 (T1) soll das Flurlicht steuern. KO zum steuern: 1 (einfache Taster haben kein eigenes KO für den Status!)
Taster 2 (T2) soll das Badlicht steuern. KO zum steuern: 1
Taster 3 (T3) soll alle Lichter ausschalten. KO zum steuern: 21
Da der Flur lang ist, gibt es noch die Taster 4 und 5, welche ebenfalls das Flurlicht steuern sollen, genau wie Taster 1


GA: Programmierung: Das sieht erst mal kompliziert aus, ist es aber nicht. Man kann beliebig viele Taster verwenden, um einen Aktor zu schalten. Da jeder Taster vom Aktor die Rückmeldung bekommt, ist sichergestellt, dass der Taster selbst weiß, welchen Befehl er als nächstes senden soll (Falls ON dann OFF, falls OFF dann ON)
Taster 3 sendet einfach immer ein OFF, wenn er gedrückt wird. Es braucht keine Statusanzeige (aber natürlich könnte man mit einem Logikmodul alle Status aller betroffenen Aktorkanäle einsammeln uns so direkt anzeigen, ob irgendwo im Haus noch ein Licht an ist... dann müsste man dem Ausgang-KO dieses OR-Moduls noch eine eigene GA zuordnen, diese zusätzlich T3-21 eintragen und noch das S-Flag setzen)

Der Witz ist, dass wir hier fünf GA brauchen, aber es sind sieben Busteilnehmer. Die Programmierung ist trivial (wenn man mal das Prinzip verstanden hat) und mit minimalem Aufwand umzusetzen.

In openHAB reichen nun zwei Channel (jeweils mit einem Item verknüpft) um die beiden Schaltaktoren zu steuern und ihren Zustand abzubilden. Soll Zentral-Aus auf knx-Ebene genutzt werden, käme noch ein dritter Channel hinzu. da openHAB nur als eine Art zusätzlicher Taster fungiert, braucht es auch keinerlei Rules oder anderes, um das Haus nutzen zu können, ja, openHAB kann sogar zeitweise ausgeschaltet sein und die Taster an der Wand steuern immer noch die Leuchten.

Danke für eure Antworten. Es kommt zwar etwas Licht ins Dunkel bezüglich ETS und/oder OH aber der Groschen ist noch nicht ganz gefallen...

Was ich bei meiner alten Anlage sehe (habe den SourceCode nicht) ist noch folgendes Detail. Ich sehe nirgends dass eine ETS am Laufen ist jedoch wurde eine Schnittstelle implementiert die so heisst: EIB/KNX Falcon.
Kenne ich jetzt nicht im Detail aber zumindest kann man dann auf dem UI für zum Beispiel jeden Taster einfach die Aktionen (Rules) angeben wie:

- Taster On
- Taster Off
- Taster kurz gedrückt
- Taster lang gedrückt
- Aktion beim Ausschalten
etc.

Dies macht es dann schon sehr einfach zum Programmieren resp. veknüpfen von einem Taster mit einem Licht.

Du schreibst:

int5749 hat geschrieben: ↑12. Jun 2022 11:47
Nein: Dies ist immer noch nicht für openHAB notwendig, denn openHAB ist immer noch eine Ergänzung und Automatisierung.

wie sieht dann der Use Case aus wenn ich zum Beispiel bei einem Tasterdruck (Off- > On) den Radio einschalten möchte? Dann muss ich doch auch diese Rule in OH anlegen oder nicht? Wenn ja, dann kann ich anstatt dem Radio einschalten auch die Rule in OH schreiben für Licht einschalten?!


Ich möchte jetzt nicht ewig auf diesem Thema rumreiten ist für mich aber schon zentral um das Ganze besser zu verstehen

Norick hat geschrieben: ↑14. Jun 2022 07:00 Ich sehe nirgends dass eine ETS am Laufen ist ....

Hier ist bereits der erste große Unterschied: ETS läuft nicht permanent, sondern nur bei der Programmierung der Komponenten

Norick hat geschrieben: ↑14. Jun 2022 07:00 ... jedoch wurde eine Schnittstelle implementiert die so heisst: EIB/KNX Falcon.

Dies scheint eine Schnittstelle für eine weitere Software zu sein, welche dann wiederum den KNX Bus bedient.

Wie Du (sehr umständlich) einen Schalter Dimmer über openHAB umsetzen könntest, hat Dir ja schon Udo erklärt.

EIn Use Case von mir: Ich schalte über einen KNX Schalter (Gira Tastsensor) ein Item in openHAB (für Beschattungsautomatik)
Hierzu wird dann in openHAB ein Control-Thing erstellt und mit der GA (erstellt über die ETS) verknüpft, ebenso wie der Tastsensor.
Somit kann ich dann über einen physikalischen Schalter ein Item in openHAB steuern.

Zu Deinem Use Case: Wie wird denn das Radio eingeschaltet?

Wie bereits int5749 geschrieben hat (und ich auch, oben, mehrfach) ETS ist ein reines Konfigurationswerkzeug.
Falcon: Das ist eine Programmierschnittstelle, welche von knx.org zur Verfügung gestellt wird (gegen Geld, versteht sich)
Man kann darüber auf den Bus zugreifen und was auch immer machen. ABER: Man muss dazu ein Gerät laufen lassen, welches die Programme ausführt. Für knx ist ein solches Gerät aber gewöhnlich vollkommen unnötig, das ist der Punkt.

Der Normalfall ist, dass die Elektroinstallation von einem Elektriker ausgeführt wird. Anschließend werden die Wandtaster fest mit ihren Funktionen programmiert, also z.B. dass der Taster am Eingang zum Bad das Licht im Bad schaltet usw.

Diese Verknüpfung wird in der ETS ausgeführt. Die ETS schreibt die Programmierung in die Geräte, so dass der Taster vor dem Bad weiß, welche GA er senden muss, wenn er gedrückt wird. Auf der anderen Seite weiß der Aktor, an dem die Badezimmerlampe angeschlossen ist, auf welche GA er hören muss.
Ist die Anlage programmiert, packt der Elektriker seinen Laptop mit der ETS ein und geht nach Hause.

Will der Bauherr eine Änderung, weil der Taster vor dem Bad jetzt besser das Flurlicht schalten soll, so rückt der Elektriker mit dem Laptop an und programmiert den Taster um. Dauert zwei Minuten und der Handwerker rechnet eine ganze Stunde plus Fahrtpauschale ab. Aber der Hausherr ist glücklich, weil weder Dreck noch Lärm angefallen sind (wegen neu Verlegen von Kabeln...)

Bei Dir ist das System anders (und extrem unüblich) aufgebaut. Du hast eine Zentrale, über die jeder Schaltvorgang läuft. Fällt diese Zentrale aus, dann geht im ganzen Haus nichts mehr. Der einzige Vorteil für Dich: Du kannst jederzeit die Zuordnung der Taster zu den Aktoren anpassen.
ABER: Punkt 1: Tust Du das? Oder ist es nicht vielmehr so, dass die Zuordnung eigentlich eher fix ist? Und Punkt 2: Mit einer ETS Lizenz kann die Zuordnung genauso jederzeit angepasst werden.
Natürlich kostet die ETS ein Schweinegeld (zumindest in der Pro-Version, welche keine künstlichen Beschränkungen hat), aber ich habe ja ausführlich beschrieben, dass es durchaus unkomfortable Wege gibt, das Ganze kostenlos zu halten, wohlgemerkt legal (im Sinne der Lizenz, was den Rest betrifft, ohnehin).

Wie die Progammierung in einer Rule aussieht, habe ich wirklich sehr ausführlich beschrieben. Nein, es gibt keinen einfacheren Weg in openHAB. In openHAB gibt es nur dort kurze und lange Tastendrücke, wo die Hardware eine solche Information abliefert. Wenn Du aber beim Drücken und Loslassen einer Taste jeweils ein Telegramm sendest, der Taster also tatsächlich als "echter" Taster arbeitet, dann bleibt nichts anderes übrig, als die Zeit zwischen den beiden Ereignissen zu messen, was natürlich möglich ist, aber auch total umständlich, zumal man, wenn die Anlage korrekt parametriert ist (korrekt im Sinne von, sagen wir mal, der Elektriker Innung) diesen ganzen Aufwand überhaupt nicht treiben muss.

Wenn ich mein Bad betrete, schalte ich das Licht ein. Der Aktor meldet, dass er eingeschaltet wurde. openHAB registriert, dass das Licht eingeschaltet wurde und zeigt den Zustand an. Gleichzeitig wird eine Rule ausgelöst. Diese Rule schaltet die Musik im Bad ein. Außerdem startet sie einen Timer.
Läuft der Timer ab, so wird der Lüfter im Bad eingeschaltet. Gleichzeitig (der Lüfter macht ja Krach) wird die Lautstärke angehoben.
Wird das Licht wieder ausgeschaltet, so wird die Musikwiedergabe pausiert. Gleichzeitig prüft die Rule, wie lange das Licht eingeschaltet war. Abhängig von der Einschaltdauer wird die Nachlaufzeit für den Lüfter gesetzt. Wird das Licht eingeschaltet, während der Lüfter läuft, so prüft die Rule beim Ausschalten des Lichts, ob die Nachlaufzeit des vorhergehenden Ereignisses länger als die neu bestimmte Nachlaufzeit dauert. Die längere Nachlaufzeit gewinnt. Nachdem die Musik zwei Minuten angehalten war, wird der Player auf Stopp geschaltet.

All dies sind Dinge, die mit knx alleine nur mit sehr viel Aufwand erledigt werden können (wobei es auch frei programmierbare Module für knx gibt), das mache ich also in openHAB. Die Player sind auch gar nicht an knx angebunden.
Ich kann das Licht im Bad (und auch den Lüfter...) jederzeit von openHAB aus steuern, zusätzlich zum Taster an der Wand.
Wenn aber openHAB ausgeschaltet ist (Hardware defekt, Wartungsarbeiten, whatever), geht das Licht trotzdem. Nur den Lüfter muss man dann mit einem zusätzlichen Taster manuell schalten.