Steuert man Gewerke auch in rudimentären Räumen am besten/hauptsächlich über Szenen

[Pyrate]

Hallo zusammen,

ich hätte eine Anfänger-Frage hinsichtlich der Parametrierung und Nutzung von Szenen. Zunächst sind ja Szenen wie "Kochen", "Fernsehen", "Dinner" usw. recht gängig und derselbe Raum (z. B. offenes Wohnen/Essen/Kochen) wird in verschiedene Zustände (=Szenen) mit Licht, Jalousien etc. versetzt. Soweit denke ich, dass ich den wesentlichen Sinn hinter Szenen erfasst habe.

Das Auslösen einer Szene läuft z.B. über eine "Szenennebenstelle" (Taster/Sensor), die die Szene an eine Gruppenadresse meldet, welche wiederum von diversen Aktoren ausgelesen wird. Diese orientieren sich dann an der übermittelten Szenennummer, um die richtigen Kanäle entsprechend zu Schalten etc.

Ich frage mich gerade, ob Szenen auch in Nebenräumen fast immer sinnvoller sind, um tägliche Standard-Vorgänge abzubilden. Z. B. stelle ich mir im Eingang die Frage, ob der PM nicht am besten eine Szene auslöst, die dann die Beleuchtung schaltet (besteht aus zwei DALI Kanälen und zwei geschalteten Steckdosen). Ich mache das gerade daran fest, dass ein Sensor ja "nur" an eine GA senden kann. Jetzt spielen hier aber schon ein DALI-Gateway und ein Schaltaktor und möglicherweise noch ganz andere Gewerke mit.

Löst ihr so etwas eher über eine "normale" (Ein/Aus) GA, die die beteiligten Aktoren lesen, oder empfiehlt sich auch hier schon die Benutzung von Szenen. Es geht ja nicht um echte verschiedene Szenen in einem Raum, sondern um Standardvorgänge. Also eigentlich ist der Vorgang in dem Raum immer nur (Szene) Ein/Aus. Gerade denke ich, dass also doch eine "normale" GA besser ist... hm...

Die Frage stellt sich auch hinsichtlich der Zentralfunktionen, wie z. B. "EG alles aus".

Über Beispiele und Tipps würde ich mich freuen, danke.

[TheOlli]

Ich habe das über normale GA gelöst. BWM schaltet Aktor ein, Treppenlichtfunktion am Aktor schaltet Licht aus.
Eine zentrale GA (z.B. "EG alles aus") sperrt den Kanal auf den Aktor (Bei Sperren ausschalten, bei Entsperren nichts machen)

[mumpf]

Hi,

Du kannst das auf 2 Arten betrachten:

• Technisch:
  Wenn Du mehrere Geräte ansteuern willst, und das Steuersignal für alle Geräte gleich ist (überall gleicher DPT und gleicher Wert), dann brauchst Du keine Szene. Sprich: Du willst nur schalten (Eingangslicht1, Eingangslicht2, Sprachbegrüßung/-abschied, Klimaanlage) und es ist klar, dass sich alle bei einem "AN" und bei einem "AUS" so verhalten, wie Du es willst.
  Willst Du aber verschiedene Geräte mit verschiedenen DPT ansprechen oder bei gleichem DPT unterschiedliche Werte realisieren, dann brauchst Du eine Szene. Und Du braucht für ein theoretisches AN + AUS nicht nur eine, sondern 2 Szenen. Beispiel: Beim betreten Licht 1 auf 20% und Licht 2 auf 50% dimmen, Alarmanlage AUS, Begrüßungsjingle AN.
• Semantisch:
  Du willst bestimmte Sachen gleichartig behandeln und meinst, auch Schaltvorgänge sollten gleichartig sein. Du brauchst für mindestens einen Schaltvorgang eine Szene, also realisierst Du alle Schaltvorgänge mit einer Szene. Da heutzutage immer noch nicht alle Funktionen von Geräten über Szenen adressierbar sind, wirst Du bei so einem Ansatz nicht um Logiken herum kommen, die Szenen wieder in einzelne GA-Aktionen umsetzen.

Ich habe mich entschieden, nur da Szenen einzusetzen, wo ich es technisch brauche.

Noch etwas:

die die Szene an eine Gruppenadresse meldet, welche wiederum von diversen Aktoren ausgelesen wird.

eine "normale" (Ein/Aus) GA, die die beteiligten Aktoren lesen,

Diese beiden Sätze sagen mir, dass Dein Bild von der KNX-Kommunikation falsch ist. Die GA ist kein Objekt, an die irgendwas gemeldet wird und die wiederum irgendwie ausgelesen werden kann. Die GA ist die Adresse eines Kommunikationskanals und kann nichts speichern und somit auch nicht ausgelesen werden.
Wenn ein KO ein Telegramm "an eine GA sendet" meint das nur, dass dieses Telegramm an alle KO gesendet wird, die diese GA zugewiesen haben. Das/Die Ziel-KO empfangen dann das Telegramm und machen dann irgendwas damit.
Ich glaube, dass Du bei der Fehlersuche potentiell Probleme bekommst, wenn Du denkst, dass die GA irgendwie geschrieben und dann auch wieder gelesen wird. Nur so als Hinweis.

Gruß, Waldemar

[Pyrate]

Danke für die sehr gute Erklärung Waldemar.

Dass mit der GA habe ich auch soweit verstanden. Was die Sache halt komplex macht, ist dass ein KO nur an/über eine GA senden kann, aber mehrere KO das entsprechende Telegramm empfangen können. Der Kommunikationskanal kann sich also vom Ursprung (Sensor) zu den Aktoren hin verästeln, wenn man es bildlich beschreiben will. Daher find ich die Formulierung, dass an etwas gesendet wird, dass von mehreren Sachen ausgelesen werden kann, gar nicht so falsch...

Ich werde es dann wie von dir vorgeschlagen umsetzen und Szenen (nur) einsetzen, wenn technisch nötig.

[gbglace]

Der Kommunikationskanal kann sich also vom Ursprung (Sensor) zu den Aktoren hin verästeln, wenn man es bildlich beschreiben will. Daher find ich die Formulierung, dass an etwas gesendet wird, dass von mehreren Sachen ausgelesen werden kann, gar nicht so falsch...

Warum soll er sich verästeln?

Der KNX ist Multicast also es ist immer ein voller Rundruf ins ganze System. Und die GA als Teil des Rundrufsignals sagt den jeweiligen KO ob der zweite Teil der Nachricht für das KO von Interesse ist. Da ist nichts mit auslesen. Technisch hat es Waldemar auch ganz gut erklärt. Die GA ist eben Teil der Information welche eine Lebensdauer auf dem Bus aufweist die der Zeit entspricht, die das elektrische Signal braucht um alle Enden der grünen Leitung zu erreichen. Das schließt auch sowas wie Speichern aus.

Und da eben ein KO mit vielen GA hörend verbunden werden kann (auch an der Definition kannst erkennen, dass da nichts aus GA ausgelesen wird) ist es ja gar nicht notwendig, dass ein Gerät, welches eine Funktion abbildet, von seinem KO aus auf mehr als eine GA sendet, solange eben alle Geräte die in dieser Funktion involviert sind das gleiche Datenformat als Input benötigen. Sind unterschiedliche Datenformate notwendig, dann nimmt man bestenfalls Szenen, sofern das alle Empfänger der Funktionsanweisung akzeptieren und der Sender das auch kann.
Geht das mit den Szenen nicht, dann geht man vom Funktionsauslöser in eine Logik und diese sendet passende Telegramme (möglichst nur eines je Datenformat) weiter.

Und schon bist wieder am Thema GA-Struktur um eben auch solche Zentralfunktionen darin sinnvoll abzubilden. Auch ein Grund weswegen ich in meiner Struktur Geschoss oder Raum nicht abbilde.

[mumpf]

Hi,

Daher find ich die Formulierung, dass an etwas gesendet wird, dass von mehreren Sachen ausgelesen werden kann, gar nicht so falsch...

ich kann und will Dir Deine Formulierungen nicht vorschreiben, ich möchte eher Denkanstöße bieten.

Meistens denkt man ja in den gleichen Bahnen, wie man es beschreibt. Und so wie Du es schreibst (schreiben in eine GA, lesen von einer GA) kann man schnell auf die Idee kommen, dass die GA etwas "greifbares", also ein Objekt ist. Und dann könnte man erwarten, dass ein GroupValueRead auf eine GA auch den Wert der GA liefert, nämlich den, den man vorher reingeschrieben hat. Und wundert sich dann, dass die ETS keinen Wert liefert und fragt dann im Forum nach, warum denn in der GA nichts steht. Bin schon recht lange dabei und hab sowas schon häufiger in verschiedenen Nuancen gelesen.

Die obige Vorstellung ist aber falsch, weil ein GroupValueRead nur eine Leseaufforderung an alle KO sendet, die diese GA zugewiesen haben. Und alle KO, die ein L-Flag gesetzt haben, antworten auf diese Leseanforderung. Es kann also durchaus keinen Wert geben (kein KO hat ein L-Flag) oder mehrere Werte (weil verschiedene KO mit L-Flag mit verschiedenen Werten antworten). Im Idealfall kommt nur eine Antwort zurück, weil nur ein KO ein L-Flag zugewiesen hat. Aber selbst da muss es nicht der Wert sein, den man irgendwann vorher per Telegramm an dieses KO geschickt hat (den man also nach Deiner Vorstellung in die GA geschrieben hat), sondern ein Wert, den das Gerät (z.B. Sensor) in das KO geschrieben hat und nicht auf den Bus gesendet hat (weil das KO z.B. das Ü-Flag nicht gesetzt hat). Es ist also mitnichten eine GA, in die man reinschreibt und aus der wieder was gelesen werden kann. Das ist und bleibt ein falsches Bild der KNX-Kommunikation!

Warum schreibe ich das Ganze? Selbst wenn Du es richtig verstanden hast, aber nur ungenau (meiner Meinung nach falsch oder zumindest irreführend) formulierst, so gibt es andere Anfänger, die es irgendwann lesen und durch die Formulierungen vielleicht eine falsche Vorstellung von der KNX-Kommunikation bekommen. Und wenn sich erstmal ein falsches Bild eines Konzeptes im Kopf festgesetzt hat, bekommt man das gar nicht mehr so einfach raus. Und es führt dann zu weiteren - häufig unnötigen - Fragen im Forum. Deswegen habe ich Dich oben korrigiert.

Viel Spaß noch bei Deiner weiteren Programmierung,
Gruß, Waldemar