Mehrere Gruppenadressen ansprechen

[anlo007]

Wenn es in der Agefo zu kompliziert wird, kannst du auch einfach in den Aktorkanal, der deine Sirene ansteuert, alle 10 GAs der Rauchmelder eintragen und das Rückmeldeobjekt des Kanals auf eine GA legen, die die AGFO anspricht.

[Frank65]

Danke für die schnelle Antwort. Ich probiere das morgen abend mal aus und werde die 10 Objekte in der Agfeo eintragen (ist dort in der Oberfläche leider etwas unkomfortabel gelöst)

Gruß, Frank

[swiss]

Die Lösung ist relativ einfach:

Ein Eingangsobjekt kan immer nur auf 1 GA senden. (Ist nunmal so)

Ein Ausgangsobjekt kann Theoretisch auf unbegrenz viele GA's hören.

Also ist die Lösung ganz einfach. Das Objekt dass auf denem Agfeo Gateway das senden des Sammelalarms auslöst, muss mit allen GA's der Rauchmelder verbunden werden.

EDIT: ^^ Ich war wohl etwas zu langsam

es stimmt, senden darf jedes kommunikationsobjekt nur auf eine GA.
aber *hören* kann es auf beliebig viele.

lass also die agfeo-anlage auf alle 10 GA hören. egal wo es brennt die anlage reagiert...

[Frank65]

Hallo,

ich glaube, ich hänge gerade an dem gleichen Problem, wie es in diesem Beitrag schon diskutiert wurde. Die Lösung dafür habe ich aber trotz intensivem Lesen nicht gefunden bzw. nicht verstanden.

Meine Situation:

Ich habe 10 Rauchmelder, die auf einzelne Binäreingänge gehen. Dazu habe ich jetzt 10 GA angelegt, in denen jeweils der Binäreingang (als sendend) und ein Befehlsausgang zur Ansteuerung der Sirene eingetragen ist. Funktioniert soweit.

Zusätzlich möchte ich aber auch eine Rauchmelder-Sammelmeldung-GA haben, in die alle 10 Binäreingänge eingetragen sind und die dann meine Agfeo-TK-ANlage zur Absendung eines Anrufes anreizen.

Das funktioniert aber nicht, weil die Telegramme von den Binäreingängen nur in jeweils einer der beiden GA als sendend eingetragen werden können.

Die folgenden Zitate konnte ich nicht umsetzen

Ich hab mir nun eine GA angelegt, in denen alle zu schaltenen GA verknüpft sind. Problem is damit gelöst

Eine Gruppenandresse in denen alle Gruppenandressen verkünpft sind ? Wie geht das in der ETS3 ?

erstelle einfach eine neue gruppe die alle objekte der 4 gruppen enthält.

Das ist ja ganau mein Problem. In der neuen Gruppe wären die Telegramme ja nicht auch als sendend einegtragen

du kannst auch über GA n:m beziehungen aufbauen...

Was ist damit gemeint ?

Ist meine Aufgabenstellung ohne Homeserver oder Automatisierungsmodul zu lösen ?

Gruß, Frank

[Tokamak]

Wie deine Unterzeile aussagt, hast du einen HS, da kannst du dir doch die entsprechenden GAs zusammenfassen und gemeinsam schalten lassen.

Im Prinzip ja. Dennoch bräuchte ich eine GA pro Sensor, um zu identifizieren, welcher denn nun gemeldet hat, um dann die eigentlich zu sendenden GA auf den Bus zu schicken. Dann kann ich diese Sensor-GA auch direkt auf den Aktorkanal legen.

Wie gesagt, zu helfen weiß ich mir. Das ändert aber nichts daran, dass das eine oder andere für mich ein Ärgernis bedeutet.

Wirklich schlimm ist es nicht

[anlo007]

Wenn ich aber bereits Kanäle mit zugewiesenen kanalbezogenen GAn habe, die ich (in kleinen Gruppen!) gruppieren möchte, würde ich die bereits existierenden GAn nehmen und diese dem Sensor zuweisen, ohne Gruppen-GAn zu bilden.

Wie deine Unterzeile aussagt, hast du einen HS, da kannst du dir doch die entsprechenden GAs zusammenfassen und gemeinsam schalten lassen.

[Tokamak]

Der EIB ist eins der seltenen Systeme die ich Analysiert habe in denen man sieht dass die Entwickler sehr grosse Gedanken zum gesammt Konzept gemacht haben und sehr Gute Lösungswege gefunden haben.

Das kommt wie so häufig auf die Abstraktionsebene an. Sicher ist es richtig, dass die Komplexität des Systems mit dem Anwenderkreis korrelieren muss. Wenn das System zu komplex oder zu fehleranfällig ist, hilft es nicht. Keine Frage.

Dass das Konzept noch zu verbessern wäre, sollte hingegen nicht verneint werden. Ob der Punkt, der von mir erwähnt wurde, bei einer Verbesserung eine Rolle spielen würde, lasse ich mal außen vor. Ich schrieb lediglich, dass ich mich das eine oder andere Mal über die oben erwähnte Einschränkung geärgert habe, nicht, dass ich damit nicht umgehen kann.

[Tokamak]

Du brauchst so oder os 3 GA's. Egal ob du pro Aktorkanal eine GA anlegst oder pro Gruppe wie z.B:

Schon klar. Aber ich werde in den seltensten Fällen nur Gruppen und nicht auch die einzelnen Kanäle schalten. Die einzelnen Lichtband-GA im obigen Beispiel würde ich schon benötigen.

Als spielt es nur in den aller seltensten Fälle eine Rolle. Dazu kommt die Buslast. Auch in einem Einfamilienhaus hast du Zentralbefehle. Ein Befeh wie Alles aus, der auf 100 GA's gesendet wird belastet den Bus viel mehr als wenn man 1 GA anlegt und alle Aktoren darauf lauschen.

Auch klar. Natürlich habe ich einen (sogar mehrere, abgestufte) Zentral-Aus-GA. Die würde ich auch dann einrichten, wenn ich die Möglichkeit hätte, mehrere GAn zu senden.

Es kommt auf die Betrachtung an. Wenn ich eine GA "Zentral-Aus" habe, überlege ich mir bei jedem neuen Aktorkanal, ob ich diesen zentral ausschalten möchte, und weise dann entsprechend die GA zu oder nicht. Da macht das EIB-Konzept Sinn.

Wenn ich aber bereits Kanäle mit zugewiesenen kanalbezogenen GAn habe, die ich (in kleinen Gruppen!) gruppieren möchte, würde ich die bereits existierenden GAn nehmen und diese dem Sensor zuweisen, ohne Gruppen-GAn zu bilden.

Die Rückmeldungen sind nicht zu vernachlässigen. Vor allem bei grösseren Installatinen mit mehreren hundert Aktoren und Sensoren. Wenn dan noch ein HS/FS dazu kommt und der Integrator keine Ahnung von Filtertabellen hat, kann das sehr unangenehme Konsequenzen haben.

Mir geht es auch gar nicht um ein "entweder-oder", sondern um ein "sowohl-als auch". Wenn ich große Installationen habe, gehe ich mit der Buslast anders um als in kleinen Installationen.
Und das Konzept "sende eine GA - schalte zig Kanäle" verhindert letztlich nicht, dass ebenso zig Statusmeldungen auf den Bus geschickt werden, wenn ich dies im Aktor so konfiguriert habe.

[Gaston]

Dass das Konzept so ist, wie es ist, ist klar. Nur, wenn man statt in Funktionen in Relationen denkt bzw. gedacht hätte, hätte sich am Konzept nichts Grundlegendes geändert.

Dann hätte sich diese "Problem" nur verschoben um anderen Problemen Platz zu machen. Wie so oft im Leben pickt man eine Lösung zu einem punktuellen Problem heraus und denkt man hätte "die Lösung", übersieht aber den globalen Kontext und somit die nuen Probleme.

Der EIB ist eins der seltenen Systeme die ich Analysiert habe in denen man sieht dass die Entwickler sehr grosse Gedanken zum gesammt Konzept gemacht haben und sehr Gute Lösungswege gefunden haben.

Gruss,
Gaston

[swiss]

Richtig.

Die Rückmeldungen sind nicht zu vernachlässigen. Vor allem bei grösseren Installatinen mit mehreren hundert Aktoren und Sensoren. Wenn dan noch ein HS/FS dazu kommt und der Integrator keine Ahnung von Filtertabellen hat, kann das sehr unangenehme Konsequenzen haben.

[MarkusS]

Nicht zu vergessen die Rückmeldungen die damit ggf. ausgelöst werden ...

[swiss]

Hallo Tokamak

Du brauchst so oder os 3 GA's. Egal ob du pro Aktorkanal eine GA anlegst oder pro Gruppe wie z.B:

(1 und 2), (2 und 3) und (1 und 3)

Also spielt es nur in den aller seltensten Fälle eine Rolle. Dazu kommt die Buslast. Auch in einem Einfamilienhaus hast du Zentralbefehle. Ein Befeh wie Alles aus, der auf 100 GA's gesendet wird belastet den Bus viel mehr als wenn man 1 GA anlegt und alle Aktoren darauf lauschen.

Das ist ein Sicherheitsmechanissmus, um die Buslast so nidrig zu halten wie möglich. Denn wen solche Zuordnungen möglich wären, könnten sie auch bei grossen Projeken wie Bürogebäuden angewant werden, wo mehreren 1000 GA's eingesetzt werden. Dann kanst du auf den Taster drücken und 10 Minuten warten bis das Licht angeht. SUPER

[Tokamak]

Nun diskutiere ich doch...

Beispiel: Ich habe 3 Aktorkanäle, die jeweils mit den GAn "Lichtband 1", "Lichtband 2" und "Lichtband 3" geschaltet werden.
Nun habe ich 3 Taster, die die Lichtbänder (1 und 2), (2 und 3) und (1 und 3) schalten sollen. Dann würde ich mir wünschen, dass ich die entsprechenden GAn auf die Ausgänge der Taster legen könnte.

Was ich aber tun muss, ist, 3 GAn anzulegen, die die Lichtbandgruppen (1 und 2), (2 und 3) und (1 und 3) symbolisieren, damit ich die geforderte 1:n-Beziehung (Sensor:Aktorkanal) aufbauen kann. Diese 3 Gruppen brauche ich sonst nicht, nur für diese eine Anwendung.

Das muss ich für jede Gruppe machen, die durch ein Ereignis ausgelöst wird. Das heißt, ich muss GAn schaffen, die ich nur aus Sensor-. nicht aber aus Aktorsicht benötige. Für mich ist das Verschwendung, weil ich möglichst wenige Variablen / GAn nutzen will.

Das es mit der Gruppierung geht, ist gar keine Frage. Aber ich empfinde es als (konzeptionelle) Einschränkung.

Sicher richtig ist, dass die Buslast durch das Senden mehrere GAn durch ein Ereignis erhöht wird. In meinem Einfamilienhaus ist das aber kein Problem. Wer große Projekte konzipiert, sollte die Buslast eh im Blick haben und kann auf das Gruppieren von GAn ausweichen.

Wie gesagt, diese Diskussion wird keine Früchte tragen...

du kannst auch über GA n:m beziehungen aufbauen...
wäre schlimm wenn nicht.

was du willst wäre eine abkehr vom multicast hin zu unicasts, was allein schon buslast-technisch unsinn ist.