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

Got it, sorry I misread! Adding to Pollster now.

I reinstalled the device type just to be sure I didn’t mess something up since the ide seems to be really slow today. But I’m still seeing the double input for Image/icon. And the image chosen is distorted.

If you remove the “canChangeBackground: true” option from the main tile in the code, it should revert back to only an icon selection. I think that was intentional to give people the option to use a picture if they want. It doesn’t cause issues for me.

1 Like

@greg and @Sticks18, I put “canChangeBackground: true” so I can choose my own image for devices. If you opt to use it, the image format that works best is PNG with a transparent back ground. Here’s more info on how I use that:

@Sticks18, saw your message on updating the device type for fixing level change responses. I’ll update GitHub in just a few minutes and reply back here for all to know. Thanks for the fix!

All - GitHub source has been updated for the following modification:

Sticks18 - Modified to ignore unnecessary level change responses to prevent level skips.

Thanks Sticks18!

2 Likes

I remembered reading this thread. Really smart use of the image option! The wife likes the icons, so they stay for now. Thanks for updating GitHub!

Once I have a chance while at home, I’ll try to get the transition time stuff baked in. My thought is to send the wattr command when the manual on signal is received. It may not help with the initial on, but it should work until the bulb loses power again.

So, I’m new to the whole ST stuff. How do I apply this code to my setup? Even just a link to some instructions to get me started would be great. Thanks?

@kgarner It’s probably hard to find this info embedded in various threads, and as far as I know there isn’t an instruction guide yet (there definitely should be though); so here you go:

  1. Go to the developers section (link at top right of page). Click the link to check out the web-based IDE and login/create an account for the IDE.

  2. Go to the ‘My Device Types’ tab (navigation at the top).

  3. Click + New SmartDevice button on the right

  4. Choose the “From Code” tab

  5. Copy the code from the github link into this window (once at Github, choosing “Raw” button will give you just the code and can eliminate formatting and other weird copying issues)

  6. Paste the code and click “Create”. Then “Save”, Then “Publish” → “For Me” (This device type is now available to you)

  7. Now click on the “My Devices” at the top and choose one of your GE Link Bulbs.

  8. Click “Edit” in bottom left, then in the “Type” dropdown choose the new device type and click update.

  9. Repeat 6 and 7 for additional bulbs.

Enjoy!

3 Likes

Awesome! Thanks for the help. Looking forward to really digging in and having fun with this system.

My thanks to @johnconstantelo, @Sticks18, and everyone else who helped on this. This thread is so informative that I was able to get this device type up and running in no time, despite having almost no programming knowledge. Many thanks.

I updated all of my GE bulbs to this device type today. They turn on quicker than before. Previously, there was a very noticeable delay between bulbs turning on/off in my 2-bulb fixtures. They’re almost instant now. I am pleasantly surprised.

2 Likes

The device type is great, thanks for the work on this. One question I have is regarding the icon in the app now - the icon looks a little strange, lacks the white border and has pixelated “cloud” in the middle. Everything works great, just curious what the deal was with the icon.

those are the same image problems I was having and mentioned a few posts up. The problem magically went away now.

Thanks @greg, I read through your post, but wasn’t sure if it was the exact problem. So it just went away? Weird.

sorry correction. I see the issue on iOS, not android. I never remember which device I used last.

I still see the “cloud” that @B_Ferguson refers to; the darkened area looks identical to the shading on the “Group” tile icon. I didn’t mention it because it was just cosmetic.

For Groups, the shading serves a purpose, where you’re using a picture instead of an icon: it helps ensure that the white text stands out even if the picture in the background is light). Presumably, the code that was employed to allow photos to be used in lieu of icons (a nifty feature, that) brings along that shading as well.

I can’t explain the missing border, however. From a UI perspective, Smartthings seems to differentiate between tiles you can interact with and those that you cannot with the white border.

For those of you having issues with GE Link bulbs acting up, i may have just found a quick fix.

I was haivng trouble with two of mine and was doing everything not to have to remove and re-add them. I was doing every trci in the book. Power cycling things that didn’t even make sense to power cycle lol. Then i noticed that the icon for the device changed back to default.

I thought hmmmm thats weird. Thinking it could be a DB thing that could cause this i renamed the bulb. Boom it worked again immediately. Thought this was too good to be true… so i tried it on the next bulb… boom worked immediately.

Give this a try next time. Hopefully it works as well for you as it did me!

so I need to boot up the sniffer and see what:

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

message actually is. From a glance it looks like a response to a read.

I know that:

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

is a ZigBee default response and is essentially a receipt of a message and not an indication that the action actually happened.

1 Like

oh I see now.

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

is a read attribute response because you added polling, catching up now :smile:

1 Like

Now that I’m using this custom device type, I now can see the correct status of my bulbs. When there is a disconnect between the state of one of my bulbs and the displayed state, the app will not update to reflect the state of the bulb. I wish that it did the opposite. The app knows what the bulb state should be. If there is a difference between the two, I wish the hub would command the bulb to change to the correct state since that is ultimately what was intended.

4 Likes