Attempting to set a state transitiontime on a light that does not support it

[OoDeLally]

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.

const state = new LightState().transitiontime(0).hue(blue);
await this.hueBridge.lights.setLightState(LIGHT_ID, state);

setLightState gives me Attempting 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, function getStateForDevice(), the allowedStates 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' ] Because transitiontime is not part of this list, transitiontime is not added to the returned state.

However my lights are perfectly able to handle transitiontime. When prefixing the if condition with true || in order to bypass this verification, then the transitiontime 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.

[peter-murray]

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.

[OoDeLally]

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"

[peter-murray]

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.

[OoDeLally]

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?

[peter-murray]

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.