Osram/Sylvania Lightify (it works)


#548

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!


#549

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.


(Cole Gleason) #550

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?


(Michelle) #551

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/


(Garrett Snelling) #552

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.


(Bernie H) #553

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.


(Simon) #554

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?


(Simon) #555

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?!?


(Simon) #556

@ady624 and @Sticks18, can you help look into this please.

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.

Thank you in advance


(Simon) #557

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):

  1. 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)
  2. 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.

(Scott G) #558

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.


#559

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…


#560

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.

@Sticks18 might know more.


#561

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…


(Andrea Bianco) #562

There are specific device type handlers for OSRAM bulbs. I have some on the specific Osram DTH and other on the more generic Zwave white color temp DTH… I have played around with various DTH’s but still have these bulbs intermittently become unresponsive, although it is better than about 6 weeks ago.


( I hate Mondays) #563

In the piston’s main page, disable command optimizations and try again please


(Simon) #564

Bingo, that did the trick :slight_smile:

Thank you very much


(Simon) #565

Hi Fredrik
I have several/many Osram bulbs.
On few occasions (very few) I have experienced that in a group of 6 spotlights, one would not respond to commands all of a sudden. The 5 other would turn on and off as normal, but not the 6th one and was just “stuck”.
I did not dig more into it, I just turned the power switch off and on again, and then it “reconnected” and worked fine again.
Just my 2 cents of experience.

BTW, I bought the Osram bridge/hub, with the only purpose to update firmware, I assume you have updated yours to newest firmware. (I have not read your previous posts sorry)


(nicholas) #566

I have used your device handler and works much better than the generic zigbee rgbw.
I am using the app CORE and when I choose to set color, I am not able to choose the white channel.
Even if I choose just plain color White, it’s still a white created by RGB mising.

Would you have an idea on how to control the dimming, on/off channel of the white through Core?
Thanks


(nicholas) #567

Ah just found in CORE there is an option RGB/W that I can choose WhiteOn or WhiteOff. My mistake. Tested and works like a charm