Depending on your exact needs, there are two possibilities. Neither is 100% satisfactory, but they both work for some use cases.
One) get a socket adapter. There are quite a few of these readily available at Amazon and other retailers. Typical cost of about five dollars each. Get one that is CE or UL listed. There are two issues with these. The first is heat dispersion. Some smart bulbs are not intended to be used upside down. Chandeliers are typically not used as much as regular ceiling fixtures, and you might be OK, but is just something to keep an eye on.
Second, of course, is that the bulbs will be larger and the socket will extend them out another couple of inches and it may just look terrible. But they do work for some people.
Two) Feit makes a very nice Bluetooth chandelier bulb. Cost right around $20 each so they’re expensive. And they don’t integrate with anything else at present. No IFTTT or Echo.
However, if like me the issue is difficult in physically using light switches, this gives you control of chandelier bulbs that you can use from the tablet or phone.
It maybe possible to control them with the harmony hub, I don’t know anyone who’s tried that. If you could do it that way, then you would have smart things integration. But because they’re using their own Bluetooth mesh, I’m not optimistic.
Anyway here are the bulbs. They are using their own Bluetooth mesh, so the bulbs become repeaters to each other. That probably doesn’t matter for chandelier bulbs but I’ll just mention it.
Thanks for bringing up the Feit bulbs - they have them at my local Home
Depot. I have been reluctant because of their total lack of integration -
not sure how my partner would deal with yet another app. And, they don’t
get the best reviews. Still, as we know, there simply is no other
candelabra option available in the US. A switch is not an option right
now. So, I might give them a try. It will all depend on how they look in
the fixtures (only two sconces - so not that much of a spend - and I can
always return if they’re a fail).
And, who knows, maybe some day Feit will open up some kind of API or the ST
Hub will enable the BT antenna.
(I was actually fantasizing about some kind of web to BT bridge but
couldn’t find anything easy to work with out there).
ongoing issue - osram bulb dropping offline. I have deleted device and re- paired - no issue with that (several times over past couple of weeks)…pairs as zigbee bulb, I have tried to change device type to the OSRAM white tunable as now found in device list. Drops still. I have logs - I am seeing a lot of did not parse messages … any other trouble shooting or suggestions for resolution.
direct connect to ST Hub - only.
Support gave no indication of doing a firmware upgrade. I was thinking this as well (firmware update).
Do we have instructions anywhere for upgrade process?
I’ve got an OSRAM Lightify A19 RGBW bulb, and for some reason I’m unable to read the Saturation. It doesn’t matter if I look at it under “My Devices” in IDE, or through SmartApp code (bulbSaturation = thebulb.latestValue(“saturation”)), the Saturation is permanently stuck at 50.
I’m trying to create an app that will remember the bulb state so I can change it and return to it.
Anyone know if they all do this? Or do I need to update my firmware, or the Device Handler? Thanks!
Just a followup in case anyone has the same issue. Not sure why it didn’t work at first, but when I switched to the Zigbee RGBW Bulb Device Handler from @sticks18, it started working correctly. Saturation reports correctly, and I can control the bulb with correctly through code, which I couldn’t do before.
So at one point I had this set up and working, but it stopped responding correctly to ST. So I deleted the thing and all associated smartapps, reset the light bulb, and now I can’t get it to connect again.
Does anyone know if there is some additional device cache I need to clear with ST to make it find the light again?
Hi, new to Smartthings, but enjoying my recent experiences. Unfortunately, I purchased Osram Lightify A19 RGBW bulbs and LED RGBW flexible lighting this week and installed them. I was hoping to be able to use IFTTT to have the lights notify me (change color) of incoming text messages, but have been unable to find a way of doing this.
I just read an article of a user who was trying to do the same thing I am, and was unable to do so. I was hoping this support board might lend me some ideas she might have overlooked. Do I need to buy a Philips Hue Bridge in order to do what I want? Or a WeMo hub? Or do I need to return them and go with Philips Hue? Thanks!!!
Here is the article I was referring to: http://homealarmreport.com/using-osram-lightify-led-smartthings/
I’m not sure if that is something you can do. You’d have to find a way for ST to read your notifications and then have that as an action. That is an interesting idea. I’ll look around and see if something exists.
I would set up Ifttt so when an SMS comes in it turns on a virtual switch in ST, Then use Core so when that virtual switch is turned on it, Core then turns on the light you want in the desired color.
I have perhaps a similar issue, that I cannot set a HSL value in CoRE and get my Osram bulbs to accept the commends. But I’m also using the "official ZLL-DH.
So I need to understand which DH from @Sticks18 to use for what, because I have a mix of whites and colored bulbs.
So should I use this “Lightify RGBW with Color Temp draft.groovy”-DH for all my colores bulbs?
and this “Lightify_Bulb_v2.groovy” for all my white bulbs?
I have changed just a few RGB bulbs to “Lightify RGBW with Color Temp draft.groovy”-DH.
When I change all the bulbs to a color, it works fine for all.
But when I try a different Piston for setting a color temperature it does not work for the bulbs with this “new”-DH.
In Live Log it says the bulb already have that temperature set, so it will skip the command.
“Preventing execution of command [Køkken Spisebord 2].setColorTemperature([2703]) because current value is the same”
So it’s like the bulbs with the nex DH doesn’t report back what color/temp it actually has?!?
Short issue: In CoRE I cannot change from a color back to using a white temperature when using Sticks DH.
Observation
The official “ZLL RGBW Bulb”-DH has the following capabilities: switch, level, hue, saturation, colorTemperature
When I change to Sticks-DH I get one more capability “colorMode”.
When I change the bulb to a color, “colorMode” changes from “White” to “Color”.
My guess is when I then want to change the bulb back to a temperature, CoRE checks that the Temperature is already set to the same, and therefore doesn’t execute the command, but the “colorMode”-variable remains being “Color”.
So I think the issue is the “colorMode” capability/variable is not being switched to “White”, when setting a setting a color temperature.
I dont know if that is a CoRE update or a DH-update or a combinations, if you agree in my observation.
But we probably need @Sticks18 to tell us a but about the “colorMode”-variable.
Side note: This is the Live Log:
“Preventing execution of command [My Bulb].setColorTemperature([2704]) because current value is the same”
Another observation: If the temperature was set to 2703 before, and I then change CoRE to setting 2704, then it works both because CoRE executes the command AND because it then set the “ColorMode” to White.
So I see 2 solutions (you probably can see more):
Option in CoRE to execute the command even if the temperature is the same already (that way the “colorMode” will also be set it seems)
Option in CoRE to set the “ColorMode”-variable (Color/White), or CoRE should do that it self when setting a temperature.
It depends how the “colorMode” acts in the DH.
Hi Simon, you should have the same issue with the ZLL-RGBW DTH if it was working for you. The bulb itself stores both a set of color values using hue/sat and a color temperature value. It then uses an attribute “colorMode” to determine which set of attributes determines the coloring of the light it produces. That’s why I incorporated it into my DTH. That’s also why the official DTH doesn’t give any indication whether it’s showing color light or a shade of white, it never checks (it’s also because the official DTHs try to maintain consistency across devices so lights are all similar, which is a good thing from a user experience standpoint; but it’s also why we rarely get the more advanced features of devices).
An option could be to set the ST stored attribute for colorTemp to 0 when colorMode is “color” and vice versa for hue/sat when colorMode is “white”. That way CORE could send any value for the opposite mode and it would work. Those attributes would only be fixed locally though, the bulb would still report back the actual values it’s storing. We’d have to constantly correct or ignore depending on colorMode.
Hi, I have a few of these bulbs, Osram LIGHTIFY CLB 40 E14 LED, 2700 - 6500K.
But they start not responding which I have read its a bit common for sram bulbs.
My question is, I have installed these through the hue bridge, is that the correct way to approach it with these bulbs? or am I better off having them linked directly through smartthings hub? If so, anyone know which device handler I should use with these? thank you very much in advance…
I’m not aware of not responding being an issue with the Osram bulbs. (It’s an issue with GE link bulbs.)
Rather, the issue with Osram bulbs has been that when they are connected directly to the SmartThings hub they are supposed to act as zigbee repeaters, but they appear to drop some of the messages they are supposed to be repeating, which causes other devices, particularly zigbee sensors, to not be able to communicate with the hub because the Osrams are dropping the messages. Moving the Osrams to the hue bridge or removing them all together then causes the sensors to start working correctly again.
(Not everyone has this problem because it depends very much on the exact specifics of your zigbee network. If there is another zigbee repeater in the same zone with a stronger signal, like a plug-in device, then the sensors will be using that instead of trying to use the bulb so you might not see any problem at all.)
I’m not aware of any situation where taking the Osrams off the hue bridge and connecting them directly to the SmartThings hub would make things better in any way unless one of the recent Hue updates means the bridge doesn’t like them anymore.
But most people have been going the other way to avoid the bad repeater problem.
Thank you, my bad explaining, sorry.
They do respond at first, but in a few days I can turn then on / off, but Its stuck on either turningoff or turningon, they dont change status to on or off.
Any solution to this?
Should I use the standard device handler they are given through the hue hub? Which in this case is: hue white ambiance bulb.
Or is there maybe another device handler made for this?
Thanks…
