-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Input needed: Refactor logic setting light state #2475
Comments
state.on
and state.bri
Because of this, The (Hue) light reports colormode |
Cross-referencing #973. |
Next iteration: the next commits add
Note that not all Window Covering devices support all these commands. Notably the Xiaomi Curtain Controller B1 (that uses the Analog Output cluster), only supports (the equivalent) of Goto Lift Percentage. The
Both old attributes are included in the websocket notifications (note: I'm running with
|
Just to throw something in here...
When looking physically at the device (and talking about the Hamton Bay one you've just fixed - thank you), you will ALWAYS have the fan. There may be an attached light unit, or there may no - it's optional whether you install it or not. Now, I don't know if the the remote can actually tell you if the light kit has been installed or not. I'd think in this case, the "whole fan", should be presented up in a similar method to the multi sensors - with a sub device for the fan, and a sub device for the lights - like a multi sensor has a device for temp, a device for pressure, etc. G |
I appreciate that you do that, but it's irrelevant for how a device is exposed through the REST API. The resource structure follows what the device looks like from a Zigbee perspective: the exposed endpoints and clusters. See my explanation in #932 (comment). |
OK, PR #2553 caused some more effects that I had anticipated.
I also found some other weird things:
For my next attempt, I propose the following:
|
For window covering, I m agree, and for retro-compatibiliy there is still {"bri_inc": 0} |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I've finally found the time to refactor the setting of the
state
of a/lights
resource, see #1111 (comment). Next to the functional changes, I'm also adding parameter checking.The logic for handling
on
andbri
is described in the issue mentioned above. The logic for handling the other attributes is less clear. I run into some design decisions for these, @manup, everybody, please provide your input.xy
trumpsct
trumpshue
andsat
. It ignores the over-trumped attributes without issuing an error, but clients can tell because they aren't reported in the response. Not sure howeffect
is supposed to relate to these. I want to do the following: for"none"
, clear the colour loop before handling the colour attributes; for"colorloop"
, set the colour loop after handling the colour attributes. And return an error for the colour attributes while colour loop is active (just as forbri
and colour attributes when the light is off).bri
trumpsbri_inc
andct
trumpsct_inc
. Note that the deCONZ API doesn't exposexy_inc
,hue_inc
, norsat_inc
. While they might be great for rule actions for the magic cube, I haven't seen any use for these;ResourceItem
foreffect
. Looking at the code,effect
is exposed only whenxy
is. On the other hand, setting the colour loop changescolormode
tohs
?hue
andsat
. It would seem the plugin tries to calculate and update thexy
values from thehue
andsat
values for the benefit oftaskToLocalData()
. Why isn't there similar logic for updatingct
. And for updatingxy
andhue
/sat
when settingct
? And for updatingct
andhue
/sat
when updatingxy
?I think API clients should take notice of
colormode
and only process the corresponding attributes (homebridge-hue does).I would really like to defer this setting of other colour attributes to the light, although not all non-Hue lights update
xy
,ct
, orhue
/sat
from other colour modes;addTaskSetEnhancedHueAndSaturation()
inzcl_tasks.cpp
. Is that intentional or just for historic reasons? Preferably, I would have a singleaddTask...()
to set any combination of hue/enhanced hue and sat, depending on the light capabilities;ct
for Color lights, orhue
andsat
for lights that don't support these for Alexa's benefit. And for using a different colour mode than specified in the API call to set the colour (e.g. settinghue
/sat
whenxy
was specified, or settingxy
whenct
was specified). How to handlecolormode
in these cases: I think it should report the actual light mode?Personally I feel this is a poor decision, leading only to confusion. If a light doesn't support
hue
andsat
, it doesn't work with Alexa, sorry. If a light doesn't supportct
, do thect
toxy
conversion in your API client./lights
resources: _Window covering device, Warning device, Fan, Range Extender, and Configuration Tool (did I miss any?). For Window covering device,on
,bri
, andsat
are abused for Open, Percentage Lift and Percentage Tilt from the Window covering cluster. For Warning device,alert
is abused for Warning from the IAS WD cluster. The only Fan currently (in progress of being) is the Hampton Bay fan module (Fan Module (Hampton Bay) #932), which exposes the Fan Control cluster on the same endpoint as the On/Off and Level Control clusters (to expose the light). The fan is exposed though an addedspeed
attribute. I'm still not sure whether the Fan Control cluster should better be exposed as a separate (for now)/lights
resource. The Trådfri repeater supports Identify, and correctly maps that toalert
.Most of these devices support Groups and Scenes, but the API cannot handle these. In preparation of this, I'd like to change the attributes for Window covering device to
open
,lift
, andtilt
(and get rid of the 0..254 to 0..100 translations) and for Warning device towarning
. As this would be a breaking change, how do we want to handle that. Expose old and new next to each other for a while?It might be prudent to add the cluster to the
uniqueid
of these non-light/lights
resources, but that might also be a breaking change. It would be needed to expose the Hamption Bay as two resources.The text was updated successfully, but these errors were encountered: