Alles klar, ich habe es geschafft 
Allerdings denke ich, dass man bei der Erstellung der Szenen geführt werden sollte. Entweder mit detaillierten Erklärungen, je nachdem, was man erreichen möchte, oder mit Links zur Dokumentation, falls diese vorhanden ist.
Super!
Zögere nicht, die wichtigsten Punkte für einen Neuling aufzulisten, damit wir die dazugehörige Dokumentation schreiben (oder du, da es öffentlich ist 
).
Okay, ich schau mal, ob ich da helfen kann!
Danke für dein Feedback!
Tatsächlich könnte die Box „Nur fortsetzen, wenn“ vielleicht nicht deutlich genug sein 
Man sollte den Ablauf in der Box erklären, da hast du recht.
Beim Trigger finde ich, dass es keinen Sinn ergibt, mehrere Vergleiche in einem Trigger zu haben, denn ein Trigger ist ein „Ereignis“, kein Zustand.
Ein Ereignis ist zum Beispiel „Die Temperatur hat sich gerade von 6 auf 8°C geändert“.
Aber ich stimme zu, dass der allgemeine Ablauf vielleicht nicht deutlich genug ist.
Ja, du hast recht. Wenn man den Ablauf explizit macht, kann man sich tatsächlich dieses berühmte „UND“ sparen
Ich weiß nicht, wie das umgesetzt werden könnte, aber in meinem menschlichen Gehirn sehe ich das so:
WENN das Licht aus ist DANN schaltet ein einfacher Klick das Licht EIN
Also ist es in der Reihenfolge Bedingung > Auslöser > Aktion
Entweder muss man diese Reihenfolge in die Erstellung einer Szene integrieren (was ich nicht für sinnvoll halte, da es am Ende zu unhomogen wäre), oder man muss herausfinden, wie man von:
Bedingung > Auslöser > Aktion
zu
Auslöser > Bedingung > Aktion
gelangt, und zwar auf eine einfache und für Leute wie mich, die nicht so fit sind, verständliche Weise. Das würde meiner Meinung nach bedeuten, die Anzahl der Schritte (der Aktionen) so weit wie möglich zu reduzieren.
In meinem Beispiel unten hätte ich gerne die Schritte 1 und 2 zusammengefasst!
Dann dachte ich mir etwas Dummes, vielleicht technisch nicht umsetzbar, aber:
Wäre es möglich, für jede Szene zu bestimmen, welche Geräte betroffen sind? Also am Anfang der Szenen-Erstellung.
Für mich sind das Aqara Mini Switch und Aqara Bulb Light
Gladys holt dann automatisch und systematisch die letzten Zustände ab.
Ich muss mich also nicht mehr darum kümmern, für jedes Gerät eine Aktion zur Abfrage des letzten Zustands zu erstellen.
Ich kann also machen:
Was haltet ihr davon?
Tatsächlich steckt hinter diesem doppelten Schritt die Idee, einen sehr, sehr leistungsfähigen Szenenmotor zu haben und Werte desselben Sensors im Zeitverlauf vergleichen zu können.
Ein Beispiel:
Allerdings bedeutet das tatsächlich, dass man auch für sehr einfache Fälle wie deinen einen doppelten Schritt durchführen muss. Ich gebe zu, das ist etwas umständlich, immer den Zustand abfragen zu müssen…
Es ist einfacher, wenn man 20+ Sensoren hat, nur diejenigen aufzulisten, die man abrufen möchte … und länger, wenn man mehr als 5 Sensoren vergleichen möchte.
Ich habe einige Szenen, in denen ich den Batteriestatus aller meiner Sensoren abrufen möchte, das dauert sehr, sehr lange!
Gibt es bereits einen Vorschlag, die alten Werte der Sensoren in den Szenen und im Dashboard zu verwenden und anzuzeigen?
Ich verstehe die Idee und tatsächlich ermöglicht das viel mächtigere Dinge.
Vielleicht würden detailliertere Beschriftungen oder Boxen helfen, bei der Erstellung einer Szene voranzukommen.
Zum Beispiel würde ich es sinnvoller finden, « Aktuellen Zustand abrufen » zu lesen als « Letzter Zustand ». Das sind kleine Details, aber ich denke, genau darin liegt der entscheidende Unterschied
Eigentlich ändert sich für mich dadurch nichts, ich mag es, zu testen / herumzuspielen… aber ich denke an den Benutzer, der sich nicht den Kopf zerbrechen will und ein fertiges Werkzeug verwenden möchte (ist das nicht der Sinn von Gladys Assistant?). Es ist immer ein bisschen abschreckend, sich mit diesem Paradoxon auseinanderzusetzen:
Ich möchte etwas Einfaches tun (eine Glühbirne mit einem Schalter einschalten) VS ich muss ein komplexes System verstehen, um das zu erreichen.
Wenn ich von komplex spreche, ist natürlich alles relativ!
Was machen diese Szenen?
Wenn du Screenshots der gesamten Seite mit dem gesamten Szenario hast, wäre das noch besser 
Ich verstehe! Ich bin einverstanden, dass wir den aktuellen Prozess verbessern könnten. Ich versuche, Feedback zu sammeln, damit wir die Anforderungen verstehen und sehen können, wie wir es besser machen können.
@Terdious du wirst deinen Titel verlieren 
Eigentlich wäre es ja interessant, einen Ort zu schaffen, an dem jeder seine Beispiele von Szenarien auflistet!
Ich finde, das ist eine sehr gute Idee.
Ich, der ich Tasker auf meinem Handy nutze, mag es, so etwas zu finden!
Man muss einfach eine einfache Möglichkeit finden, Szenen vorzuschlagen und sie nach Kategorien zu klassifizieren, damit man immer mehr davon in der Dokumentation vorschlagen kann.
Es wäre interessant zu spezifizieren, welche Sensortypen beispielsweise verwendet werden und auf die Liste der Integrationen zu verweisen.
Aber diese Art von Dokumentation wird sicherlich den Bedarf an Import und Export von Szenen in den Vordergrund rücken.
Nicht sicher, ob das den Import/Export fördert, zumal jeder unterschiedliche Hardware hat… ein totales Chaos!
Aber ein sortierter Index ist eine gute Idee!
Waaa tatsächlich! 
Ok, ich verstehe!
Aber bei den Batterien, meiner Meinung nach sollte man das meiner Meinung nach direkt in Gladys nativ codieren, oder? Das ist etwas, das meiner Meinung nach nicht in den Szenen gemacht werden sollte, oder? Aber ansonsten denke ich, dass wir in der Box « Nur fortsetzen, wenn » die Möglichkeit hinzufügen könnten, auf « Echtzeit »-Sensorwerte zuzugreifen, zusätzlich zum Variablenteil, damit wir das Beste aus beiden Welten haben
Da die Szenarien meiner Meinung nach noch nicht vollständig ausgereift sind, könnten wir das meiner Meinung nach zunächst im Forum teilen? Das Ziel wäre es, genau solche Unstimmigkeiten zu erkennen, bevor wir sie in die Dokumentation aufnehmen (klar, wir wollen keine solchen Szenen in der Dokumentation zeigen, das ist nicht benutzerfreundlich )
Wie bereits besprochen, sollte Gladys das selbst überprüfen:
Was meinst du mit „in Echtzeit“?
Wenn ich das Beispiel des Dienstes zigbee2mqtt nehme, senden die Sensoren in der Regel ihre Daten und nicht umgekehrt. Der Echtzeitwert entspricht in einigen Fällen dem zuletzt empfangenen Wert.
Ansonsten ist es eine gute Idee, aber ich würde noch weiter gehen:
Damit kann man sagen: „Wenn in den letzten 10 Minuten in einem meiner Räume eine Bewegung erkannt wurde, dann etwas tun“.
Ein Szenario, das ich derzeit überhaupt nicht umsetzen kann.
Gleiches Problem, das ist einer der Gründe, warum ich HA bei mir behalte.
PG, ich unterstütze dich bei den Geräten mit Batterie, eine Kernoption, die die Administratoren benachrichtigt, wenn die Batterie leer ist, wäre einfach und effektiv.
Der aktuelle Sensorwert!
Das ist normal, wir haben noch nicht die Funktionalität zum Vergleichen von Sensor-Daten/Zeiten. Ich stimme zu, das ist essenziell. Lustig, das steht gar nicht in den Feature-Anfragen, das hatte ich nicht im Kopf, also
Ja, das geht aktuell auch nicht. Ich stimme zu, das fehlt definitiv!
Sollen wir eine Feature-Anfrage für diese beiden Funktionswünsche + funktionale Spezifikationen machen?
