Hi, I recently added 4 new (factory reset) TRÅDFRI LED bulbs (E27 806lm, P/N 204.391.65) to replace some older (Belkin Wemo) bulbs but they refuse to stay off when told, coming back on at what ever dimming they’d last been set to.
My well established home setup is:
RPi3 with ConBee II (FW 26780700) + deconz-gui 2.26.3 and connected to Home Assistant (HAOS 11.5 & HA Core 2024.6.4) with 52 Zigbee devices - lights, plugs, switches, sensors & a blind.
To try and work this out:
I added another 2 new lights elsewhere, a 806lm plus a different/newer 1055lm bulb (P/N 305.456.84), same problem…
Factory reset & re-added the old Wemo bulbs and they behave normally.
I’ve no automations or switches driving these new lights.
Shutdown Deconz on the RPi, behaviour stops
Disabled the Deconz integration on Home Assistant, behaviour continues.
Checking device logs of HA, its just shows them turning off & on, no sign of HA driving them.
When off, the IKEA bulbs all come on together too!
Hope someone can help me shed some light (yes, pun intended ) on this issue!
Hi, here’s ~5 minutes of my debug log deCONZ Debug Log 20240625T1809 - Pastebin.com with INFO , INFO_L2 , ERROR , ERROR_L2 , APS , APS_L2 levels set in Debug View on deconz-gui
The IKEA lights that are the issue are known as:
Pole Lamp Top
Kitchen North East
Kitchen North West
Kitchen South East
Kitchen South West
Spare 1
These lights all powered on in the last few minutes before the end of the log. Hope it’s helpful, I can’t see anything I understand there.
Also I should add we’ve noticed they appear to randomly “breathe” as well…
My suspicions are confirmed by your log: they seem to reboot. That is causing the lights turning on. The log also shows it: 1. 18:08:02:049 DeviceAnnce of LightNode: 0xA46DD4FFFE50B1AC Permit Join: 148
When devices lose power / reboot they will light up. The breath means they are in pairing mode somewhat.
Are you opening the network yourself?
@manup Could the above be explained by OTAU updates?
Indeed it looks like they reboot. But I don’t see why.
18:07:30:280 send permit join, duration: 65
As mentioned the network is open, which should only be the case when light/sensor search is started but should stop after a given time (here 65 seconds).
If it still continues then there must be something triggering this like REST API client.
Ok, please forgive my “newbie-ness” to Zigbee networking, protocols & concepts, I’m an mostly an enduser here. I’m a retired IT professional with a hobby of home automation, we’ve had a reliable network of devices but it has become less so…
I did re-add lights “Patio North” & “Patio South” during that logging, that might explain one of the “send permit join”.
Yes we get those same lights turning on without a human “opening the network”, spent the last few days trying to capture a log with them coming on by themselves but to no avail. Came home this afternoon after spending time away and they were on… Attempting to get another log now.
Side note, the lights in the logs have same models but different MAC address prefixes: 60:b6:47:ff:fe, a4:6d:d4:ff:fe and 30:fb:10:ff:fe which all belong to Silicon Labs.
Not sure if this helps but I noted on the IKEA packaging, a stamped number, the 806lm lights have 2342 or 2327 and the 1055lm has 2345 . Also noticed IKEA use different “Article Numbers” for these lights in different regions…
Update: I have now running the TRADFRI bulb E27 WW globe 806lm running in my test network with the sniffer attached. So far so good, the light is turned off I hope to catch if it turns on by itself.
If it works with the Hue bridge I can make a comparison via sniffer later on to see what are the differences.
Oha, the light in my setup just updated from version 1.0.25 to 1.0.36.
Unfortunately the changelog for this version is a bit thin, not sure if it improves on the issue here.
) on this issue!