Light (switch) unreachable but still works using the group

[abmantis]

It is frequent that a light gets offline, but it is still controllable using the group it is assigned to. Also, it seems that toggling the group makes the light available again faster. Using the latest version, but this has been present for a long time.

[manup]

Can you please provide more details on which light/type?

After a group command lights might send attribute reports to the gateway which would mark them as reachable again.

[abmantis]

It is a switch (relay) from a local company (not sold internationally). But if the switch is able to receive the group command and reply back, why is it going offline? Maybe deConz could be failing to ping them periodically?

[gmitch64]

I've been having this issue with on of my bulbs since upgrading to 2.05.46 last night. Bulb is a GE. It often shows as offline, and non controlable. However, if I use the group associated with it, it works 100% of the time, and the bulb magically becomes reachable again.

G

[ebaauw]

A false value for state.reachable doesn't mean that the light is offline. It only means that deCONZ received no response from the light for the last (unicast) message it sent to the light. Similarly, a true value for state.reachable doesn't mean that the light is online. It only means that deCONZ did receive a response (or that the light recently sent a report).

There are some routing issues in recent versions of deCONZ and the RaspBee firmware, that cause deCONZ sometimes to lose the route to a light. Group commands are broadcast, so they continue to work even if the (unicast) route is broken. Routes are asymmetric, so the light might still know how to reach deCONZ for the (unicast) attribute report, even through deCONZ doesn't know how to reach the light. deCONZ marks the light as reachable when it receives the attribute report, even though it cannot reach the light because of the broken route.

[abmantis]

Thanks @ebaauw for the explanation. That makes much sense. It indeed seems like a bug, since the switch stayed offline for hours but came online as soon as the group was turned on, and stayed online ever since (the whole day now).

[JBS5]

I experience the same issue. Some newly added lights (Tradfri GU10) are shown as not reachable but do switch on/off when controlling the group in the Phoscon app or via HASS. Unfortunately the ligts doesn't get reachable again after switching off/on the group.

I am using a Conbee on a NUC.

[manup]

Which deCONZ and firmware version are you using? There were some Ikea related fixes in recent versions.

[JBS5]

@manup The Phoscon app and HASS log shows 0x261f0500 But I am not sure, because of the Phoscon app is showing a RaspBee instead of my Conbee: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/956 Not sure if only the device name is wrong or also the firmware version is incorrect.

[manup]

Ok, looks like deCONZ version 2.05.44 and firmware 0x261f0500.

I'd suggest you try the recent version deCONZ 2.05.49 with firmware 0x262f0500 (make backup first).

[JBS5]

@manup Thanks for your advice, I will try. Where can I find the release notes?

[manup]

They are not online yet (shame on me), I hope to find the time for the changelog this weekend.

But in summary most important changes are related to mesh problems and Ikea lights.

[JBS5]

@manup A few days later and the problem seems to be solved with the firmware upgrade. The lights are still available.

[manup]

Closing the issue for now.

[abmantis]

This is happening a lot lately. A light appears as unreachable, but the group toggles it just fine and instantaneously. I'm using 2.05.59 with the latest raspbee firmware.

@manup should this be reopen?

[Markkuuss]

I have exactly the same problem with the Ubisys S1-R. The light goes offline and cannot be controlled anymore, but I can still switch it on and off via the group.

I am using the latest version v2.5.87 and the latest firmware for the RaspBee. I have often reset and removed the node from Deconz and then added it again. Unfortunately this did not solve the problem either.

What else could I do? Unfortunately I do not know any more. Could the issue be reopened?

[Markkuuss]

I just noticed that if the node is offline, it is still possible to read the binding table.

This is proceeding successfully. Afterwards a connection to the device is established again and you can control it again.

08:15:52:113 read binding table for 0x001fee00000009c8 (0xb0a3) 
08:15:53:115 Mgmt_Bind_req id: 116 to 0x001FEE00000009C8 send
08:15:54:369 ZDP status = 0x00 -> SUCCESS
08:15:54:379 MgmtBind_rsp id: 116 0x001fee00000009c8 seq: 53, status 0x00 
08:15:54:384 found binding 0x0006, 0x02 -> 0x001FEE00000009C8 : 0x01
08:15:54:388 add binding to check rule queue size: 0
08:15:54:393 found binding 0x0006, 0x01 -> 0x00212EFFFF004D54 : 0x01
08:15:54:398 add binding to check rule queue size: 1
08:15:54:403 found binding 0x0B04, 0x04 -> 0x00212EFFFF004D54 : 0x01
08:15:54:408 add binding to check rule queue size: 2
08:15:55:115 Mgmt_Bind_req id: 116 to 0x001FEE00000009C8 send
08:15:55:526 ZDP status = 0x00 -> SUCCESS
08:15:55:533 MgmtBind_rsp id: 116 0x001fee00000009c8 seq: 55, status 0x00 
08:15:55:537 found binding 0x0702, 0x04 -> 0x00212EFFFF004D54 : 0x01
08:15:55:541 add binding to check rule queue size: 0
08:15:58:010 Mgmt_Lqi_req zdpSeq: 141 to 0x001FEE00000009C8 start index 0
08:15:58:742 ZDP status = 0x00 -> SUCCESS
08:15:58:747 ZDP Mgmt_Lqi_rsp zdpSeq: 141 from 0x001FEE00000009C8 total: 4, startIndex: 0, listCount: 3
08:15:58:751     * neighbor: 0x00212EFFFF004D54 (0x0000), LQI: 105, relation: 0x02 rxOnWHenIdle: 1
08:15:58:756     * neighbor: 0x001FEE000000073F (0x59E7), LQI: 92, relation: 0x02 rxOnWHenIdle: 1
08:15:58:760     * neighbor: 0xEC1BBDFFFE9405A1 (0x5DD3), LQI: 29, relation: 0x02 rxOnWHenIdle: 1
08:15:59:050 reuse dead link (dead link container size now 8)
08:15:59:530 reuse dead link (dead link container size now 7)
08:16:00:011 reuse dead link (dead link container size now 6)
08:16:00:615 remove outdated neighbor 0x604C
08:16:00:620 remove outdated neighbor 0xF67D

@manup: Please reopen the issue.

[Mimiix]

@Markkuuss It won't get re-opened. But please open a new issue and provide all information requested by the template + all logs you have.