Szene freigeben/sperren

[fudi6489]

Hallo Leute

Da es ja oftmals nötig ist dass gewisse Szenen unter bestimmten Umständen nicht ausgeführt werden, wäre ich jetzt an der praktischen Umsetzung interessiert bzw hätte eine Idee wie dies meiner Meinung nach einfacher und meist ohne zusätzliche Logik durchführbar wäre.

Beispiel aus der Praxis:
Szene Duschen: Jalousien Behang 100% / Lamellen 50% (Sichtschutz vor Nachbarhaus) , Licht überall 100%, Präsenzmelder sperren, Heizkörper an, Musik ein

Wenn ich zum Beispiel spät duschen gehe, der Nachtmodus bereits aktiviert ist und schon jemand schläft, sollte sich die Musik nicht einschalten
Wenn die Jalousien schon auf 100/100 stehen sollten diese natürlich nicht auf 100/50 fahren, da der Sichtschutz schon gegeben ist
In den Sommermodus muss der Heizkörper nicht eingeschalten werden

Meine vermutlich einfach durchführbare Idee wäre zusätzlich zu jeder Szenennummer ein KO mit Szene sperren/freigeben zu implementieren womit diese Szene dann nicht ausgeführt wird.

Nachtmodus / 1 / Szene Duschen / Radio bleibt aus
MDT Jalousieaktor / Status unter Position / 1 :Szene Duschen / Jalousien verfahren nicht da die untere Position bereits erreicht ist
Sommermodus / 1 : Szene Duschen / Schaltaktor schaltet Heizkörper nicht ein

Vermutlich führen beim MDT Jalousieaktor und MDT Dimmer die vielseitigen Einstellung auch zum gewünschten Effekt, beim MDT Schaltaktor hab ich aber keine Möglichkeit gefunden mit der selben Szenenummer unterschiedliche Aktion auszuführen/sperren. Aber auch bei Jalousieaktor und Dimmer wäre diese Möglichkeit einfacher nachvollziehbar und zu parametrieren.

Mit einem expliziten Sperr KO pro Szenenummer könnte dies meiner Meinung nach sehr einfach umgesetzt werden, was meint ihr dazu bzw was ist eure Variante um ohne zusätzlich Logik Szenen unterschiedlich zu steuern?

Liebe Grüße
Jürgen

[araeubig]

Was hast Du denn sonst noch für Möglichkeiten Logiken zu programmieren? Welche Geräte sind noch verfügbar?

[fudi6489]

Grüß dich
Ich könnte die Szenen beispielsweise in Edomi auslagern, bin aber der Meinung dass Hersteller hier eine für den Endanweder einfache/übersichtliche Möglichkeit schaffen könnten, um die Szenen nur auf KNX bzw in den Geräten die es auch betrifft belassen zu können.

Gerade hier wird ja immer von dem großen Vorteil der Dezentralität von KNX gegenüber anderen Systemen gesprochen. Mit zunehmender Komplexibilität muss man aber immer mehr aus KNX auslagern, was diesen Vorteil klar zu nichte macht.

Zumindest obiges Problem, könnte wahrscheinlich relativ simpel gelöst werden. Dass kompliziertere Logiken über eine Logikengine abgearbeitet werden müssen, steht außer Frage.

Liebe Grüße
Jürgen

[gbglace]

Also Wenn es wegen der Telegrammreduktion Szenen sein sollen, dann in Logiken nur den Auslöser und Nebenbedingungen auswerten und dann verschiedene definierte Szenen je Ergebnis senden und in den Geräten entsprechend anlegen.

[Beleuchtfix]

So einfach Logiken…. du wirst schon Schwierigkeiten haben so etwas genau zu definieren mit allen Abhängigkeiten, noch etwas mehr so etwas als Kunde deinem SI zu erklären oder umgekehrt. Für mich ist das keine typische und notwendige KNX Only Aufgabe.
Such mal bei den Beiträgen von mumpf nach State Machine.
Gruß Florian

[mumpf]

Hi Jürgen,

bin aber der Meinung dass Hersteller hier eine für den Endanweder einfache/übersichtliche Möglichkeit schaffen könnten, um die Szenen nur auf KNX bzw in den Geräten die es auch betrifft belassen zu können.

genau das ist gegeben. Einzelne KNX-Geräte werten Szenen aus und schalten entsprechend.

Was Du willst, sind aber keine Szenen, Du willst die Auswirkungen, die eine Aktion hat, erstmal algorithmisch ermitteln und dann in passende Unteraktionen übersetzen. Das kann man so erreichen, wie Göran das bereits gesagt hat:

in Logiken nur den Auslöser und Nebenbedingungen auswerten und dann verschiedene definierte Szenen je Ergebnis senden und in den Geräten entsprechend anlegen

Ich löse solche Sachen, wie bereits von Beleuchtfix erwähnt, über Zustandsautomaten (State Machines). Die kann man durchaus auch als bedingte Szenen betrachten. Zumindest löst ein Zustand auch eine festgelegte Anzahl von Aktionen aus. Ob ein Zustand betreten wird, entscheiden eben 1 oder mehrere logische Bedingungen. Da man sich auch auf einen vorherigen Zustand beziehen kann (der ja eine Menge von Bedingungen repräsentiert), sind Zustandsautomaten IMHO übersichtlicher als klassische Logiken.

Mit einem expliziten Sperr KO pro Szenenummer könnte dies meiner Meinung nach sehr einfach umgesetzt werden,

Wieso? Wenn Du ermitteln kannst, dass eine Szene gesperrt werden soll, dann kannst Du deren Aussendung einfach verhindern (TOR-Logik). Und die (meist höhere) Komplexität, wann so eine Sperre wieder aufgehoben werden soll, hast Du außer Acht gelassen.

Ich könnte die Szenen beispielsweise in Edomi auslagern,

Gerade hier wird ja immer von dem großen Vorteil der Dezentralität von KNX gegenüber anderen Systemen gesprochen. Mit zunehmender Komplexibilität muss man aber immer mehr aus KNX auslagern, was diesen Vorteil klar zu nichte macht.

Der Vergleich hinkt etwas... KNX erlaubt eine Dezentralisierung, erzwingt sie aber nicht. Keiner verbietet es Dir, 20 Edomi-Instanzen laufen zu lassen, um eine passende Dezentralisierung zu erreichen. Dass die meisten Leute sich ein Zentralsystem als Logik- und Visu-Server hinstellen und den Aufwand von verteilten Logiken scheuen (ich nehmen mich da nicht raus) kann man nicht KNX anlasten.

Ich habe für mich z.B. eine Logikengine geschrieben, die ich nativ als KNX-Gerät betreibe und die in 17 meiner KNX-Geräte vor sich hin werkelt. Ist aber klassische Logik und aufwändig zu pflegen, deswegen denke ich immer wieder darüber nach, wie ich das als State Machine hin bekomme.

Gruß, Waldemar

[Amenophis]

Ich hänge mich mal dran mit der Frage was denn genau dann State Machine ist? Reden wir dann von einem selbst entwickelten Aktor oder einem Server? Was genau meinst du damit? Also was es machen soll habe ich verstanden aber kann mir physisch unter dem Begriff noch nichts vorstellen.

[mumpf]

Hi Etienne,

eine State Machine (SM) ist eine Software-Lösung für Logiken. Ich nutze diese auf meinem zentralen Server (derzeit Home Assistant, vorher Callidomus), um bestimmte Steuerungen zu realisieren. Es ist kein Zaubermittel, alles was mit einer SM lösbar ist, ist auch mit einer "normalen" UND/ODER/NICHT Logik lösbar, die Dekweise ist aber anders. Du gehst immer von einem Zustand aus und überlegst Dir nur, welche Bedingungen notwendig sind, um in den nächsten Zustand zu kommen. Das macht es IMHO übersichtlicher.

Minimalbeispiel (eine simple UND-Logik als SM):

                 A=1 und B=0
AUS -----------------------------> AN

soll sagen: Ich bin im Zustand AUS, der einzige Weg zu AN ist gegeben, wenn A=1 und B=0 sind. In klassischer Logik würde man so was als X = A UND NICHT B schreiben. Hier hat man also noch nicht wirklich was gewonnen.

Der Vorteil ist erst gegeben, wenn man mehrere Einflüsse hat:

               A=1 und B=0
AUS -------------------------------> AN

               A=0 und C=1
AUS -------------------------------> AN

In klassischer Logik wäre das schon X = (A UND NICHT B) ODER (NICHT A UND C). Würde ich hier weiter machen, würde der Logikausdruck immer unleserlicher werden, bei der SM-Notation kommen nur weitere "einfache" Zeilen dazu.

Aber wie immer hängt viele aus vom UI bzw. dem entsprechenden Editor ab. Ich hab mal versucht, eine SM in der ETS abzubilden, das ist nicht einfach (aufgrund der eingeschränkten Editiermöglichkeiten):
Matrix-Logik.png
Ohne jetzt auf Details einzugehen, das Ding würde mir die Information "Motor fährt" und "Nächste Richtung" für meinen Rollladen ausgeben (gibt mein Aktor nicht her) und den Fahrbefehl "Weiterfahren" implementieren. Ich nutze für Rolläden 1-Tasten-Bedienung und habe den STOP-Befehl dahingehend erweitert, dass STOP bei stehendem Rollladen ein "Weiterfahren" bedeutet. Obiges mit klassischen KNX UND/ODER/NICHT/TOR/TREPPENLICHT-Logiken hat 15 Logikkanäle gekostet. Und das pro Rolladen/Markise (24 Stück) würde alleine schon 360 Logikkanäle bedeuten...

Ist aber nur ne Studie meinerseits, ich schaue derzeit, was so alles geht.

Reden wir dann von einem selbst entwickelten Aktor oder einem Server?

Die Studie oben zielt auf eine Erweiterung von meinem Logikmodul, also ein eigenständiges KNX-Gerät. Ich habe 17 davon in meinem Haus verbaut und sehe durchaus Chancen, ca. 50 solcher Logikkanäle pro Modul unterzubringen.

Ist aber noch ein weiter Weg dahin. Für mich ist aber verteilte, direkt in KNX implementierte Logik durchaus ein erstrebenswertes Ziel. In meinem Idealbild liefern 2 zentrale Server (wegen Ausfallsicherheit) externe Daten (Wetterdaten, Kalender, Fingerprint, PV, also generell IP-basierte Informationen) auf den Bus und jegliche Weiterverarbeitung erfolgt über meine verteilte Logik nativ in KNX.

Gruß, Waldemar

[Amenophis]

Ich hoffe, dass es irgendwann mal wieder ne Sammelbestellung gibt um mir mal 2-3 der Geräte zu besorgen und deine Software drauf zu machen. Ist immer wieder spannend was du aus den Dingern raus holst

[mumpf]

Hi Etienne,

bevor da ein falscher Eindruck entsteht: Das oben sieht vielleicht nett aus (und kompliziert), weil die ETS es darstellen kann, aber es geht noch gar nichts weiteres: Weder werden die Parameter korrekt auf das Gerät geschrieben (statt 12 k werden nur ca. 800 Byte übertragen, auch ohne partielle Programmierung, ich hab keine Ahnung warum), das gesamte Coding im Gerät fehlt noch und ich versuche gerade mal (wenn ich dazu komme) die einzelnen Schreibtelegramme der ETS zu verstehen, um eine Idee zu bekommen, was da schiefläuft.

Also ist es wirklich noch eine SEEEEEHR weiter Weg... Die letzte Logik, die ich gebaut habe, hat 2 Jahre gedauert .

Gruß, Waldemar

[fudi6489]

Danke für eure Antworten

Meine Szenen hätte ich mit dem Vorhaben aus Beitrag 1 alle leicht erschlagen können, aber ihr habt vermutlich recht und ich werd mir die State Machines mal näher ansehen.

Wieso? Wenn Du ermitteln kannst, dass eine Szene gesperrt werden soll, dann kannst Du deren Aussendung einfach verhindern (TOR-Logik). Und die (meist höhere) Komplexität, wann so eine Sperre wieder aufgehoben werden soll, hast Du außer Acht gelassen.

Die Aufhebung der Sperre sollte die Szene eben nicht tangieren. Ist ja beim Senden einer Szene auch so dass nur der Soll Zustand zum jetzigen Zeitpunkt gesendet werden soll.

Liebe Grüße
Jürgen

[mumpf]

Hi,

Meine Szenen hätte ich mit dem Vorhaben aus Beitrag 1 alle leicht erschlagen können,

meine Ausführungen sollten nicht gegen Deine Lösungsidee sprechen, ich wollte Dich nur davon abbringen, von einem Hersteller (oder gar von dem gesamten KNX-System) zu erwarten, dass man Szenen anders implementiert (eben mit zusätzlichen Sperrobjekten), weil Du jetzt speziell einen Fall hast, wo es gerade mal passen würde.

Wenn Du mit Deiner Idee auskommst, dann mach das doch. Szene sperren ist direkt als Logik im MDT Glastaster machbar (falls Du so einen hast):

• UND mit invertiertem Eingang2 (für die Sperre)
• Ausgang sendet die gewünschte Szene
• Eingang1 bekommt das Tastsignal (allerdings DPT1, nicht als Szene)
• Eingang2 bekommt das Sperrsignal (1 heißt gesperrt, sonst die Invertierung rausnehmen)

Mit einem Glastaster kannst Du 4 solche Dinger bauen. Mit dem MDT Logikmodul auch 24 (dann auch kompliziertere).

Die Aufhebung der Sperre sollte die Szene eben nicht tangieren.

Das habe ich nicht gemeint. Ich meinte, dass es anspruchsvoll sein kann, herauszufinden, wann die Sperre zurückgesetzt werden soll. Ist vielleicht in Deinem Falle nicht so, aber im allgemeinen braucht man dafür wieder eine Logik.

Und noch hierzu:

Wenn die Jalousien schon auf 100/100 stehen sollten diese natürlich nicht auf 100/50 fahren, da der Sichtschutz schon gegeben ist

Der Gedanke ist für Abends korrekt. Morgens ist aber der Sichtschutz noch gegeben (Szene wird also nicht gesendet), aber dann wird während des Duschens der Nachtmodus abgeschaltet und die Jalousie geht hoch, der Sichtschutz wird also zum ungeeigneten Zeitpunkt aufgehoben. Deswegen sollte man bei solchen Zusammenhängen, wie Du sie möchtest (und die sind gut) nicht mit einer Szene "Duschen" arbeiten (die in manchen Situationen ignoriert wird), sondern mit einem Zustand "Duschen", der den Behang auf die gewünschte Höhe bringt (falls nötig) und der Vorrang vor dem Zustand "Tag" hat.

Gruß, Waldemar