The mystery of devices turning on (or off) by themselves

I use deCONZ as home assistant add-on with the deCONZ integration. I have around 190 devices connected, and a quite stable network with many mains powered devices of all kind of vendors.

For some time now, I try to understand and hunt down why sometimes, lights, or more rarely, plugs, are switching on or off without an apparent reason. These incidents do happen sporadically, but do not follow any obvious pattern (at least I cannot recognize it).

Just now, the terrace light went on:
image

Nobody with exception of myself is at home. This device is not included in any automation. deCONZ logs indicate that just before the light was reported as “on” in HA (7 seconds before), the device sent a “DeviceAnnce” message (see below).

09:24:28:053 skip configure report for cluster: 0x0006 attr: 0x0000 of node 0x7CB03EAA0A018143 (seems to be active)
09:24:28:053 binding for cluster 0x0006 of 0x7CB03EAA0A018143 exists (verified by reporting)
09:23:38:198 ZCL attribute report 0x7CB03EAA0A018143 for cluster: 0x0300, ep: 0x03, frame control: 0x18, mfcode: 0x0000 
09:23:38:062 ZCL attribute report 0x7CB03EAA0A018143 for cluster: 0x0008, ep: 0x03, frame control: 0x18, mfcode: 0x0000
09:23:38:026 ZCL attribute report 0x7CB03EAA0A018143 for cluster: 0x0006, ep: 0x03, frame control: 0x18, mfcode: 0x0000
09:23:31:800 delay sending request 205 dt 0 ms to 0x7CB03EAA0A018143, ep: 0x03 cluster: 0x0004 onAir: 1
09:23:31:084 DeviceAnnce of LightNode: 0x7cb03eaa0a018143 Permit Join: 0
09:21:19:707 0x7CB03EAA0A018143 error APSDE-DATA.confirm: 0xE9 on task

What could be the reason for this behaviour?

Looks like the device is rebooting itself (similar what you do when you remove power from it). the Device Announcement is exactly what your seeing there.

Perhaps it’s reaching it’s due date?

To avoid you might be able to change the PowerON behavior to “off” , so that they are off as default on power loss/reboot.

I had this problem.
Check if you have the latest firmware installed.

I have a large system (nearly 400 devices) and an otherwise identical setup and identical occasional problem. I’m a few software versions behind on deCONZ and maybe a firmware update behind, but not seeing any specific bugfixes mentioning this issue, I haven’t rushed to update.

FWIW, my issues seem isolated to Hue bulbs and with no ability to update firmware on them w/o removing from this network and pairing with the Hue hub, I’m not really sure what to do.

When I have time, I will see if this behavior is isolated to a few bulbs in my system, in which case maybe it’s time for a swap. But they’re all brand new (<12 months old).

Anyway - no help from me, but a “me too” in a big way on the problem!

I’ve had that problem too, occasionally. One possible reason I could determine were certain older OSRAM/LEDVANCE devices. These seem to behave erratic when they get older, first switching on irregularly and possibly even interfering with the Zigbee network, until they finally fail completely. In the meantime I have exchanged most of these devices and haven’t noticed the problem recently. As these devices are probably based on Zigbee chipsets for certain vendors the problem may occur with other devices using these chipsets too.

Thanks all, some good insights for sure! Indeed, the device which caused the “incident” is an OSRAM outdoor lantern. I have the latest deconz and also device firmware installed where possible.

I have quite many Osram and LEDVANCE lights, and a few Hue and Innr. I think that the self-switch on did happen always with Osram/LEDVANCE devices, with the notable exception of a Blitzwolf SHP-15 smart plug which switched off.

I will watch this further and report if there are any new insights.

1 Like

It’s not all Osram/Ledvance devices that are affected. I have LED strips, an outdoor light chain, and Ledvance light panels still in operation and not noticed any of these problems (although an Osram LED strip controller died recently and couldn’t be controlled anymore). The main problems I had with GU10 spots and E27 bulbs. Since I have replaced them all with other products I no longer notice “phantom switching”. And I’m using lights from several vendors (Philips, Innr, Lidl).

1 Like

My loooong story regarding this issue
Device turn on alone · Issue #5626 · dresden-elektronik/deconz-rest-plugin (github.com)

Some update on this. In below snippet you can see that deCONZ seems to reboot (?) - which happens by the way quite often and in suspiciously deterministic intervals of 1h for some time until it stabilizes. This is followed by several DeviceAnnce messages, all by GU10 lights (LEDVANCE/OSRAM). Could it be that deCONZ some how manages to crash those lights?

@LeoeLeoeL in your very informative but long thread, did you observe something similar?

05:26:04:335 delayed group sending
05:26:03:942 0x7CB03EAA00ABB587 error APSDE-DATA.confirm: 0xE9 on task
05:26:03:831 ZCL attribute report 0x84FD27FFFED2465D for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:26:02:599 DeviceAnnce of LightNode: 0x7cb03eaa00ab82b1 Permit Join: 0
05:26:02:066 DeviceAnnce of LightNode: 0x7cb03eaa00abb587 Permit Join: 0
05:26:02:051 ZCL attribute report 0x7CB03EAA0A018193 for cluster: 0x0008, ep: 0x03, frame control: 0x18, mfcode: 0x0000 
05:26:01:457 0x7cb03eaa0a09aa49 found group 0xFFF0
05:26:00:984 DeviceAnnce of LightNode: 0x7cb03eaa0a09aa49 Permit Join: 0
05:26:00:740 ZCL attribute report 0x84FD27FFFECE7C7E for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:25:57:629 ZCL attribute report 0x84FD27FFFED2465D for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:25:57:389 ZCL attribute report 0x001788010BD1188A for cluster: 0x0400, ep: 0x02, frame control: 0x08, mfcode: 0x0000 
05:25:57:369 rule event /sensors/279/state/lastupdated: 1397613666 -> 1397911926
05:25:57:367 ZCL attribute report 0x001788010BD1188A for cluster: 0x0406, ep: 0x02, frame control: 0x08, mfcode: 0x0000 
05:25:57:366 No presence sensor found for 0x001788010BD1188A, endpoint: 0x02
05:25:57:347 0x5c0272fffebd49ac found group 0xFFF0
05:25:57:062 ZCL attribute report 0x7CB03EAA0A018193 for cluster: 0x0006, ep: 0x03, frame control: 0x18, mfcode: 0x0000 
05:25:54:891 ZCL attribute report 0x84FD27FFFECE7C7E for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:25:54:292 ZCL attribute report 0x54EF4410000C2DC2 for cluster: 0x0001, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:25:54:235 reconnect network done
05:25:53:831 ZCL attribute report 0x7CB03EAA00AF6A19 for cluster: 0x0300, ep: 0x03, frame control: 0x18, mfcode: 0x0000 
05:25:53:331 ZCL attribute report 0x60A423FFFE6214B8 for cluster: 0x0702, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
05:25:53:268 ZCL attribute report 0x84FD27FFFECE7C7E for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:25:53:206 ZCL attribute report 0x84FD27FFFED2465D for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:25:51:537 0xf0d1b80000139bc5 found group 0x0004
05:25:51:535 0xf0d1b80000139bc5 found group 0xFFF02023-02-15 05:25:50	
05:25:50:279 ZCL attribute report 0x001788010B014B76 for cluster: 0x0001, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
05:25:50:258 ZCL attribute report 0xF0D1B800001CB5BA for cluster: 0x0300, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
05:25:50:249 skip configure report for cluster: 0x0300 attr: 0x0008 of node 0xF0D1B80000139BC5 (seems to be active)
05:25:50:248 skip configure report for cluster: 0x0300 attr: 0x0004 of node 0xF0D1B80000139BC5 (wait reading or unsupported)
05:25:50:248 skip configure report for cluster: 0x0300 attr: 0x0003 of node 0xF0D1B80000139BC5 (wait reading or unsupported)
05:25:50:247 skip configure report for cluster: 0x0300 attr: 0x0007 of node 0xF0D1B80000139BC5 (seems to be active)
05:25:50:245 binding for cluster 0x0300 of 0xF0D1B80000139BC5 exists (verified by reporting)
05:25:50:242 skip configure report for cluster: 0x0008 attr: 0x0000 of node 0xF0D1B80000139BC5 (seems to be active)
05:25:50:240 binding for cluster 0x0008 of 0xF0D1B80000139BC5 exists (verified by reporting)
05:25:50:239 skip configure report for cluster: 0x0006 attr: 0x0000 of node 0xF0D1B80000139BC5 (seems to be active)
05:25:50:236 binding for cluster 0x0006 of 0xF0D1B80000139BC5 exists (verified by reporting)
05:25:50:207 unlocked max nodes: 512
05:25:50:185 Device firmware version 0x26720700 ConBee II
05:25:49:236 Skip idle timer callback, too early: elapsed 929 msec
05:25:49:235 failed to reconnect to network try=3
05:25:48:304 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2250692-if00 / serialno: DE2250692, ConBee II
05:25:44:235 failed to reconnect to network try=2
05:25:39:235 failed to reconnect to network try=1
05:25:35:235 Skip idle timer callback, too early: elapsed 924 msec
05:25:34:311 start reconnect to network
05:25:34:309 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2250692-if00 / serialno: DE2250692, ConBee II
05:25:33:837 0xF0D1B80000175C2E error APSDE-DATA.confirm: 0xAE on task
05:25:33:835 0xA4C138CD2C5AAAE9 error APSDE-DATA.confirm: 0xAE on task

I’ve sometimes seen issues where osram /led Vance devices malform packages they receive and forward those. That might cause the crashes and reboots.

A way around this: change the power on behavior of the device, that a powerloss doesn’t turn the light on.

Yes, unfortunately not possible with this specific device (OSRAM PAR16 50 TW).

image

In that case your pretty much out of luck other than replacing them

Maybe, at some point. Don’t you find it also suspicious that three devices reboot nearly at the same time after deconz rebooted? In the thread on github by @LeoeLeoeL it was in the end acknowledged that the issue still exists, although the firmware fix did help to mitigate one specific case.

If the reboot triggers the device its firmware bug, it’s clear where the issue is right? If all other devices keep working.

Nevertheless: i am wondering why decONZ reboots. First, i sugest updating your firmware on the stick Guide can be found : Update deCONZ manually · dresden-elektronik/deconz-rest-plugin Wiki · GitHub

Additionally, can you log with APS , APS L2, Info, Info L2, Error, ERror L2? Than we might see why it reboots/ restarts

Right, I can understand your position. For the deCONZ rebooting issue, I will start another discussion at some point but need to collect some data first. See e.g. here in the last 24h, each line to my understanding indicates a reboot of deCONZ (running as an add-on in a container on home assistant OS).
image

1 Like

Updated now the firmware, thanks for the heads-up, I was somehow assuming that the latest FW is already installed :slight_smile:

Out of curiosity, I now did a search for DeviceAnnce messages for the last 6 hours (works quite nicely with Grafana & Loki). In this period, two DeviceAnnce “storms” happend with devices of the same type in a relatively short time period.

The first device group consisted of Hue wall module switches (prefix 0x00178801) and the second group of Osram lights of different types (prefix 0x7cb03). It is quite amazing to see that those devices, triggered by whatever, show this behavior (see below). However, there are differences - the Hue wall modules are spread over a longer time period and have several consecutive tries - maybe a way to keep themselves in the network? The OSRAM “storm” is happening within a very short time period. It would be interesting to understand what caused the Osram behaviour.

16:52:42:433 DeviceAnnce of LightNode: 0x7cb03eaa00ab82b1 Permit Join: 0
16:52:42:208 DeviceAnnce of LightNode: 0x7cb03eaa0a018193 Permit Join: 0
16:52:41:978 DeviceAnnce of LightNode: 0x7cb03eaa00ab82b1 Permit Join: 0
16:52:41:413 DeviceAnnce of LightNode: 0x7cb03eaa00aba2ae Permit Join: 0
16:52:41:221 DeviceAnnce of LightNode: 0x7cb03eaa0a018193 Permit Join: 0
16:52:40:434 DeviceAnnce of LightNode: 0x7cb03eaa00af6a19 Permit Join: 0
16:52:40:218 DeviceAnnce of LightNode: 0x7cb03eaa0a09aa49 Permit Join: 0
16:52:40:204 DeviceAnnce of LightNode: 0x7cb03eaa00aba2ae Permit Join: 0
16:52:40:185 DeviceAnnce of LightNode: 0x7cb03eaa00abc0fa Permit Join: 0
16:52:40:024 DeviceAnnce of LightNode: 0x7cb03eaa00aba2ae Permit Join: 0
16:52:39:996 DeviceAnnce of LightNode: 0x7cb03eaa0a09aa49 Permit Join: 0
16:52:39:309 DeviceAnnce of LightNode: 0x7cb03eaa00af6a19 Permit Join: 0
16:52:39:300 DeviceAnnce of LightNode: 0x7cb03eaa00abb36e Permit Join: 0
16:52:39:181 DeviceAnnce of LightNode: 0x7cb03eaa0a09aa49 Permit Join: 0
16:52:38:760 DeviceAnnce of LightNode: 0x7cb03eaa0a018143 Permit Join: 0
16:52:38:751 DeviceAnnce of LightNode: 0x7cb03eaa00ab9f0b Permit Join: 0
16:52:38:516 DeviceAnnce of LightNode: 0x7cb03eaa00abab48 Permit Join: 0
16:52:38:495 DeviceAnnce of LightNode: 0x7cb03eaa00abb36e Permit Join: 0
16:52:38:411 DeviceAnnce of LightNode: 0x7cb03eaa00abab48 Permit Join: 0
16:52:38:230 DeviceAnnce of LightNode: 0x7cb03eaa00ab9f0b Permit Join: 0
16:52:38:095 DeviceAnnce of LightNode: 0x7cb03eaa0a018143 Permit Join: 0
16:52:37:913 DeviceAnnce of LightNode: 0x7cb03eaa00abab48 Permit Join: 0
16:52:37:790 DeviceAnnce of LightNode: 0x7cb03eaa0a018143 Permit Join: 0
16:30:12:385 DeviceAnnce of SensorNode: 0x001788010B031158 [1]
16:30:10:732 DeviceAnnce of SensorNode: 0x001788010B031158 [1]
15:50:03:851 DeviceAnnce of SensorNode: 0x001788010B004388 [1]
15:35:11:103 DeviceAnnce of SensorNode: 0x001788010B03104B [1]
14:31:27:587 DeviceAnnce of SensorNode: 0x001788010B005B3E [1]
14:06:12:309 DeviceAnnce of SensorNode: 0x001788010B005B3E [1]
13:53:55:273 DeviceAnnce of SensorNode: 0x001788010B014B8D [1]
13:53:26:771 DeviceAnnce of SensorNode: 0x001788010B031158 [1]
13:53:25:079 DeviceAnnce of SensorNode: 0x001788010B031158 [1]
13:53:23:601 DeviceAnnce of SensorNode: 0x001788010B031158 [1]
13:48:38:735 DeviceAnnce of SensorNode: 0x001788010B004388 [1]
13:45:59:921 DeviceAnnce of SensorNode: 0x001788010B005B3E [1]
13:43:26:434 DeviceAnnce of SensorNode: 0x001788010B004386 [1]
13:42:27:358 DeviceAnnce of SensorNode: 0x001788010B0311A9 [1]
13:42:24:829 DeviceAnnce of SensorNode: 0x001788010B0311A9 [1]
13:42:23:694 DeviceAnnce of SensorNode: 0x001788010B0311A9 [1]
13:42:22:842 DeviceAnnce of SensorNode: 0x001788010B0311A9 [1]
13:25:47:579 DeviceAnnce of SensorNode: 0x001788010B005B3E [1]
12:05:50:228 DeviceAnnce of SensorNode: 0x001788010CC3BF66 [1]

Can you share the full logs?

Sure, here. You will see quite many ep: 0x01 but what can you do… only “INFO” activated unfortunately.

If it’s only info, i probably won’t see anything.

I’d prefer error, info and aps all on levels 1 and 2.