OSRAM A19 Bulb going to 100% on its own

Been having a few Osram Lightify A19 RGBW bulbs that seemingly randomly will go to 100% at various times. Been chasing this for a while now but only now today feel I got something.

This screenshot shows where the bulb is off at 8:44AM. From there the next entries are checkinterval and configure and then the bulb goes to 100% at 1:08PM

Couldn’t figure out why its doing that, but then in reviewing the item itself I noticed it has 1:08PM listed as the last time it checked for an update as shown below.

Everything else looks fine and this really is the first lead during this whole saga that makes sense as being a possible culprit.

So does anyone have any ideas or suggestions as to how to fix this? The WAF is slowly but surely fading on these things as they are also tied to notifications for possible power loss based off bulbs going to 100% level.

First question… are you using the Classic app or new app?

Classic app, new app installed but just to keep up to date on developments.

All control done through webcore, no ST automations or scenes or triggers or anything.

Control and display through actiontiles.

Ok, you can verify in the classic app or IDE all routines, webcore pistons and smart lighting rules that are associated with that device. In the Classic app, open the device and click on Smartapps in the upper menu. You can click on them to open and examine if one may be causing the issue.

Second, do you use other systems such as Alexa that could be the cause?

Sometimes, it can take some investigating to find the culprit.

We may need to look at the piston so you may want to post an image of it. Click on the green camera above the piston to produce that image.

Confirmed that it is only WebCore controlling the device and other smartapps that don’t exert control such as logging when it was on etc.


This device is controlled by a number of pistons but none of them take it to 100% level. All programmatic levels are 99%. This is done so that when it does go to 100% (such as after a power failure) it notifies me.

That first snap I posted is all the info off that device from IDE. If there is a piston (or any other source) sending the command it typically lists it there.

Whats odd to me and also the first thing that (to me) is an indication of where to look is the checkinterval/update of the device that seems to re-trigger the configure and from there it goes to 100%.

We’ve seen internally that hose bulbs can be prone to crashing which will result in the bulb rebooting, turning back on, checking for an OTA update, and triggering that configure log you see.

1 Like

Is there anything that can be done to check to see if that is the case in my instance as well?

Otherwise I am assuming that the only remedy is to get different bulbs? Or write a piston in WebCore to turn it back off if it ever goes to 100% and remove it from my power failure reporting piston.

What you describe and the logs strongly indicate that is the case in your instance.

I’m not aware of any other workarounds than what you describe unfortunately.

1 Like

Understood, thank you for the prompt reply and info!

1 Like

Just be happy yours turn on at 1pm… mine does it at 2am to 3 am.
Come and goes. Few weeks it doesn’t it but could resume any time.

My Philips never behaved that way. So I would recommend Philips. Specially as the customer service of OSRAM just doesn’t give a dime of the request I submitted.

These issues exist for years with the Osram bulbs. I am really surprised that it hasn’t been fixed yet. Many firmware updates later they still crash and reboot.

It does as well. Just did it this morning again at 4AM-ish. Have a webcore piston fixing it now though until I migrate to different bulbs

1 Like

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.