Suddenly all Tradfri Lights are unreachable

[Nic0205]

Hey there,

from one moment to the next all my tradfri light became unreachable.

The diagram is like this:

I use the newest firmware and deconz Version (0,44).

Before yesterday the system run well for lots of days. I tried already several older firmwares and deconz versions, but i still can´t control any of my bulbs...

Is there anything i could do to resolve this problem by myself?

Is there perhaps a logfile (i am using the raspi version) that i could use for further investigations?

[wvuyk]

I have this every now and then, where the few IKEA bulbs I have become unreachable. Rebooting deCONZ or updating does not change things. But taking the power off the bulb once and putting power back on solves my issue most of the time... somehow the bulbs seem to stop communicating?

Wim

[Nic0205]

Thanks for replying.

I am glad that I am not the only one with this problem.

But divide the power line to make the bulbs reachable again is not really a comfortable solution. I do not really know how to tell this to my wife;-)

Is there a more usable solution?

Greetings Nic

[Nic0205]

Just tried to take the fuse and put it in angain for all lights. Now all bulbs are on but i can not switch them off.

The graph now shows a mesh between all lights but there is no line from the conbee to any of the lights. That seems to me like there is no connection between the mesh of lights and the Controller. I tried to leave and join the network but this does not change anything.

Does anybody have another hint?

Greetings Nic

[manup]

Later today 2.05.45 will be released, which has a fix for Ikea lights, I'm not sure if it is related to the above problem but might be worth a try.

What is the firmware version of your lights?

[Nic0205]

The firmware version is 1.2.214 - that should be the latest Version.

[manup]

OK yes that's a recent firmware and should be ok.

Can you please try 2.05.45 with firmware 0x262e0500, once the network is up you may have to force one of the lights to rejoin by selecting it in deCONZ and pressing L key.

[Nic0205]

The update of both (deconz and firmware) did not change the situation. I did a reset of the conbee stick and reset all lights via touchlink and paired them again. for now all is working fine again i will have a further look on it...

[manup]

Did it work out?

[Nic0205]

Yes. now it runs for 5 days without problems. I will report if the situation changes...

[Nic0205]

Hey there.

Just a few minutes ago the first bulb disappears again.

The GUI looks like this.

Do you have any further suggestions?

I am using the .46 deconz Version ans the latest Firmware.

[Nic0205]

And it happened again:

@manup: It´s frustrating to see day for day more lights become unreachable. Do you have any further hints for me?

[manup]

The new version 2.05.47 with firmware version 0x262f0500 is available which fixes some queue and polling issues.

https://www.dresden-elektronik.de/rpi/deconz/beta/deconz-2.05.47-qt5.deb

Have you tried pressing L when a light which works is selected? It would be helpful to have the debug output while doing that.

deCONZ --dbg-info=1 --dbg-zdp=1 --http-port=80

Further can you provide more details about the lights, which type are they?

[Nic0205]

Hey,

here is the log output

log_deconz.txt

The type pf the lights is:

IKEA Tradfri E27 1000 lm - LED1623G12 (TRADFRI bulb E27 W opal 1000lm)

Does this information help?

[Nic0205]

Update:

After doing the Update to .47 (which is displayed still as .46?) the mesh is back again but I cannot control any of my bulbs.

All lights are off but phoscon looks like this:

Heres is again a log file deconz1.log

@manup: Thats a strange behavior - could you see anything in the logs?

[manup]

By looking at the log (Mgmt_Lqi_rsp) and also the line colors the signal between nodes look very weak. When you press the LQI button in deCONZ after a few seconds the Link Quality Indicator numbers will be shown. Low values below ~150 are tricky they are better around 200 and upwards.

Here is the neighbor table how the gateway sees the lights:

• neighbor: 0x000B57FFFED60294 (0x4187), LQI: 252, relation: 0x03 rxOnWHenIdle: 1
• neighbor: 0x90FD9FFFFE02C7AC (0x3F11), LQI: 65, relation: 0x03 rxOnWHenIdle: 1
• neighbor: 0x000B57FFFED8CA8D (0xE8C0), LQI: 87, relation: 0x03 rxOnWHenIdle: 1
• neighbor: 0x000B57FFFEE31779 (0xB968), LQI: 44, relation: 0x03 rxOnWHenIdle: 1

The lights also don't have strong connections between them.

Not a solution but a little test:

• The light names suggest that they are outside;
• While LQI display is enabled via LQI button in deCONZ
  • Open the window/door in living room (assuming the gateway is there due strong connecting to that light) to the outside;
• After a few minutes you may note a increase in LQI values from the gateway to the outside lights.

It may sound a bit weird but we saw those issue multiple times, glass has a up to 30% decrease in signal strength. Anyway might not be the case here at all but a easy thing to test.

Older firmware versions did have lower barriers to accept also very weak connections, to rule out other routing issues these were raised and might hit here too, I'll try to make these configurable in further firmware versions.

Non the less I strongly suggest you bring in a repeater between inside and outside to improve the mesh.

[Nic0205]

Thanks for helping.

I will give it a try this evening.

For now two questions:

• I thought that the tradfri bulbs act as repeater

• Does the signal situation change if i use the raspee instead of the conbee stick?

[Nic0205]

Hey @manup,

this is the result with closed terrace door:

this is the result with opened terrace door:

and this closed terrace door after a reboot of the raspberry where the Conbee is hosted:

For me as a layman it looks like opening one terrace door (which is next to the first bulb) did not increase the lqi´s much...

Or do i interpet the values wrong?

[manup]

Indeed, looks like no significant difference. How long did you wait after opening the door? It takes some minutes to settle changes and query neighbor tables.

For now two questions:

• I thought that the tradfri bulbs act as repeater

Yes most light bulbs act as repeaters the lines between nodes might be used as routes. In my experience I find Ikea lights do mesh but signal range is quite limited to a few meters.

• Does the signal situation change if i use the raspee instead of the conbee stick?

RaspBee and ConBee are the same, only the USB/Serial interface is different.

To improve the mesh other routing nodes like lights or smart plugs can be placed in the weak spots.

[Nic0205]

Hey,I opened the door for about 30 minutes.

Neither before, during  nor after opening the door the lqi really changed. 

I will try to put an osram smart outdoor plug next to the terace door and will have a look if things improve.

You mentioned that you will check if you Co could integrate an Option in the firmware to improve behaviour with weak Signals - do you need help for testing ?

[Nic0205]

Hi @manup,

Today i installed an additional PowerPlug for outdoor use (osram lightify plug+).

After adding it to the zigbee network (it worked the last days great!) it looks like this:

So now even the nearest Tradfri bulbs are not reachable.

After a reboot it looks still like this

It seems, as there is something in principle wrong :-(

[manup]

What on earth is this sorcery :/ Is this with firmware 0x262f0500? .48 is out with more fixes for querying nodes, but even with .47 this shouldn't happen.

[Nic0205]

Yes, it is the firmware f0500.

I will give .48 a try this evening.

Its really strange...

[Nic0205]

For sadness 5 of 6 Lights came up again.

But the potentially nearest bulb outside does not react anymore. Its really strange.

@manup: Do you have an Idea?

[Nic0205]

I went outside and put the bulb in an lamp really near to the gateway and did then a touchlink scan with the old web interface.

this is the result:

For me it is confusing that the gateway is on channel 11 and the bulb on channel 20 . The mysterious thing is that it did work days ago without any problems...

[manup]

That's very interesting! Did you ever made a ZigBee channel change? In the last weeks some bugs related to channel updates and Ikea lights popped up, this might be the very problem here. Ikea lights are a bit stubborn to detect that network parameters like channel and nwkUpdateId have changed.

Can you please create a backup in Phoscon App and send it to mpi@dresden-elektronik.de I can check if and how the network parameters changed.

After creating the backup, to get the light on board again you can change the ZigBee channel to 20. Important: All lights must be powered.

[Nic0205]

Hey,

i did a channel switch a few weeks ago. I sent you a backup i made the last days because for now I paired the misterious bulb with a tradfri remote and then reseted it and paired it in the end with the raspbee again.

I will send you the backup in the next minutes.

[manup]

I sent you a backup i made the last days because for now I paired the misterious bulb with a tradfri remote and then reseted it and paired it in the end with the raspbee again.

Ok, but the screenshot from above is before the reset and pairing again or after?

[Nic0205]

Yes it is.

I will send you in the next seconds a collection of backups of the last days/weeks... :-)

[manup]

:) ok

[manup]

I've checked the backup, the network was at channel 20 once at the time of deCONZ version 2.05.44 and 0x262d0500. Before and later the network is on channel 11.

I'm not sure if the light reverted back to channel 20 on it's own or if it simply didn't get the memo when the channel changed back to 11.

Normally it shouldn't be an issue when the channel is changed even when the lights are powered off, since they should search for the latest network (indicated by nwkUpdateId counter) on all channels after power-up.

For some reason Ikea lights won't do this or not reliably, I'll need to do more testing to investigate further. Theoretically the gateway can detect lights which are lost in this way and in future versions bring them back, but it would be just another hassle to implement only for Ikea devices, hopefully they fix this in the light firmware :)

[Nic0205]

Thank you. Would you recommand a channel switch to 20 or should i just leave the system as it is for now?

[manup]

The channel switch was just for the lost bulb, since it is rejoined now the switch isn't needed anymore.

[Nic0205]

@manup: And it happend again.

Suddenly all lights are not meshing or connecting :-(

[manup]

Are they controllable? As single light or group commands? The lines are independent from that, this problem is under investigation, also they should reappear after some time.

[Nic0205]

no, not controllable neither as group nor as single light. It even more worse:

they get red - from one of the other second :-(

If i could help you by further investigations tell me. My wife is not really happy with this situation :-)

[manup]

Yes sorry I can imagine, yesterday I had one of my Ikea lights also not reachable, it was powered and working for weeks. Only a power-cycle did bring it back to life.

I don't know what happened, if it happens again I'll sniff on all channels, looking if it shows some signs of life.

If i could help you by further investigations tell me.

Can you please do the test above again moving the gateway next to a dead bulb and scan would be interesting if it pops up somewhere on another channel.

[ebaauw]

Yes sorry I can imagine, yesterday I had one of my Ikea lights also not reachable, it was powered and working for weeks. Only a power-cycle did bring it back to life.

Is it a color light? Sending a y value of 0 will do this. For "fun", try:

ph put /groups/0/action '{"on" true, "xy": [0, 0]}'

See #973, point 3.

[manup]

It's just a E27 1000lm dimmable light, it is only controlled by Xiaomi motion sensor and some rules with on and bri group commands. Since the values are always the same I think something different killed the light, might be some maintenance requests or maybe just a bug in the light.

I just noticed it was dead because the sensor didn't turn it on.

See #973, point 3.

Cool I'll add this to the Wiki to document known issues.

Found some strange things in Ikea firmware which are currently documented here (will move to it's own page).

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/End-device-Polling#ikea-gu10-ws-400lm-fw-12221-datecode-20180410

I'll forward these to Ikea devs maybe they can address some of it in future firmware updates.

[Nic0205]

Hey,

i tried it via touchlink:

Seems all ok.

But another thing is strange: I can turn on and off the lights via the old web-interface. After login out and then login in in the phoscon app i can manage all lights - thats really confusing.

[Nic0205]

Addition: I took one light (the one that change the channel last time) out of the lamp and put it in a lamp near to the gateway. I did not move the gateway.

Does this perhaps have any effect?

[manup]

Does this perhaps have any effect?

Yes it generates some traffic and may cause some lower level stuff to repair meshing. The interesting part from scan would have been while the lights are in the dead state before power cycle :)

[Nic0205]

Damn :-( I will try it again when it happens again... Just have to search a long lan cable to go outside with the gateway. Or i put the conbee in my notebook.

We will see - i try it as soon as the situation occurs again...

[manup]

Version 2.05.49 is out and behaves a bit smoother to Ikea lights hopefully this makes a difference but only time will tell.

[Nic0205]

... and it happend again.

For 23 days all went great. But this night suddenly all bulbs are not reachable again.

It went outside (cold and rainy :-)) with my notebook and the conbee stick and did the mentioned touchlink scan.

In result the touchlink scan does not find the bulb. I then tried a power cycle but the bulbs are not controllable. At last i tried the "all off" command. The duty cycled bulb went off but i can´t put it on again.

I am using still the .49 version you mentioend @manup .

Do you have further ideas?

[manup]

In result the touchlink scan does not find the bulb. I then tried a power cycle but the bulbs are not controllable.

Hmm Touchlink scan should find a bulb in any case, it's not bound to the current network. Note: ConBee needs to be very close to the bulb

At last i tried the "all off" command. The duty cycled bulb went off but i can´t put it on again.

At least that means they react to group commands. Can you control them by controlling the whole group in Phoscon App (not a single bulb)?

It went outside (cold and rainy :-))

Don't think it's the problem here, but as a side note: rain/water does have a bad impact on signal. It's like a metal wall.

Do you have further ideas?

deCONZ was already restarted?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Elliott32224]

I have this every now and then, where the few IKEA bulbs I have become unreachable. Rebooting deCONZ or updating does not change things. But taking the power off the bulb once and putting power back on solves my issue most of the time... somehow the bulbs seem to stop communicating?

Wim

So, Wim, today I had several bulbs (Philips and Ikea) not reachable, yet I could turn them on and off with the global ON and OFF in the Phoscon GUI. How do you think this works? The deConz api showed those lights with no connections, too. Elliott

[wvuyk]

Elliot,

Check the forum, I answered you on this. You will probably need to use the network restore in Phoscon.