Osram/Sylvania Lightify (it works)

I’m on android, the slider shows 0-100 haha must be that

I guess stick to v1 for now. I just updated them to correct an issue with dimming below 7.

@Jim @juano2310 any ideas why the custom slider range wouldn’t work on Android? Maybe just a bug? Thanks for the help!

Hi Scott,
Definitely a bug. Do you mind reporting it to support@smartthings.com?
Thanks a lot!

Try force closing and clearing cache the ST. Maybe the dashboard just needs to reload with the new code. If not, report to ST and see if they can help.

So I’ve encountered some weird behavior using the above devicetype/bulb and have no idea how to fix it. If I have it set to turn on with motion, that works just fine. However, if I have it set to turn off after motion stops, regardless of delay or no delay, it won’t even turn on. As soon as I remove the turning off when motion stops, it turns on just fine. I’d like it to do both, otherwise it’s kind of useless to me.

As an aside, using the turn off after motion stops radial button from within the turning on with motion menu is what causes this. The separate Turn off with motion stopped menu actually does nothing (IE it won’t turn off still, almost like it wasn’t enabled).

This is curious because my hue lights operate just fine.

By any chance are you doing this with a Hello Home Action? The default time range for motion is bizarre, I had several unexpected results until I figured out that was the reason. Also, there’s an undocumented “feature”: a HHA won’t run at all if you’re already in the mode that HHA changes to. Both are discussed here:

If you’re not using a Hello Home Action, these don’t apply,but just in case…

For anyone having issues connecting with these. follow the procedure but it will never say it’s connected in the SmartThings app. wait for the bulb to blink 3 times then blink 3 times again. It’s actually connected, but ST borked it. go back out all the way and then you will see a blue 1 with a circle on your PLUS, you have a unconfigured item, it’s the bulb. now finish the configuration.

Hoping to verify they actually do repeat ZHA signals. Nothing has any solid proof that they do, and the documentation does not say it does.

I was skeptical too, but a couple of community members have talked to the manufacturers and gotten the repeater verification.

However, if you connect through a Hue bridge, they probably won’t repeat your ZHA device messages because they think the bridge is their controller, not the hub.

updated to add

Osram marketing materials do say they’re using the ZHA standard:

https://www.sylvania.com/en-us/newsroom/press-releases/Pages/OSRAM-SYLVANIA-Launches-LIGHTIFY-Connected-Lighting-Portfolio-at-2015-International-CES.aspx

connects to LIGHTIFY devices (up to 50 per each Gateway) via the ZigBee Home Automation standard. Initial products include a true A19 Tunable White 60W replacement LED bulb which delivers over 800 lumens, unlike other 60W

See also the following discussion, which says that Osram confirmed that the lightify bulbs sold in the US are ZHA profile while the ones sold in Europe are ZLL profile, and they can send a firmware update to shift from one to the other.

This is just Internet discussion, so would need to be officially confirmed, but it’s from the everyhue forum with generally reliable sources:

http://www.everyhue.com/vanilla/discussion/1766/third-party-hardware

1 Like

Well Osram bulbs doesn’t repeat generic ZHA signals as I still have problems with my door sensors at that end of the home. I installed 2 Osram Lightify lamps in two staged locations to give it the best chance of having a better signal path. The lamps work just fine and are very reliable.

I open and close the garage door, or the exterior garage door and nothing. 20 to 30 minutes later I get the open and close alerts. then it works fine for an hour until I go to no alerts at all for hours, acting exactly the same as without the osram bulbs in place.

1 Like

I’m sure that’s frustrating! Routing corrections can be really tricky. After you had the lamps in place, did you unplug the smartthings hub for 15 minutes and then plug it back in? You need to get the garage door to know that it has new neighbors or it won’t use the repeaters. Unplugging the controller (in this case the hub) and leaving it off-line for a while will cause all the devices to look for new routing information.

Once you do you plug it back in it’s not like you see in instant improvement. It takes a while for the routing table changes to propagate. Typically we would leave everything in place and come back the next day and check them to see if we were getting better routing.

Also, you have the Osram lights connected directly to the hub, right? Not through a bridge?

You can also try try taking device that you know repeats, like a plug-in module or the first generation smartthings motion sensor (on USB power, it won’t repeat if it’s on battery) and put it near where you want to put the bulbs. Again, unplug the controller for 15 minutes, plug it back in, and wait to check QOS improvements until the next day. If you don’t see any improvement with a known repeater, the bulbs aren’t going to be able to help either.

Then the problem is likely either a bottleneck, local interference, or maybe a bad end device.

FIXING BOTTLENECKS

You might have a bottleneck somewhere on the network. It could happen, depending on the order in which you added devices. Because zigbee devices choose their own parents based on signal strength, it sometimes happens to many devices try to pick the same parent, and the network becomes inefficient.

One way to fix that is to power off not just the hub but all your zigbee devices. You not going to have to rejoin them to the network, just unplug them or kill the power on that circuit.

Leave everything off for 15 minutes.

Now plug the hub back in and leave it on for five minutes.

Now return power to all the mains-powered devices, beginning with the ones closest to the hub and working out.

Again, be patient. Check the next day to see if you got visible message chain improvements.

Well, those are just some things to try that don’t require specialized equipment. Good luck!

I’m re-posting here since this thread has the most Osram Lightify users.

I’m using the Osram Lightfiy Tunable White bulb. The Osram Lightify android app has this neat feature of changing the default dimmer level and color temperature to the bulb. So, when the bulb is power-cycled, it retains this setting instead of using the default dimmer level of 100% and color temp or 2700K. However, since I am using the bulbs with SmartThings, I have to reset the bulbs to pair them to the ST hub. From the SmartThings app, I don’t see such a feature to change this default dimmer level and color temperature setting.

Question: Is it possible to set the default power-on settings for the bulbs using the SmartThings app?

1 Like

In my experience the color temp retains it setting after on/off cycles, so you should be ok with that. I do get annoyed that this bulb defaults to 100% when turned on. It seems to be how Osram implemented zigbee dimming into the bulb. Usually on/off doesn’t impact the dim level, which is why “on” returns to the previous setting.

I think we can write this into the device handler for the bulb. If they don’t have the necessary zigbee features enable, we can always use a state variable. I’ll try to work on it sometime soon.

If you have the Lightify gateway, use it to update to the latest bulb firmware. It fixes that turning on at 100% thing.

Here is an update. I went out and bought more osram lightify bulbs and tried everything to fix my ZHA network problems. No dice as they just do not re-transmit ZHA traffic and act as generic ZHA repeaters. no matter how many times I tried the different tricks to “heal” the network.

I bought 2 smarthome light switch cubes, installed those and did the 15 minute hub reset plus I restarted all my door sensors.

Instantly I had all my problems solved. no more wierd problems from that end of the house on sensors. So my personal experience is that Osram Lightify might be ZHA, but they do not repeat ZHA signals from devices that are not Osram brand and will not help your Zigbee network health.

I really hope that smarthub 2.0 give us some real tools for troubleshooting a ZHA and ZLL network. because right now the only thing we have right now is empty hope and possibly small animal sacrifice to ancient long forgotten deities.

1 Like

Good to know, thanks for the report. I’m glad the other repeaters solved the problem.

Hi Scott,

Just to clarify that when I mention power-cycle the bulbs, I meant switching it off like in a normal light switch, i.e. there is no power to the Lightify bulb. Then, when you power back on, the bulb goes back to the “default setting”, which is 2700K and 100% level.

When using the bulbs with the Osram Lightify Gateway (http://www.amazon.com/gp/product/B00R1PB2T0) and the Lightify Android app, you have the option to change this “default setting”. That means a way to program into the non-volatile memory of the bulb. This is what I need when I use the bulb with the Smartthings hub.

The other possible way may be to integrate between Smartthings hub and Lightify Gateway, similar to what it is right now between ST hub and Philips Hue bridge, but this is not supported.

Thanks.

I have the RGB bulbs (which i love) and run into the same (but different) issue after setting any colour. If you want to return to ‘warm white’ after a using any colour you have to use the wall switch to switch off / on again. Otherwise if you set the colour picker to ‘white’ it goes a very cold white. It would be great if in the device type you had a ‘default’ light state to return it to the rather nice warm white.

Is anyone else using the RGB bulbs and figured a way round this?

thanks.

Edit - I just went to try and create a custom device type to answer my own question and noticed that these were picked up automatically as Zigbee Hue Bulb’s - not Osram Lightify RGB bulbs… there isnt actually a device type for Osram Lightify RGB - only the white tunable, strip & spot light… thought this might interest some people - i wonder how different the hardware is to an actual hue bulb given the price difference & no need for Hue hub :smile:

In the standard Zigbee clusters there is no way to set a “default” for color temp. There may be a way to set the default level, but I’m not sure if it would be in non-volatile memory or not. Most likely this is implemented in a special manufacturer specific cluster FC0F, which would take quite a bit of digging to discover unless someone can get the info from Osram directly.

I might have free time this weekend to dig a little.

1 Like

For one thing Osram labels their bulbs as RGBW with distinct mention of white color temp from 2,000-6,500K. That might mean that you can send the bulb a color temperature command and it will switch to “white” mode to give the range of white including warm white. If you’re a tinkerer, you could copy over all the colorTemp code from the Tunable White devicetype. Then you’d have the color picker and a separate “Color Temp” slider.

Try this device type. No idea if it will work, but using the new color temp slider might bring the bulb back to a range of white. So after you’re on “red” or something, try sliding the color temp piece to 2700.

1 Like

Will report back how far i get - great suggestion @Sticks18 !!

hopefully i get some time this evening.