New IKEA TRÅDFRI LED bulbs turning themselves on

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:

  1. I added another 2 new lights elsewhere, a 806lm plus a different/newer 1055lm bulb (P/N 305.456.84), same problem…
  2. Factory reset & re-added the old Wemo bulbs and they behave normally.
  3. I’ve no automations or switches driving these new lights.
  4. Shutdown Deconz on the RPi, behaviour stops
  5. Disabled the Deconz integration on Home Assistant, behaviour continues.
  6. 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! :open_mouth:

Hope someone can help me shed some light (yes, pun intended :smiley: ) on this issue!



Can you capture some logs when this occurs?

There’s a topic called how to get logs where it describes how to capture and share them.

1 Like

Hi, here’s ~5 minutes of my debug log deCONZ Debug Log 20240625T1809 - 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?

Ok thanks and that explains the behaviours.

What do you mean by “opening the network”?

I had wondered if there was an update required to “fix them” but unsure how to get an IKEA update without an IKEA hub etc.

18:08:31:277 send permit join, duration: 65

He is right, why you have your zigbee network open ?

What do you mean by “opening the network”?-

Set the permit join ? Set the inclusion mode on ?

There’s also some that show permit join on the device join. Perhaps touchlink?

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”.

Is there a way to see what’s opening the network?

Was probably you, using phoscon if you have used “Add new light” ^^.
But you have same result without opening the network ?

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.

For my own reference… the light is:

Modelid: TRADFRI bulb E27 WW globe 806lm
SwVersion: 0x01000025

Running on legacy code (no DDF yet).

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.

In the logs I can’t see a reason why they do behave like that, but it’s an indicator when all with that model id show this.

We are gonna get a bunch of these lights next week to see if there is something going on deeper in the Zigbee sniffer.

1 Like

I have the 1055 version. Same problem.
For info, these bulbs connected to Zigbee2Mqtt have the same problem while under HUE bridge they are OK.

Thanks, I was going to say that the new 1055lm (“Spare 1” in my logs) also turns on with the new 806lm lights.

Recent logs captured when the lights spontaneously switch on:

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…

There should be something “new” in these new Ikea bulbs.
The incredible thing is ALL bulbs work out of the box with Hue bridge always.

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.

1 Like

Something just noted is they trigger each other to switch on when another is powered up.

Ah ok guess I need to to test this somehow.
So far the light in my setup hasn’t turned on by itself and is normally in the network.

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.

TRÅDFRI warm white bulbs E27/GU10 (1.0.36)
Product ID: LED2103, LED2104

  • New product.

The OTA file is

1 Like