Zigbee2mqtt: proper handling of error 205

Created on 14 Jun 2019  路  11Comments  路  Source: Koenkk/zigbee2mqtt

Current behaviour is ZNP, when there is no route to the end-device, just fails transfer with error 205. And Z2M reports.

Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.

And nothing else is happening and request is lost.

I don't think this in acceptable for coordinator. There might be various reasons why there is no entry in the routing table just at this particular moment. And, very often, repeating request just fraction of second later works, as route is discovered in the mean time (or routing table gets fixed)
I know that all routes are supposed to be there and bla-bla-bla. But this is what it is. And, it looks like this is inevitable with ZNP. Even on CC2538 with much more memory it happens time to time. (And more and more I suspect that there is also bug in ZNP code, for both 1.22 and 3.3 stacks, so it can be conceptual bug, most likely something with race conditions)

So, I think that (for coordinator) correct behaviour (in case there no route) must be to either issue route request in ZNP at least once, and only then fail after time-out, if route wasn't discovered, or Z2M should try to resend request, after some time-out, in case of error 205. And fail only after few retries.

stale

Most helpful comment

This could be implemented easily here: https://github.com/Koenkk/zigbee2mqtt/blob/master/lib/util/zigbeeQueue.js#L43

I also was thinking about it yesterday.

BTW, there is also option to decrease general delay, but to add delay in this part of the code for request repeat, when error 17 is hit. I am testing this now.

All 11 comments

And, by the way, can we retrieve from coordinator routing table? To actually know routes to devices.
Network map is nice, but it has all-to-all links. Would be nice to know how data is actually passing.

I think this message should be sent to the TI-forum

I think this message should be sent to the TI-forum

They aware, it was discussed in the forum.

This could be implemented easily here: https://github.com/Koenkk/zigbee2mqtt/blob/master/lib/util/zigbeeQueue.js#L43

I also was thinking about it yesterday.

BTW, there is also option to decrease general delay, but to add delay in this part of the code for request repeat, when error 17 is hit. I am testing this now.

How do you do atomic writes/reads in JS?
I think we need to define
delay_min=50
delay_max=300

And we need to start with delay=delay_min, then once we hit error 17, then we increase delay (for all workers), and once it is not error 17, then we decrease delay back. Step can be 50 or 100.

And for error 205 we have to do 3 retries, before we give up, with increasing delay (200-1000ms) only for current worker.

Can we trigger route request from host?

And, by the way, can we retrieve from coordinator routing table? To actually know routes to devices.
Network map is nice, but it has all-to-all links. Would be nice to know how data is actually passing.

Routes are now shown on the network map (dev branch) https://github.com/Koenkk/zigbee2mqtt/pull/1641
Routing table isn't just on the coordinator though. Each router also holds its own routing table.

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.

Was this page helpful?
0 / 5 - 0 ratings