Hallo zusammen,
Weiß jemand, wie man eine Szene basierend auf der Rückmeldung eines Tastendrucks erstellt?
Die Schnittstelle zeigt mir die richtigen Werte an, aber in den Szenen weiß ich nicht, wie ich es machen soll.
Ich habe versucht:
Nichts funktioniert! In den Gladys-Logs steht conditionVerified = false. Das ist eindeutig!
Welches Modell hat deine Taste?
Kann sie lange, einfache oder doppelte Drücke ausführen?
Meine ist eine WXKG06LM.
Ja, ich kann das!
Es ist der Xiaomi Aquara-Schalter.
@lmilcent ist das ein Button für welche Integration?
Wenn es sich um die Zigbee2mqtt-Integration handelt, hängt alles davon ab, was in diesem PR geändert wurde…
Es handelt sich tatsächlich um Zigbee mit einem Feature button.
Eigentlich müsste beschrieben werden, wie Gladys auf die verschiedenen Features reagiert, um nicht jedes Mal die Frage stellen zu müssen (vielleicht ist das schon gemacht?).
Zum Beispiel, wenn es vom Typ switch ist, wird ein Ein-/Ausschalter angeboten und erkannt als Steckdose.
In meinem Fall ist es vom Typ button und die zurückgegebenen Werte sind konsistent. Aber in einer Szene sehe ich nicht, wie ich es verwenden kann.
Im Xiaomi-Service werden die Literalwerte der Tasten in numerische Werte übersetzt.
const SWITCH_STATUS = {
NO_CLICK: 0,
CLICK: 1,
DOUBLE_CLICK: 2,
LONG_CLICK_PRESS: 3,
LONG_CLICK_RELEASE: 4,
};
Vielleicht sollte ich das Gleiche im Zigbee-Service machen 
Allerdings gibt es viele Arten von Tasten…
Mist, ich dachte, das wäre Gladys Core, das sich darum kümmert, basierend auf den features.
Ist das nicht logischer?
Vor allem denke ich, dass es verhindert, dass ein Dienst eine Schaltfläche anders interpretiert als ein anderer, um eine Kohärenz und damit eine gewisse Einfachheit unabhängig vom Protokoll zu wahren.
In meinem Fall gibt es:
Was ich nicht verstehe, ist, dass diese Geräte Ereignisse und keine Werte ausgeben.
Für ein Thermometer wird der Wert jedes Mal aktualisiert, wenn er sich ändert.
Für einen Knopf, wenn du darauf drückst (z. B. durch einen einfachen Klick), könnte man den Wert auf 1 setzen, aber direkt danach sollte er wieder auf 0 zurückkehren (um den Zustand des Knopfes widerzuspiegeln)?
Es ist tatsächlich Gladys Core, der das Format der Features definiert.
Das ist das Ziel in der Theorie 
Wir versuchen, so weit wie möglich gemeinsame Feature-Formate zwischen den Diensten zu haben (Ein/Aus, Farbe, Helligkeit, Temperatur usw…)
Allerdings ist es in der Praxis leider manchmal schwierig, Verallgemeinerungen von Geräten mit sehr exotischen Spezifikationen zu treffen. Im zitierten Beispiel (Xiaomi) war es bisher das einzige Tastengerät mit mehreren Drucktypen (kurz, lang, doppelt usw.), und daher hat es tatsächlich als einziges diese Art von Funktionsweise implementiert.
Jetzt, wo wir den Fall in 2 Diensten haben, können wir darüber nachdenken, was sich überschneidet und was nicht
Man sollte tatsächlich das Gleiche auf der Zigbee-Seite tun (es ist derselbe Knopf, oder?)
Ich denke, dass man im Fall eines Knopfes den Wert eher als Ereignis denn als Zustand betrachten sollte. Es ist ein Ereignis « Der Knopf wurde gedrückt ».
Ich sehe wenig Sinn darin, jedes Ereignis mit einem Ereignis zu verdoppeln, das den Zustand auf 0 zurücksetzt (« Der Knopf wurde nicht gedrückt » ) … Siehst du einen?
Edit: Übrigens, das NO_CLICK: 0, wurde am Anfang hinzugefügt, aber nicht verwendet, ich sehe keinen Sinn darin. Es hätte beim PR entfernt werden müssen.
Ich weiß nicht, ob das aktuell der Fall ist, aber auf dem Dashboard wird mein Knopf zunächst als „single“ angezeigt und dann nach einigen Sekunden „kein Ereignis“ (wenn ich die Seite neu lade).
Das wird kompliziert sein, alle Fälle zu verwalten.
Für Geräte wie dieses Aqara WS-USC02 control via MQTT | Zigbee2MQTT oder dieses Aqara WXKG02LM_rev2 control via MQTT | Zigbee2MQTT haben wir:
@lmilcent Hast du mit dem Wert « single » in den Szenen versucht?
Ja, ich habe es mit « 1 » und einem einzelnen kurzen Druck auf meinen Knopf versucht.
@cicoub13 Ich denke, man sollte das nochmal überarbeiten. Solche Buttons sollten nativ unterstützt werden und out of the box in den Szenen funktionieren
Genau wie wir die UI anpassen, wenn es sich um einen binären Button handelt, zum Beispiel:
Das sollte auch für diese Buttons gelten.
Ich würde mir ein Dropdown mit den verschiedenen Werten wünschen:
Der Benutzer sollte nicht raten müssen, wie das funktioniert, das ist sonst die Hölle ^^
Gilt das auch für Präsenz-/Kontaktsensoren?
Sollte man nicht eher „geschlossen/offen“ und „Bewegung/keine Bewegung“ anzeigen?
Genau dasselbe! Außer bei numerischen Vergleichswerten (Temperatur > XX) sollte der Nutzer nichts eingeben müssen, das ergibt keinen Sinn.
@cicoub13 ich habe gesehen, dass du den PR zigbee2mqtt vorgeschlagen hast. Wie funktioniert das mit Geräten wie Tastern mit mehreren Druckarten? Was wird vom Dienst gesendet? Ist das das gleiche Format wie beim Xiaomi-Dienst?
Bisher habe ich noch nichts gemacht.
Ich kann die gleichen Werte wie der Xiaomi-Dienst integrieren. Aber es wäre gut, das für alle Dienste zu vereinheitlichen (in den Konstanten) und einen Button (wie Ein/Aus) in einem anderen PR zu erstellen.
Und wie ich schon sagte, gibt es Geräte, die viel mehr Fälle haben: linke/mittlere/rechte Tasten, die alle kurze/doppelte/lange Drücke haben können. Sollte man das als verschiedene Features behandeln (das wird hart für Zigbee 
) ?
Ich würde mir vorstellen:
kurz, doppelt, langSo ist es einfacher
Ich bin einverstanden, es muss vereinheitlicht werden. Die gleichen Konstanten wie der Xiaomi-Service erscheinen mir gut! Das können wir tatsächlich in die Konstanten des Projekts setzen.
Ich denke, man sollte bei exotischen Geräten Fall für Fall vorgehen, nicht alles ist faktorisierbar und meiner Meinung nach ist es nicht wünschenswert, « Hyperverallgemeinerung » zu betreiben
Also ja, es stört mich nicht, wenn bestimmte exotische Geräte als separates Feature definiert werden, solange es im Allgemeinen mit Gladys übereinstimmt. Man muss die Nutzung im Blick behalten. Zum Beispiel, wenn es darum geht, ein Licht zu steuern, ist das Ein-/Ausschalten, die Helligkeit und die Farbe lebenswichtig, dass es « native/allgemeine » Features von Gladys sind, damit Gladys diese Geräte im Chat, in Szenen und anderem steuern kann.
Wenn es sich um sehr exotische Tasten handelt, die nur für eine einzige Integration spezifisch sind und nie anderswo verwendet werden, muss man von Anfang bis Ende darüber nachdenken, wie das in Gladys nützlich sein wird, und das Beste daraus machen, ohne notwendigerweise zu versuchen, es in ein Schema zu pressen und es unbrauchbar zu machen.