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.
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…
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.
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.
Die Funktion wäre eine nette Ergänzung, aber ich sehe momentan keinen funktionalen Zugewinn. Die Umsetzung würde wahrscheinlich sehr viel Entwicklungszeit binden. Da ja jetzt schon mehrere Bedingungen möglich sind und auch der Zeitpunkt wann die Bedingungen zutreffen, da wird wohl auch die Festlegung wann „else“ gilt nicht so einfach sein? Wahrscheinlich dann nur bei einem eindeutigen „Nein“. d.h. dann wieder, wenn 2 von 3 Bedingungen „NEIN“ und eine „JA“, dass ein zusätzliches HG benötigt wird. Auch Tagebucheinträge von einem HG werden dann noch vielfältiger und die Nachverfolgung noch unübersichtlicher.
Momentan freue ich mich daher mehr über neue Features, mit denen ich Aufgaben lösen kann, die ich bis jetzt noch gar nicht umgesetzen konnte.
Dann müsste das da oben implementiert werden - den homees traue ich das durchaus zu, aber dem Durchschnittskunden traue ich es nicht zu das dann richtig zu benutzen
