I’ve had this issue over the last few weeks, two bulbs (both A60s) in particular turning themselves on at odd times with no apparent trigger. Has anyone else noticed this on their systems?
Got some logging from the IDE, my brain is shot right now so if anyone can interpret what is happening I’d be very grateful. Entry prior to this last power on is at 18:45, two minutes later it powers back on…
18:47:55: debug [name:level, value:100]
18:47:55: debug description is read attr - raw: B37A03000808000020FE, dni: B37A, endpoint: 03, cluster: 0008, size: 08, attrId: 0000, encoding: 20, value: fe
18:47:55: info DID NOT PARSE MESSAGE for description : catchall: 0104 0008 03 01 0040 00 B37A 00 00 0000 07 01 00
18:47:55: trace zigbeeMap : [raw:0104 0008 03 01 0040 00 B37A 00 00 0000 07 01 00, profileId:0104, clusterId:0008, sourceEndpoint:03, destinationEndpoint:01, options:0040, messageType:00, dni:B37A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00], clusterInt:8, commandInt:7]
18:47:55: debug description is catchall: 0104 0008 03 01 0040 00 B37A 00 00 0000 07 01 00
18:47:52: info DID NOT PARSE MESSAGE for description : catchall: 0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 1100
18:47:52: trace zigbeeMap : [raw:0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 1100, profileId:0000, clusterId:8021, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:B37A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[11, 00], clusterInt:32801, commandInt:0]
18:47:52: debug description is catchall: 0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 1100
18:47:52: info DID NOT PARSE MESSAGE for description : catchall: 0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 1000
18:47:52: trace zigbeeMap : [raw:0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 1000, profileId:0000, clusterId:8021, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:B37A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[10, 00], clusterInt:32801, commandInt:0]
18:47:52: debug description is catchall: 0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 1000
18:47:51: debug [name:switch, value:off]
18:47:51: debug description is on/off: 0
18:47:50: info DID NOT PARSE MESSAGE for description : catchall: 0104 0006 03 01 0040 00 B37A 00 00 0000 07 01 00
18:47:50: trace zigbeeMap : [raw:0104 0006 03 01 0040 00 B37A 00 00 0000 07 01 00, profileId:0104, clusterId:0006, sourceEndpoint:03, destinationEndpoint:01, options:0040, messageType:00, dni:B37A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00], clusterInt:6, commandInt:7]
18:47:50: debug description is catchall: 0104 0006 03 01 0040 00 B37A 00 00 0000 07 01 00
18:47:48: info DID NOT PARSE MESSAGE for description : catchall: 0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 0E00
18:47:48: trace zigbeeMap : [raw:0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 0E00, profileId:0000, clusterId:8021, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:B37A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[0E, 00], clusterInt:32801, commandInt:0]
18:47:48: debug description is catchall: 0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 0E00
18:47:48: info DID NOT PARSE MESSAGE for description : catchall: 0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 0D00
18:47:48: trace zigbeeMap : [raw:0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 0D00, profileId:0000, clusterId:8021, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:B37A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[0D, 00], clusterInt:32801, commandInt:0]
18:47:48: debug description is catchall: 0000 8021 00 00 0040 00 B37A 00 00 0000 00 00 0D00
18:47:46: trace zigbeeMap : [raw:B37A0303000A0100002000, dni:B37A, endpoint:03, cluster:0300, size:0A, attrId:0001, result:success, encoding:20, value:00, isValidForDataType:true, clusterInt:768, attrInt:1]
18:47:46: debug description is read attr - raw: B37A0303000A0100002000, dni: B37A, endpoint: 03, cluster: 0300, size: 0A, attrId: 0001, result: success, encoding: 20, value: 00
18:47:44: trace zigbeeMap : [raw:B37A0303000A0000002000, dni:B37A, endpoint:03, cluster:0300, size:0A, attrId:0000, result:success, encoding:20, value:00, isValidForDataType:true, clusterInt:768, attrInt:0]
18:47:44: debug description is read attr - raw: B37A0303000A0000002000, dni: B37A, endpoint: 03, cluster: 0300, size: 0A, attrId: 0000, result: success, encoding: 20, value: 00
18:47:42: debug [name:colorTemperature, value:2703]
18:47:42: debug description is read attr - raw: B37A0303000C070000217201, dni: B37A, endpoint: 03, cluster: 0300, size: 0C, attrId: 0007, result: success, encoding: 21, value: 0172
18:47:40: debug [name:level, value:100]
18:47:40: debug description is read attr - raw: B37A0300080A00000020FE, dni: B37A, endpoint: 03, cluster: 0008, size: 0A, attrId: 0000, result: success, encoding: 20, value: fe
18:47:38: debug [name:switch, value:off]
18:47:38: debug description is catchall: 0104 0006 03 01 0040 00 B37A 00 00 0000 01 01 0000001000
18:44:45: debug [name:sThey turn on by themselves because they are a joke. A cheap joke. I got fed up with these Osrams, A60 and gu10, that I’m swapping them out for Fibaro Dimmer’s, more expensive but more reliable.
You’re not wrong. I have 5 Osram Lightify bulbs. They serve a purpose for things like lamps and uplighters, but for main lights - Fibaro Dimmers all the way.
How well do those work with LEDs?
I won’t lie - I had a few issues when I tried to replace 3 of my outside GU10 bulbs to be LED’s.
From what I read - it was something to do with such a low load. I’m sure somebody with more knowledge than me can elaborate though. I ended up just leaving standard GU10’s in.
@bago
Could you share your app?
I have 6 Osram in my master bedroom.
2 of them turn on itself very often (from 1:00AM - 3:00AM)
If I don’t have any option to resolve this issue, my wife would kill me 
From what I have read they should work with LED’s with a minimum load of 25w and a bypass wire. It looks like you can also re-calibrate them to prevent LED flickering. http://www.vesternet.com/resources/application-notes/apnt-24#.WfxjpVWnFEY
The curse of the Osram’s strike again…
I have not turned the device on manually (or asked Alexa to turn it on) yet on it goes! Osram bulbs have been nothing but annoying since I bought them.
I’d advise anyone to either get a Fibaro Dimmer (for ceiling lights etc…) and perhaps get some Ikea Tradfri bulbs instead!
You’re right @David_Van about needing a Bypass if the load is under 25W. But thought I’d share that today I replaced a GU10 Osram Lightify, with a 6W GU10 Ikea dimmable LED and installed a Fibaro Dimmer behind the switch, without a Bypass, because there wasn’t any space, and it’s working absolutely fine, so it can be pot luck, there’s no flicker or light leakage.
in last 2 days all my RGBW light strips are going crazy
no problems last year.
last 2 days its turning on in random time
I raised a ticket with ST support, they are aware of a bug in the ST firmware that relates to this issue and have engineers working on the problem. No ETA yet but it is good to know.
1 Like
I have the same issue with one of my two OSRAM lightify strips. It’s in my daughters room and turns on at night while she’s asleep, sometimes waking her. Very annoying. Hope it’s fixed soon.
I’ve had a single Lightify GU10 bulb and a flex strip turn on randomly these last few days with no input… Been perfect in two months they’ve been installed!
I did note that a new firmware update (0x01020510) became available since I last updated my 12 lightify bulbs when first installed two months ago. Has anyone with issues updated yet to see if this resolves it?
Update: thinking about it… Could the availability of new firmware be causing this issue? Smartthings has never (for me) been able to successfully update lightify firmware despite being enabled. It says the current version is the latest. When pairing the bulbs with the lightify gateway, a newer update is available.
For reference, I am using UK (EU) bulbs - a mixture of Gu10, surface lights, flex strips and gardenspots
For what it’s worth I dug out my old Osram Lightify Gateway and decided to see if there were any firmware updates for my bulbs.
Despite there being no reported firmware updates in the IDE… Osram said different.
My bulbs were sitting on v01020412 firmware, and I’m currently updating them to the latest (v01020510).
I was of the opinion that SmartThings now pushed the bulbs firmware out automatically but I guess I was misunderstood.
As I understand it, SmartThings releases updated ZigBee firmware after their own QA and with new hub V2 firmware. It’s possible the new Lightify firmware will be available in the next hub update.
The latest firmware resolved the known issue if the light becoming unresponsive when it is used as a repeater by another zigbee device (in my case a smartthings motion sensor).
I emailed Osram to request a change log of 01020510 a few days back. I will post here if they reply… Don’t fancy going through the lightify gateway firmware update process. . It took an entire weekend first time around!
mine are sat on Current Version: 0x01020307
and turning on randomly
It looks like you’re quite a few versions behind then. Do you have a gateway?
nope this is new from the shop like 2 weeks ago. is there anyway to update?