[question] timed fade in/out that can be set via HomeKit

[DJay-X]

Do you guys see a way for a timed fade in/out that can be set via HomeKit? For example the Hue app's native "Wake up/Sleep" routines but manageable via HomeKit scenes or longpresses/3D touches.
At the moment I use the hue light native with the hue bridge connected to HomeKit.
Thanks.

[ebaauw]

That's an interesting idea!

In the Hue API, you can specify transitiontime when changing a light (or group) state, to specify how long the change should take. 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.

As far as I know, there's no equivalent concept in HomeKit. I don't expect the Hue bridge exposing this functionality to HomeKit, but that's why I created homebridge-hue in the first place ;-). 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.

However, transitiontime is not a regular light state attribute. It's value isn't stored with the light state on the Hue bridge. I would remember it's value in homebridge-hue, just as I do for Duration or Heartrate. 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 toHeartrate).

@DJay79, please let me know if this would work for you. The usual caveats would apply:

• The iOS builtin Home app doesn't support custom characteristics, so you'd need Eve or another HomeKit app that does. You would be able from Home to recall a scene created in Eve containing Transition Time;
• You can only specify Transition Time once in a scene, so you'd need a separate "reset" scene;
• The value of Transition Time would be reset after homebridge restarts, see Support dynamic homebridge accessories #4;
• Using HomeKit scenes might not be as smooth as using Hue bridge scenes. HomeKit scenes are just a collection of characteristic values, each sent to the accessory (i.c. home bridge-hue) in a separate request, forwarded to the Hue bridge in separate API calls, resulting in separate ZigBee messages. Unlike Hue bridge scenes which are stored in the lights and only require a single API call and a single ZigBee message. 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. Expose this sensor to HomeKit using homebridge-hue, and then set the status from HomeKit scenes.

[DJay-X]

wow.. your idea sounds like the complete concept to me. Very interesting and could be a helpful feature also for some people. As always I'm looking forward to the ongoing development of your great work. 👍🏻

[ebaauw]

Have a look at v0.5.4. I think Transition Time is fully functional, but I found two more caveats:

• In Eve, you cannot set Transition Timeaccurately. I set the maximum transition time to an hour, so the slider contains 36,000 values (from 0.0 to 3600.0 in steps of 0.1 second);
• When using a longer transition time, HomeKit doesn't reflect the actual light state. This is a limitation of the Hue bridge: it polls the lights at discrete intervals, so the state only gets updated once every so many seconds (depending on the number of connected lights).

[DJay-X]

You are crazy @ebaauw and this in an absolutely fantastic way. 👍
So I think to take advantage of Transition Time, this is the point where I have to use my hue light thru your homebridge-hue plugin and not native by the hue bridge connected to HomeKit as it is now.

[ebaauw]

In Eve, you cannot set Transition Time accurately. I set the maximum transition time to an hour, so the slider contains 36,000 values (from 0.0 to 3600.0 in steps of 0.1 second)

I've been thinking about ways to address this issue. I haven't found another (free) HomeKit app, which allows typing the value instead of using a slider. Matthias' Home app (paid) allows changing the value one step using + and -, but somehow it tends to freeze when changing custom characteristics.

Some ideas:

1. Reset Transition Time to the default 0.4s automatically, 20ms (value of waitTimeUpdate in config.json) after a light state has been changed (so the entire scene would still use the Transition Time);
2. Use a more limited and/or coarser-grained range (e.g. 0 to 30 minutes in 1-minutes steps);
3. Expose Transition Time as a string?
4. Split Transition Time into multiple characteristics: for 0.1 seconds (0.0 to 0.9), for seconds (0 to 59), for minutes (0 to 59)? Best create a separate service to group these.

[DJay-X]

@ebaauw I noticed, that I'm good with the slider in Eve App. But what I forgot, my Raspberry auto-starts every hour for better performance. And as you mentioned the Transition Time is always reset 0.4s. Unfortunately I didn't have the time yet to test everything because I was not at home and already on the jump.
What would a scenario be to use Transition Time or rather how to integrate this feature?

[ebaauw]

I tested a HomeKit scene that includes Transition Time and turns six lights on, at maximum brightness and with colour red. The lights fade in, as intended.

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. That was long enough for Transition Time to be set. You might want to adjust waitTimeUpdate if transitiontime isn't included in the first(s) light updated from the scene. If needed, you can run homebridge -D and check whether transitiontime is actually included in the command to the bridge.

For my wakeup scene (from the Hue bridge), I turn on my bedroom lights at 0% brightness when my alarm goes off. 1 second later, I set the brightness to 100%, with a transitiontime of 10 minutes. 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. 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).

[ebaauw]

Reset Transition Time to the default 0.4s automatically, 20ms (value of waitTimeUpdate in config.json) after a light state has been changed (so the entire scene would still use the Transition Time);

Implemented that in v0.5.5, so you won't need the third alarm and scene to reset Transition Time yourself.

What would a scenario be to use Transition Time or rather how to integrate this feature?

For example, I created a Fade On and Fade Off scene in Eve (note I cannot set Transition Time to 300.0 seconds exactly):

Here's the homebridge -D log of applying the Fade Off scene (when the lights are at 100%):

[6/30/2017, 1:12:45 PM] [Hue] Living Room 4: homekit power changed from 1 to 0
[6/30/2017, 1:12:45 PM] [Hue] Living Room 1: homekit power changed from 1 to 0
[6/30/2017, 1:12:45 PM] [Hue] philipshue: homekit transition time changed from 0.4 to 269.3
[6/30/2017, 1:12:45 PM] [Hue] Living Room 6: homekit power changed from 1 to 0
[6/30/2017, 1:12:45 PM] [Hue] Living Room 2: homekit power changed from 1 to 0
[6/30/2017, 1:12:45 PM] [Hue] Living Room 3: homekit power changed from 1 to 0
[6/30/2017, 1:12:45 PM] [Hue] Living Room 5: homekit power changed from 1 to 0
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #103: put /lights/4/state {"on":false,"transitiontime":2693}
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #104: put /lights/1/state {"on":false,"transitiontime":2693}
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #105: put /lights/6/state {"on":false,"transitiontime":2693}
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #106: put /lights/2/state {"on":false,"transitiontime":2693}
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #107: put /lights/3/state {"on":false,"transitiontime":2693}
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #108: put /lights/5/state {"on":false,"transitiontime":2693}
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #105: ok
[6/30/2017, 1:12:45 PM] [Hue] philipshue: reset homekit transition time from 269.3 to 0.4
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #104: ok
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #107: ok
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #108: ok
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #106: ok
[6/30/2017, 1:12:45 PM] [Hue] philipshue: hue bridge request #103: ok

HomeKit actually issues the Transition Time change after the first two light changes, but because of waitTimeUpdate, transitiontime is included in the Hue bridge requests. You also see Transition Time is reset, after the bridge requests have been issued (but before all requests have returned).

HomeKit now shows the lights as Off (as does the Hue bridge), but they're still On. After a while, the Hue bridge updates the light states when polling the lights. Because the transition to Off is still underway, HomeKit now reports the lights as On, with reduced brightness:

[6/30/2017, 1:14:31 PM] [Hue] Living Room 6: light on changed from false to true
[6/30/2017, 1:14:31 PM] [Hue] Living Room 6: set homekit power from 0 to 1
[6/30/2017, 1:14:31 PM] [Hue] Living Room 6: light bri changed from 254 to 155
[6/30/2017, 1:14:31 PM] [Hue] Living Room 6: set homekit brightness from 100% to 61%
...
[6/30/2017, 1:14:36 PM] [Hue] Living Room 5: light on changed from false to true
[6/30/2017, 1:14:36 PM] [Hue] Living Room 5: set homekit power from 0 to 1
[6/30/2017, 1:14:36 PM] [Hue] Living Room 5: light bri changed from 254 to 151
[6/30/2017, 1:14:36 PM] [Hue] Living Room 5: set homekit brightness from 100% to 59%
...
[6/30/2017, 1:14:41 PM] [Hue] Living Room 4: light on changed from false to true
[6/30/2017, 1:14:41 PM] [Hue] Living Room 4: set homekit power from 0 to 1
[6/30/2017, 1:14:41 PM] [Hue] Living Room 4: light bri changed from 254 to 147
[6/30/2017, 1:14:41 PM] [Hue] Living Room 4: set homekit brightness from 100% to 58%
...
[6/30/2017, 1:14:46 PM] [Hue] Living Room 3: light on changed from false to true
[6/30/2017, 1:14:46 PM] [Hue] Living Room 3: set homekit power from 0 to 1
[6/30/2017, 1:14:46 PM] [Hue] Living Room 3: light bri changed from 254 to 144
[6/30/2017, 1:14:46 PM] [Hue] Living Room 3: set homekit brightness from 100% to 57%
...
[6/30/2017, 1:14:51 PM] [Hue] Living Room 2: light on changed from false to true
[6/30/2017, 1:14:51 PM] [Hue] Living Room 2: set homekit power from 0 to 1
[6/30/2017, 1:14:51 PM] [Hue] Living Room 2: light bri changed from 254 to 140
[6/30/2017, 1:14:51 PM] [Hue] Living Room 2: set homekit brightness from 100% to 55%
...
[6/30/2017, 1:15:06 PM] [Hue] Living Room 1: light on changed from false to true
[6/30/2017, 1:15:06 PM] [Hue] Living Room 1: set homekit power from 0 to 1
[6/30/2017, 1:15:06 PM] [Hue] Living Room 1: light bri changed from 254 to 126
[6/30/2017, 1:15:06 PM] [Hue] Living Room 1: set homekit brightness from 100% to 50%

At the next polling cycle, the brightness is adjusted:

[6/30/2017, 1:16:51 PM] [Hue] Living Room 6: light bri changed from 155 to 26
[6/30/2017, 1:16:51 PM] [Hue] Living Room 6: set homekit brightness from 61% to 10%
...
[6/30/2017, 1:16:56 PM] [Hue] Living Room 4: light bri changed from 147 to 18
[6/30/2017, 1:16:56 PM] [Hue] Living Room 4: set homekit brightness from 58% to 7%
[6/30/2017, 1:16:56 PM] [Hue] Living Room 5: light bri changed from 151 to 22
[6/30/2017, 1:16:56 PM] [Hue] Living Room 5: set homekit brightness from 59% to 9%
...
[6/30/2017, 1:17:01 PM] [Hue] Living Room 3: light bri changed from 144 to 15
[6/30/2017, 1:17:01 PM] [Hue] Living Room 3: set homekit brightness from 57% to 6%
...
[6/30/2017, 1:17:06 PM] [Hue] Living Room 2: light bri changed from 140 to 11
[6/30/2017, 1:17:06 PM] [Hue] Living Room 2: set homekit brightness from 55% to 4%

Until the transition has finished, and the lights are reported as Off:

[6/30/2017, 1:17:21 PM] [Hue] Living Room 1: light on changed from true to false
[6/30/2017, 1:17:21 PM] [Hue] Living Room 1: set homekit power from 1 to 0
[6/30/2017, 1:17:21 PM] [Hue] Living Room 1: light bri changed from 126 to 1
[6/30/2017, 1:17:21 PM] [Hue] Living Room 1: set homekit brightness from 50% to 0%
...
[6/30/2017, 1:19:07 PM] [Hue] Living Room 6: light on changed from true to false
[6/30/2017, 1:19:07 PM] [Hue] Living Room 6: set homekit power from 1 to 0
[6/30/2017, 1:19:07 PM] [Hue] Living Room 6: light bri changed from 26 to 1
[6/30/2017, 1:19:07 PM] [Hue] Living Room 6: set homekit brightness from 10% to 0%
...
[6/30/2017, 1:19:12 PM] [Hue] Living Room 5: light on changed from true to false
[6/30/2017, 1:19:12 PM] [Hue] Living Room 5: set homekit power from 1 to 0
[6/30/2017, 1:19:12 PM] [Hue] Living Room 5: light bri changed from 22 to 1
[6/30/2017, 1:19:12 PM] [Hue] Living Room 5: set homekit brightness from 9% to 0%
...
[6/30/2017, 1:19:17 PM] [Hue] Living Room 3: light on changed from true to false
[6/30/2017, 1:19:17 PM] [Hue] Living Room 3: set homekit power from 1 to 0
[6/30/2017, 1:19:17 PM] [Hue] Living Room 4: light on changed from true to false
[6/30/2017, 1:19:17 PM] [Hue] Living Room 4: set homekit power from 1 to 0
[6/30/2017, 1:19:17 PM] [Hue] Living Room 4: light bri changed from 18 to 1
[6/30/2017, 1:19:17 PM] [Hue] Living Room 4: set homekit brightness from 7% to 0%
...
[6/30/2017, 1:19:22 PM] [Hue] Living Room 2: light on changed from true to false
[6/30/2017, 1:19:22 PM] [Hue] Living Room 2: set homekit power from 1 to 0
[6/30/2017, 1:19:22 PM] [Hue] Living Room 2: light bri changed from 11 to 1
[6/30/2017, 1:19:22 PM] [Hue] Living Room 2: set homekit brightness from 4% to 0%
[6/30/2017, 1:19:22 PM] [Hue] Living Room 3: light bri changed from 15 to 1
[6/30/2017, 1:19:22 PM] [Hue] Living Room 3: set homekit brightness from 6% to 0%

[ebaauw]

Another fun fact: of you set Transition Time to 0.0s, and then recall a scene that turns on 6 lights, you notice the lights turning on separately, quickly after another. With the default 0.4s Transition Time, the lights appear to fade on simultaneously.

When you set Transition Time manually (from Eve, not from a scene). It stays on the new value, until you recall a scene, or set a light state manually.

[ebaauw]

Expose Transition Time as a string?

No go. Works for setting it manually, although Eve doesn't show the value while editing (on my old iPhone 5s, which I use for testing). However, Eve won't allow me to include it in a scene.

[DJay-X]

This is so amazing just by reading your lines. WOW
When I'm at home this Weekend I definitely check things out.
But as I mentioned earlier and as I understand from the description, I now have to set in the config.json the "lights": true
But at the moment it's false and I expose the lights native from the hue bridge/app.
I have to change this somehow. Sorry I'm a bit slow on the uptake. I'm having a blonde moment :-)

[ebaauw]

That's OK, I used to be blond (back in the days when I had more fun...)

Yes, you would need to expose the lights through homebridge-hue to use Transition Time. Technically, you can continue to expose them by the Hue bridge, but each light would appear twice in HomeKit. I stopped using the HomeKit feature of the Hue bridge long ago. The only thing I miss is the feature to copy room assignments from the Hue bridge to HomeKit, every other month or so, when I need to reset my entire HomeKit configuration.

[DJay-X]

Well... The wisdom comes, the full blond hair goes. 😬 I can tell you a thing or two about it.

Okay.. so have to be brave and do what? How would I remove the hue lights from HomeKit but not the bridge? I'm a bit scared about doing this. I have 14 Lights and sometimes this was the only thing that works wehen the Raspberry with Homebridge was not working.
But I see much more and endless possibilities with your plugin. Now and the days who come.
You can admit and tell the truth, this was you plan the whole time to get me switched completely to homebridge-hue. 😉

[ebaauw]

You can admit and tell the truth, this was you plan the whole time to get me switched completely to homebridge-hue.

You found out my plan to conquer the world through homebridge-hue! Now I need a new plan for world domination ;-(

How would I remove the hue lights from HomeKit but not the bridge?

You don't need to change the Hue bridge configuration. Just remove the Hue bridge from HomeKit (in Home, hold the bridge tile with the same triangle-like symbol as homebridge and scroll down), and the lights are removed from HomeKit as well. The Hue app remains fully functional, as do any other apps making use of the Hue API.
Re-pair the Hue bridge with HomeKit to expose the lights once again through the Hue bridge.

[DJay-X]

OMG I did it. YOU did it. 😉 I removed the Hue bridge from HomeKit.
Thanks for your reassurance. Everything works well. 💡👍🏻

All lights are there and the Test Scene I created with a few lights with transition time to 349.0s switched slowly after 5 minutes to blue. Now I can configure my morning wake-up routine all in Eve and with HomeKit. This is so cool and fantastic what you created. 🏆
And my "wish" was just 3 days ago. Thank you very much.

[DJay-X]

Today homebridge did not respond anymore.
I found this in the log as the last entry.
After stop and start homebridge,
sudo systemctl stop homebridge
sudo systemctl start homebridge
everything seems to work okay. I'll have an eye on that.

-- Logs begin at So 2017-07-02 00:16:11 CEST. --
Jul 02 00:31:26 raspberrypi homebridge[512]: [2017-7-2 00:31:26] [Hue] Philips hue: hue bridge request #426: get /config
Jul 02 00:31:26 raspberrypi homebridge[512]: [2017-7-2 00:31:26] [Hue] Philips hue: hue bridge communication error ETIMEDOUT
Jul 02 00:31:32 raspberrypi homebridge[512]: [2017-7-2 00:31:32] [Hue] Philips hue: hue bridge request #427: get /config
Jul 02 00:31:32 raspberrypi homebridge[512]: [2017-7-2 00:31:32] [Hue] Philips hue: hue bridge communication error ESOCKETTIMEDOUT
Jul 02 00:31:32 raspberrypi homebridge[512]: [2017-7-2 00:31:32] [Hue] Philips hue: hue bridge request #428: get /config
Jul 02 00:31:32 raspberrypi homebridge[512]: [2017-7-2 00:31:32] [Hue] Philips hue: hue bridge communication error ESOCKETTIMEDOUT
Jul 02 00:31:33 raspberrypi homebridge[512]: [2017-7-2 00:31:33] Changed occupancy state for 192.168.178.38 to true. Last successful ping 2017-07-02T00:31:33+02:00 , last webhook none .
Jul 02 00:31:34 raspberrypi homebridge[512]: [2017-7-2 00:31:34] [Hue] Philips hue: hue bridge request #429: get /config
Jul 02 00:31:34 raspberrypi homebridge[512]: [2017-7-2 00:31:34] [Hue] Philips hue: hue bridge communication error ESOCKETTIMEDOUT
Jul 02 00:31:42 raspberrypi homebridge[512]: [2017-7-2 00:31:42] Changed occupancy state for 192.168.178.23 to true. Last successful ping 2017-07-02T00:31:42+02:00 , last webhook none .

[ebaauw]

ETIMEDOUT and ESOCKETTIMEDOUT typically indicate hickups in the network between homebridge and the Hue bridge, see issue #15. Make sure you connect the Hue bridge and the Raspberry Pi running homebridge (and the AppleTV as HomeKit Hub) by wired Ethernet, not by WiFi or Powerline LAN.

[DJay-X]

Okay, thanks @ebaauw
Configurations is the same since years. ALL WiFi.
Apple TV, Raspberry and actually all devices here at home. Except the hue bridge which is connected directly to the Fritz!Box Cable Router/Modem. Didn't had any problems in the past.
Ethernet is no Option here at home.

But as mentioned, I'll have an eye on this if there is something strange with homebridge-hue now.

[Krocko]

Hello @ebaauw i have a question. I can‘t set a Scene two times behind each other? I must use a reset Scene between? (i use the Raspbee Gateway)

[ebaauw]

Are you referring to setting a HomeKit scene in Apple’s Home app? That seems to be limitation of the app. In other HomeKit apps (e.g. Eve) this is possible.

[Krocko]

Yes, with HomeKit. If i activate a Scene with Custom transition Time and turn the light off, the Scene (this transition Time) don’t work anymore. I must bring the light to an other State (other brightness, or other color), Then the Scene is working again.

[DJay-X]

I notices that you have the room where the Transition option can be selected, has to be the first in the row of rooms. Meaning my default room where the bridge is place and transition time is set, is on top. In a Scene it is then on first place (eve App) and then the lights are following. Buy doing this, transition time is recognized ad working here.

[ebaauw]

I don't think order of characteristics in a HomeKit scene is guaranteed - it's just how the app displays them.

After receiving a notification from HomeKit that a characteristic has changed, homebridge-hue delays sending the bridge request for a light or group by 20ms (waitTimeUpdate in config.json), to collect multiple changes in a single Hue bridge API call. Transition Time is only reset 20ms (again, waitTimeUpdate) after the first request is sent.
As long as the characteristics in a scene are processed within these 40ms, it shouldn't matter in which order HomeKit issues the characteristics when recalling a scene.

By running homebridge -D, you should be able to check whether transitiontime is included in the bridge requests. If it isn't (gen1 bridge?), you might want increase waitTimeUpdate.

[tomky]

Does this work on Raspbee as well? I set the Transition Time in Eve and I can see this command in homeridge-hue message, but the light still turns on instantly.

[ebaauw]

If homebridge-hue show the correct command in the debug log, there’s little I can do here. What type of light? What happens if you issue the same command directly to the deCONZ REST API?

[tomky]

I try several configurations and find how it works. As you mentioned in previous comments, you need two separate scenes to make Hue-like wake up work: first turn the light on and set the brightness at 0%, and then set the transition time and set brightness to 100%.

I think the reason that single scene setup doesn't work is because that if the light is not on before you set the transition time, it may automatically restore your previous setup at power off, which is 100% in my default cases. So, no transition will happen.

[aguaman15]

Using Homebridge-Hue is a very cool way to add transition time in HomeKit automations, not to mention voice activation using Siri. Very cool.

Interestingly, with the addition of Siri Shortcuts in iOS 12, we can now use Siri to "natively" activate transition times in Hue light scenes created or edited by third party apps such as the Hue Lights app. I go into more detail about it here http://techheroesinc.blogspot.com/2018/11/finally-siri-supports-transition-times.html

Unfortunately, HomeKit and the Hue app still do not recognize the transition time attribute, so using scenes with transition times in automations without Homebridge and the Hue plugin is still not possible.

[ebaauw]

Thanks for the info. How does Siri tell the Hue bridge to recall the scene? Is that through a (new?) HomeKit characteristic, or does she make a direct API call to the Hue bridge?

[jerzytraczynski]

I didn't get, why do we need to turn the lights on at 0% brightness before setting the scene with transition time? Are you automating this using hb automation switches or how? :)

[ghost]

Am I right that transitiontime only works (appears as an option in the Eve app) if the Hue lights are exposed to HomeKit via Homebridge-Hue and not via the Hue bridge?

[jerzytraczynski]

From what I understand that's correct however you can expose both ways at the same time. You can whitelist the lights (in the hue bridge) you want to use with transitiontime and this way only part will be exposed, then put those homebridge duplicates into 'automation' room in HomeKit and use them for automation purposes only. pon., 30 lis 2020 o 14:33 JCHH <[email protected]> napisał(a):

…

Am I right that transitiontime only works (appears as an option in the Eve app) if the Hue lights are exposed to HomeKit via Homebridge-Hue and not via the Hue bridge? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AINHNWKWLZLH4QOBHMZIBXLSSONLRANCNFSM4DQ5DISA> .

[ghost]

cheers!