Senden und Hören auf GAs - ein KO auf verschiedene GAs hörend?

[Pyrate]

Hallo zusammen,

ich wollte kurz einmal ein wenig Struktur abklären:

- KOs (Kommunikationsobjekte) können "nur" auf eine GA (Gruppenadresse) senden
- Mehrere KOs (z. B. von zwei unterschiedlichen Tastern) können auf dieselbe GA senden (und damit bspw. den gleichen Leuchtenkanal schalten)
- Außerdem können auch mehrere hörende KOs (z. B. zwei Aktoren) auf dieselbe GA hören (und damit z. B. auf denselben Taster reagieren)

Jetzt folgende Frage: kann ein hörendes KO (z. B. vom Schaltaktor Ein/Aus) auf mehrere GAs "hören"?

[Beleuchtfix]

Ja

[mumpf]

Hi Pyrate,

Deine Fragen sind sehr gut, ich ergänze das mal, um Dich zu verwirren - natürlich nicht, sondern nur um es zu vervollständigen:

Es gibt keine hörenden oder sendenden KO, ob und auf was ein KO hören oder senden kann, wird durch die Flags bestimmt. Hat ein KO ein S-Flag, dann hört es auf (jegliche zugeordnete) GA. Hat es ein Ü-Flag, dann kann es auf eine (die erste) GA senden. Hat ein KO sowohl S- wie auch Ü-Flag gesetzt, dann ist es beides: hörend und sendend. Es kann dann auf viele (auch die erste) hören und auf die erste GA senden.

Das hier (und bei dir oben) gesagte gilt nur für die Telegramme vom Typ "GroupValueWrite", bei "GroupValueRead" und "GroupValueResponse" gibt es noch Detailunterschiede, aber ich will nicht noch mehr verwirren.

Gruß, Waldemar

[Pyrate]

Danke für die Erläuterungen. Die Flags habe ich mir auch angesehen. Allerdings will ich da insbesondere nicht irgendwas verstellen, sondern nehme es so, wie es quasi schon sinnvoll vorgegeben ist.

Ich finde die Einschränkung, dass man nur auf eine GA ein sendendes KO senden lassen kann schon nervig. Aber das ist meine persönliche Meinung, dass ich vom "Sender" aus denke und der quasi alles Ein/Ausschalten whatever soll...

[gbglace]

GA ein sendendes KO senden lassen kann schon nervig.

Was ist daran nervig es ist konsequent und überaus logisch. Du drückst einen Taster und erwartest eine Reaktion. Was hindert dich daran genau EINE GA zu nehmen die diese Reaktionserwartung (Schaltbefehl) verkörpert überall dahin zu verbinden wo das entsprechende ausgeführt werden soll?

Und wenn ein Aktor mit 2 Kanälen für jeden Kanal gemeinsame Auslösungen und aber auch gemeinsame Auslöser hat, dann ist es doch gut wenn diese verschiedenen Befehle (schalte A schalte B schalte beide) eben beliebig mit den Kanälen verbunden werden könnte. So kann Kanal B auch irgendwann mal mit Kanal X aus Aktor Y zusammen schalten und das aus Taster Nr.5.

Und noch eins was soll ein binärer Taster sonst so senden als eben 0/1.

Für die Zusammenlegung von verschiedensten Befehlstypen, wie Licht AN, Rollo 5% höher und Heizung auf Nachtbetreib mit einem Tastendruck, dafür nutzt man Szenen. Da ein KO eh nur ein Datentyp sein kann macht es da auch keinen Sinn direkt mehrere GA zu beschreiben.

Geht es um reine binäre Auslösungen ja/nein kann alles was auf den Taster reagieren soll auch damit mit einer GA verbunden werden, warum sollte der Taster da mehrere GA senden? Der Befehl lautet an der Stelle Schalte Gruppe xy.

Hat da etwa wer ein GA-System streng nach Aktor gebaut und kommt jetzt mit einigen Gruppenaktionen nicht mehr klar?

[Shine120]

Hat da etwa wer ein GA-System streng nach Aktor gebaut und kommt jetzt mit einigen Gruppenaktionen nicht mehr klar?

Wie meinst denn das? Ist doch auch erst mal nicht verkehrt?

[gbglace]

Naja wer seine GA streng nach Aktoren auslegt hat dann natürlich ein Problem wenn eine Taste Licht an Aktor A und Aktor B gleichzeitig schalten soll. Weil es eine solche GA dann ja nicht gibt und dann kommt man auf die Idee zwei GA an den Taster zu verbinden und ist genervt, dass das nicht funktioniert und man sich dann schon wieder ne Sonderlocke in sein GA-System basteln muss.

[Beleuchtfix]

Wenn Gruppenbefehle eine z.B. eigene Mittelgruppe haben sehe ich auch keinen Unterschied zu anderen Wegen.

[Shine120]

Wenn Gruppenbefehle eine z.B. eigene Mittelgruppe haben sehe ich auch keinen Unterschied zu anderen Wegen.

Genau so handhabe ich das i.d.R auch.... eine Mittelgruppe für Gruppierungen.



gbglace wie ist dein Ansatz in der Regel?

[gbglace]

Ich bin da sehr funktionsorientiert im Gewerk/Funktion/Objekt-System unterwegs. Lichtgruppen z.B. (also alles was nicht Gewerkübergreifende Gruppen sind) nehme ich dazu gern als eigenes Element mit in die Untergruppen auf, haben ja soweit auch alle Funktionen (MG) wie eine einzelne Lampe. Gewerkübergreifende Funktionen was keine Szenen sind, sind eigene HG, weil meist eh nur 1-Bit Format, die MG sind da dann sehr flexibel.

[Pyrate]

Hm... also ich habe mich nicht (bewusst) am Aktor orientiert, sondern zunächst an den physischen Dingen, d.h. z. B. an der Leuchtengruppe Spots im Eingang sowie der LED-Stripe Beleuchtung des Garderobenschranks. Für beides habe ich die Gruppenadressen angelegt. Für die Spots DALI (d. h. inkl. Dimmen usw.) und für den Stripe "nur" Schalten. Nach diesem Schema habe ich als Startpunkt einmal das Haus abgebildet. Nun ergeben sich durch die reale Benutzung aber natürlich Schaltszenarien, bei denen nicht nur die Spots für sich geschaltet werden, sondern der Stripe immer dazu. Es gibt aber vielleicht auch mal eine Nutzung wo nur der Stripe an ist (als Ambiente Licht) und die Spots nicht.

Die Frage, die ich mir stelle, ist: Baue ich dafür jetzt eine Mittelgruppe für Gruppierungen (mein GA System: Raum/Gewerk/Funktion) oder nutze ich direkt Szenen (hier dann Zusatzfrage, wie ich Szenen in die GA Struktur einsortiere)...

Gibt es eine Art Daumenregel, ab wann man eher auf Szenen setzen sollte und wann Gruppierungen noch das sinnvollere Vorgehen sind? So nach dem Motto: "spätestens ab zwei Gewerken nur noch Szenen" (wobei DALI und Licht-nur-schalten schon zwei Gewerke wären?)

[Gast1961]

Die Szene ist vor allem auch interessant, weil man im laufenden Betrieb die Definition der Szene ändern kann. Also langer Tastendruck für "Szene speichern" und dann wird der jeweils aktuelle Wert der Aktoren als neue Definition der Szene in den Geräten gespeichert. Gilt aber immer für nur die Kanäle, die in der ETS für diese Szene konfiguriert sind. Also Szenenteilnehmer in der ETS festgelegt, Szenenwert jederzeit ohne ETS leicht zu ändern durch langen Tastendruck.

Für Szene und Sammel-GA such dir eine Struktur aus, die für dich sinnvoll und plausibel ist. Man muß da auch keine Wissenschaft draus machen, es ist nur eine Hilfskonstruktion zur besseren Übersicht.

[gbglace]

Bei Szenen daran denken das diese GA ja inhaltlich mehrdeutig sind. Da bekommt nicht jede Szene eine GA sondern eine Ausprägung des Wertes in einer GA. Meist benötigt man dann aber doch mehr Szenen-GA, da nicht alle Geräte die möglichen 128 Szenen-Nummern in einer Szenen-GA unterstützen.

Bei Szenen die sich nicht aus zu vielen Geräten zusammensetzen und gerade so gut sichtbare Elemente wie Licht und Rollos steuern, ist das Nachjustieren der Aktorzustände ohne ETS ein sehr mächtiges Feature. Man muss nur bei den Szenen aufpassen, wo auch Sperren usw. enthalten sind. Sollte eine Szene also schon eine weile aktiv sein und man dann den aktuellen Zustand (Licht etwas die Dimmstufe / Lichtfarbe angepasst) speichern, könnte es sein, dass eine Rollo-Automatik schon nicht mehr gesperrt war oder so. Das würde man sich dann auch rein speichern. In diesen Fällen das feature also nur bewusst verwenden und vorab erneut die Szene auslösen, dann Dimmstufe / Rollo-Position per Hand verändern und direkt speichern. (Voraussetzung die Handbedienung wird nicht von einer Logik abgefangen und ändert andere Zustände die auch in der Szene definiert waren)

Ansonsten habe ich für regelmäßig auch gemeinsam bediente Leuchten entsprechend alle GA auch für die Leuchtgruppe als eigenes Objekt angelegt (Gewerk/Funktion/Objekt). So kann ein Lichtkanal im PM auch die Gruppe schalten ein anderer Lichtkanal bedient nur eine einzelne Leuchte daraus.

[jayw82]

Hi, ich denke das passt hier ganz gut rein. Ich habe das Problem, dass ich 2 Heizkreise, Ankleide und Schlafzimmer zusammengelegt habe und über einen Glastaster steuere. Unten seht ihr die Gruppenadresse dazu. Warum übernimmt der Aktor für die Ankleide die Werte nicht?

image.pngWenn ich die Temperatur um 0,5K ändere, Wird der Sollwert Schlafen verändert, der der Ankleide bleibt aber leider.

[gbglace]

Was bedeutet zusammengelegt?

Da sollen also zwei Räume identisch geregelt werden?
Das macht man nicht in dem man versucht zwei unabhängigen Reglern (Kanäle im Aktor) versucht gleiche Inputdaten beizubringen.

Erste Lösung wäre für mich elektrisch einfach das Stellventil vom Schlafzimmer und der Ankleide am selben Aktorkanal zu verklemmen.

Der nächste Ansatz wäre im Aktor nur an einem Kanal zu rechnen und dem anderen Kanal den errechneten Stellwert in% zu übergeben, also ohne integrierten Regler zu betreiben. Dabei kann man auch dem führenden Aktor neuerer Generation auch mehrere IST Temperaturen liefern (Ankleide/Schlafen)

Die letzte Variante ist es je Regler die gleichen Werte zu geben.

Der Screenshot kann nicht funktionieren, wenn der aus der GA-Liste stammt. Eine GA kann nicht Status und Vorgabewert gleichzeitig sein, wenn unterschiedliche Geräte diese beiden Funktionen generieren. Aber da an der Stelle der Taster nicht funktionieren kann, ist das erstmal egal bzgl. eines Aktorverhaltens..

Also nochmal genauer beschreiben was überhaupt erreicht werden soll oder besser gleich mit weniger SW Abhängigkeit umbauen. Und wenn der eingeschlagene Weg beibehalten werden soll dann neben der besseren Beschreibung. Screenshots der Geräte mit den jeweiligen KO-Listen aus denen die verbundenen GA's inkl. der Flags ersichtlich sind.

Und was führt zu der Aussage das der andere Aktor nicht tut was er soll, woran machst Du das fest? Aus dem Screenshot ist das nicht ersichtlich. Beweisführung wäre ein Auszug aus dem Buslog mit passenden Telegrammen wenn was am Taster an den Sollwerten bedient wird. Und ob dann was fehlt kann eben wieder nur beurteilt werden wenn man alle GA Verbindungen sieht.

PS hat mit dem Thread wahrscheinlich nix zu tun. Weil mit mehreren GA an einem KO ist das hier nicht zu lösen. Und ob Du das gebaut hast weiß niemand weil das passende Bild fehlt.