Hue + transitiontime & set on

Navigator · 23 Oktober 2019, 12:03:18

Immer wenn ich bei den Hue Devices transitiontime als festes Attribut verwende, dann werden die Lampen bei einem 'set on' auf einen sehr geringen Wert um die 1 Prozent gedimmt. Ich muss zum einschalten dann einen direkten Dimmwert anfahren. Das ist insorfern nicht besonders praktisch, weil FHEMlazy und Alexa das bei einem einfachen "einschalten" genauso macht. Lasse ich das Attribut weg, kappt alles und der letzte Einschaltwert wird bei einem einfachen "set on" angefahren. Kann das jemand so bestätigen? Ist das ein Bug oder was mache ich falsch?
Eine Befehl aus der CommadRef....

Code Auswählen

set HueDevice1 on : transitiontime 100 mit schon gesetztem Attribut lässt die Lampe auf 06% erleuchten.

MadAlex · 24 Oktober 2019, 06:51:06

Hallo ,
meine Hue Lampen verhalten sich genau so wie von dir beschrieben -
mit pct geht es einwandfrei

set HUEDevice1 pct 100 : transitiontime 100

bei

set HueDevice1 on : transitiontime 100

dümpelt die bei 6% rum .
Warum kann ich dir nicht nicht sagen ,kann aber die Beobachtung bestätigen.

mfg

Navigator · 24 Oktober 2019, 11:43:51

Danke, dann bin ich nicht der einzige. Ich hoffe der Maintainer findet dieses Thread und schaut sich das mal an.

Beta-User · 24 Oktober 2019, 12:25:51

IMO ist das "works as designed":

ZigBee scheint sich da ähnlich zu verhalten wie ZWave. Hier wie dort heißt "on" immer: Mache an, und zwar mit dem letzten eingestellten Level. Wenn das 6% waren (da abgedimmt), dann sind das eben 6%, waren es 45%, dann eben das usw.. Dafür kann man teilweise auch schon vor dem Einschalten festlegen, mit welchem Wert dann "irgendwann" auch eingeschaltet werden soll (bzw., auf welchen Level die Lamellen eines Jalousieaktors dann fahren sollen).

IMO ist das der Grund, warum in der cref auch ausdrücklich erwähnt ist, dass man mehrere Commands kombinieren kann, v.a. das Beispiel

Code Auswählen

set bulb on : bri 100 : color 4000macht nur dann Sinn, wenn "on" eben nicht zwangsläufig "bri 100" bedeutet, oder?

ggf. kann man das mit einer eventMap (nur für usr) dahingehend "richten", dass "on" zu "pct 100 100" (das sollte ohne Doppelpunkt gehen) übersetzt wird...?

Nachtrag: Beispiel für ein "usr"-eventMap (@ZWave, da wird "dim 100" wie "on" bewertet, also "letzter Level", ausgeführt werden soll aber bei beiden Befehlen "ganz hoch")

Code Auswählen

attr Jalousie_WZ eventMap { usr=>{'dim.100'=>'dim 99','on'=>'dim 99'}}

Navigator · 24 Oktober 2019, 16:40:42

Das Problem hierbei sind nicht so sehr die Visualisierung oder das Mapping auf FHEM Ebende. Das Problem ist eher Alexa und FHEMlazy. Wenn ich der Dame sage, Lampe xx anschalten ohne eigene Routine dafür, wird dann diese Lampe über FHEM und die Bridge eben auf besagte 6% gedimmt. Ich kann ihr mündlich natürlich immer den Dimmwert mitgeben, aber wer macht sowas....

Beta-User · 24 Oktober 2019, 16:52:18

Hast du es denn jetzt mit dem eventMap versucht, oder nur behauptet, dass das "Mapping auf FHEM-Ebene" nicht das Problem ist?

(Alexa kann ja (ohne Custom Skill) scheinbar nur on und off, wie ich vorhin lernen durfte; aber wenn man den "on"-Befehl in FHEM mappt wie beschrieben (begrenzt auf usr!), müßte sie eigentlich einen "tauglichen" "on"-Befehl für FHEM daraus machen, was dann für die HUEBridge den Dimmwert entsprechend setzt (und die ramp-time, wenn man das möchte).).

Navigator · 24 Oktober 2019, 16:57:26

Also ich verwende ja bisher nur FHEMlazy und dort funktionieren auch sämtliche Dimmbefehle ohne Routinen oder ähnliches. Dein Mapping mit deinem Code im eventMap habe ich getestet und der Befehl wird wirklich erfolgreich umgemappt. Leider sind dann alle anderen 'setextensions' nicht mehr verfügbar und ich erhalte einen Fehler beim schalten.

Beta-User · 24 Oktober 2019, 17:14:33

Zu FHEMlazy usw. kann ich wenig sagen. Wenn das die SetExtensions stört, ist das natürlich unglücklich (bei meiner Jalousie ist das egal, die braucht kein on-for-timer usw. zu kennen).
Evtl. muß dann das alexa-Mapping anders gemacht werden (da kenne ich mich aber auch nicht aus, sondern hatte nur am Rande dazu mal was im Hinterkopf abgespeichert), und welcher Fehler da kommt, wäre evtl. auch interessanter gewesen wie der Hinweis, dass da einer kommt... Je nachdem kommt man vielleicht auch mit einer Kombination zum Ziel, z.B. indem man neue Befehle erfindet wie "alexa_on" und die dann mit einer usr-eventMap umbiegt...

Wie dem auch sei, IMO immer noch kein Grund, nach dem Entwickler zu rufen, das Modul "works as designed"...

Navigator · 24 Oktober 2019, 18:40:16

Wie auch immer, ich war halt der Meinung es handelt sich um einen kleinen Fehler. Dass der letzte Einschaltzustand auch wieder als Einschaltwert bei einem einfachen "on" zu Grunde gelegt wird, erschließt sich auch mir und ist gut so. Aber ein Dimmen auf 0 Prozent, bzw ausschalten mit "transitiontime" sollte doch eher als Ausnahme behandelt werden. Ein einfaches "dim0" oder "off" ohne diese 'transitiontime' dimmt die Lampen im Grunde auch herunter, zwar sehr schnell und innerhalb einer Sekunde, aber dort wird ja auch nicht der letzte Einschaltwert mit 06% gespeichert. Es heisst ja nicht umsonst Übergangszeit und ich sehe hier eher einen temporären Zustand. Der letzte Schaltzustand ist ja hier auch eigentlich dim0% und nicht dim06%. Ach man kann es drehen und wenden wie man will, jeder möchte es womöglich anders...
Vielleicht handelt sich es hier einfach um einen ungewollten Nebeneffekt oder die Entwickler denken anders und weiter wie ich..

Beta-User · 24 Oktober 2019, 19:23:43

OK, der Vergleich langsames Runterdimmen verhält sich anders als schnelleres "aus" ist nachvollziehbar, die Frage hat - so gestellt - ihre Berechtigung...
K.A., wie das intern gehandhabt wird, auch bei HM ist es z.B. so, dass es teilweise drauf ankommt, welches IO genutzt wird und wie die aktuelle Funklage ist, welche Zwischenwerte bei FHEM ankommen bzw. in FHEMWEB angezeigt werden. Könnte also auch sein, dass sowas (in FHEM oder auch im IO-Gerät, also z.B. deCONZ) eine Rolle spielt.