Ganz genauso hier auch ^^
Genau, für mich ist es dasselbe, aber ich bevorzuge diesen Zustand, weil es für mich logischer ist, das durchgestrichene Symbol anzuzeigen, wenn die Tür oder das Fenster geschlossen ist. Als meine Xiaomi-Öffnungssensoren noch über die Xiaomi-Integration verwaltet wurden, wurden sie wie oben angezeigt, aber nachdem ich auf die Zigbee-Integration umgestiegen bin, wurden sie umgedreht. Ich glaube, dass sie in Zigbee2MQTT falsch herum konfiguriert waren.
Ahhh ich werde mir Ärger einhandeln!!!
Seid ihr euch sicher?
Ich gebe zu, dass das „durchgestrichene Schild“-Symbol für mich nicht gerade aussagekräftig ist.
Aber vielleicht habe ich 0/1 oder false/true vertauscht.
Dieses mehrdeutige Icon wird hier besprochen, falls es relevant ist
Hmmm
Also, ich sehe, dass, wenn der Kontakt hergestellt ist, der Wert „true“ vorliegt, aber Gladys spricht nicht von „Kontakt“, sondern von „Öffnung“.
Die Begriffe sind also umgekehrt.
Kontaktsensor = überprüft, ob es geschlossen ist
Öffnungssensor = überprüft, ob es geöffnet ist…
Mist. Das habe ich nicht gesehen.
guten abend @ Alex Trovato
Ich riskiere, ausgebuht zu werden, aber das durchgestrichene Symbol zu sehen, wenn die Tür oder das Fenster geschlossen ist, ist aussagekräftiger (die Idee einer Barriere). Außerdem kehren wir mit dieser Lösung zur gleichen Logik wie die Xiaomi-Integration zurück. Tatsächlich würde „geöffnet“ oder „geschlossen“ das Problem lösen. ![]()
Es stimmt, dass diese Symbole nicht sehr aussagekräftig sind. Für mich war es logischer in die andere Richtung, aber das könnte ein langes Diskussionsthema sein ![]()
Danach muss man sich vor allem auf den zurückgegebenen Wert konzentrieren, denn wenn wir es so belassen, muss ich alle meine Szenen neu machen, in denen ich diese Sensoren berücksichtige.
Ich bin mit diesen Icons einverstanden.
Man stellt sich weniger Fragen, wenn man ein offenes oder geschlossenes Schloss sieht, finde ich.
Ich habe es gerade bemerkt, ich wollte gerade einen Beitrag dazu schreiben. Danke für dein Feedback, ich bestätige das gleiche Verhalten auf meiner Seite!
Mein Einbruchserkennungsszenario, wenn ich im Urlaub bin, funktioniert jetzt überhaupt nicht mehr ![]()
Für Infos, @AlexTrovato hat einen PR erstellt, um das umgekehrte Verhalten der Türöffnungssensoren zu beheben!
Da er es nicht testen kann, wäre ich für euer Feedback zu dieser PR dankbar! Ich habe ihn gebeten, ein Docker-Build für euch zu erstellen, das er hier posten wird.
Ich weiß, dass es etwas umständlich ist, Zigbee2mqtt-Builds zu testen, aber da diese Entwicklungen blind gemacht werden, gibt es keine andere Möglichkeit ![]()
Ich würde es heute Abend testen.
Bild wird gerade gebaut.
atrovato/gladys:zigbee2mqtt
Es wird heute Abend verfügbar sein ![]()
@pierre-gilles, @AlexTrovato
Ich habe gerade getestet und meine Öffnungssensoren funktionieren wieder wie zuvor und meine Szenen funktionieren wieder!
![]()
Hier ist ein Bild mit meinen geschlossenen Fenstern/Türen.
Ich habe gerade den PR gemerged
Danke @AlexTrovato für den Fix und @Will_71 für die Tests ![]()
Korrektur in Produktion bereitgestellt! ![]()
Ich bestätige, dass es wieder funktioniert! Danke @AlexTrovato
Das sieht schon besser aus, aber ich habe immer noch die alten Icons. Ist das normal?
Ich beziehe mich auf diese Nachricht (ich habe nicht überprüft, ob das Teil der MR war)
Ja, das ist normal, der Fix war nicht im Frontend, wie ich dachte, sondern im Dienst Zigbee2mqtt. Alex’ PR sollte nur diesen Bug so schnell wie möglich beheben
Mein Kommentar war nur ein Vorschlag.
Gestern Abend habe ich meiner Partnerin begonnen, die Funktionsweise von Gladys zu erklären, mit den verschiedenen Registerkarten, die ich eingerichtet habe, …
Ich habe ihr die Registerkarte zum Öffnungszustand von Fenstern und Türen gezeigt und ihr die Bedeutung des Schildes erklärt.
Ihre spontane Reaktion: „Wäre es nicht besser, ein offenes oder geschlossenes Vorhängeschloss zu verwenden?? Ist das nicht logischer?"
Ich habe ihr gesagt, dass es dazu Überlegungen gibt.


