Auslöserszene

Ja und nein, für mich ist es auch die Aktivierung der Szene des Ereignisses
Meine Szene ist, dass ich die Aktivierung des Alarms anfordere und dass alle Sensoren in Ordnung sein müssen, um die Fortsetzung zur Aktivierung (oder nicht, wenn ein Sensor defekt ist) dieses Alarms auszulösen (das ist meine Logik, vielleicht ist sie nicht gut)
Um einen Überblick darüber zu geben, was ich derzeit mit meiner HC2-Zentrale von Myfox habe, die von Somfy übernommen wurde, die aber keine Hardware mehr liefern, sondern nur die Website aufrechterhalten, daher, je mehr meine Geräte ausfallen, desto schlimmer wird es (Problem der Rauchmelder, die zwingend alle 10 Jahre ausgetauscht werden müssen), ich muss mich also nach einer anderen Lösung umsehen, ich habe die Hauptlösungen Domoticz, Jeedom, Home-Assistant angesehen und muss sagen, dass Gladys bei der Konfiguration am einfachsten ist, aber für bestimmte Anforderungen auch die am wenigsten leistungsfähige, da sie in der Konfiguration begrenzt ist, der beste Kompromiss zwischen den beiden ist sicherlich keine einfache Aufgabe für die Entwickler, aber Gladys hat den Vorteil, dass die Entwicklung so weit wie möglich den Anforderungen der Benutzer folgt.
Um ein Beispiel dafür zu geben, was ich derzeit habe

Meine Einbruchssensoren


et ihre Einstellungen, sie sind standardmäßig in die Logik des Alarmsystems integriert, haben aber dennoch eine feine Einstellung

Schönes, gut durchdachtes, aber geschlossenes System und da es aus dem Jahr 2013 stammt und nicht mehr gewartet wird, wird es wahrscheinlich nicht mehr lange dauern, bis es entweder auf der Zentrale oder den Sensoren ausfällt, daher meine Orientierung zu Gladys…
Der Vorteil von Gladys ist, dass er im Code offen ist (also anpassbar), in den Technologien, die er unterstützt (also dauerhaft), es ist kein kompliziertes System, um es zu bedienen oder zu konfigurieren, das Entwicklungsteam versucht, den Bedürfnissen der Benutzer gerecht zu werden (auch wenn der Dialog manchmal nicht immer einfach ist, da er lang schriftlich ist und manchmal denselben Ansatz des Verständnisses der Dinge erfordert, auf der einen Seite die Entwickler, die den Code von Gladys kennen und daher wissen, was möglich ist und die Komplexität, es zu tun, und auf der anderen Seite die Benutzer, die Entwicklungen fordern und deren Wissen zwischen Neuling, der Gladys entdeckt, und Gladys-Entwickler liegt, Entwicklungen, die manchmal gerechtfertigt und nützlich für Gladys sind, mit einer zeitlichen Beschränkung, die manchmal technisch nicht umsetzbar ist, manchmal weil die Funktionsweise von Gladys nicht richtig verstanden wird, mein Fall manchmal, aber für mich, wenn es nicht verstanden wird, kann es auch vielleicht einen zukünftigen Benutzer abschrecken, es zu übernehmen).
Das war lang, aber ich hoffe, ich war diesmal klar.

@pierre-gilles

Für mich kannst du diese Anfrage schließen, ich dachte, sie würde die Programmierung von Szenen vereinfachen (hier im Fall eines Alarms), aber vielleicht ist die Anfrage schlecht formuliert.
Vielleicht wäre das Ideale gewesen, ein virtuelles Gerät zu erstellen, das alle Sensoren zusammenfasst, die dem Alarm zugewiesen sind, wodurch die Erstellung von Szenen vereinfacht wird…aber ich werde keine Anfrage stellen, beruhige dich! :blush:

Ps: Ein weiterer Vorteil von Gladys ist die Einfachheit der Fernsteuerung, man muss nur schauen, wie man es unter HA oder Jeedom macht, um sich davon zu überzeugen
Es ist ein Vorteil, der nicht immer hervorgehoben wird, was Gladys einfach machen kann, was für andere Lösungen viel schwieriger ist…

Ich glaube, wir verstehen uns nicht richtig.
Ich dachte, das Ereignis (genauer gesagt der Auslöser der Szene) sei das Verlassen des Hauses… also verstehe ich den Rest eigentlich nicht.
Eigentlich schlägt du vor, einen Schalter hinzuzufügen, um EIN oder ALLE Auslösekriterien zu bestätigen.
Aber unter diesen Kriterien gibt es das Verlassen des Hauses (ein Ereignis) und das Überprüfen des Zustands einer Steckdose (ein Zustand). Es ergibt keinen Sinn, diese beiden Dinge in den Block AUSLÖSER zu setzen.

Logischerweise sollte das Verlassen des Hauses die Überprüfung des Zustands der Steckdosen auslösen. Das Hinzufügen des Schalters kann die logische Funktionsweise der Szenen nicht ändern. Verstehst du, was ich meine?

Ja, eigentlich wäre es mehr in einem Block nach dem Block (der Benutzer verlässt das Haus) am sinnvollsten, um die Programmierung von Szenen zu vereinfachen. In meinem Kopf war es:

WENN (der Benutzer verlässt das Haus UND alle vorhandenen Sensoren sind in Ordnung)
DANN (wird der Alarm aktiviert)
SONST (wird eine Nachricht gesendet, um zu warnen)

Aktuell existiert das SONST nicht.

WENN (der Benutzer verlässt das Haus)
DANN (wird der Zustand des Sensors 1 abgerufen)
WEITER WENN (Sensor 1 ist in Ordnung)
DANN (wird der Alarm in den « bewaffneten » Modus versetzt)
WENN (Alarm und entwaffneter Modus) 'nach Fehlschlag
DANN (wird eine Nachricht gesendet)

Der Teil
DANN (wird der Zustand des Sensors 1 abgerufen)
WEITER WENN (Sensor 1 ist in Ordnung)
ist abhängig von der Anzahl der möglichen Sensoren und muss entsprechend oft wiederholt werden, was mühsam werden kann… und Fehlerquellen schafft!

Wie ich @pierre-gilles sagte, wäre das Ideale, ein virtuelles Gerät in der MQTT-Integration zu erstellen, um den Zustand der für die Alarmverwaltung notwendigen Sensoren zu gruppieren und es in einer Szene zu verwenden. Es würde dann werden:
WENN (der Benutzer verlässt das Haus)
DANN (wird der virtuelle Zustand abgerufen)
WEITER WENN (virtuell ist in Ordnung)
DANN (wird der Alarm in den « bewaffneten » Modus versetzt)
WENN (Alarm und entwaffneter Modus) 'nach Fehlschlag
DANN (wird eine Nachricht gesendet)

Und in meinem Kopf würde es dann werden:
WENN (der Benutzer verlässt das Haus UND virtuell in Ordnung)
DANN (wird der Alarm aktiviert)
SONST (wird eine Nachricht gesendet, um zu warnen)

Ich glaube, es ist die Ereignis-Notation, die auch ein Zustand ist und zu Verwirrung führen kann

Der Benutzer verlässt das Haus => Wechsel vom Zustand „Benutzer anwesend“ zu „Benutzer abwesend“ (keine Schrödinger-Katze :thinking:)

Meine Logik ist, dass die Szene ausgeführt wird, also dass der Alarm (in diesem Fall der Gesamtalarm) aktiviert wird, wenn „Benutzer abwesend“ UND „alle Alarm-Total-Sensoren OK“ vorliegt.

Ok, ich denke, ich verstehe deine Anfrage, auch wenn mir ein paar Punkte in deiner Logik noch Kopfzerbrechen bereiten :wink:

Letztlich verlieren wir uns ein bisschen, weil du in diesem Thema zwei separate Anfragen äußerst.

Deine Anfrage Nr. 1:

  • Erstellen eines virtuellen Geräts, das die Funktionen mehrerer physischer Geräte zusammenfasst, sodass du nur noch ein einziges Gerät in deinem Szenario testen musst. (Vielleicht entspricht das der Idee eines « Super-Geräts », über das ich hier bereits gesprochen habe > Créer un super device virtuel (aber das für mich ein geistiges Fiasko war ^^)

Anfrage Nr. 2:

  • Ändern der Art und Weise, wie eine Szene funktioniert > der berühmte Toggle EIN <> ALLE, der aber keinen Sinn ergeben kann, da selbst wenn ich deine Logik verstehe, Gladys die Informationen nacheinander verarbeiten muss, um logisch voranzukommen. Mit anderen Worten, der Zustand eines Sensors kann kein Auslöser sein. Nur die Zustandsänderung desselben kann ein auslösendes Ereignis sein.
    Daher ist deine Logik, die lautet:

damit die Szene ausgeführt wird, also der Alarm (in diesem Fall der Gesamtalarm) aktiviert wird, müssen « Benutzer abwesend » UND « alle Alarm-Sensoren total ok » sein

Man kann sie in alle Richtungen drehen, sie kann in Gladys (oder anderswo, denke ich) nicht diese Form annehmen.

Das muss wohl mein veganer Teil sein, ich denke nicht in 3D (die Älteren verstehen den Bezug :blush:), obwohl ich ein Anhänger der ersten Stunde der OOP bin!

Im Fall des Alarms können Szenen verschachtelt werden

Daher können Basisszenen mit Bedingungen erstellt werden

BEDINGUNGEN (Benutzer abwesend + Sensor OK) => AKTION (Alarmanlage scharfstellen)

Die dann in anderen Szenen wiederverwendet werden.
Jetzt haben wir
Ereignis (Benutzer verlässt) BEDINGUNGEN (Benutzer abwesend + Sensor OK) => AKTION (Alarmanlage scharfstellen)

Dadurch können Szenen, die auf Ereignisse reagieren, und Szenen, die auf Anfrage ausgelöst werden, wie oben (wobei die Ausführung von Bedingungen abhängt) erstellt werden, aber ich hatte nicht bemerkt, dass das möglich ist

Das war ein nachträglicher Vorschlag, da meine Anfrage nicht möglich zu sein schien, aber es ist genau die Idee (es wäre interessant, diese Möglichkeit in der MQTT-Integration zu haben, um ein Gerät zu erstellen, das den Zustand mehrerer anderer Geräte widerspiegelt)

Na, wenn ja, dann haben wir es hier mit einem Zustand und nicht mit einem Ereignis zu tun… Übrigens finde ich, dass « Ereignisse » passender oder aussagekräftiger gewesen wären als « Auslöser »

Tatsächlich, es stimmt schon, dass die Logik es erfordern würde, da Szenen andere Szenen auslösen können, ohne den Auslöserteil zu berücksichtigen, dass dies im zweiten Teil

getan wird

mit der Möglichkeit, UND zusätzlich zu ODER zu haben, und in diesem Fall passt es genau zu dem, was ich erreichen wollte, und das wäre die einfachste Art und Weise… Ich wage es nicht mehr, eine Funktionsanfrage zu stellen :woozy_face:

Wenn man 2 Minuten nachdenkt, ist das aktuell möglich.
Nichts hindert dich daran, dein virtuelles Gerät in MQTT zu erstellen.

Dann aktualisierst du mit 2 Szenen dein virtuelles Gerät mit den Zustandsänderungen deiner Öffnungssensoren, Bewegungsmelder…

könntest du mir das bitte zeigen, denn ich verstehe wirklich nicht, wie ich das gerade machen soll (aber vielleicht habe ich etwas übersehen, ja, das ist möglich! :upside_down_face:)

Ich zeige dir, wann ich nach Hause komme

Also, ich habe einen Bug in den Szenen beim Auslöser „Gerätestatusänderung“ gefunden.

Ich melde den Bug und versuche, es dir zu erklären.

Kein Problem! Danke :wink:

Zuerst muss ein MQTT-Gerät erstellt werden

Ich habe ein Gerät mit der Funktionalität Öffnen (Ja/Nein) erstellt

Dies ist kein Sensor, da man es von einer Szene in Gladys aus steuern muss.

Als nächstes müssen 2 Szenen erstellt werden, um das MQTT-Gerät zu steuern
Eine Szene zur Erkennung der Öffnung, die den Zustandswechsel eines Öffnungssensors erkennt. In diesem Fall wird das MQTT-Gerät auf den Wert 1 gesetzt.
Die zweite Szene dient zur Erkennung des Zustandswechsels eines Sensors, und somit wird das MQTT-Gerät auf 0 gesetzt.

Die Werte des MQTT-Geräts kannst du auch umkehren, wenn du möchtest. Hier ist es nur ein Beispiel.

  1. Erstellung der Szene zur Erkennung der Öffnung

ACHTUNG: Hier habe ich einen Fehler beim Auslöser für den Zustandswechsel. Ich werde hier die richtige Vorgehensweise beschreiben, aber es wird aufgrund des Fehlers nicht funktionieren. Damit es funktioniert, musst du die Auswahl geöffnet/geschlossen umkehren.

Hier müssen alle Sensoren, die du testen möchtest, in die Auslöser eingestellt werden. Wenn einer der Sensoren in den Zustand geöffnet wechselt, bedeutet das, dass dein Haus geöffnet ist. Zum Beispiel habe ich nur 2 Sensoren eingestellt.


Ich habe die Option „Nur ausführen, wenn…“ nicht aktiviert, damit die Szene jedes Mal ausgeführt wird, wenn dein Zigbee-Sensor sendet.

In einem Aktionsblock die Aktion „Gerät steuern“ auswählen und den Schalter auf den Zustand 1 / EIN setzen

Die Szene ist fertig.

  1. Erstellung der Szene zur Erkennung des Schließens

ACHTUNG: Hier habe ich einen Fehler beim Auslöser für den Zustandswechsel. Ich werde hier die richtige Vorgehensweise beschreiben, aber es wird aufgrund des Fehlers nicht funktionieren. Damit es funktioniert, musst du die Auswahl geöffnet/geschlossen umkehren.

Hier müssen alle Sensoren, die du testen möchtest, in die Auslöser eingestellt werden. Die Szene wird jedes Mal ausgeführt, wenn Gladys einen geschlossenen Zustand von einem der Sensoren empfängt. Zum Beispiel habe ich nur 2 Sensoren eingestellt.

In einem ersten Aktionsblock werden die Zustände aller Sensoren abgerufen.
Im Gegensatz zur Öffnungsszene müssen hier alle Sensoren geschlossen sein, um das Haus als geschlossen zu betrachten!

In einem zweiten Aktionsblock wird eine Aktion „Nur fortsetzen, wenn“ für jeden Sensor hinzugefügt.
Wenn der Wert gleich 1 ist, bedeutet das, dass dein Sensor geschlossen ist.

Dann in einem letzten Block eine Aktion „Gerät steuern“ hinzufügen und dein MQTT-Gerät auf 0 / AUS setzen

Danach kannst du dein MQTT-Gerät in deinen Szenen verwenden.

Zum Beispiel eine Szene mit dem Auslöser „Haus verlassen“ erstellen.
In einem Block darunter den Zustand deines MQTT-Geräts abrufen
In einem anderen Block eine Aktion „Nur fortsetzen, wenn“ hinzufügen, um den Wert 0 oder 1 deines MQTT-Geräts zu überprüfen
Dann weitere Blöcke je nach Zweck deiner Szene hinzufügen.

Das war’s, ich hoffe, es ist klar für dich und es wird dir helfen.

Ja, super klar, danke :+1: Ich werde es so machen :wink:

Aber um ehrlich zu sein

  • die erste bleibt einfach (Test zur Erkennung einer Öffnung)
  • die zweite ist dagegen verdammt umständlich

Und ich bin überrascht von der Logik, die die zweite impliziert. Im ersten Fall wird eine Zustandsänderung getestet, im zweiten Fall ist es ein Zustand der Zustände!
Allerdings, da wir den Haken « Nur ausführen… » haben, kann man auf eine Zustandsänderung testen

Die Bezeichnung sollte « Gerätezustand » sein. Der Öffnungssensor sendet regelmäßig einen Zustand und nur einen Zustand oder auch ein Ereignis: Zustandsänderung und genau das wird erkannt? (Beides, wie oben erwähnt, der Haken, aber das ist unwichtig, das ist interne Kochen :blush:)

Also, im Endeffekt haben wir im Auslösebereich
Fall 1
« Jeder Auslöser ist unabhängig. Wenn die Bedingungen eines dieser Auslöser erfüllt sind, wird die Szene ausgeführt. »
was geeignet ist, um zu testen, ob mindestens ein der Sensoren geöffnet ist

Wenn wir den Toggle hätten, den ich vorgeschlagen habe
Fall 2
« Jeder Auslöser ist unabhängig. Wenn die Bedingungen aller dieser Auslöser erfüllt sind, wird die Szene ausgeführt. »
was geeignet ist, um zu testen, ob alle Sensoren geschlossen sind

Man hätte die Szene 1 duplizieren, den Toggle auf « alle » setzen, die Sensoren von geöffnet auf geschlossen ändern und es wäre okay gewesen

Man wäre in derselben Funktionslogik geblieben und müsste sich nicht des
« Letzten Zustand abrufen » und « Nur fortfahren wenn » bedienen (ich habe 20 Sensoren, 3 Rauchmelder :smiling_face_with_tear:)

Aber gut, ich war da zu ehrgeizig! :sob:

Aber ich finde, die Idee, einen virtuellen Sensor mit mehr Funktionen anzubieten


wo man die verschiedenen Sensoren wie folgt einfügen könnte

wäre doch nicht schlecht, oder?

Ich erlaube mir, den Link zu einer Nachricht von anderswo einzufügen, die auch hier funktionieren könnte.
Ich neige dazu zu denken, dass du, @cce66, dazu neigst, zu verlangen, dass sich Gladys an deine Denkweise anpasst, obwohl das nicht das Sinnvollste ist (und ich sage nicht, dass du falsch denkst! Ich hatte anfangs ein ähnliches Problem).

Nein nein, ich hatte schließlich weiter oben vereinbart, dass das Ereignis tatsächlich der Auslöser „Benutzer verlässt das Haus“ ist und dann in dem Teil „Bedingungen“ die Möglichkeit fehlt, zwischen „UND“ und „ODER“ in den Bedingungen zu wählen.
So kann man haben:

  • Sensor1 geschlossen UND Sensor2 geschlossen UND Sensor3 geschlossen usw. => BEDINGUNG alle Sensoren sind geschlossen AKTION (man kann den Alarm scharf machen oder Alarm scharf und alles ist gut)
  • Sensor1 offen ODER Sensor2 offen ODER Sensor3 offen usw. => BEDINGUNG mindestens ein Sensor offen AKTION (man kann den Alarm nicht scharf machen oder Alarm scharf, also Einbruch also Auslösung der Sirene oder Senden einer Nachricht usw.)

Findest du nicht, dass es so klarer und einfacher wäre?

[quote=« cce66, post:26, topic:8448 »]
Tatsächlich, es stimmt, dass die Logik es erfordern würde, da Szenen andere Szenen auslösen können, indem sie den Auslöser-Teil ignorieren, sei es im Teil 2

dass dies geschieht

mit der Möglichkeit, UND zusätzlich zu ODER zu haben, und hier passt es genau in das, was ich tun wollte, und das wäre die einfachste Art und Weise… Ich wage es nicht mehr, eine Funktionsanfrage zu stellen :woozy_face:

Statt einen UND-Knopf zusätzlich zum ODER-Knopf zu setzen, was Entwicklung erfordert, kannst du einfach eine Box „Fortfahren nur wenn“ daneben im gleichen Block hinzufügen, das wird wie ein UND funktionieren.

Ich sehe immer noch nicht wirklich das Problem.

Beispiel:

Vielleicht wäre es klarer, den Vorschlag von @Tlse-vins umzusetzen (die Jungs aus dem Süden sind gut ;)), eine einfache kosmetische Änderung, damit es so aussieht:

Wäre das vielleicht besser so?

Um mich besser zu verstehen, habe ich die entsprechenden Szenen gemacht:

Mindestens ein offener Detektor


Alle Detektoren geschlossen, aktuelle Version


Alle Detektoren geschlossen, Version, die ich einfacher finde

Ideale Version

Ich hatte die von dir vorgeschlagene Lösung nicht in Betracht gezogen, weil sie außerhalb meiner Logik liegt, das stimmt schon :thinking: :exploding_head:

Jetzt würde ich es so machen, mein Vorschlag war nur, um die Dinge zu verbessern, wenn das möglich ist! Es gab weder Eile in der Anfrage noch einen Versuch, meine Sichtweise oder meine Denkweise aufzuzwingen, nur einen Vorschlag (der anfangs sehr schlecht formuliert war, das stimmt, aber es ist nicht immer einfach, etwas Schriftliches umzusetzen, wenn es visuell oder funktional ist!). Aber ich schließe mich der Mehrheit der Stimmen ohne Probleme an, aber ich bin ein bisschen überrascht von der Reaktion, die das ausgelöst hat…

Wenn mir jemand gesagt hätte

  • stimmt, das ist klarer, wir behalten die Idee im Hinterkopf, denn im Moment können wir anders vorgehen und wir haben andere Prioritäten in der Entwicklung
    oder
  • das geht nicht aus technischen Gründen oder wegen der aktuellen Codierung
  • du kannst es so machen (aber für mich bleibt es hässlich :stuck_out_tongue_closed_eyes: :blush:)

hätte ich das verstanden! :wink:

Ich werde also versuchen, das zusammenzufassen, denn am Ende redet man viel und sagt nicht viel :wink:

Die Version, die ich vorgeschlagen habe, entspricht dem, was du als « Alle Detektoren geschlossen, eine Version, die ich einfacher finde ». vorgeschlagen hast.
Es ist nur so, dass du ein paar Klicks mehr brauchst (nicht viele, ehrlich gesagt).
Also treffen wir uns am Ende fast vollständig.

Die Richtung, die wir einschlagen sollten, wäre, Pierre-Gilles zu fragen, ob er es interessant findet, einen einfachen Text UND beim Hinzufügen einer Aktion in einem Block hinzuzufügen, oder ob er einen anderen Vorschlag hat.

Kleine Abschweifung:
Ich komme noch einmal auf die Verständnisprobleme zurück. Es war sehr schwierig, dir im Forum zu folgen, denn meiner Meinung nach hast du deine Nachrichten im Laufe deines Nachdenkens geschrieben, indem du deiner Logik gefolgt bist.
Und als jemand dir sagte, dass du dich irrst / dass du auf dem falschen Weg bist, hast du darauf bestanden, als hättest du immer eine Antwort, was für deine Leser nicht einfach zu handhaben ist.
Außerdem, wie du sagst, ist es schriftlich kompliziert.

Ich verstehe dich, denn ich weiß, dass ich am Anfang hier viele Ideen, viele Vorschläge hatte… und ich war super frustriert, als Pierre-Gilles mir sagte, dass es nicht interessant war oder nicht zum Projekt passte, oder dass ich vom Thema abwich.
Ich hatte das Gefühl, missverstanden zu werden :sweat_smile:

Je mehr ich die Funktionsweise von Gladys und ihrem Forum verstanden habe, desto besser konnte ich teilnehmen (wenn ich immer noch Mist rede, gebt mir Bescheid, okay ^^).
Du scheinst begeistert zu sein, und das ist etwas sehr Positives, es fehlt nur ein etwas strukturierterer Rahmen, um unseren Austausch zu erleichtern.

Also mein Rat: Nimm dir die Zeit, um zu verstehen, was Gladys macht, in welcher Logik, und du wirst ihr ganzes Potenzial sehen. Deine Vorschläge zur Verbesserung werden dadurch nur noch relevanter :wink: !!

Die ideale Version, die du vorschlägst, kannst du bereits umsetzen, nur ist nicht „UND“ markiert. Du fügst 3 Aktionen Nur fortfahren, wenn im gleichen Kasten hinzu und das macht genau das, was du verlangst.

Voll und ganz deiner Meinung (bis auf den Klick genau ist es dasselbe)

Für den Rest habe ich eine Anfrage gestellt, um meinen Bedarf zu decken, aber man sagt mir, es ist nicht möglich oder man muss es anders machen. Da es so frustrierend ist, mache ich andere Vorschläge, die es umgehen könnten, bis @Will_71 mir eine funktionierende Lösung vorschlägt (nochmals danke :+1:), daher ja, meine Überlegungen haben sich tatsächlich in Abhängigkeit von den gegebenen Antworten und dem, was ich unterwegs verstanden habe, mit den gegebenen Antworten weiterentwickelt (wer hat gesagt, es ist ein Macronist im Raum? :rofl: « Nur die Siths sind so absolut. » :crazy_face:)

Danach bleibt es das Ziel eines Forums…und manchmal muss man durchhalten, sonst hätte ich es nicht geschafft, Gladys mit meinem IPX800V5 über Node-red zu verbinden und meine Rollläden in Abhängigkeit von der Position der Sonne zu steuern. Ich habe herausgefunden, wie man es macht, und meine Erfahrung über Mini-Tutorials geteilt :slight_smile: obwohl ich anfänglich Anfragen an @pierre-gilles (oder im Forum in den Feature-Anfragen, ich erinnere mich nicht mehr genau) gestellt hatte und die Antwort war, dass es im Moment nicht möglich ist, und es war im Laufe der Diskussionen (weil ich nicht verstanden hatte, dass die MQTT-Syntax nicht standardmäßig ist) mit @pierre-gilles unter anderem, dass ich verstanden habe, wie Gladys funktioniert und daher, wie man es über Node-red macht, genauso bei der Position der Sonne, ich hatte eine Anfrage dazu gestellt, man hat mir geantwortet, dass es im Moment nicht möglich ist, ich habe es mit Node-red umgangen und jetzt kann ich die VR in Gladys steuern, unter Berücksichtigung der Position der Sonne!
Mein Ansatz ist « Ich möchte etwas tun, wenn ich es durch die Tür machen kann, dann versuchen wir zu sehen, ob ich es durch das Fenster machen kann » und wenn ich es schaffe, teile ich es mit anderen!

Da verstehe ich deinen Kommentar nicht, intern ist es nicht dieselbe Logik, auf der einen Seite haben wir
ODER in der Szene, die erkennt, ob EIN Detektor GEÖFFNET ist

et auf der anderen Seite ein UND in meiner 2. Szene, die erkennt, ob ALLE meine Sensoren GESCHLOSSEN sind, das ändert die interne Logik der Verarbeitung, es ist nicht nur eine Textergänzung

Um die Art und Weise zu ändern, wie die Blöcke interpretiert werden, müsste man die Wahl mit einem Umschalter haben, um von einer « ODER »-Logik zu einer « UND »-Logik zu wechseln

das erste Mal ODER im Algorithmus
FÜR JEDEN BLOCK
WENN BEDINGUNG ERFÜLLT DANN VERLASSEN-SZENE
BIS ZUR ANZAHL DER BLOCS

das zweite Mal UND im Algorithmus
BLOCKS-GETESTET=0
FÜR JEDEN BLOCK
WENN BEDINGUNG ERFÜLLT DANN ERHÖHE BLOCKS-GETESTET
BIS ZUR ANZAHL DER BLOCS
WENN BLOCKS-GETESTET <> ANZAHL DER BLOCS DANN VERLASSEN-SZENE

Um zu testen, habe ich die Frage an chatgpt gestellt
« Schreibe mir mit Kommentaren in der zweiten Schleife die Möglichkeit zwischen einer seriellen oder parallelen Verarbeitung gemäß eines Umschalters namens SceneSerieParallele in der UI das folgende Programm » und ich habe den Code von github eingefügt
Gladys/server/lib/scene at master · GladysAssistant/Gladys · GitHub (zumindest beim Suchen des github-Codes scheint es mir, dass es dort passiert)

Er hat mir das zurückgegeben (danke chatgpt :slight_smile: ) ich bin platt! :crazy_face:
Nachher ist nicht sicher, dass es so direkt nutzbar wäre :thinking: :rofl: oder in Gladys umsetzbar (es stimmt, es gibt die Datenbankstruktur, die damit verbunden ist) aber es ermöglicht mir, den Code zu entdecken und zu verstehen (nicht meine Tasse Tee, diese Sprache :nauseated_face:) und mein Wort, zu sehen, was ChatGPT für mich schaffen kann, der in Schwarz-Weiß-Fernsehen aufgewachsen ist und wo man sich den Hintern erheben musste, um zwischen 1 und 2 zu wählen, ist atemberaubend, auch wenn es zu meinen Träumen gehörte (« Verbotene Planet »!)

const Promise = require(‹ bluebird ›);
const { actionsFunc } = require(‹ ./scene.actions ›);
const { EVENTS, WEBSOCKET_MESSAGE_TYPES } = require(‹ ../../utils/constants ›);
const { AbortScene } = require(‹ ../../utils/coreErrors ›);
const logger = require(‹ ../../utils/logger ›);

/**

  • @description Führe eine Aktion aus.
  • @param {object} self - Referenz auf den SceneManager.
  • @param {object} action - Eine Aktion aus der Datenbank.
  • @param {object} scope - Der Scope, der an alle Aktionen übergeben wird.
  • @param {number} [columnIndex] - Der X-Index der Aktion im Array der Aktionen.
  • @param {number} [rowIndex] - Der Y-Index der Aktion im Array der Aktionen.
  • @returns {Promise} Wird aufgelöst, wenn die Aktion erfolgreich ausgeführt wurde.
  • @example
  • executeAction(this, action, {});
    */
    async function executeAction(self, action, scope, columnIndex, rowIndex) {
    // Überprüfe, ob der Aktionstyp unterstützt wird
    if (!actionsFunc[action.type]) {
    throw new Error(Aktionstyp "${action.type}" existiert nicht.);
    }

// Sende eine Nachricht, um die UI darüber zu informieren, dass die Aktion ausgeführt wird
if (columnIndex !== undefined && rowIndex !== undefined) {
self.event.emit(EVENTS.WEBSOCKET.SEND_ALL, {
type: WEBSOCKET_MESSAGE_TYPES.SCENE.EXECUTING_ACTION,
payload: { columnIndex, rowIndex },
});
}
try {
// Führe die Aktion aus
await actionsFunc[action.type](self, action, scope, columnIndex, rowIndex);
} catch (e) {
if (e instanceof AbortScene) {
throw e;
} else {
logger.warn(e);
}
}

// Sende eine Nachricht, um die UI darüber zu informieren, dass die Aktion abgeschlossen ist
if (columnIndex !== undefined && rowIndex !== undefined) {
self.event.emit(EVENTS.WEBSOCKET.SEND_ALL, {
type: WEBSOCKET_MESSAGE_TYPES.SCENE.FINISHED_EXECUTING_ACTION,
payload: { columnIndex, rowIndex },
});
}

return null;
}

/**

  • @description Führe ein Array von Arrays von Aktionen aus.
  • @param {object} self - Referenz auf den SceneManager.
  • @param {object} actions - Ein Array von Arrays von Aktionen aus der Datenbank.
  • @param {object} scope - Der Scope, der an alle Aktionen übergeben wird.
  • @param {boolean} isParallel - Ob Aktionen parallel oder seriell ausgeführt werden sollen, basierend auf dem UI-Umschalter.
  • @returns {Promise} Wird aufgelöst, wenn die Aktion erfolgreich ausgeführt wurde.
  • @example
  • executeActions(this, actions, {}, true);
    */
    async function executeActions(self, actions, scope, isParallel = true) {
    // Die erste Ebene des Arrays sollte seriell ausgeführt werden
    await Promise.mapSeries(actions, async (parallelActions, columnIndex) => {
    // Dann wird die zweite Ebene basierend auf dem Wert von isParallel ausgeführt
    if (isParallel) {
    // Führe Aktionen parallel aus
    await Promise.map(parallelActions, async (action, rowIndex) => {
    await executeAction(self, action, scope, columnIndex, rowIndex);
    });
    } else {
    // Führe Aktionen seriell aus
    for (const [rowIndex, action] of parallelActions.entries()) {
    await executeAction(self, action, scope, columnIndex, rowIndex);
    }
    }
    });
    return null;
    }

module.exports = {
executeAction,
executeActions,
};

Ein bisschen lang, aber wenn einige beim Lesen etwas aus diesem Beitrag lernen, umso besser, das ist immer ein Gewinn! :slight_smile: