Szenen und Regeln sammeln

[Proton]

Hallo zusammen,
ich bin gestern auf ein "Problem" gestoßen.
Und zwar wollte ich eine Szene einrichten. Die Szene braucht einen kurzen Thread.sleep deswegen kann man das nach meinem Wissensstand nicht direkt bei Szenen umsetzen, sondern über eine Regel. Die Regel habe ich erstellt und diese funktioniert auch, aber mir fehlte der Trigger, also habe ich ein Switch Item angelegt welches über die Szene angesprochen wird und die Regel auslöst. Jetzt kann ich natürlich sagen, dass die Regel immer ausgelöst wird, sobald sich der Zustand des Schalters ändert und das wird wahrscheinlich auch funktionieren, aber ich weiß halt nicht, ob das die angedachte Vorgehensweise ist bzw. wie man es vielleicht besser machen könnte, deswegen die Frage an die Community.

Wie würdet ihr so etwas umsetzen?

Schönen Gruß

[udo1toni]

Erst mal: Was meinst Du mit Szene?
Grundsätzlich wurden in openHAB zuletzt Schedules und Scenes in der UI eingeführt, tatsächlich sind die aber nur dazu da, den Nutzern die Illusion zu geben, dass openHAB "jetzt auch" Szenen und Timer beherrscht, dabei ging beides schon immer, einfach, indem man eine Rule dafür anlegte.
Ich persönlich halte überhaupt nichts von dieser Trennung

Was will man erreichen? Wenn ein bestimmtes Ereignis auftritt, sollen bestimmte Befehle ausgeführt werden, im einfachsten Fall ein einzelner Befehl, wenn es komplexer wird, auch eine Reihe von Befehlen, die vielleicht auch in einer bestimmten zeitlichen Abfolge ausgeführt werden sollen.
Unterm Strich könnte man z.B. ein Treppenhauslicht auch als "Szene" bezeichnen, bei Tastendruck wird das Licht eingeschaltet und ein Timer gestartet, der das Licht nach Zeit x wieder ausschaltet.

Ein Thread.sleep() ist tatsächlich in den seltensten Fällen wirklich notwendig (im Grunde genommen nie), es kann natürlich die pragmatische und einfache Variante sein aber dazu müsste ich Deine Szene sehen, bzw. wissen, wozu Du das Thread.sleep() eingebaut hast.

Da ich beruflich sehr viel mit Automation zu tun habe, gibt es noch einen wichtigen Punkt zum Thema Szenen:
Aus meiner Sicht (wie gesagt, ich arbeite viel mit Automationen) ist eine Szene nichts weiter, als eine Reihe Befehle, die zu einem großen Block zusammengefasst sind. Bei mir im Wohnzimmer drücke ich eine von drei Tasten, woraufhin drei Dimmer eine bestimmte Helligkeit ansteuern und drei Steckdosen ein- oder ausgeschaltet werden, je nachdem, welche Taste ich drücke.
Das heißt aber auch: Eine Szene wird aufgerufen. Eine Szene ist aber per Definition nicht "aktiv".
Allenfalls könnte ich alle betroffenen Items abfragen, und wenn alle Dimmer sowie Steckdosen exakt dem Wert entsprechen, könnte ich zurück melden, dass die Szene aktiv ist. Ob sie allerdings aufgerufen wurde, oder jemand die Einstellungen nur exakt so vorgenommen hat, wie in der Szene hinterlegt, kann so nicht festgestellt werden.
Umgekehrt, was soll denn passieren, wenn ein einzelner Wert der Szene geändert wird (also z.B. ich schalte eine der Steckdosen um)? Soll die Szene als "aktiv, aber unvollständig" angezeigt werden, oder soll sie als "deaktiviert" gelten? In letzterem Fall: was soll passieren, wenn anschließend der Originalzustand wieder erreicht wird? In ersterem Fall: Wie viel Änderung soll es brauchen, bis die Szene nicht mehr aktiv ist?
Das ist alles extrem unscharf, weshalb es z.B. in knx gewöhnlich keine Möglichkeit gibt, abzurufen, welche Szenen gerade aufgerufen sind. Stattdessen werden lediglich alle Einzelzustände gemeldet.
Das Gegenstück zu einer Szene wäre dann eine Planung, über die man z.B. zeitgesteuert Sollzustände definieren könnte.
Hier könnte man sagen: Planung xy ist aktiv, aber es gibt eine Abweichung vom Sollzustand.
Wieder wäre hier die Frage: Was soll passieren? Soll der Sollzustand unter allen Umständen wiederhergestellt werden, oder doch nicht?
Was ist mit einer manuellen Übersteuerung? Man müsste also Prioritäten einführen, und schon wird das Ganze beliebig kompliziert und vor allem steigen die Möglichkeiten der Fehlbedienung enorm (habe ich schon erwähnt, dass ich einen professionellen Hintergrund dazu habe...?)

[Proton]

Hallo Udo,
erstmal danke für die Antwort. Diese sagt mir wiederum, dass ich meine Frage nicht gut formuliert habe.
Ich habe gelesen, dass Szenen (das was man unter Einstellungen links auswählen kann) ganz ähnlich wie Regeln sind, "fire and forget", deswegen wegen wollte ich auch nicht testen ob eine Szene aktiv ist oder nicht. In der Demo-Umgebung wird das ja irgendwie über general_scene gelöst, aber das ist ein anderes Thema.
Das Szenario ist folgendes: Ich möchte das Wohnzimmer spielbereit machen. Fernseher einschalten, Stromzufuhr für AVR und Mediabox einschalten und dann Mediabox über WOL einschalten. Das Thread.sleep habe ich gesetzt, weil ohne eine kurze Unterbrechung, das WOL-Signal verloren geht und der Rechner nicht startet. Wenn es dafür eine bessere Lösung gibt, ist die natürlich herzlich willkommen.
Das ganze würde ich gerne auch über Alexa starten können, deswegen brauche ich auch ein Item, bei dem ich die Metadaten setzen kann. (So habe ich es jedenfalls verstanden.
Bisher war ich der Annahme, dass Szenen der "richtige" Weg sind um solche Szenarien zu steuern. Wenn es besser ist Regeln zu nehmen, dann ist mir das recht, ich würde nur gerne die angedachte Lösung verwenden.

(habe ich schon erwähnt, dass ich einen professionellen Hintergrund dazu habe...?)

Ich habe das irgendwo schon mal gelesen

Schönen Gruß

[udo1toni]

Ah, der Rechner, der per WOL eingeschaltet wird, wird erst kurz vorher mit der Stromversorgung verbunden. Es läuft darauf hinaus, dass Du in der Größenordnung 10 bis 20 Sekunden warten musst?

Eine Möglichkeit: Du stellst im BIOS des Rechners ein, dass er automatisch einschalten soll, wenn der Strom wieder kommt. Wenn die Stromzufuhr ohnehin gekappt ist, wird das ja sowieso immer der Wunsch sein.

Zweite Möglichkeit (wie bisher mit WOL):
Du verwendest statt des Thread.sleep() einen Timer. Als DSL Rule:

Code: Alles auswählen

rule "Kino vorbereiten"
when
    Item Kinomodus changed to ON
then
    AVR.sendCommand(ON)
    Mediabox.sendCommand(ON)
    Fernseher.sendCommand(ON)
    createTimer(now.plusSeconds(15),[|
        WOL_Mediabox.sendCommand(ON)
    ])
end

Das ist die simple Methode. Wenn das Item auf ON wechselt, löst die Rule aus, dadurch werden drei Items auf ON geschaltet. Anschließend wird ein Timer gestartet, der nach 15 Sekunden WOL absetzt.
Geht natürlich auch mit jeder anderen Scriptsprache und auch per UI. Wenn ma nes ordentlich mahcen will, checkt man zunächst, ob die Geräte schon an sind, aber das Prinzip sollte klar sein.

Wie gesagt, die neuen Bereiche in der UI sind nur geschaffen worden, damit man nun das Wort Szene verwenden kann. Die Funktion lässt sich (mit wesentlich mehr Möglichkeiten) genauso über Rules lösen, ich sehe derzeit keine Vorteile, eher bekomme ich in dem Zusammenhang Verwirrung mit...

[Proton]

Ah, der Rechner, der per WOL eingeschaltet wird, wird erst kurz vorher mit der Stromversorgung verbunden. Es läuft darauf hinaus, dass Du in der Größenordnung 10 bis 20 Sekunden warten musst?

Da beim Switch die ganze Zeit Spannung anliegt, reichen ein paar Sekunden, bis die Netzwerkkarte bereit ist.

Eine Möglichkeit: Du stellst im BIOS des Rechners ein, dass er automatisch einschalten soll, wenn der Strom wieder kommt. Wenn die Stromzufuhr ohnehin gekappt ist, wird das ja sowieso immer der Wunsch sein.

AVR und Mediabox hängen am gleichen Mehrfachstecker und wenn man nur Fernsehen möchte, braucht die Box ja nicht starten, deswegen fällt diese Lösung raus.

Zweite Möglichkeit (wie bisher mit WOL):
Du verwendest statt des Thread.sleep() einen Timer. Als DSL Rule:

Code: Alles auswählen

rule "Kino vorbereiten"
when
    Item Kinomodus changed to ON
then
    AVR.sendCommand(ON)
    Mediabox.sendCommand(ON)
    Fernseher.sendCommand(ON)
    createTimer(now.plusSeconds(15),[|
        WOL_Mediabox.sendCommand(ON)
    ])
end

Das ist die simple Methode. Wenn das Item auf ON wechselt, löst die Rule aus, dadurch werden drei Items auf ON geschaltet. Anschließend wird ein Timer gestartet, der nach 15 Sekunden WOL absetzt.
Geht natürlich auch mit jeder anderen Scriptsprache und auch per UI. Wenn ma nes ordentlich mahcen will, checkt man zunächst, ob die Geräte schon an sind, aber das Prinzip sollte klar sein.

Hier stellen sich mir zwei Fragen:
Wofür ist die Pipe in der createTimer-Aufruf? (Ich habe leider nichts dazu gefunden)
Wie schlimm ist es, wenn man Geräte einschaltet, die schon eingeschaltet sind?
Oder wenn man Rollladen runterfährt, die schon unten sind.
Ich hoffe nicht allzu schlimm, sonst habe ich einiges an Arbeit vor mir.

Wie gesagt, die neuen Bereiche in der UI sind nur geschaffen worden, damit man nun das Wort Szene verwenden kann. Die Funktion lässt sich (mit wesentlich mehr Möglichkeiten) genauso über Rules lösen, ich sehe derzeit keine Vorteile, eher bekomme ich in dem Zusammenhang Verwirrung mit...

Okay, also mit anderen Worten, Regeln sind mächtiger als Szenen und daher zu bevorzugen.
Also muss ich für jede Regel, die ich in der UI schalten möchte, ein Switch-Item anlegen und die Regel immer auslösen, wenn sich der Zustand ändert (also wenn der Button gedrückt wurde), korrekt?

[udo1toni]

Wenn Du nur eine Schaltsteckdose nutzt, ist die Lösung über die Zeitverzögerung natürlich die naheliegende Variante.

Die Pipe schreibe ich nur der Vollständigkeit halber dazu, der Code wird ja als Lambda übergeben und die Pipe ist Bestandteil des Lambda. Das ist aber nur meine Art der Notation, Du kannst die Pipe in diesem Fall auch einfach weg lassen, steht ja kein Platzhalter davor.

Item wegen Regel: Wenn Du die Regel über die UI auslösen willst, läuft es darauf hinaus, ja.
Die Frage wäre, wie würdest Du eine Scene auslösen? Auch da benötigst Du letztlich eine Möglichkeit, den Start der Scene zu kontrollieren. Items sind genau für solche Aufgaben gedacht, ich sehe da nichts, warum man das nicht so machen sollte
Natürlich bist Du nicht auf Switch Items beschränkt. Es könnte z.B. sein, dass Du im Wohnzimmer noch weitere Aktionsszenarien hast, die aber immer exklusiv sind, also z.B. entweder "Kino mit Lichtstimmung indirekt" oder "Festbeleuchtung und Radio" oder "Leselicht ohne weitere Medien" oder "gar kein Licht/alles aus", schwups hast Du vier verschiedene Szenen, da böte sich dann ein Number Item als Selector an, welches im Zweifel über eine einzige Rule alle vier Szenarien aktivieren kann.

[Proton]

Wenn Du nur eine Schaltsteckdose nutzt, ist die Lösung über die Zeitverzögerung natürlich die naheliegende Variante.

Die Pipe schreibe ich nur der Vollständigkeit halber dazu, der Code wird ja als Lambda übergeben und die Pipe ist Bestandteil des Lambda. Das ist aber nur meine Art der Notation, Du kannst die Pipe in diesem Fall auch einfach weg lassen, steht ja kein Platzhalter davor.

Ah okay, wieder was gelernt!

Item wegen Regel: Wenn Du die Regel über die UI auslösen willst, läuft es darauf hinaus, ja.

Die Frage wäre, wie würdest Du eine Scene auslösen? Auch da benötigst Du letztlich eine Möglichkeit, den Start der Scene zu kontrollieren. Items sind genau für solche Aufgaben gedacht, ich sehe da nichts, warum man das nicht so machen sollte

Eine Szene über UI auslösen ist ja kein Problem, aber da hätte ich nicht gewusst wie man es an Alexa anbindet.

Natürlich bist Du nicht auf Switch Items beschränkt. Es könnte z.B. sein, dass Du im Wohnzimmer noch weitere Aktionsszenarien hast, die aber immer exklusiv sind, also z.B. entweder "Kino mit Lichtstimmung indirekt" oder "Festbeleuchtung und Radio" oder "Leselicht ohne weitere Medien" oder "gar kein Licht/alles aus", schwups hast Du vier verschiedene Szenen, da böte sich dann ein Number Item als Selector an, welches im Zweifel über eine einzige Rule alle vier Szenarien aktivieren kann.

Okay, das würde dann wohl dem Beispiel aus der Demo-Umgebung entsprechen.
Das wirft wiederum Fragen bezüglich meiner UI-Gestaltung auf. Ich habe gelesen, dass man Elemente nur anzeigen soll, wenn sie benötigt werden. Klingt logisch und sinnvoll, aber wie man das macht, wurde nicht erklärt.
Wie sollte die UI aufgebaut sein?

[udo1toni]

Eine Szene über UI auslösen ist ja kein Problem

Solange Du das System administrierst, kannst Du die Scene direkt aus den Scenes starten, ja. Aber das ist ja nicht Sinn und Zweck der UI Auch dort liefe es also darauf hinaus, den Aufruf der Szene über ein Item zu realisieren.

Ich habe gelesen, dass man Elemente nur anzeigen soll, wenn sie benötigt werden.

Eventuell ist das sogar noch etwas zu kurz gefasst.

openHAB verbindet die zu steuernden Funktionen über Channel. Dabei sind die Channel gewöhnlich pro Gerät angelegt. Teilweise bieten einzelne Things dutzende oder gar über hundert Channel an. Vielleicht benötigst Du aber von diesen Channels nur zwei Stück "wirklich" dann legst Du eben auch nur zwei Items an und verknüpfst diese mit den beiden Channels.
Und schon hast Du alles, was Du brauchst, aber nichts, was Du nicht brauchst.
In der UI zwingt Dich niemand, Widgets für jedes Item zu definieren. Du kannst z.B. automatisch gesteuerte Items haben, die Du aber nie sehen musst, also lässt Du sie einfach weg.
In Rules kannst Du solche Items dennoch verwenden.
Für Testzwecke kannst Du solche Items natürlich auch in der UI sichtbar machen, damit Du dort siehst, wie sich das Item verhält. Später entfernst Du es dann wieder, wenn Du weißt, dass die Rules wie erwartet funktionieren.

[Proton]

Hallo Udo,
sorry für die späte Antwort.

Solange Du das System administrierst, kannst Du die Scene direkt aus den Scenes starten, ja. Aber das ist ja nicht Sinn und Zweck der UI Auch dort liefe es also darauf hinaus, den Aufruf der Szene über ein Item zu realisieren.

Mit einer Label Card kann ich doch als Aktion "Run scene, script or rule" auswählen und dann die Scene die ich starten möchte. Das sieht für mich so gewollt aus

openHAB verbindet die zu steuernden Funktionen über Channel. Dabei sind die Channel gewöhnlich pro Gerät angelegt. Teilweise bieten einzelne Things dutzende oder gar über hundert Channel an. Vielleicht benötigst Du aber von diesen Channels nur zwei Stück "wirklich" dann legst Du eben auch nur zwei Items an und verknüpfst diese mit den beiden Channels.
Und schon hast Du alles, was Du brauchst, aber nichts, was Du nicht brauchst.
In der UI zwingt Dich niemand, Widgets für jedes Item zu definieren. Du kannst z.B. automatisch gesteuerte Items haben, die Du aber nie sehen musst, also lässt Du sie einfach weg.
In Rules kannst Du solche Items dennoch verwenden.

Das mache ich auch schon so oder so ähnlich, aber es las sich so als ob man in der UI, abhängig von dem derzeitigen Zweck, Elemente ein und ausblenden sollte. Das kann natürlich auch eine Fehlinterpretation meinerseits sein.

Und jetzt zum für mich wichtigsten Punkt der etwas untergegangen ist:
Welchen negativen Einfluss hat es, wenn man Dinge schaltet, die schon geschaltet wurden?
Rollladen herunterfahren die schon schon unten sind, Licht einschalten, dass schon an ist usw.

Schönen Gruß

[udo1toni]

Mit einer Label Card kann ich doch als Aktion "Run scene, script or rule" auswählen und dann die Scene die ich starten möchte. Das sieht für mich so gewollt aus

Ja, aber mein Punkt ist ja, dass es keinen Grund gibt, das über einen speziellen Bereich in der UI zu erledigen, die Rule kannst Du ja genauso triggern, also wo ist der Vorteil einer Scene? Oh, ja, das Ding heißt Scene, toller Vorteil... Dafür fehlen sämtliche Möglichkeiten, eine Scene zu dynamisieren, was innerhalb einer Rule fast unbegrenzt möglich ist-

es las sich so als ob man in der UI, abhängig von dem derzeitigen Zweck, Elemente ein und ausblenden sollte.

Das einzige, was mir dazu einfällt, ist die Möglichkeit, innerhalb einer Sitemap einzelne Widgets invisible zu schalten, was z.B. sehr praktisch ist, um Bedienelemente auszublenden, die derzeit ohne Funktion sind. Oder man möchte die Formatierung eines Widgets dynamisch ändern, aber in Abhängigkeit eines anderen Items als desjenigen, welches man steuern möchte

Und jetzt zum für mich wichtigsten Punkt der etwas untergegangen ist:
Welchen negativen Einfluss hat es, wenn man Dinge schaltet, die schon geschaltet wurden?
Rollladen herunterfahren die schon schon unten sind, Licht einschalten, dass schon an ist usw.

Kurz: Keinen.

etwas länger: Keinen, außer dass Du im Log unnötige Logzeilen hast.

ganz lang: Es kann natürlich sein, dass Du ein System steuerst, welches empfindlich auf unnütze Befehle reagiert, das wird es dann aber auch über die native Oberfläche tun, ist also kein openHAB-Spezifishces Problem.