No response on commands - error APSDE-DATA.confirm: 0xA7 #2245
Comments
The gateway has lost the route to the node, so it cannot send unicast commands (generated by light commands). The node is still on the network, and responds normally to broadcasts (generated by group commands). Note that routes are asymmetric. Typically, reports from the node will reach the gateway normally as well. Not sure why the gateway loses the route. It seems worse with multi-manufacturer networks - different manufacturers use different route discovery methods. What RaspBee/ConBee firmware are you on? What deCONZ version are you on? The usual workaround is to power-cycle the node; the Device Announcement message that the device sends on boot seems to reset the route discovery.
The node blinks blue when sending or receiving traffic. It blinks red on a timeout or error sending traffic. Typically behaviour querying a powered-down device is blue blinking when sending the command, followed by red blinking, a while later. |
If I power-cycle the node It seems to get the Device Announcement. But the problem is still there.
I see. But it doesn't blink red. Just blue. It's acting like it's there even when it's unplugged. Waited for 5 minutes now, no red blink. Can I see the traffic in some kind of log? |
Yes. Start deCONZ with deCONZ just writes to standard output and/or standard error. To which file this is redirected depends on how you start deCONZ. I'm sorry, I don't know Hassio. |
|
15:58:28:153 add task 5745 type 19 to 0x00158D00017D4431 cluster 0x0006 req.id 236 I get the error APSDE-DATA.confirm: 0xA7 on task all the time. I don't understand which telegram the failed ack belongs to. |
|
16:24:21:646 APS-DATA.request id: 139, addrmode: 0x03, addr: 0x001788010496197e, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0x0B queue: 3 len: 5 tx.options 0x00 A bit less cluttered. |
|
16:35:19:540 APS-DATA.indication srcAddr: 0xaa76, srcEp: 0x01 dstAddrMode: 1, profile: 0x0104, cluster: 0x0000, lqi: 207, rssi: -65 0xA6 INVALID_PARAMETER |
|
That’s a new one, not yet documented in https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log |
|
I have a theory I have another network with the same behavour. The common ground is an IKEA bulb close to the gateway that other bulbs are routed trough. I have now powered off the IKEA bulb and things are starting to work again. There must be some kind of bug when routing trough this kind of bulb.
|
|
I’m afraid the details are lost on me, but different manufacturers seem to use different methods for route discovery. Notably, IKEA Trådfri works very differently from Hue and dresden elektronik. When the first Trådfri bulbs came out, they spend a lot of time and effort trying to handle them the right way, resulting in many different versions of the RaspBee/ConBee firmware and the deCONZ core program. There still seem to be some residual issues, especially on larger, networks (> ~22 routers from multiple manufacturers). |
Yeah it seems like mixing manufactorers cause problems. But I have exactly the same issue on the smaller network. In my opinion it should be a warning when you buy a conbee about this. I don't like the fact that there is a problem and no solution is at hand. If i knew this before I bought all the bulbs it would have been a different story.
|
|
Okey. I had one more TRADFRI bulb E27 WS opal 1000lm in the big network. So the thing is that it caused problems even to another IKEA bulb (hall på byrå) when routed through the 1000lm (kök kösbord). When I unlugged the 1000lm and (hall på byrå) changed route it started to respond directly. So my conclusion (for now) is that TRADFRI bulb E27 WS opal 1000lm is causing problems. Even to other IKEA bulbs. |
|
The firmware on that bulb seems a little old (just from memory based on the versions my IKEA bulbs show). Have you tried updating it? |
http://fw.ota.homesmart.ikea.net/feed/version_info.json If i'm not misstaken 2.0.022 is the lastest for that bulb acording to the link? |
|
I've similar situation as you, have not nail down to if the issue is the same as you might point out that a bulb is the cause of "routing" problem or not. Today I got one "old timer bulb" to be not responding to any action, even after a power cycle... |
Do the node have a direct link to the gateway if you look at the mesh network in deconz? |
I do not think so at that time. I see now after a reboot of Deconz that most bulbs that is active do have a direct link and a mesh to some other. It is too messy to really see if all have it or not, but when I dragged the "coordinator" it looked that all my routers had a link attached. I doubt that all has, since some of them are too far away from the coordinator to actual have a direct link. |
|
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. |
Update 1:
Yesterday I notised that TRADFRI bulb E27 WS opal 1000lm seems to be the cause. When light nodes are routed through a TRADFRI bulb E27 WS opal 1000lm the problems occur. I have powered of my two TRADFRI bulb E27 WS opal 1000lm and after that things are working.
I have two networks with exactly the same behavour. The common ground are TRADFRI bulb E27 WS opal 1000lm.
The problem seems to be related to TRADFRI bulb E27 WS opal 1000lm. Can I get any feedback and can I provide any information to help out a solution?
I'm having some serious bugs in my setup:
Hassio deConz - lastest version
Conbee connected to USB extension cable - latest firmware
Some light nodes in my network stop responding on commands to them. The manufacturer doesn't seem to matter. It's affecting my IKEA, Philips and Osram nodes. One very intressesting fact is that if I send a group command to the node it responds perfectly. I cannot get a grip on the problem. An (for me) strange example :
If I send i read Attributes command the node is blinking blue as if it responds, but nothing happens. Even if I unplug the power (!?) the node is blinking blue if I send the read attributes command.
To me it seems like there is some kind of bug. Here are I screenshot of the node when it's unplugged (still acting as it is there):
The text was updated successfully, but these errors were encountered: