Updated : GE Link Bulbs - FINALLY getting ON status after manually turning on!

Devices & Integrations
1

There’s been a few updates to this thread, so please make sure to keep up with the latest posts at the bottom!

Sorry for starting another thread on these bulbs, but this warrants a new thread (I think). This thread provides the device type for the GE Link Bulb modified by community members specifically to allow ST to receive the bulb’s “ON” status when it’s manually turned on by a switch - not the app.

Thank you to this community for all the help, especially @Sticks18 for the code snippet that did the trick. This was a shortcoming to address between ST and the bulb, and this community did it. The device type code below works for the several bulbs I have. Now whenever someone in my house turns on a lamp with one of these bulbs ST’s app correctly shows the status of the bulb - yea!

https://github.com/constjs/SmartThings-Devices/blob/master/ge_link_bulb.device.groovy

19 Likes
2

@johnconstantelo Thank you for sharing work good for me. Thanks again for all you do for the Smart Things community

3

Sorry for not looking at the before and after code, but in a few words, what did you add to get the state?

BTW, good work!

4

No worries @wackware,and thanks. The parse was modified to also look at case “1000” and case “1001” that the stock device type wasn’t checking for in the catchall string.

Once debug and trace info was opened up to see everything possible, Sticks18 picked up on the fact the device passed different values for when the app turned on the bulb vs manually turning it on: (hopefully I got that right)

ON via the app:

trace catchall: 0104 0006 01 01 0000 00 E68D 00 00 0000 0B 01 0100

ON manually (refreshed as well):

catchall: 0104 0006 01 01 0000 00 E68D 00 00 0000 01 01 0000001001

5

If I’m not mistaken, @urman found an issue with dimming because the hex value was not padded with zero and someone had a workaround. Does your device type include this workaround or am I thinking about some other issue?

6

Here is the conversation:

This may just be for on/off dimming.

7

Edit: Code is there, see my next post.

8

@beckwith, actually the code was there to address a smooth transition, but the parameter value for level was 0000. I updated the code to make it 1500, and tested to see that it works, and it does transition smoothly. Now, the issue with anything below 7 is still there, for now.

9

This is right. The problem was that the response message format was different when the bulb gets an ‘on’ command (default response) versus the ‘refresh’ command (read attributes response). This fix should help correct the bulb state when it gets out of sync by getting the right on/off state when refresh is called.

I don’t think it fixes getting status when physical power is off, or automatically updating to ‘on’ when a physical switch turns it ‘on’. It will update correctly to ‘on’ as long as refresh is called though. I’m still working on these scenarios.

Anyone make progress on the setLevel stuff? It seems to bounce around because it gets multiple responses.

1 Like
10

My take: I’m honestly happy with the fact that a $15 bulb is controllable at all. It makes me even happier that this wonderful community is making it better. Keep it up, y’all. Nice work.

11

seems to work great…one question.

When I turn on the light I can manually adjust the dimmer and it smooth transition to that level.

Can we have the bulb turn on from 10% and transition to 100% instead of just clicking on to 100%?

12

Hi @sjones0812, I know my GE Dimmer Switches do that when I turn them on, but I’m not sure if that’s the code or the physical device doing the transition. I’ll poke around and see how that works.

13

I didn’t mention it in my first post, but Polling is also included in the code. If you use the Pollster app, then these bulbs will be selectable.

1 Like
14

This is a huge step forward. Well done @johnconstantelo

Is this device type able to handle when the bulb is switched off manually too? Can’t wait to mess around with this tonight.

15

There was some work done to try and fix that, but we haven’t gotten it working yet because the bulb loses the setting when turned off at the switch. Hopefully soon.

16

@NorCalLights, no unfortunately. If this bulb could do what the MIMOLite does when losing power, it would be great.

17

Nice fix. Hopefully it can be rolled into the official devicetype @urman…

I am amazed at these bulbs, cheap, easy and a great learning experience for lights in ST / Zigbee.

Now if we could just get a zigbee topology map from ST to see if these things are actually extending zigbee as a router, or just acting as endpoints even though they support routing…

3 Likes
18

Here’s a fix for dimming below 7. Thanks to @kelchm for suggesting the hex() function. I just tweaked his code to transform the level percent from ST to a value the device can use before sending it to the hex() function. I couldn’t test it, but it should work.

    def setLevel(value) {
        def cmds = []
    
        sendEvent(name: "level", value: value)
        value = (value * 255 / 100)
        def level = hex(value);
        cmds << "st cmd 0x${device.deviceNetworkId} 1 8 4 {${level} 1500}"
    
        log.debug cmds
        cmds
    }
3 Likes
19

Excellent, thanks @Sticks18! As soon as I can get out of work I’ll test at home and update the device type code I posted above.

1 Like
20

I installed code and pollster; however, I only see my door locks as select-able.

Isn’t pollster only for z wave devices?