Question concernant: Code: d4 Status: Unicast frame does not have a route available but it is buffered for automatic resend

[Martial83]

Bonjour,
Dans mes logs domoticz j'ai souvent ce type de message et l'ordre passé n'arrive pas au destinataire, alors que si je le renouvelle moi-même (à la main ou pas script) l'ordre passe.
Question: qui va faire le resend indiqué, quand ... et peut-on en avoir la trace dans la log?
Cordialement

[pipiche38]

As discussed on #106, we have implemented inside the plugin a resend mechanism when receiving an APS Failure 0xd4 and a New Discovery Route Success is reported.

However, I did some test with a Xiaomi Plug, and if I'm unplugin this device and sending a On or Off, then I'm entering in a kind of infinite loop as it looks like the Zigate is finding a new route (outside of this device). As The new Discovery Route 0x8701 is not bringing any reference to an end device, there is no way to filter nor limit.

CC: @fairecasoimeme , @Martial83 , @ISO-B

[fairecasoimeme]

Warning,
When you use retries, you have to limit number of retries (max 3) even if you receive another APS failure 0xd4.

You can't use retry packet depending only of this kind of error.

[pipiche38]

What do you mean we can retries more than 3 times ? Did we get an error, as from my tests, I didn't and I was more in an infinite loop and receive 0xd4 followed by Success Route Discovery.

So again as pointed my Martial, I think we need really to understand what is the meaning of 0xd4? Is the retry relevant to the Application/PLugin, is the retry relevant to the Firmware integration, or simply is the retry not implemented and we have a bugy function.

[fairecasoimeme]

I mean that we must not do more than 3-4 retries because we will sature the channel. but nothing forbids doing it (technicaly) and the risk is the infinite loop. It's not good.

I think d4 messages is due to route lost due to communication problem. I think we can test the effect of ack message, it's interesting to see the new behaviour. But i'm pessimist with it. I think d4 flood messages is not a firmware bug or other thing. simply a communication issue.

But may be i'm false. I can't confirm with 100%

[pipiche38]

@fairecasoimeme , in fact in the implementation I did, the retry (or resend) is done only when received a Discovery Route Success ( 0x8701 ), so it was not really flooding the channel.

However, @ISO-B mentioned in #106

From JN-UG-3101 v1.5 page 80

Note: If a message is unicast to a destination for which a route has not already been established, the message will not be sent and a route discovery will be performed instead. If this is the case, the unicast function will return ZPS_NWK_ENUM_ROUTE_ERROR. The application must then wait for the stack event ZPS_EVENT_NWK_ROUTE_DISCOVERY_CONFIRM (success or failure) before attempting to re-send the message by calling the same unicast function again.

ZPS_NWK_ENUM_ROUTE_ERROR = 0xd1
ZPS_EVENT_NWK_ROUTE_DISCOVERY_CONFIRM = 0x0e

And in that particular case, I understand this is the App responsability to do the retry.

[fairecasoimeme]

I think that in this case, you can do as the documentation say. But don't forget to place a maximum number of retries to avoid infinite loop and flood.
Fred.