philipshue: hue bridge request #103: put /lights/4/state Living Room 5: homekit power changed from 1 to 0 Living Room 3: homekit power changed from 1 to 0 Living Room 2: homekit power changed from 1 to 0 Living Room 6: homekit power changed from 1 to 0 philipshue: homekit transition time changed from 0.4 to 269.3 Living Room 1: homekit power changed from 1 to 0 Living Room 4: homekit power changed from 1 to 0 You might want to add a third alarm with a scene only to reset Transition Time, or all other (manual) light changes from HomeKit would use the value set from the scene (until homebridge restarts). You could get the same behaviour in HomeKit, by setting two alarms, one second apart, the first recalling the scene to turn the lights on at 0%, the second scene to turn the lights up to 100% with TransitionTime. 1 second later, I set the brightness to 100%, with a transitiontime of 10 minutes. If needed, you can run homebridge -D and check whether transitiontime is actually included in the command to the bridge.įor my wakeup scene (from the Hue bridge), I turn on my bedroom lights at 0% brightness when my alarm goes off. You might want to adjust waitTimeUpdate if transitiontime isn't included in the first(s) light updated from the scene. That was long enough for Transition Time to be set. I don't think the order of the characteristics in a scene is guaranteed, but homebridge-hue waits 20ms to collect all state changes to a single light before issuing the command to the bridge. I tested a HomeKit scene that includes Transition Time and turns six lights on, at maximum brightness and with colour red. Expose this sensor to HomeKit using homebridge-hue, and then set the status from HomeKit scenes. For serious home automation, I recommend using Hue bridge scenes: create a CLIPGenericStatus sensor with a number of rules that, when the status becomes non-0, recall a scene and reset the status to 0. Unlike Hue bridge scenes which are stored in the lights and only require a single API call and a single ZigBee message. home bridge-hue) in a separate request, forwarded to the Hue bridge in separate API calls, resulting in separate ZigBee messages. HomeKit scenes are just a collection of characteristic values, each sent to the accessory (i.c. Using HomeKit scenes might not be as smooth as using Hue bridge scenes.The value of Transition Time would be reset after homebridge restarts, see Support dynamic homebridge accessories #4.You can only specify Transition Time once in a scene, so you'd need a separate "reset" scene.You would be able from Home to recall a scene created in Eve containing Transition Time The iOS builtin Home app doesn't support custom characteristics, so you'd need Eve or another HomeKit app that does.Rather than adding Transition Time to each Lightbulb service (increasing the size of the HomeKit configuration, see #129), I would add it to the Hue bridge service (next to please let me know if this would work for you. I would remember it's value in homebridge-hue, just as I do for Duration or Heartrate. It's value isn't stored with the light state on the Hue bridge. However, transitiontime is not a regular light state attribute. I could easily create a custom Transition Time characteristic and insert its value with each request to the Hue bridge to change a light (or group) state. I don't expect the Hue bridge exposing this functionality to HomeKit, but that's why I created homebridge-hue in the first place -). This defaults to 400ms, but you can specify 0 for immediate changes or a longer time, like 10 minutes, that I use for my wakeup routine.Īs far as I know, there's no equivalent concept in HomeKit.
In the Hue API, you can specify transitiontime when changing a light (or group) state, to specify how long the change should take.
0 kommentar(er)
