@smwein no they do not unfortunately.
FYI to everyone… TCP makes outdoor flood lamps now. Saw them in Home Depot the other day!!
Another thing worth noting in the log is that the hues are in fact polled every 5 (or 6???) minutes. So, I would guess that it should pick up the correct state. I do turn off the hues using my own code once my wife and I leave for work.
blah...blah...
section("Control these bulbs...") {
input "hues", "capability.colorControl", title: "Which Hue Bulbs?", required:true, multiple:true
}
//blah...blah....
//Not the complete code. Just an excerpt.
def turnOffLights(){
//Turn off lights everyone is away.
def offLights = []
hues.each {
if (it.currentValue("switch") == "on") {
log.debug ("turning off : " + it.label)
it.off();
offLights.add(it.label);
}
}
log.debug "Turned off these lights: $offLights"
return offLights;
}Hi Ron, I should have stated I have GE bulbs. Right now I have 7, and on my to 10 of them fairly soon.
1 Like
Only 2 GE bulbs…unmonitored. 
GE also has outdoor flood lamps (PAR38). They also have indoor down lamps (BR30) for ceiling can-lights along with the BR15’s (standard 60 watt replacement bulbs) that are being referenced here.
At my local Home Depot, they carry the BR15’s and the BR30’s. I have 3 of the BR15’s and they are working great.
I’m disappointed that the GE bulbs get so hot, compared to my Hues and they are also quite big and don’t fit well under bedside lamp shades, but the price is good.
This may be helpful, and it was the one thing I needed:
@antman2 I also had a TCP setup and constantly lost communication to the bulbs. I didn’t quite have to 40 that you mentioned, but I did have quite a few. After testing one of the GE bulbs when they were released, I returned my entire TCP collection. Luckily, I did save the boxes. My only complaint with the GE bulbs, as others have mentioned, is the dimming. I believe the TCP bulbs dimmed a little smoother and darker than the GE. Other than that, I have had no issues…not that a bulb dimming as dark as another is an issue.
I believe the following thread has a device type that fixes the dimming as well as other issues:
I am on the other end of the boat I cannot still get my GE link bulbs to be seen by the St hub. I have the bulb right next to the hub and my router and it still does not detect via the St hardware
Have you reset the bulb? I think you have to turn on and off the bulb 3 times real fast until it blinks. Also, make sure to put the hub in include mode first before turning the bulb back on after a reset.
Zigbee firmware 1.5.4 was a manual update by special request to support?
Maybe ST hub is too close to router.
zigbeeChannel: 19
zigbeeFirmware: 1.5.4
zigbeeNodeID: 0000
zigbeePanID: 090D
zigbeePowerLevel: 254
zwaveHomeID: E236C1C3
zwaveNodeID: 01
zwavePowerLevel: 00
zwaveSerialVersion: 0
zwaveVersion: 0
I have reset the bulb to where it fades then goes back to bright while the hub is scanning for new devices. I just don’t think my hub or my router is able to communicate with this particular bulb. The bulb doesn’t even show up on my IP tables for “Wireless devices” connected (I do find my LIFX bulbs though)
The router shouldn’t communicate with the bulb as it is Zigbee, only the hub should. The LIFX bulbs use wifi, which is why they show up under the IP table.
Have you tried initiating the new device scan after the reset (your comment says while, so I wasn’t sure)? I wonder if it’s a zigbee channel issue causing interference. I thought the hub purposely chooses a channel with low interference, but maybe ST support could change it for you. My hub uses channel 14 for instance. The Zigbee documentation for the HA profile recommends (11, 14, 15, 19, 20, 24, 25), so your channel is listed, but maybe one of the others would work better for you.
I’m having a lot of trouble with bulbs either not turning on when directed or not turning off. The hub and the app seem to think their state has changed, but it doesn’t. I have about 7 bulbs in my house and each one malfunctions about once a day. This is most annoying when bulbs are commanded to turn off at night or after I leave the house and then I return to see they have been on all day, mitigating the benefits of having smart control of them to save energy.
I have a ticket open with the SmartThings support and they have said the GE bulbs aren’t officially supported right now. They suggested I reset my bulbs. I did that but that did not solve the issue. I would think this could be resolved with more two way communication between the hub and the bulbs.
I’ve been thinking about either of these options, but I’ve personally decided on the 3rd option, which is to rather replace my wall switches with Z-Wave connectivity.
For one thing it’s always a problem having a wall switch that ends up being switched off. then you can also control multiple lights with a single switch. Lastly you can also switch brands and get cheaper simpler lights while still maintaining automation.
Just my 2c. Sorry that it does not answer the question asked… I hate it when people do that. 
2 Likes
I’ve had similar problems at times with the GE bulbs, in particular getting all bulbs to respond to mass on/off commands. I think that issue lies with ST as TCP and Hue owners have had similar problems with single bulbs being missed.
From all the commentary, it does seem like the GE bulbs are particularly susceptible to interference from wifi and other 2.4 GHZ products, so maybe take a look at the Home Networking thread to see if you can better align the channels that your ST hub and wifi router use to minimize interference.
For improving the status updates, check out the device type code in this thread: Updated : GE Link Bulbs - FINALLY getting ON status after manually turning on!
It has enhancements to better update the on/off state and adds polling capability to be used with pollster. It might not fix the bulbs turning off all at once, but if you add polling, at least the app will update to show the actual status and you can remotely fix the bulbs that didn’t respond at first.
Thanks. I updated the device types. Do I also need to use Pollster for this to be effective? I don’t currently use pollster and, in looking through the pollster thread, I couldn’t determine the use cases for it.
ST approach is to send a command and assume it worked approach, so the ‘on’ status is set as part of the ‘on’ command. It doesn’t wait for a response from the device. This causes the sync problem when commands aren’t received due to interference or some other issue.
You don’t have to use Pollster, but the state will only update when refresh() or poll() is called and since refresh() is usually manually triggered, Pollster is a good option for automatic periodic updates to status, particularly for devices that don’t report in occasionally.
It’s unfortunately a flawed approach with any kind of wireless network. I will say that the GE Link bulbs definitely tend to work better with the Hue Bridge (despite being listed as unreachable) than when connected to the SmartThings hub.
I really only seem to have problems when sending large groups of commands (3 or more bulbs). I’m wondering if it’s an issue of timing between commands not being consistent. In that case utilizing the groups cluster might help to address some of the problems we are seeing.