Closed OoDeLally closed 5 years ago
The actual states that can be applied to the specific lights are based off the type of the light when it is obtained from the hub.
The type of light is matched against the lists provided from Phillips hue API documentation and then a specific matching light class, which is matched against valid states for that particular light when you later set a state on them.
It sounds like we are not getting a correct match here, or there is a bug in the code.
Can you provide the details on the lights that this is not working for? Dumping the output of .toStringDetailed()
on the light instance should provide enough information. Then I can properly investigate if this is a bug, or something else.
This is what I get:
ExtendedColorLight
id: 1
state: {"on":true,"bri":51,"hue":10000,"sat":127,"effect":"none","xy":[0.4341,0.419],"ct":328,"alert":"none","colormode":"hs","mode":"homeautomation","reachable":true}
swupdate: {"state":"noupdates","lastinstall":"2019-09-10T06:08:02"}
type: "Extended color light"
name: "Lampe Piano"
modelid: "LCT010"
manufacturername: "Philips"
productname: "Hue color lamp"
capabilities: {"certified":true,"control":{"mindimlevel":1000,"maxlumen":806,"colorgamuttype":"C","colorgamut":[[0.6915,0.3083],[0.17,0.7],[0.1532,0.0475]],"ct":{"min":153,"max":500}},"streaming":{"renderer":true,"proxy":true}}
config: {"archetype":"sultanbulb","function":"mixed","direction":"omnidirectional","startup":{"mode":"safety","configured":true}}
uniqueid: "00:17:88:01:02:82:97:53-0b"
swversion: "1.46.13_r26312"
swconfigid: "0CE67A8F"
productid: "Philips-LCT010-1-A19ECLv4"
I have released version 3.1.3
of the library to resolve this, it was an oversight on my part when refactoring the library.
The transitiontime
value is no longer returned from the bridge for the light states, so I had nothing to match against in the existing state values for the light. All lights in the hue system support a transtiontime
, so have fixed that in the 3.1.3
release.
Cool, thanks! I'm glad this was quick.
I checked your commit. Because you push transitiontime
inconditionally into states
, Is it possible that transitiontime
end up being twice in states
, if the user uses a bridge with an older firmware?
It might be possible, but not really an issue, as the Hue bridge encourages updates and the change around this was much earlier in the year, I cannot remember the actual date.
It also does not really cause any issues if it occurs twice for the older API versions.
Thanks for this amazing library.
I have a set of 4 Philips Hue bulbs "White and Color Ambiance". Every device's firmware is updated with the lastest available version.
setLightState
gives meAttempting to set a state transitiontime on a light that does not support it
on console. While other light state attributes are taken in account, the transition is ignored.I did a little digging in the code of
node-hue-api
.In
node-hue-api/lib/api/http/endpoints/light.js
, functiongetStateForDevice()
, theallowedStates
is evaluated to the following value:[ 'on', 'bri', 'hue', 'sat', 'effect', 'xy', 'ct', 'alert', 'colormode', 'mode', 'reachable', 'bri_inc', 'sat_inc', 'hue_inc', 'ct_inc', 'xy_inc' ]
Becausetransitiontime
is not part of this list,transitiontime
is not added to the returnedstate
.However my lights are perfectly able to handle
transitiontime
. When prefixing theif
condition withtrue ||
in order to bypass this verification, then thetransitiontime
is accepted, and my light change hue instantly, as expected.I am not sure I understand where this list comes from, the codebase was becoming too obscure as I was digging. But I hope it gives you a hint to solve this mystery.