Ach sry, hatte ich mit @Jackflash verwechselt, der geschrieben hatte, das er von homatic kommt. 
Wenn du als Auslöser “Abspielen” hinzu nimmst, klar, allerdings werden dann auch die Bedingungen mit geprüft. Da kann ich nochmal Schleichwerbung für meinen Feature Vorschlag machen: 
Forciertes Abspielen
@Captain: Mir ging es hier um Benutzerfreundlichkeit. Durch das Else würde ich aus mMn. mindestens sieben benötigten Homeegrammen eben nur noch vier machen.
@cru8602 das Forciertes Abspielen hatte ich mir gar nicht genauer angeschaut. Ich hatte nur gesehen, dass man unter Homeegramm testen die Möglichkeit hat die Aktionen zu testen und das hatte mir an der Stelle gelangt. Aber wahrscheinlich gibt es auch für das forcierte Abspielen sicherlich einen Use-Case.
Hast ja Recht, aber solange das nicht funktioniert, muss man seinen Gedankengang eben umdrehen, um diesen Case abzudecken.
Bei einer zeitabhängigen Lichtschaltung wäre es auch viel komfortabler.
WENN Lichtschalter gedrückt wird UND nur täglich zwischen 01:00 - 06:00 DANN homegramm “dunkles Licht” ANSONSTEN homegegramm “helles Licht”.
So muss man nur in einem Homegramm die Zeit einstellen und nicht in allen davon abhängigen. Vor allem bei einem Homegramm von 01:00 - 06:00 und im nächstenvon 06:01 - 00:59 für die restliche Zeit. Wehe man will nun mal die Zeit verändern, dann muss man durch zig Homegramme rennen, anstatt eins für die Zeitüberprüfung zu bauen, dass dann alles weitere händelt.
Wäre eine extrem sinnvolle Funktion und aus Programmierersicht auch essenziell.
Gibts bei diesem Feature schon Neuigkeiten? Will das unbedingt, mal ein wenig Ordnung in die zig Homeegramme zu bringen, die alle voneinander abhängen. 3-4 Homeegramme für meine Funktion (vorheriger Post) is einfach schwachsinn und würde in vielen Bereichen so viel erleichtern!
BITTE NEHMT DIESE FUNKTION INS NÄCHSTE UPDATE AUF 
Ich würde dieses Feature auch begrüßen, da ich auch immer mehr HGs verwende bei denen das Sinn machen würde.
Zuletzt habe ich ein HG realisiert, welches die Beleuchtung der Wohnwand ausschaltet und den TV samt Verstärker einschaltet. Wenn der TV ausgeht, geht der Verstärker auch aus und das Licht wieder an.
Ich hätte aber gerne noch eine Verzweigung in der ich prüfen kann ob es schon dunkel ist. Wenn ja schalte Verstärker auch aus und licht ein, wenn nein dann nur Verstärker aus und Licht auch nicht einschalten.
Für solche einfachen HGs muss man direkt 2 Stück erstellen 
if, else, finally … fänd ich cool, aber anderes Thema…
Ich hätte es so gemacht …
homeegramm 1:
Name: TRIGGER | Lights indoor | Evening
Wenn
Button am Gerät XYZ gedrückt
UND
Zwischen 17-22 Uhr
Dann
Spiele homeegramm „FLOW | Lights indoor | Büro evening“ ab
Spiele homeegramm „FLOW | Lights indoor | Badezimmer evening“ ab
etc
Für die Zeit ausserhalb 17-22 Uhr ein eigenes mit ähnlicher Struktur … die homeegramme so simpel wie möglich halten, finde ich besser als ein monster-homeegramm mit if, else und tausend bedingungen.
Alle homeegramme in die Gruppe packen: „COMPONENT | Lights indoor“
Aus der gruppe heraus kannst du in die homeegramme springen … if else , wäre cool aber würde einfache homeegramme vereinfachen, aber komplexere unübersichtlich machen.
Euch ist schon aufgefallen, dass der Thread jetzt fast vier Jahre alt ist. Da wird sich ohnehin so schnell nichts tun. Das wiederspricht nun mal der GUI vom homee, die möglichst einfach sein will.
Das ist genauso, wie mit den UND und ODER Verknüpfungen, die es nicht zusammen in einem Auslöser bzw. einer Bedingung gibt, da sonst auch Klammern für die Reihenfolge der logischen Auswertung notwendig werden, da in der boolschen Algebra:
(WENN Auslöser A ODER WENN Auslöser B) UND WENN Auslöser C
logisch nicht identisch ist mit
WENN Auslöser A ODER (WENN Auslöser B UND WENN Auslöser C)
Das gilt für Bedingungen analog.
Es soll allerdings demnächst kommen, dass man in den Auslösern (und Bedingungen), jeweils UND bzw. ODER verwenden kann, wenn man bei einer Verküpfungsart bleibt. Dann gibt es auch keine Problem mit der boolschen Algebra.
Aus eigener Erfahrung in der Software Entwicklung, ist es besser viele kleine „Sprechende“ Funktionen(homeegramme) zu haben, anstatt nur ein paar aber dafür komplexe. Der name des homeegramms sollte beschreiben was dieses tut.
Wenn man gut und klein schneidet , kann man auch besser Pflegen und erweitern. Es ist nichts schlechtes viele homeegramme zu haben.
Auslöser A
Bedingung B (ist größer als)
Dann Aktion C
Auslöser A
Bedingung B (ist kleiner als)
Dann Aktion D
2 HGs, gleicher Auslöser, je nach Bedingung eine andere Aktion
Den Gedanken kann ich nur unterstützen. Allerdings sind die Homeegramme nicht so richtig darauf ausgelegt, wenn mich meine bescheidene Erfahrung damit nicht trügt.
Beispiel: Ich möchte 10 LED-Gruppen mit 10 Schaltern immer auf dieselbe Weise bedienen können (An/Aus, Dimmen). So wie ich es verstehe, muss ich für jede LED-/Schalterkombination die notwendigen HG duplizieren und die Zuordnungen anpassen. Das macht aus 3-5 kurzen HG direkt 30-50 ziemlich redundante. Jedes für sich leicht verständlich, dafür muss ich Änderungen aber auch in jedem einzelnen vornehmen… 
Ja, hast du richtig verstanden 
Da sucht man sich den Wolf und dann gibt es das ja schon. Komisch, obwohl ich nach „wenn dann sonst“ gesucht habe wurde nichts gefunden 
Ich pushe diesen Mal, weil ich es nach wie vor für sinnvoll halte 
Das wiederspricht nun mal der GUI vom homee, die möglichst einfach sein will.
Einfach ist klasse, ich bin dafür.
Um in etwa solche Bedingungen (if then … else …) nachzubauen, wird es derart kompliziert, dass die Homeegramme nicht mehr zu verstehen und zu warten sind. Für den „Power-User“ muss es aber auch noch etwas geben, damit es einfach bleibt ohne gezwungen zu sein, zu openHAB abzuwandern.
Denke, nicht jeder muss jedes Feature nutzen (müssen) können.
Da aber 80-90% der homee-Anwender eben keine PowerUser sind wird das eher nicht passieren. Es werden eher bestimmte Standardszenarien wie Heizplan, Beschattung, usw. in vereinfachte Assistenten gepackt. Ich hätte auch nichts dagegen, mit einer LUA-ähnlichen Sprache meine HGs zu schreiben, wenn ich dann if then … else usw. und in Auslösern und Bedingungen gemischt mit UND/ODER arbeiten zu können. Aber auch da müsste das GUI wegen der boolschen Algebra entsprechend aufgebohrt werden.
Das ist aber einfach nicht die Zielgruppe von homee. Ich lagere kompliziertere Logikoperationen in iobroker aus. Den habe ich für die homee-Sprachausgabe via Alexa ohnehin am Laufen. Da kann ich mir sogar die Skriptsprache aussuchen.
Ich finde den Sprung von „zu einfach um nützlich zu sein“ (Status quo) zu „ich bin der Überbastler und skripte mir sowieso alles selbst zusammen“ (iobroker) geradezu produktschädigend groß.
Es sind sicherlich nicht nur 10-20%, die in ihrem Setup mindestens an einer Stelle gerne etwas mit Wenn/Dann darstellen würden, weil es so viel mehr Übersichtlichkeit bringt bzw. einige wichtige neue Möglichkeiten schafft - sonst wäre das kein so viel diskutierter Dauerbrenner.
Außerdem überzeugt mich das Argument „Einfachheit“ an dieser Stelle auch überhaupt nicht. Wenn/Dann/Sonst ist intuitiv und so alltagsnah, dass sich so ziemlich jeder Nutzer zumindest etwas darunter vorstellen kann. Ob er sich zutraut es zu nutzen, ist eine andere Frage. Aber wie immer gilt: man muss/sollte nicht alles nutzen, bloß weil es da ist.
Ich halte nach wie vor die Aktivierungsmöglichkeit eines Expertenmoduses (auf eigene Gefahr und von mir aus ohne offiziellen Support) für einen guten Kompromiss, um die meiner Wahrnehmung nach große Zielgruppe der „Casual-Bastler“ auf Dauer nicht zu vergraulen.
Ja, in einfachsten Fällen hast du Recht.
Doch ist hier die Frage, wie oft diese tatsächlich vorkommen. Meist ergeben sich im Negativfall leicht andere Bedingungen oder mehrere „Cases“. Ich habe in einem anderen System, wo es Else gibt, die Erfahrung gemacht, dass dieses (für mich) kaum sinnvoll einsetzbar ist.
Was natürlich nicht gegen eine Umsetzung in homee sprechen soll. Denn das ein oder andere HG spart sich damit sicherlich.
Viel wichtiger finde ich es zu erwähnen, dass die Umsetzung und Nutzbarkeit im Falle von homee alles andere als trivial ist. Denn das „Else“ muss mit der bereits vorhandenen, genialen und nicht unbedingt intuitiven Möglichkeit der Verzögerungen und Bedingungsprüfzeitpunkte zusammenarbeiten. Das wird knifflig.
Als „Casual-Bastler“ will ich mehr Funktionalität. Funktionalität, die sich mit Bordmitteln bis dato nicht oder nur extremst umständlich umsetzen lässt.
Das „Else“ nehme ich da gerne mit. Aber ich sehe da (leider) viele, viel wichtigere und größere Baustellen 
Wer kennt die Möglichkeiten der logischen Verknüpfungen von Abfragen in Kombination mit der Einschränkung auf Websites oder Teile einer Website?
Ist zu kompliziert, macht die Sache nur unübersichtlich, braucht keiner!
Donnoch bietet es Google in seiner Suchmaschine an. Keiner empfindet Google als zu kompilziert oder unübersichtlich.
Nur weil etwas möglich ist, muss es weder schwieriger, unübersichtlicher oder gar produktschädigend sein. Es werden jene, die es nicht benötigen, gar nicht bemerken, ebenso wenig, wie diese sehr mächtige Abfragesprache in der Suchmaschine von Google.
Hier eine gut zusammengestellte Übersicht: https://www.online-marketing.de/google-suchoperatoren
Ich arbeite viel mit und/oder und dann/sonst.
Ich denke das Problem ist nicht der 0815 Nutzer, sondern dass es mangels Umsetzung, hier nur wenige Leute kennen.
Sofern sich jemand noch nicht mit dem Thema befasst hat, wird er es nicht vermissen und braucht halt mehr homeegramme, um einen ähnlichen Effekt zu erzielen.
Ich würde ungern darauf verzichten.
Aber nicht mit homee 