Nach dem Hinzufügen des Alarms wollte ich meine Szenen zur Erkennung des Öffnens von Türen oder Fenstern wieder aktivieren.
Das Problem ist, dass der Auslöser „Gerätestatusänderung“ für den Tür-/Fensterkontakt rückwärts funktioniert.
Das heißt, ich muss den Text „Geschlossen“ auswählen, um das Öffnen zu erkennen!
Ja, tatsächlich finde ich das auch irritierend, einen Sensor zu haben, der den umgekehrten Zustand des Geräts anzeigt, das er überwacht. (Öffnungssensor geschlossen, wenn das Fenster offen ist
Ja, das ist eine alte Diskussion, die immer mal wieder aufkommt
Wenn ich mich nicht irre, liegt das Problem nicht mehr in der Anzeige des Icons (die mir völlig kohärent erscheint), sondern es geht um die Erstellung der Szene.
Auch bei mir teste ich den Zustandswechsel meiner Öffnungssensoren und ich muss „GESCHLOSSEN“ angeben, wenn ich das Öffnen einer Tür erkennen will. Also darauf müssen wir uns konzentrieren
Das Problem liegt bei den Geräten, die ‹ 1 › für ‹ offen › zurückgeben und anderen, die ‹ 0 › für offen zurückgeben…
Ein Feature-Request, um den ‹ Zustand umkehren › zu können?
Ein Kontrollkästchen (davon ist @pierre-gilles ein Fan), das ‹ mein Sensor gibt invertierte Daten zurück › sagt oder…?
Das könnte die Sache etwas komplizierter machen, oder?
Oder wenn wir das machen müssten, bräuchten wir einen ganzen Text, um den Benutzer nicht zu verwirren:
Dieser Sensor zeigt den Zustand „OFFEN“ an.
Stellen Sie sicher, dass er sich in der richtigen Position befindet.
Falls er weiterhin „OFFEN“ anzeigt, obwohl er geschlossen ist, aktivieren Sie dieses Kontrollkästchen:
Wie wird das gehandhabt? Denn am Ende zeigt Gladys dasselbe an, was der Sensor sendet, 0 oder 1. Ich denke, man sollte diese Logik einfach umkehren, damit, wenn Gladys einen geöffneten Zustand vom Sensor erhält, ein geöffnetes Fenster behandelt wird
Vollkommen einverstanden, die Logik des Geräts erscheint mir nicht gut, nicht der Core von Gladys, es erscheint mir logischer, eine Funktion mit einem Häkchen in den Geräteeinstellungen hinzuzufügen, um die Werte, die es zurückgibt, umzukehren, und das wäre allgemeiner (falls eines Tages Geräte „offen“ „geschlossen“ anstelle von 0 und 1 senden!) oder sollte das vielleicht in der Geräteintegration berücksichtigt werden?
Es wird einen Gladys Plus Build geben, den ich euch hier zur Verfügung stellen werde, falls ihr das Umkehren testen wollt, um zu bestätigen, dass es funktioniert!
Oh, ich werde schon sehen und mich irgendwie durchschlagen, falls etwas kaputt geht. Ich habe den Fortschritt dieses Themas verpasst
Bearbeitung: Ich bin mir nicht mal sicher, ob ich überhaupt betroffen bin.
Ich werde vielleicht etwas Dummes sagen, aber da ich keinen Öffnungssensor zum Testen habe…
Kann man das Problem mit den invertierten Werten nicht einfach in der Sensor-Konfiguration lösen, indem man die Werte wie folgt invertiert?
Ich habe es an einer Steckdose getestet, das funktioniert. Es invertiert die Funktionsweise in der UI, aber falls jemand einen Öffnungssensor zum Testen hat
Das sieht trotzdem nach einem nicht gerade intuitiven Flickwerk aus ^^
Und nebenbei geht es hier um die MQTT-Integration. Wenn ich mich nicht irre, handelt es sich hier um die allgemeinere Integration der Funktion „offen/geschlossen“ und deren Übersetzung, die korrigiert wurde.
Ich kann es kaum erwarten, meine Szenen jetzt endlich richtig sprechen zu hören!!
Ich bin deiner Meinung, das Problem ist, dass es alle Geräte betrifft, die eine 0 für „offen“ senden und die, die eine 1 senden, wie @GBoulvin sagt.
Wenn man es direkt im integrierten Gerät ändert, löst das beide Fälle, oder?
(Ich habe nur MQTT, daher kann ich dir nicht zu den anderen Fällen etwas sagen, meine Idee ist vielleicht nicht gut.)
PS:
Der Sensor, der 0 für „geschlossen“ sendet, ist nicht intuitiv!!! Aber bei Relais oder Detektoren, bei denen es NF und NO gibt, macht das Sinn. Gladys muss einfach beide Fälle verwalten können!
?
Aber bei Relais oder Detektoren, bei denen es NF und NO gibt, macht das Sinn. Gladys muss einfach beide Fälle verwalten können!