GE Link - Turn On/Off with Dimming over 1.5 seconds?

Hi there,

I think this has been answered a few times before so if so, I’m sorry for the duplicate.

Overall, my brother and I are looking for a way with the GE Link lightbulbs so that they can be turned on or turned off using the dimming feature but over a period of 1.5 seconds and not be turned on to an instant dim level of say 50%. So for example…

  1. The motion sensor no longer detects motion so it begins to turn the light off starting at 100%
  2. 400ms later the light is dimmed to 75%
  3. 400ms later the light is dimmed to 50%
  4. 400ms later the light is dimmed to 25%
  5. 400ms later the light is turned off

From all my research gathered from reading the multiple posts on here, I’ve read the following…

  • Hue lightbulbs have a built-in “transitionTime” property which allows this to happen (although $60 a bulb)
  • SmartThings hub doesn’t yet support the “transitionTime” property and uses a default of 400ms instant
  • GE Link lightbulbs don’t have the “transitionTime” property so it’s not possible?
  • Some say it’s possible, others say it’s not possible

I’ve seen a few code examples but slightly unsure how to start to use them, as some as listed as “app” code and others as “device type” code so slightly confusing since we are just starting out!

I’m pretty sure though from reading other posts that in the end, I think I will have to create another “device type” maybe based on the “GE Link” device type which already exists but change the code maybe to incorporate this “transitionTime” property if it’s possible or code it such that it mimics a transition time from say setting the bulb from 100% to 75% and vice versa.

Finally a few of the links I have bookmarked to try to help solve this issue are listed below however I don’t think they are actually relevant to my question but I thought they might be a starting point I guess…

Any help or small tutorials are greatly appreciated, thank you all!

Welcome! I’d check out this thread for the GE Link bulbs. There is an improved device type, and post 51 or so has step by step instructions for adding the new device type code to your bulbs.

In general, the device type code in that thread will use transitionTime when changing the dim level, so a command for setLevel(75) would slowly move the dim level to 75% from wherever it started (1.5s transition time from 0-100%). This code does not use transitionTime for On/Off commands, so if you just tap the icon to turn on, it will move directly to the last dim level. That is controlled by a transitionTime attribute, but we are having trouble getting it to stick. Not sure what use cases you have in mind, but if you always use setLevel() even for on/off (ie setLevel(99)/setLevel(0)), you will get the slow movement you’re looking for. (Of course physical state changes via a wall switch will turn the bulb on/off instantly as well.)

Awesome! Thanks Scott for the quick feedback.

My brother and I will definitely take a look as soon as we can!

Basically, my simple use case is just a SmartThings motion sensor and GE Link lightbulb (I have a Hue lightbulb but we both have the GE Links so to ease confusion, we are both just using the GE Link bulbs haha). When any motion is detected, the lightbulb will gradually turn on from 0% to 100% over 1.5s, and when there is no longer motion detected, the lightbulb will gradually turn off from 100% to 0% over 1.5s.

We will rarely ever use the icon to turn it on/off manually using the app or rarely even use the wall switch to manually turn it on/off, so it should all be 100% automatic with no user interaction! :smile:

I will let you know on any updates! Thanks a ton!

Hi Scott, so I tried the new device type and here is what I found so far…

I have noticed that if you drag the slider for the lightbulb in the app that it will slowly dim the lightbulb which I would assume is using the setLevel defintion/function of the device type called whenever the event “switch.setLevel” is created which passes the new dim level to be set.

However when setting up an action for “Turn on with motion”, there is no way in the app under the actions section to say “use the setLevel” code or aka “Dim over Time” to dim over 1.5s instead of the ST default code which I will assume uses the device type code to create a “switch” event with an instant value of just “on” or “off”.

Do you think this means I have to modify the device type code to perhaps hardcode it to instead of creating a “switch” event with “on” value, it creates a “setLevel” event with a value of 100 and instead of creating a “switch” event with an “off” value, it creates a “setLevel” event with a value of 0.

Noting that if I hardcode it by replacing the instances of “switch” events with “setLevel” events then that will change the whole functionality of the lightbulb used at any time.

What do you think as a suggestion?

You are exactly right as to what is happening.

I don’t have any motion sensors, so I don’t know what options are available in SmartApp form for them; but I can think of a couple of options

1: Use a SmartApp that will set the dim level based on motion. When motion detected set dim level to 99. When motion stops set dim level to 0. If you search the SmartApps on this community and/or in the IDE, you can probably find one that sets dim level based on motion. This would minimize disruption to the device type.

2: Do as you mentioned in your post and edit the on() and off() functions to use a level zigbee command. This wouldn’t affect how ST sees or interacts with the device. It would just use a different command to the bulb when on/off commands are received. Basically you would just change two lines of code.

In the off() function you would replace line 183
"st cmd 0x${device.deviceNetworkId} 1 6 0 {}" with this “st cmd 0x${device.deviceNetworkId} 1 8 4 {00 1500}”

In the on() function you would replace line 174
"st cmd 0x${device.deviceNetworkId} 1 6 1 {}" with this “st cmd 0x${device.deviceNetworkId} 1 8 4 {fe 1500}”

The only thing you would lose by going this route is that normally the bulb will return to the last dim level when turned ‘on’, but with this change the bulb will always go to full brightness when turned on.

Note: I didn’t test the code suggestions, but they are pretty straightforward. The only thing I’m not certain of is the payload formats at the end in {} since we usually have a variable instead of 00 and fe. They should be hex values for 0 and 255 respectively though. The 1500 tells it to transition over 1.5 seconds.

Good luck!

I decided to go with option 2 since we would rather have it always dim on/off after 1.5 seconds every time (except for the wall switch toggle of course)!

When I replaced the existing line of code with yours…

  • In the off() function, it is working perfect and dims to off after 1.5s!!!
  • In the on() function, it is not working at all and just instantly turns on without any dimming at all. :frowning:

So I tried to do a bit of research and troubleshooting as to why, and came to the “hopefully right” conclusions…

  • Previously in the on/off fns, the “1 6 0” or “1 6 1” after the deviceId meant that it was basically sending only an on/off command to the bulb where the last 0 is turn off and last 1 is turn on (no dim possible with this command).
  • In the new code with the “1 8 4”, the only part I recognized was that the 8 stood for a transition or dim level change instead of a standard on/off change.
  • In the old code, the braces aren’t used but are of course still required, but in the new code the braces are used so I tried finding the “parameters” which could be specified inside the braces and couldnt so maybe I was looking in the wrong spot.
  • I do know however, with your help that the first parameter is the dim level to be reached (00 = 0 or 0% off, and fe = 254 or 100% on) whereas the second parameter is the time to reach that dim level (1500ms = 1.5s).

With that in mind, I could only think that the possible issue might be that turning the light on always seems to start at 99% so dimming wouldn’t work regardless from 0% to 99% since it’s already at 99% when it’s being turned on. Maybe there is even another section of code to be modified. I thought however that the previous bulb dim level would be saved when the light gets turned off after no motion is detected so if it dims to off (0%) then when turning the bulb on with motion it would start at the last dim state which would be the 0%.

I kinda figured the off() fn will always work because the bulb is already in an existing dim level state on being already on, say 50%. So that should always work since the light is already on, it then simply dims to off after the 1.5s no issues!

I guess I’ll still try messing with it to see if there is anything I can do to fix it.

For references I went to the following site…

Still very new at all this but hopefully learning a bit more as I dive deeper with the time I have available! :smile:

You got it well broken down. Here’s some added info for you to understand what the code is doing…The way Zigbee works is via control clusters for specific functions. 6 is the on/off cluster, so we use that to send command 0 = “off” and 1 = “on”. No payload is necessary. 8 is the level control cluster, so we use it to set the dim level. 4 is the command for “move to level with (on/off)” and its payload is level and transitionTime.

When I used the code for a test bulb, it did transition for both ‘off’ and ‘on’. It was less noticeable for ‘on’. The bulb doesn’t start producing light until about 5%, whereas it can dim all the way down to 1% once on. It’s also tough to tell the difference once the bulb hits about 40% or so and the higher brightness settings.

Try increasing the 2nd payload number to 2500. The bulb can handle it and it really makes a nice, slow change that you might prefer.

Here is a better zigbee reference that I used often in trying to understand the code and these bulbs. Might be more in depth than you want/need, but I found it helpful.

I should clarify something on this. The transitionTime parameter is always in relation to a change from 0-100% or off to full brightness. So the 1500 means a movement from 0% to 100% will take 1.5s. If the bulb starts at 50% and you tell it to move to 100%, it will only take half that time or .75s when you use 1500 as the parameter.

Yup yup, thanks for the clarification! :smile:

Ended up finding that out when messing around with the 1.5s to off with starting at 50% since it only took the .75s!

With changing the 2nd payload number to 2500, we can now notice a slight difference, but still a difference, when the light bulb turns on so that works for us, it also makes the bulb turning off better/smoother as well like you mentioned so thanks a ton!

Only other issue I’ve really seen at this point is that when it actually ends up turning off, it actually flashes again (on then off quickly and briefly) but I think it was mentioned as a caveat in the other thread with the new device type though.

Also with using the new device type, the icon for the lightbulb is messed up as shown in post 53/54 of the other thread, but I think that’s still an issue as I didn’t see it get resolved in the thread besides someone saying it magically fixed itself which it didn’t on mine after numerous app/phone reboots but ehh.

And thanks a ton for the docs on ZigBee Cluster Library!

@mxrugg, I think the issue with the icon is more related to ST’s app. I tried the “renaming” trick that was suggested and it worked for me. For some reason (before applying the new device type), I had a couple bulbs that worked perfectly with the the icon I selected (the same icon in the on and off state), but then I also had a couple bulbs that just would not. Those that kept my selected icon for just an on or off state are the ones I renamed and then I was able to keep the icon consistent.

I’m assuming this is just in the app that the icon flashes, and not the actual bulb turning on then off? This should be an easy fix if it’s just the app icon. In both the on() and off() functions change the state.trigger = “on/off” to state.trigger = “setLevel”. And also change the line in the on() function state.lvl = “00” to state.lvl = “fe”. Since we’re using the move to level command, we get different responses from the bulb and this helps us focus on only the right ones.

It’s not messed up, but it looks funny because it allows you to use a picture as the background (look in the preferences section for that option). @johnconstantelo added that to the bulb, so you can use his trick to show device names (see link). To get rid of the pixelated cloud, you can remove canChangeBackground: true from line 48 if you want.

Ahh ok, thanks a lot guys, when I get a chance i’ll try out the fixes/suggestions you mentioned!

No problem, glad I could help in any way. Happy New Year!

At first I thought it was the lightbulb but it must just be my eyes since I took a slowmo video and watched it over and over and it turned out to be the flash when it goes to completely “off” that fooled me haha. Sorry about that.