Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Kuddel]

@amg_666 weder bei Brightness_up noch Brightness_down tut sich was.

[Kuddel]

Kurzes Update:

Die beiden Buttons "brightness_move_down" und "brightness_move_up" reagieren nur auf Longpress.

Man muss sie also gedrückt halten.

[holgerwolf]

@kuddel Das mit Brightness funktioniert anders.
Up und Down sind nur kurz (solange gedrückt) "true". Danach toggeln die sofort auf false und "Brighness Stop" geht kurz auf "true". Somit bekommt man gut hell-dunkel bzw laut-leise hin.
Du musst in deinem Script einfach auf die Änderung nach true triggern. So habe ich es umgesetzt:

[Kuddel]

@holgerwolf das die Statusämderung nur kurz zu sehen ist, weiß ich.

Leider tut sich bei kurzem Tastendruck gar nichts. Der Status wird nicht geändert.

Nur bei langem Tastendruck

[holgerwolf]

@kuddel Schau mal in On und Off:

zigbee.0.xxxxx.off bzw zigbee.0.xxxx.on

Die sind für den kurzen Druck zuständig:

[Kuddel]

@holgerwolf ja die Tasten funktionieren auch wie gewünscht (siehe erster Post)

[holgerwolf]

@kuddel So stehts in der Anleitung:

Da gibts keine Mitte. Nur kurz oben und kurz unten für aus und ein.

[Kuddel]

@holgerwolf oh okay. Dann muss ich nochmal genauer testen.

Bei der Vorgänger Version gab es Mitte noch

[chris299]

@holgerwolf vielen Dank für das Teilen deines Steuerungsskripts.
Ich habe das bei mir etwas anders gelöst und frage mich, ob ich was übersehen habe, bzw. warum deins so viel komplizierter ist.
Warum benutzt dieses "größer als" im Trigger, und fängst es danach wieder per "falls" ab?
Warum die zusätzliche Verzögerung beim Setzen?
Wie hast Du die Pfeil-Tasten angebunden?

Hier mal meins, was bisher auch einwandfrei funktioniert:

[chris299]

@holgerwolf nachdem bei mir die zyklischen Ausführungen ein paar mal nicht angehalten haben (vermutlich ging das "stop" im zigbee netz unter) habe ich das zusätzlich innerhalb der Ausführung auch nochmal auf "Anhalten" geprüft:

[Asgothian]

@chris299 Ich würde Dir empfehlen die Konstruktion aus Timeout und alle 500 ms hoch / runter dimmen durch ein Konstrukt nach dem folgenden Muster zu ersetzen. (Muster im Pseudocode, da ich keinen Zugang zu meinem ioBroker habe)

Probier es mal aus - es ist viel eleganter:

• Trigger auf den Styrbar Datenpunkt up, grösser als vorher.
• Darin: Setze Datenpunkt "brightness_move" to 25
• Trigger auf den Styrbar Datenpunkt down, grösser als vorher.
• Darin: Setze Datenpunkt "brightness_move" to -25
• Trigger auf den Styrbar Datenpunkt brightness_stop, grösser als vorher.
• Darin: Setze Datenpunkt "brightness_move" to 0

Das gleiche geht für die Farbtemperatur mit dem Datenpunkt "colortemp_move".

ggf. musst du die Lampe in die Ausschlussliste aufnehmen um den Datenpunkt zu bekommen falls Du diesen noch nicht hast.

A.

[chris299]

@asgothian danke für den Tipp. Aber warum "grösser als vorher" und nicht "wahr" ?

[holgerwolf]

@chris299 Du willst ja nur beim Wechsel von False auf True triggern. Prüfung auf True würde dann ja immer ziehen.

[chris299]

@holgerwolf evtl. habe ich dann das Konzept der Trigger noch nicht verstanden. Bisher dachte ich, dass Trigger sowieso nur bei Änderungen des Objekts ausgelöst werden. (die verfügbaren Optionen scheinen das zu untermauern)

Aber wenn ich Euch richtig verstehe, dann wird auch bei einer "Änderung" von "wahr" auf "wahr" ausgelöst, richtig?
wenn ja, was genau verursacht denn "Änderungen" von "wahr" auf "wahr"? der Wechsel von unbestätigt auf bestätigt?

Bisher hatte ich nicht den Eindruck, dass mein Skript zu oft auslöst... :relaxed:

[Asgothian]

@chris299 sagte in [gelöst] Zigbee Ikea Styrbar Problem:

@holgerwolf evtl. habe ich dann das Konzept der Trigger noch nicht verstanden. Bisher dachte ich, dass Trigger sowieso nur bei Änderungen des Objekts ausgelöst werden. (die verfügbaren Optionen scheinen das zu untermauern)

Nein. Die Trigger werden aktiv wenn das Objekt 'beschrieben' wird - das kann eine Änderung oder eine Aktualisierung mit dem gleichen Wert sein.
Um die verschiedenen Optionen abzufangen gibt es die Einstellungen 'ist wahr', 'ist falsch' und so weiter.
Der Punkt 'auslösung durch hat mit dem "acknowledge" status zu tun. Um den zu erklären muss ich ausholen:

Wenn der ioBroker Hardware steuern will macht es sinn wenn die Software erkennt welche Änderungen von Werten eines Datenpunktes als "Aufforderung zum Schalten" interpretiert werden - im Gegensatz zu den Meldungen das ein Gerät seinen Status geändert hat. Dazu gibt es das "Acknowledge".
Steuerbefehle werden immer ohne Acknowledge (also als unbestätigte Änderung) gesetzt. In Blockly gibt es dazu beim SetState die Auswahl "steuere" (ohne acknowledge als unbestätigte Änderung) und "aktualisiere" (mit acknowledge, als bestätigte Änderung). Wenn der Adapter die information bekommen hat das der Steuerbefehl ausgeführt wurde aktualisiert dieser überlicherweise den Datenpunkt (mit acknowledge).

im Admin 5 wird dieses farblich dargestellt. Wertänderungen ohne acknowledge werden in rot dargestellt, Wertänderungen mit acknowledge in grün.

Aber wenn ich Euch richtig verstehe, dann wird auch bei einer "Änderung" von "wahr" auf "wahr" ausgelöst, richtig?
wenn ja, was genau verursacht denn "Änderungen" von "wahr" auf "wahr"? der Wechsel von unbestätigt auf bestätigt?

Bisher hatte ich nicht den Eindruck, dass mein Skript zu oft auslöst... :relaxed:

Fun fact: Bei JS (und vielen anderen Programmiersprachen) gilt: true > false.

Damit löst ein Trigger auf "ist grösser als" nur aus wenn sich der Wert von false auf true ändert.

Ein Trigger auf "true" wird immer dann aktiv wenn der Datenpunkt mit dem Wert true beschrieben wird (also bei Änderung UND Aktualisierung)

A.