search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 498 forks source link

OSRAM bulbs turn on randomly and unexpected #7546

Closed danube closed 5 months ago

danube commented 7 months ago

Does the issue really belong here?

Is there already an existing issue for this?

Describe the bug

I have a network with 38 nodes, including several E27 lights. Five of them are from OSRAM and give me (and my wife) a serious headache, as they turn on unexpectedly.

These OSRAM bulbs are installed already since a while and have worked without problems, but since about end of December, I'm experiencing this issue. Maybe some software update raised it, but I really can't say which.

I changed from ConBee II to III but things didn't change.

I attach a log where the event happens today 2024-01-22 at 8:25:17 am. I also attach a ZSHARK capture from within the same time period. Both cropped to 5 seconds +/-. Lamp's UID is 7c:b0:3e:aa:00:af:6b:90-03.

I referred to https://forum.phoscon.de/t/lights-randomly-turning-on/1679/3, but the creator moved to a Hue system without finding a solution.

I'll proceed capturing the event in the hope of any valuable information. If there is more I could do or try, let me know.

debug.txt nodered.json capture.pcapng.gz

Steps to reproduce the behavior

no idea... install OSRAM E27 bulbs and wait?

Expected behavior

lamps don't turn on unexpectedly

Screenshots

No response

Environment

deCONZ Logs

No response

Additional context

No response

danube commented 7 months ago

Attached are the logs of another event. Lamp UID here is 7c:b0:3e:aa:00:af:6b:90-03.

2024-01-22_09-59-07_Bastelzimmer.zip

May I ask one question. What is that meaning of: INSERT INTO resource_items (sub_device_id,item,value,source,timestamp) SELECT id, 'state/on', 'true', 'dev', 1705908316 FROM sub_devices WHERE uniqueid = '7c:b0:3e:aa:00:af:6b:90-03'

Looks like SQL to me. This line is logged in both events just a short time before the relevant light goes on. What's the meaning of this command, and who's executing it?

danube commented 7 months ago

Filtering all lines for the relevant UID, monitoring 5 seconds +/-, the following lines remain (affected UID in this case is 7c:b0:3e:aa:00:af:a4:fe-03):

15:31:02:955 DeviceAnnce of LightNode: 0x7CB03EAA00AFA4FE Permit Join: 0
15:31:02:955 Websocket 192.168.178.32:37122 send message: {"attr":{"id":"11","lastannounced":"2024-01-22T14:31:02Z","lastseen":"2024-01-22T14:31Z","manufacturername":"OSRAM","modelid":"Classic A60 W clear - LIGHTIFY","name":"Bastelzimmer Licht","swversion":"V1.04.12","type":"Dimmable light","uniqueid":"7c:b0:3e:aa:00:af:a4:fe-03"},"e":"changed","id":"11","r":"lights","t":"event","uniqueid":"7c:b0:3e:aa:00:af:a4:fe-03"} (ret = 364)
15:31:03:306 APS-DATA.request id: 252, addrmode: 0x03, addr: 0x7CB03EAA00AFA4FE, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
15:31:03:462 add task 54782 type 21 to 0x7CB03EAA00AFA4FE cluster 0x0004 req.id 254
15:31:03:462 APS-DATA.request id: 254, addrmode: 0x03, addr: 0x7CB03EAA00AFA4FE, profile: 0x0104, cluster: 0x0004, ep: 0x01 -> 0x03 queue: 0 len: 4 tx.options 0x00
15:31:03:531 0x7CB03EAA00AFA4FE found group 0xFFF0
15:31:03:531 0x7CB03EAA00AFA4FE found group 0x0014
15:31:03:531 0x7CB03EAA00AFA4FE found group 0x0012
15:31:05:820 INSERT INTO resource_items (sub_device_id,item,value,source,timestamp) SELECT id, 'state/on', 'true', 'dev', 1705933865 FROM sub_devices WHERE uniqueid = '7c:b0:3e:aa:00:af:a4:fe-03'
15:31:05:834 ZCL attribute report 0x7CB03EAA00AFA4FE for cluster: 0x0006, ep: 0x03, frame control: 0x18, mfcode: 0x0000 
15:31:05:834 Websocket 192.168.178.32:37122 send message: {"e":"changed","id":"11","r":"lights","state":{"alert":"none","bri":254,"on":true,"reachable":true},"t":"event","uniqueid":"7c:b0:3e:aa:00:af:a4:fe-03"} (ret = 152)
15:31:05:852 ZCL attribute report 0x7CB03EAA00AFA4FE for cluster: 0x0008, ep: 0x03, frame control: 0x18, mfcode: 0x0000 
15:31:09:264 0x7CB03EAA00AFA4FE: update ZCL value 0x03/0x0019/0x1000 after 0 s
15:31:09:264 APS-DATA.request id: 45, addrmode: 0x03, addr: 0x7CB03EAA00AFA4FE, profile: 0x0104, cluster: 0x0019, ep: 0x01 -> 0x03 queue: 2 len: 4 tx.options 0x04

Now I'm not an expert in reading these logs, nor do I know all the abbr's, but maybe someone does?

ebaauw commented 7 months ago

15:31:02:955 DeviceAnnce of LightNode: 0x7CB03EAA00AFA4FE Permit Join: 0

This means the bulb's firmware has rebooted. It's probably configured to turn on on reboot; you might want to change that. Not sure if we expose this through the API, but OSRAM lights have a manufacturer-specific command to store the current state as power-on state. I think it's on the Basic cluster, but I'm not sure.

As to why the light reboots: It could be a bad electric contact; it could be a firmware bug; or it could indicate failing hardware due to age.

Mimiix commented 7 months ago

15:31:02:955 DeviceAnnce of LightNode: 0x7CB03EAA00AFA4FE Permit Join: 0

This means the bulb's firmware has rebooted. It's probably configured to turn on on reboot; you might want to change that. Not sure if we expose this through the API, but OSRAM lights have a manufacturer-specific command to store the current state as power-on state. I think it's on the Basic cluster, but I'm not sure.

As to why the light reboots: It could be a bad electric contact; it could be a firmware bug; or it could indicate failing hardware due to age.

Would you recommend closing the issue as it's not a bug?

danube commented 7 months ago

Let me check some other situations. If that's the case on all bulbs, that should of course not be of your concern.

bcutter commented 7 months ago

Hi. Yesterday I updated from deCONZ 2.22.2 to 2.25.3. Since then, my only Classic A60 W clear - LIGHTIFY turns on within 1 to 2 minutes after it has been turned off - and stays on like FOREVER. That's a pattern, no real randomness. That's an absolute showstopper currently in my smart (now dumb) home! 😞

grafik

I initially reported this to https://github.com/basnijholt/adaptive-lighting/issues/920. But as really NOTHING changed besides the deCONZ update and the issue initially started once running 2.25.3, I'm rather confident the issue is in the deCONZ field.

My OSRAM bulb does not allow to set the 0x4003 PowerOn ONOff cluster. I have no idea what it was set to earlier or if this changed, but this is the current state of 0006 On/Off cluster: grafik

Regarding

As to why the light reboots: It could be a bad electric contact; it could be a firmware bug; or it could indicate failing hardware due to age.

@danube Please exactly verify when you updated to which deCONZ version. As I made a rather big jump from 2.22.2 to 2.25.3 I can not really isolate which version exactly might have introduced this.

bcutter commented 7 months ago

Minor update on my issue @ https://github.com/basnijholt/adaptive-lighting/issues/920#issuecomment-1937903397

danube commented 7 months ago

I understand the explanation of the logs. Although, I seriously wonder how several bulbs from the same time on start to act weird, when they behaved for more than a year without any problem.

After removing the bulbs from my home installation (and my son's birthday), I haven't got time to do any sort of investigation yet. But as I hold another ConBee stick, I may be able to set up a test environment. I than can do some checks against different software versions. I'd be happy about any clues limiting the scope of combos. @bcutter What server hardware (ConBee, RaspBee) are you using? Between "yeey" and "booh" state, have you also changed the firmware?

bcutter commented 7 months ago

@bcutter What server hardware (ConBee, RaspBee) are you using? Between "yeey" and "booh" state, have you also changed the firmware?

First of all: as mentioned @ https://github.com/dresden-elektronik/deconz-rest-plugin/issues/7546#issuecomment-1937903511 I think I might have identified the issue in my case - or at least I could find a working change to suppress the new unwanted behavior (light turned on). Nevertheless there are unanswered questions directly pointing to a deCONZ update.

Information requested:

danube commented 7 months ago

Is this a user-only driven hunt or is someone at dresden-elektronik supporting? @Mimiix? If so, what sort of information do you need? We seem to have scratched some sort of surface. Where to look at?

Mimiix commented 7 months ago

Is this a user-only driven hunt or is someone at dresden-elektronik supporting? @Mimiix? If so, what sort of information do you need? We seem to have scratched some sort of surface. Where to look at?

I'm not employed by Dresden. Just a volunteer / community member.

I can ask Dresden to check in :)

manup commented 7 months ago

Not sure what's going on, from what I remember at least the original / old Osram Lightify bulbs had issues in the past where they rebooted for some reason at random intervals. This was a few years ago and I never could figure out why they do that. Perhaps they don't like some commands we send, but I did try to reduce the commands to a minimum back than without success.

The "Classic A60 W clear - LIGHTIFY" nowadays do work via DDF, which in this case is very simple. Perhaps the lights don't like reading the binding table or creating bindings.

Lets have a look of the last communication before the light reboots:

08:25:13:377 APS-DATA.request id: 219, addrmode: 0x02, addr: 0xD76E, profile: 0x0000, cluster: 0x8001, ep: 0x00 -> 0x00 queue: 0 len: 12 tx.options 0x04 08:25:13:409 APS-DATA.indication srcAddr: 0xD76E, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 173, rssi: -83 08:25:13:521 APS-DATA.indication srcAddr: 0xD76E, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0019, lqi: 175, rssi: -81 08:25:13:521 APS-DATA.request id: 223, addrmode: 0x03, addr: 0x7CB03EAA00AF6B90, profile: 0x0104, cluster: 0x0019, ep: 0x01 -> 0x03 queue: 1 len: 4 tx.options 0x04

Here the light asks for the MAC address of the coordinator (likely to find out binding or OTA server destination)

08:25:14:881 APS-DATA.indication srcAddr: 0xD76E, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x0001, lqi: 174, rssi: -82

Here the coordinator answers

08:25:14:881 APS-DATA.request id: 232, addrmode: 0x02, addr: 0xD76E, profile: 0x0000, cluster: 0x8001, ep: 0x00 -> 0x00 queue: 0 len: 12 tx.options 0x04

Light has rebooted

08:25:15:233 APS-DATA.indication srcAddr: 0xD76E, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x0013, lqi: 182, rssi: -74

The light firmware shouldn't crash/reboot as this would indicate a bug in the firmware.

I was tempted to say to also try with the new ConBee III firmware (make a backup first) but since this also occurs with ConBee II I guess that won't help much. Osram also has ConBees for testing, perhaps they should be contacted if they can spot anything unusual :thinking:

andreasgily commented 7 months ago

I have kind of a similar problem with my IKEA Tradfri lights. When I turn off a light group, one light turns on again after few seconds. This started after the last Gateway Update to 2.25.3 (Firmware: 26720700)

ostgardh commented 7 months ago

Same for me, I have install deCONZ 2.25.3

3 light turns on again after few seconds after turn off.. 1 is singel HUE , not i group and 2 HUE lights that is in group.

After downgrade to 6.21.0, problem is gone.

bcutter commented 7 months ago

Now that starts to create a pattern... so the cause is likely in 2.25.3 right? Would also match the fact not that much reports of this/similar issues came in so far, as 2.25.3 is pretty fresh.

manup commented 7 months ago

I'm doing some tests with 3 Osram lights:

The last one just acted up after a while not responding to binding table and read attribute requests, and then rebooted:

image

image

So from the DDF and commands send to the lights perspective this is all valid, but there is some bug in the firmware where it runs into problems. I'll try now a DDF without reporting and bindings, using just plain polling of the light to see if that is any different.

manup commented 7 months ago

That seems to work better, not using any attribute reporting and bindings keeps the OSRAM Classic A60 RGBW going without reboot (so far). I'll let it run over night and prepare a test version tomorrow, would be cool if anybody can check it out.

The downside is that we can't use reporting here and polling takes a while, but better than reboots I guess.

Note this only applies for Osram lights.

manup commented 7 months ago

Hi here is a testing version which includes above fixes for selected Osram/Ledvance lights, would be cool if anybody having the problems can check this out.

deconz_2.26.0_1ab70f-debian_armhf.deb

deconz_2.26.0_1ab70f-debian_arm64.deb

For the Ikea and Hue lights turning on after turning off, please create a separate issue for that as this is different to the Osram firmware bugs handled in this issue, here we need to gather more info which light modelids are affected and the setups with logs.

danube commented 7 months ago

On it 20240216_080316.jpg

Have to admit, I'm still on 2.24.3.

mattreim commented 7 months ago

@manup The Osram plug 01 seems to have the same problem. Sporadic reboots or resets after losing bindings.

danube commented 6 months ago

I had it running under 2.24.3 for a week now but haven't seen a single lamp going on. The difference to where the weird things happened was the physical installation. Where the lamps hung down from the ceiling, they now lay in a box. I seriously hope this doesn't make any difference...

I today upgraded to 2.25.3. I want to make sure to have a "faulty" installation before upgrading to 2.26 in order to be able to verify the fix. Keep you posted.

quickgold1 commented 6 months ago

I purchased about ten of these bulbs more than a year ago, I paired them with Alexa and they had never given me any problems, for a month (having in the meantime purchased a minipc and implemented HA) I paired these bulbs with Z2mqtt.

From that moment the problems began, as they turned on randomly even at night (among other things on HA, the light bulbs, even on the register, were off).

I tried, I think everything, I tried changing each zigbee channel, I tried unpairing and re-pairing, no luck, the bulbs kept turning on suddenly.

I searched the forum or the internet in general to see if anyone else had had the same problem, but nothing.

A few days ago I unpaired them from HA and re-paired them to Alexa, and the problem disappeared, so they work now.

Jungleboot commented 6 months ago

Hello, I've been having the same problem since last Friday. I went from version 2.24.2 to beta version 2.26.1 for testing and since about once an hour a lamp, or several, disconnects and then reconnects and turns on. I have a Conbee 3 key that I also updated at the same time. I have 28 OSRAM lamps that are generating the problem. I migrated my installation to another PC in version 2.24.2 to test, still with the Conbee 3 and the latest firmware, it's less frequent but still the same. I have another Zigbee network with a Conbee 2, I made the same changes: firmware update of the conbee 2 and deconz beta version 2.26.1 and I don't have the same problems at all. Isn't the Conbee 3 to blame?

github-actions[bot] commented 5 months ago

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

github-actions[bot] commented 5 months ago

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.