Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removes the EmberZNet
APS_OPTION_RETRY
flag and moves retries into zigpy. A simple patch to zigpy is required: zigpy/zigpy@dev...puddly:zigpy:puddly/application-level-retriesThis will allow us to provide slightly more useful error codes (e.g.
MAC_INDIRECT_TIMEOUT
) and unblock the implicit transmit queue for each device, which can get blocked for 30+ seconds per request.One issue with this type of introspection is that there genuinely aren't more status codes to return to the user: other than channel access failures or a missed APS ACK (which EmberZNet doesn't allow you to enable!), failures during delivery more or less are just that. Unless a routing device decides to broadcast a routing failure status (e.g. just
MAC_INDIRECT_TIMEOUT
), we really have no way to determine why an individual request failed like this. I'm working around this issue by just blindly assuming that status codes are received in the order the request was sent out. Realistically, I don't think it matters because two requests sent at the same time likely will both fail or both succeed.I'm testing this change locally without any issues, even with intentionally disconnected devices (both mains-powered and battery-powered), so I think this approach may have promise.