Mir fehlt hier auch immer noch die Phantasie wie du das ohne Auslöser lösen willst. Denn mit dem “von 7 bis 18Uhr soll dies oder das” kann man nicht helfen.
Du hast ja jetzt einen Auslöser, wenn homee auf abwesend gesetzt wird, fahre Rolläden runter oder auf X%.
Dann: Wenn homee auf Zuhause gesetzt wird, das aktuelle Wetter sonnig ist und zwischen Y und X Uhr, (Oder wie du das sonst unterscheiden willst mit Tageszeit/Himmelsrichtung), fahre Rolläden auf 60% (Mein Wert bei dem die Rolläden unten sind, aber durch die Löcher noch Licht kommt)
Bei nicht sonnig der einer andere Uhrzeit brauchst du dann ein anderes HG das die Rolläden auf 0% fährt. Da nimmst du quasi das selbe HG mit anderen Bedingungen.
Die Himmelsrichtung ist dadurch gelöst, dass ich für die Rollläden auf jeder Hausseite eine eigene Gruppe habe und die fahren dann, abhängig von der Temperatur, bereits jetzt zu unterschiedlichen Tageszeiten hoch oder runter. Was mir eben fehlt sind Homeegramme, die zu einem beliebigen Zeitpunkt (Manuell ausgelöst oder über die Präsenzerkennung) die geeigneten Zustände für alle Rollläden einstellen können.
Das mit dem anderen HG ist mir schon klar. Man kann es machen. Benutzerfreundlicher wäre es meiner Ansicht nach im ersten HG einfach ein “else <Fahre Rollläden hoch>” einzusetzen.
In meinen Augen ist das eine kleine Änderung, die einen großen Nutzen für die Benutzer hätte…
erstmal: eine Else Funktion würde ich für viele Fälle sehr begrüßen, ABER
ich glaub das du wegen deinen vorherigen Systemen einfach eine andere Herangehensweise gewohnt bist.
homee braucht halt einen zeitlich fixierten Auslöser. Sprich das setzen auf „zuhause“ oder der Alarm eines BWM. Die Zeitspanne, wie du es gewohnt bist bildest du dann in den Bedingungen ab (Zeitraum von 7:30-18:00 Uhr)
Nein, ich hatte keine vorherigen Systeme. Ich bin Informatiker und da gehört für mich das Else einfach dazu. Und durch die Softwareentwicklerbrille geschaut sehe ich auch keinen Grund das nicht umzusetzen… Das ist aber nur meine persönliche Meinung.
Als Auslöser dient ja das Setzen auf zuhause oder abwesend oder eben ein manuelles Auslösen über die App. Wobei ich bei Letztem gar nicht sicher bin, ob das überhaupt funktioniert. Aber das ist ein anderes Thema…
Dann kennst du dich ja auch mit der Negation aus. Wenn du kein Else hast, dann drehst du das ganze eben um.
Es gibt ein paar Dinge, die auch nur mit Testen erfolgreich funktionieren.
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.
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!
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.
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.
Und durch die Softwareentwicklerbrille geschaut sehe ich auch keinen Grund das nicht umzusetzen… Das ist aber nur meine persönliche Meinung.
