Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Einfach alle UM ausgänge der Tasterschnittstelle die für die gleiche Funktion sind auf die gleiche Gruppenadresse legen. Dann höhren die Taster auch, welches der letzte Befehl (ein oder aus) war und senden dann beim betätigen entsprechend das gegenteil
Du ziehst einfach die schaltende GA des einen, auf das Schaltobjekt (nicht an die erste Stelle - dies ist die sendende) des anderen Tasters und umgekehrt (Suchstichworte: hörende Gruppenadresse). So weiß jeder Taster über die aktuelle "Stellung" des anderen Bescheid.
danke - so langsam wirds mir schwindelig...
Gibt es irgendwo eine gute Erklärung über das Zusammenwirken der verschiedenen Kommunikationsobjekte und Schnittstellen?
Ich persönlich kenne keine. Allerdings bekommt der Kurs vom Eibmeier ständig gute Kritiken. Ich habe mir dieses Buch angeschaft, viel im Forum gelesen und auch viel ausprobiert.
Im grunde ist es nicht soo schwierig. Es gibt ein paar Grundsätze, die man verstehen muss.
- Gruppenadressen sind wie Schalterdrähte. Sie verbinden die Eingänge mit den Ausgängen. Zum schalten ein/aus braucht es 1 Gruppenadresse (für 1bit) die mit allen Ein- und Ausgängen die das gleiche tun sollen verbunden werden. Zum dimmen per Taster brauchtes noch eine zweite Gruppenadresse (für 4bit). Man kann nur Kommunikationsobjekte mit einader verbinden, die die gleich "funktion" haben. Die wichtigsten "funktionen" sind dabei:
1bit: Alles was mit schalten (ein/aus), auf/ab, offen/geschlossen usw zu tun hat.
4bit: Alles was eine "relativen Wert" sendet .z.B. Jalousie hoch/runter oder dimmen heller/dunkler
8bit: Alles was einen absoluten Wert hat. z.B. setze Helligkeit auf 40%, fahre Jalousien auf 60% usw...
-Kommunikationsobjekte: Das sind die Schnittstellen, die jeder KNX Teilnehmer softwaremässig zur verfügung stellt. Wichtig dabei ist: Jedes Kommunikationsobjekt kann nur maximal auf EINE Gruppenadresse senden. Jedoch theoretisch auf beliebig viele Gruppenadressen höhren (hängt von der Applikation ab). Dabei ist immer die erste Gruppenadresse die, auf die gesendet wird.
-> Desshalb gehöhren z.B. bei Aktoren die Gruppenadressen immer in der Reihenfolge... 1. Direkte Ansteuerung (z.B. Lichtschalter Wohnen). Danach kommen alle anderen Zuordnungen wie ZentralAUS. Das hat den Grund, weil viele Aktoren ebenfalls über die erste Gruppenadresse ihren Status zurücksenden.
Ein Beispiel:
Du hast 2 KNX Taster um das Wohnzimmerlicht zu dimmen und willst das licht mit einemZentralAUS Taster neben dem Wohnungsausgang beim verlassen löschen können...
- Beide KNX Taster auf dimmen parametrieren.
- 2 Gruppenadressen anlegen. zB. 4/1/0 für schalten und 4/1/1 für dimmen.
- Die Gruppenadressen sinvoll benennen. z.B. 4/1/0 Licht Wohnen e/a und 4/1/1 Licht Wohnen heller/dunkler.
- Die Gruppenadresse 4/1/0 verbindest du mit den beiden Kommunikationsobjekten "schalten" der beiden KNX Taster.
- Die Gruppenadresse 4/1/1 verbindest du mit dem Kommunikationsobjekt "dimmen" beider KNX Taster.
- Den Taster neben der Wohnungstüre parametrierst du als "nur AUS senden".
- Dann legst du wieder eine Gruppenadresse z.B. 1/1/0 an und benennst sie z.B. ZentralAus.
- Diese Gruppenadresse verbindest du mit dem entsprechenden Kommunikationsobjekt des Tasters neben der Türe.
Nun kommt nur noch der Aktor:
Gehen wir davon aus es ist ein einkanaliger Dimmaktor. Bei mehrkanaligen ist aber der Ablauf theoretisch gleich...
- Auf das Kommunikationsobjekt "schalten" verknüpfen wir als erste Gruppenadresse unser 4/1/0 und als zweite die 1/1/0
- Auf das Kommunikationsokjekt "dimmen" verknüpfen wir die Gruppenadresse 4/1/1.
Fertig ist der Zauber.
Weil wir nun als erste Gruppenadresse beim Dimmaktor unser 4/1/0 angegeben haben, und diese vom Aktor auch zur Rückmeldung genutzt wird (ist ja die erste) können wir diese Gruppenadresse nun auch mit unseren Status LED's auf den Tastern verbinden. Der Status stimmt dan auch, wenn z.B. über den ZentralAUS der Dimmer ausgeschaltet wurde
Wenn du noch eine dritte Schaltstelle für das Wohnzimmerlicht willst, wird die wieder als dimmen konfiguriert und das Schaltobjekt mit 4/1/0 und das Dimmobjekt mit 4/1/1 verbunden. Das kann man beliebig ausbauen.
D.h. in dem Beispiel dass die GA 4/1/0 dabei nie direkt zum schalten benutzt wird, sondern nur für die Rückmeldung "AUS" da ist, korrekt?
Der Hager WYT hat außerdem noch ein Objekte Zustand pro Taste, ich vermute mal das ist eben genau der gemerkte Schaltzustand bei "Taster UM". Der Aktor hat auch ein Zustandsobjekt pro Relais - was würde jetzt passieren wenn ich die alle mit der gleichen Gruppenadresse verbinde?
Nein die 4/1/0 wird von den Tastern direkt genutzt um den Aktor zu schalten. Wenn dan der Aktor einen neuen Zustand hat, wird dieser wieder über die 4/1/0 zurück gemeldet. Die Kommunikation geht also in beide Richtungen.
Ich habe jetzt nicht die Applikationen angesehen. Das problem ist, dass jeder Hersteller die Kommunikationsobjekte ein bischen anders benennen.
Das Zusatz Kommunikationsobjekt beim Aktor (Zustand) ist optional, wenn du die Rückmeldung getrennt benötigst. Wird aber bei korrekter Programmierung unter einhaltung der oben genannten Regel (1. GA ist immer der direkte Befehl) nur selten benötigt.
Um mit einem Taster dimmen zu können braucht es wie oben im Beispiel beschrieben zwingend 2 Gruppenadressen. Eine zum schalten und eine zum dimmen. Wenn du kurz auf den taster drückst, wird UM geschaltet. es wird also ein 1bit Befehl auf die GA 4/1/0 gesendet. Der Aktor der auch mit dieser GA verbunden ist schaltet darauf hin z.B. EIN und meldet (sofern die 4/1/0 im Aktor auch die erste GA ist!) über diese Gruppenadresse seinen Status zurück auf den BUS. Dort wird diese Meldung von den Tastern verwendet, um ihren internen Zustand zu synchronisieren, damit bei der nächsten Betätigung auf einen beliebigen Taster der sich in dieser Gruppe befindet auch ein AUS Befehl gesendet wird.
Wenn man den Taster lange betätigt, wird auf die Gruppenadresse dimmen also im Beispiel auf 4/1/1 gesendet. Der Dimmer wird damit angewiesen hoch oder runter zu dimmen.
Mal ein Beispiel zur oben skizierten Kommunikation basierend auf dem oben beschriebenen Testaufbau...
Du betätigst kurz den Taster1 im Wohnzimmer um das Licht ein zu schalten...
-> Der Taster sendet auf die Adresse 4/1/0 den Befehl EIN
-> Der Aktor höhrt auf der 4/1/0 den EIN befehl und fürhrt ihn aus
-> Nach dem der Aktor seinen Zustand aktualisiert hat, sendet er seinen Zustand (EIN) sowohl über das getrennte Rückmeldeobjekt als auch im Beispiel auf die 4/1/0
-> Die Taster aktualisieren ihren internen Status um zu wissen, dass der nächste Befehl AUS ist.
Du Betätigst nun den ZentralAUS-Taster neben der Wohnungstüre...
-> Der Taster sendet den Befehl AUS auf die Gruppenadresse 1/1/0
-> Der Aktor höhrt den AUS Befehl auf der 1/1/0 und führt ihn aus
-> Nun sendet der Aktor seinen neuen Zustand AUS auf die erste Gruppenadresse 4/1/0
..Das ist wichtig! Weil die Taster glauben zu diesem Zeitpunkt noch, dass der Aktor EIN ist und würden bei der nächsten Betätigung ein AUS senden obwohl der Aktor schon AUS ist.
-> Die Taster höhren nun den AUS Befehl der vom Aktor auf der 4/1/0 zurück gesendet wurde und aktualisieren ihren Zustand
Wenn du nun wieder im Wohnzimmer z.B. den Tsater2 betätigst, wird das Licht EIN geschaltet, da die Taster immer über den aktuellen Zustand des Aktors informiert werden. Das läuft alles über die gleiche Gruppenadresse. Desshalb ist die Reihenfolge der Gruppenadressen bei der Zuweisung sehr wichtig
nach einigen Spielereien mit der ETS und dem Studium der Applikationsanweisungen denke ich, dass ich irgendeine komplexere Logik-Engine brauche.
Gibts "irgendwas", bevorzugt auf Linux (Raspberry Pi?), mit dem man so auf dem Bus mitspielen kann, dass ein externes Perl-Script odgl. auf Tastendruck zurück in den Bus sendet?
Ich hab dein eibd gefunden und diverse Visu-Projekte aber so recht schlau werde ich daraus nicht.
Als ich kann Dir Wiregate empfehlen. Dort bekommst Du auch gerade dazu die ganze Hardware um mit dem Bus zu kommunizieren und hast zudem ein sehr schönes Linux-System mit Rootzugang. Für die Logik könntest Du dann noch ein "linknx" darauf installieren oder Plugins (bsp. Perl) verwenden. Das ganze kannst Du dann mit XML konfigurieren. Im Forum findest Du auch viele Einträge dazu. Die passende Visu wäre dann gerade wohl CometVisu...
Eine Alternative wäre natürlich auch, das ganze auf Raspberry Pi selber aufzusetzen (Du kannst mehr oder weniger das gleiche bauen, was auch Wiregate kann), aber das war mir zu aufwändig und ich fand, dass da die Leute, die das ermöglicht haben, auch was verdienen sollen. Hier war ich froh, dass ich so einfach eine funktionierende und getestete Umgebung zu bekommen.
Wiregate hatte ich auch schon gesehen, das Perl Plugin klingt wirklich gut. 476 Euro ist zwar nicht wenig aber im Rahmen gesehen wohl auch verkraftbar.
Linknx finde ich - zumindest anhand der zugänglichen Wiki und Web Ressourcen irgendwie unbenutzbar ( da ich noch in der Planungsphase bin habe ich es aber noch nicht runtergeladern oder probiert, vllt. täuscht das ja).
Wahrscheinlich stelle ich mir das was ich will zu einfach vor
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar