Osram Ceiling light: Is it dying?

Advice
1

Hi there :slight_smile:

I own a Osram Veiwling Light (Ceiling TW OSRAM, V1.05.10).

I have a fixed schedule which wakes me up in the morning. However, today it was not working. Huh. I looked in the docker logs and saw several error APSDE-DATA.confirm: 0xA7 on task (with different error IDs) for exact that light and that light ONLY (Have a Xiaomi button and a Humidity sensor, both report NO errors - thus, I think my ConBee II is ok).

I restarted the Osram Light and for some minutes, the error were gone, then:

20:10:12:438 delay sending request 59 dt 3 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:12:538 delay sending request 59 dt 3 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:12:638 delay sending request 59 dt 3 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:12:737 delay sending request 59 dt 3 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:12:838 delay sending request 59 dt 3 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:12:937 delay sending request 59 dt 3 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:13:052 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:13:138 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:13:238 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 2
20:10:13:314 0x7CB03EAA00AD82C8 error APSDE-DATA.confirm: 0xA7 on task
20:10:13:314 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 1
20:10:13:337 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 1
20:10:13:438 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 1
20:10:13:538 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 1
20:10:13:638 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 1
20:10:13:738 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 1
20:10:13:838 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 1
20:10:13:938 delay sending request 59 dt 4 ms to 0x7CB03EAA00AD82C8, ep: 0x03 cluster: 0x0008 onAir: 1
20:10:22:597 0x7CB03EAA00AD82C8 error APSDE-DATA.confirm: 0xA7 on task
20:10:22:686    0x7CB03EAA00AD82C8 force poll (2)



...



20:16:53:682 max transmit errors for node 0x7CB03EAA00AD82C8, last seen by neighbors 240 s
20:16:59:069 Device TTL 2803 s flags: 0x7
20:17:33:377 0x7CB03EAA00AD82C8 error APSDE-DATA.confirm: 0xE9 on task
20:17:33:377 max transmit errors for node 0x7CB03EAA00AD82C8, last seen by neighbors 280 s
20:17:34:178 0x7CB03EAA00AD82C8 error APSDE-DATA.confirm: 0xE9 on task
20:17:34:178 max transmit errors for node 0x7CB03EAA00AD82C8, last seen by neighbors 281 s
20:17:34:882 0x7CB03EAA00AD82C8 error APSDE-DATA.confirm: 0xE9 on task
20:17:34:882 max transmit errors for node 0x7CB03EAA00AD82C8, last seen by neighbors 282 s
20:17:35:680 0x7CB03EAA00AD82C8 error APSDE-DATA.confirm: 0xE9 on task
20:17:35:680 max transmit errors for node 0x7CB03EAA00AD82C8, last seen by neighbors 282 s
20:17:35:770 0xA34F seems to be a zombie recv errors 10
20:17:35:770 Node zombie state changed 0x7cb03eaa00ad82c8
20:17:59:068 Device TTL 2743 s flags: 0x7

Would you say its dying? Would not be the first time, another same model is dead already.

THANKS in advance :smiley: