question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Possible routing issue(?): Timeout - 57587 - 1 - 246 - 513 - 4 after 10000ms

See original GitHub issue

Hi there,

I’ve got a Zigbee network with the following components:

  • Z2M 1.10.0
  • CC2531 w/ the default 1.2 20190619 firmware
  • serveral SPZB0001
  • two innr SP120
  • various Xiaomi sensors
  • various Tradfri bulbs
  • one Tradfri repeater

Today, one SPZB0001 (0xE0F3) became unreachable. It still periodically sends data requests to what it considers its parent (a Tradfri bulb 0x63B), but never gets anything back. Requests addressed to the SPZB0001 end with a timeout such as:

zigbee2mqtt:error 2020-02-10 18:14:32: Publish 'set' 'current_heating_setpoint' to 'climate.thermostat_<redacted>' failed: 'Error: Write 0x00158d0001ffb027/1 hvacThermostat({"16387":{"value":1850,"type":41}}, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":4151,"disableDefaultResponse":true}) failed (Error: Timeout - 57587 - 1 - 246 - 513 - 4 after 10000ms)'
zigbee2mqtt:debug 2020-02-10 18:14:32: Error: Write 0x00158d0001ffb027/1 hvacThermostat({"16387":{"value":1850,"type":41}}, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":4151,"disableDefaultResponse":true}) failed (Error: Timeout - 57587 - 1 - 246 - 513 - 4 after 10000ms)
    at Endpoint.<anonymous> (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:150:23)
    at Generator.throw (<anonymous>)
    at rejected (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:6:65)

Using a Zigbee sniffer I found out that the reasons seems to be that the coordinator sends the requests to 0xad22, the Tradfri repeater, which previously used to be the parent of the SPZB0001:

image

So, the request ends up on 0xad22, but the SPZB0001 0xE0F3 tries to retrieve it from 0x63B:

image

Any ideas?

Edit: Apologies if I picked the wrong project - not sure if this is zigbee-herdsman, zigbee2mqtt or firmware

Edit^2: In the network map I can see that 0x63B is considered the parent of the SPZB0001. 0x63B does not have a direct link to the coordinator, so attempting to reach it via a router would make sense. I am not that familiar with Zigbee yet, so I am uncertain whether the route should manifest in the Wireshark dump or whether I should observer any communication between the Tradfri repeater and the bulb regarding the SPZB0001.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:15 (10 by maintainers)

github_iconTop GitHub Comments

1reaction
ginkelcommented, Feb 25, 2020

Running dev with the fix included since last weekend. So far the issue hasn’t surfaced again.

1reaction
Koenkkcommented, Feb 19, 2020

Attempt to fix this is available in the latest dev branch.

After a timeout it will now do a route request and retry the command.

Read more comments on GitHub >

github_iconTop Results From Across the Web

No results found

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found