KNX Dimmer über einen Taster implementieren

[Norick]

Danke für die Antworten welche jetzt doch mehr Licht in die Ganze Sache bringen. Ich sehe was ihr nun meint dass man eine ETS benötigt für den Betrieb "Taster & KNX" resp. was die Vorteile sind. Wie ich aber (aucht) Recht hatte oder ihr beschrieben habt gibt es zwar die Möglichkeit alles in OH umzusetzen aber mit allen genannten Nachteilen...

Aber nun gut, wenn ich die ETS Lizenzen anschaue gibt es davon ja 3 Stk. Wobei die "Home" leider nur 1 Projekt mit 64 Geräten unterstützt. Die ETS-Lite jedoch x Projekte mit 20 Produkten. Dazu habe ich dann folgende Fragen:

- Ist es möglich mit der "Lite" auch zum Beispiel 80 Geräte zu programmieren aufgeteilt in 4 Projekte? Oder ist die Anzahl unabhängig von der Projektanzahl?
- Ist der Dongle nur nötig für die Programmierung (einmalig) und dann nicht mehr?
- oder kann man sich den ETS-Dongle evtl "ausleihen" das wäre in der Tat etwas billiger...

Normalerweise, so sehe ich das, benötigt man dann die ETS eigentlich nur einmal für die Programmierung der KNX Komponenten und dann wahrscheinlich nie mehr (ausser bei Erweiterungen evtl.). Das heisst man könnte wie Udo beschrieben hat diese auch per Remote einmalig machen? Dies wäre natürlich genial die ProVersion wirklich schweineteuer ist...

[udo1toni]

Das Dongle ist die Lizenz für die Software. Wenn Du jemanden kennst, der Dir sein Dongle leihweise zur Verfügung stellt, wird das funktionieren.
Ich bin kein großer Lizenzbedingungen Leser, vermute aber, dass Du damit gegen die Lizenzbedingungen verstößt, auch wenn rein technisch kein Verstoß vorliegt (es läuft nur eine Instanz des Programms, es wurden keine Dateien ausgetauscht, um die Dongle Abfrage zu umgehen). Vermutlich verlangt die Eiba, dass Du nicht nur Besitzer, sondern auch Eigentümer des Dongle bist (wie gesagt, nur eine Vermutung).

Die ETS braucht man in der Anfangsphase schon häufiger, gerade als Anfänger, der keinen Lehrgang ETS & knx mitgemacht hat. Aber die Grundlagen kann man hervorragend auch online erklären, wie teilt man GA auf, wie werden die Geräte am Bus adressiert, Wie müssen die Flags gesetzt sein, welche KO müssen miteinander verbunden werden, sowas halt.
Später braucht man die ETS nur noch, um mal was nachzuschauen oder mal eine Kleinigkeit anzupassen. Z.B. kann man einem Dimmer vorgeben, wie lange er zum Dimmen braucht. Bei mir dimmen alle Lampen beim Einschalten sanft von 0 % auf 80 % auf, innerhalb fünf Sekunden. Beim Ausschalten genauso, von der aktuellen Helligkeit auf 0 % runter in 5 Sekunden, das ist für mich persönlich wahnsinnig angenehm. Solche Dinge kann man aber ebenfalls nur über die ETS anpassen, und da kommt dann doch Geschmack ins Spiel, und gerade, wenn man ein Haus nicht alleine bewohnt, können die Meinungen darüber auseinander gehen. Und man kann so etwas letztlich nur im realen Leben wirklich gut einschätzen, es hilft also nicht, in einem Testaufbau mal kurz eine Lampe aufzudimmen.

Was die Home und die Lite Version betrifft: Die Einschränkung bezieht sich ausschließlich auf die im Projekt verwendete Anzahl Geräte. Du kannst in jedem Projekt beliebig viele GA anlegen. Du kannst in jedem Projekt beliebige Zuordnungen der GA vornehmen. Niemand hindert Dich, in einem Projekt 20 andere Geräte einzubauen als in einem anderen Projekt.
Die einzige Schwierigkeit besteht darin, dass Du die Übersicht behalten musst, welche GA wo programmiert werden müssen. Und natürlich musst Du fast zwingend eine doppelte Buchführung machen, also z.B. in einer Tabellenkalkulation eine Liste der GA mit allen verknüpften KO aller Devices führen, um die Übersicht zu behalten. Innerhalb eine Projekts übernimmt die ETS das, und das inzwischen auch sehr übersichtlich (ich habe noch die ETS 1.x kennengelernt, damit gearbeitet habe ich aber erst ab der ETS 3).

Auch bei der Home Version gibt es Wege, die Beschränkung auf ein Projekt zu umgehen (im Zweifel, indem man die Projektdatei auf Windowsebene austauscht, bevor Home gestartet wurde).

Der Remote Zugriff ist grundsätzlich möglich, aber mit Aufwand verbunden. Entweder, es wird ein spezielles Gateway zum Fernzugriff montiert (das alleine kostet schon mehr als die ETS pro...) oder man muss ein passendes VPN bauen und das Routing so anpassen, dass der Zugriff auf das knx Interface möglich ist, denn gewöhnlich wird Multicast überhaupt nicht geroutet und knx/IP Tunnel ebenfalls nicht. Das ist aber kein unlösbares Problem. Notfalls bringt openHABian auch die Option mit, Wireguard laufen zu lassen (auch wenn das vom Sicherheitsaspekt nicht schön ist).

[Norick]

so wie du es sagst macht es dann schon Sinn eine eigene ETS zu haben. Da die Pro in jedem Fall viiiiiiel zu teuer ist frage ich mich jetzt nur noch ob es die Lite oder Home sein soll.
Wie du sagst wäre die Lite nutzbar wenn man die Adressvergabe irgendwo in einer Tabelle separat noch mitschreibt damit es kein Durcheinander gibt. Ich denke dies ist kein grosser Aufwand denn die Differenz ist am Schluss doch 150 Euro.

Man könnte u.U. auch die Projekte entsprechend dem Raum aufteilen dann hätte man auch eine gewisse Ordnung im System. Würdest du so etwas empfehlen wenn ich die Lite beschaffe?

Danke

[udo1toni]

Die Adressorganisation ist ein Stück weit Geschmackssache, ich habe bei mir z.B. eine recht übersichtliche Anzahl an Räumen, weshalb ich den ersten Teil als Raumkennung nutze, also 1 = Flur, 2 = Wohnzimmer, 3 = Bad usw. Ursprünglich war die GA mal mit /0-15/0-7/0-255 definiert. Inzwischen darf man aber auch an der ersten Stelle bis 31 zählen (kann aber sein, dass sehr alte Hardware hier ein Problem hat).
Die zweite Stelle verwende ich für die Art der Daten, also Schalten, Messen, Heizung, Szenen, Rollläden, Dimmer (so in der Art... müsste zuhause noch mal genau nachschauen) und die dritte Stelle verwende ich analog zur Nummer des KO, wobei ich mich immer am ersten Kanal eines Geräts orientiere. Damit ist die 0 meist der Schaltkanal und die 1 der Status dazu. Meine Devices haben pro Kanal immer weniger als 10 KO, so dass ich dann pro Kanal 10 addiere. Im Wohnzimmer habe ich z.B. acht Rollläden (einer davon die Leinwand des Heimkinos...) so dass ich dort GA bis hinauf zur 80 habe.
Der Witz ist aber, dass die Definition aller gleichartigen Things in openHAB quasi identisch aussieht, abgesehen vom ersten Teil oder dem Zehner der letzten Stelle. das macht die ganze Sache extrem übersichtlich.

[Norick]

ich denke so in dieser Art der Adressierung würde ich es dann wohl auch machen, muss mich aber dann schon noch zuerst einlesen wie es im Detail dann aussieht, da ich noch nie eine ETS programmiert habe. Dies wird dann wohl oder übel zu der einen oder anderen Frage führen

Aber kurz nachgefragt: Die ETS-Lite kann ich dann benutzen und in mehrere Projekte aufteilen wenn es dann mehr als 20 Geräte sind?

[udo1toni]

Ja, genau.

Du kannst Dich aber gerne auch noch mal per PN bei mir melden, weil der ganze Themenkomplex nur noch am Rande mit openHAB zu tun hat.

[TorstenE]

Wie ich ja schon im anderen Thread geschrieben habe, ist es eher ungewöhnlich, knx Geräte über openHAB mit anderen knx Geräten zu verbinden.

Ich möchte an dieser Stelle auch darauf hinweisen, dass dies auch wegen der Ausfallsicherheit keine gute Idee ist. knx als Bussystem ist sehr zuverlässig, obwohl auch hier natürlich Komponenten ausfallen können.
openHAB selbst funktioniert durchaus stabil, es kann aber aus verschiedensten Gründen ausfallen, sei es die Anbindung zum Bus, ein Absturz, ein defektes Netzteil, eine defekte SD-Karte... Sobald openHAB nicht mehr korrekt funktioniert, ist auch der knx Bus mit allen über openHAB aufgebauten Verknüpfungen davon betroffen.

Die Idee von openHAB ist auch nicht, diese Verknüpfungen zu ersetzen. Die Idee ist, alle Aktoren von openHAB aus steuern zu können und jederzeit ihren Status zu kennen. Weiterhin ist es natürlich möglich, Taster anzubinden, um dann Hardware eines anderen Systems zu verknüpfen.
Grundsätzlich sollten aber alle Verknüpfungen, die innerhalb eines Bussystems angelegt werden können, dort angelegt werden. Fällt openHAB aus, so läuft knx ganz normal weiter.
Ich habe bei mir tatsächlich eine Verknüpfung über openHAB laufen, das ist der Badlüfter. Ich war damals zu geizig ein Nachlauf Modul für knx zu kaufen. Jetzt ist es so, dass ich das Licht einschalte, woraufhin openHAB einen Timer startet. Wird das Licht nicht vorher ausgeschaltet, so startet nach 10 Sekunden der Lüfter. Wird das Licht ausgeschaltet, errechnet openHAB die Einschaltdauer, bestimmt so die Nachlaufzeit des Lüfters und startet einen passenden Ausschalttimer. Wird das Licht wieder eingeschaltet, wird der Ausschalttimer abgebrochen. Wird das Licht wieder ausgeschaltet, wird die neue Ausschaltzeit berechnet. Liegt sie hinter der alten Ausschaltzeit, so wird ein Timer mit der neuen Ausschaltzeit gesetzt. Ansonsten wird der Timer mit der alten Ausschaltzeit gestartet.
Wenn ich also dusche, läuft der Lüfter durch die Länge des Aufenthalts fünfzehn Minuten nach. Geht nach mir jemand anderes ins Bad und wäscht sich nur schnell die Hände, so läuft der Lüfter dennoch weiter. War der Lüfter aber aus, so schaltet der Lüfter direkt nach dem Verlassen des Bads ab, weil das Händewaschen in weniger als zwei Minuten erledigt ist.
Das geht grundsätzlich auch direkt in knx, aber es braucht dazu Logikmodule und Zeitmodule.

Sollte openHAB ausfallen, so funktioniert das Licht weiter, aber den Lüfter müsste ich dann händisch ein- und ausschalten. Ich verliere hier also Komfort, kann aber trotzdem alles ganz normal bedienen.
Insbesondere bei Rollläden ist das nicht ganz unwichtig. Es wäre schon extrem ärgerlich, wenn ich nach dem Aufstehen eine Kerze anzünden müsste, um den Weg zu meinem Computer zu finden, mit dem ich dann openHAB wieder gangbar machen kann, damit ich mit dem Wandtaster manuell(!) die Rollläden öffnen kann.
Bei mit steuert openHAB die Rollläden vollautomatisch, abhängig von Uhrzeit und Sonnenstand. Fällt openHAB aus, so muss ich die Rollläden per Tastendruck manuell steuern, aber immerhin kann ich sie noch bedienen

Der Beitrag hat mir geholfen das Verständnis zwischen KNX und OH zu verbessern - Danke Udo