pipiche38 commented 5 years ago

If I weel understood from the Source code, the Send Data Unicast implementation is base on ZPS_eAplAfUnicastDataReq.

This means 2 things : There is no garantee that the command/data will be received by the end node, there is no feedbacks from the device if this has been received or not.

Would it be possible to have an implementation of the Unicats with the ZPS_eAplAfUnicastAckDataReq() ?

ISO-B commented 5 years ago

This is only related to command 0x0110 (Write attribute request)? Or is there other cases where this is used?

pipiche38 commented 5 years ago

No need to keep this open, as this was for my purpose and that is not needed anymore.

ISO-B commented 5 years ago

Using ack version of unicast will enable sending larger payload. Might be good idea to add new parameter to switch between ack and non ack versions

Martial83 commented 5 years ago

Hi, I have a lot of errors at home and many orders do not reach their destination. I need to know if the security of the exchanges envisaged by the zigbee protocol is implemented in the firmware or if another mechanism exists. I have, in my log domoticz, many messages of the type "Unicast frame does not have a route available but it is buffered for automatic resend" and I want to know if this "automatic resend" is done and by whom.

Do you use: ZPS_eAplAfUnicastAckDataReq() or not inside the firmware and who assume the integrity of the transmission?

ISO-B commented 5 years ago

There is no command to use ZPS_eAplAfUnicastAckDataReq(). ZPS_eAplAfUnicastDataReq() is used when requesting attributes using 0x0110 command. It is sent using ZPS_E_APL_AF_SECURE_NWK.

According JN-UG-3113 v1.2 page 203

If data is sent using this function to a destination for which a route has not already been established, the data will not be sent and a route discovery will be performed instead. In this case, the function will return ZPS_NWK_ENUM_ROUTE_ERROR and must later be re-called to send the data (see Note under “Unicast” on page 84).

I haven't looked code through but it doesn't seem that ZiGate would buffer message if you need to re-call same command again to get data sent. So I guess that maybe Domoticz buffers data. Maybe @pipiche38 can confirm this?

pipiche38 commented 5 years ago

I haven't looked code through but it doesn't seem that ZiGate would buffer message if you need to re-call same command again to get data sent. So I guess that maybe Domoticz buffers data.

This where I think the all confusion is coming ! As Zigate is sending back to plugin via 0x8702 messages which are referring to buffering for resend. That is exactly what @Martial83 is referring. And looks like this buffering is not happening !

Here is the Status Code brought by 0x8702. d4 - Unicast frame does not have a route available but it is buffered for automatic resend

I think in general everything works well. However if you have radio transmission issues ( as @Martial83 ) you are coming to situation where there are some strange and un-expected behaviours like :

You send a Command like Switch On a Plug
Nothing happen and you receive an APS Failure code 0xD4
Nothing happen
you redo the Switch On and then the Plug switch on !!!

Martial83 commented 5 years ago

Exact @pipiche38. the interest of the zigbee protocol is its security of the exchanges and the recalculation of automatic routes in the event of network incident with guarantee of the execution of the order (within the limits of timers set up), the application (domoticz) being notified of the successful completion or error. Is this is implemented in the chain domoticz - zigate -router - end device or not?

doudz commented 5 years ago

maybe on 0xD4 error we (the plugin) need to do the resend ?

Martial83 commented 5 years ago

@pipiche38 : in your example: sometimes, the plug switch On, but the response is lost and domoticz believes that the plug has not changed state

Martial83 commented 5 years ago

@doudz : why not, but the first thing is to understand how that is implemented

ISO-B commented 5 years ago

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

Also from same document page 84

An End Device which is asleep will be unable to receive a data packet directly, so the data is buffered by its parent for collection later. The End Device must explicitly request this data, once awake. This method of receiving data is called data polling and is described in Section 5.5.3.

From JN-UG-3113 v1.2 page 486

As described in Section 5.5.3, data sent to a sleeping End Device is buffered in the node’s parent until the End Device collects the data through a polling mechanism, typically on waking from sleep. It is important that the polling interval is not too long, as the buffered data will be discarded after 7 seconds. In addition, there is limited buffering space in the parent and the buffers are shared by all the children of the parent. Therefore, applications should be designed in such a way that data is only sent to a sleeping End Device when it is either awake or will wake in a timely manner to collect the data from its parent.

I looked code and it seems that part of code that handles sending that APS failure code is inside of NXP prebuilt libraries. There is no source code for those, which means that there is nothing we can do for it on firmware side. I don't know which devices will poll data after waking up, but buffer will be destroyed quite quickly(7 seconds) so I guess that not many. Data is buffered on nearest parent so it might be that device that is parent sends that 0xd4 not ZiGate. Is ZiGate direct parent for this device or not?

If somebody could test if there is different response when ZiGate is direct parent vs there is another device as parent. This would help narrowing cause.

Martial83 commented 5 years ago

@ISO-B : yes, your right, but some lines later you can see: However, equivalent functions are available which request the destination node to provide an acknowledgement of data received - these ‘with acknowledgement’ functions are ZPS_eAplAfUnicastAckDataReq() and ZPS_eAplAfUnicastIeeeAckDataReq(), requiring network and IEEE/MAC addresses respectively.

Why don't use them ?

Martial83 commented 5 years ago

I think we should not want to mix the type of devices: a device on battery can not receive order (since it sleeps most of the time), but a plug or a lamp or any actuator need to be secured

Martial83 commented 5 years ago

@ISO-B : i have some tradfri plugs directly on the zigate and other ones and lamps thru tradfri plugs and i don't see any difference

ISO-B commented 5 years ago

I don't know if there is any reason why we are currently using non Ack version of that function. @fairecasoimeme Is there reason for this? If there is not then we should try if using ack version makes desired difference.

@ISO-B : i have some tradfri plugs directly on the zigate and other ones and lamps thru tradfri plugs and i don't see any difference Good to know.

pipiche38 commented 5 years ago

maybe on 0xD4 error we (the plugin) need to do the resend ?

@doudz maybe , but we just need to agree on which layer has to do it ? And the message seems to say it is up to the ZigBee Stack

doudz commented 5 years ago

sure

Martial83 commented 5 years ago

@ISO-B @doudz @pipiche38 @fairecasoimeme I thank you all for taking care of that Am I the only one with this kind of problem?

pipiche38 commented 5 years ago

I don't know if there is any reason why we are currently using non Ack version of that function. @fairecasoimeme Is there reason for this? If there is not then we should try if using ack version makes desired difference.

@ISO-B : i have some tradfri plugs directly on the zigate and other ones and lamps thru tradfri plugs and i don't see any difference Good to know.

@ISO-B , by the way, I think that @fairecasoimeme is using APS ACK on the ZHA1.2 firmware (for pluzzy), as a new message is introduced 0x8011

pipiche38 commented 5 years ago

207

pipiche38 commented 5 years ago

I did further investigation from the plugin side, and for instance trying to resend the message. What is surprising is that if I remove (unpower the Xiamo Plug which I'm using for test) , it looks like the Stack is never learning that the device is not on the network anymore.

I suspect that could be trigger by an increase of some TimedOut value that @fairecasoimeme did to workaround the Xiaomi battery based device.

Martial83 commented 5 years ago

cas d'école de mes problèmes. Concerne la prise Pergola, connectée par 2 routes à la zigate: en direct et au travers d'une autre prise. Je ne sais pas quelle route est prise. Par domoticz, je coupe cette prise, dans domoticz la prise est bien passée au statut Off et voici la log: vous noterez que les ordres ne sont pas dans l'ordre du timestamp dans la log, d'où certaines incompréhensions 2019-07-27 15:04:54.075 (Zigate d'en bas) UpdateDevice - (Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01) 0:Off 2019-07-27 15:04:54.427 (Zigate d'en bas) timedOutDevice unit Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01 nwkid: d16b 2019-07-27 15:04:54.487 (Zigate d'en bas) Decode8701 - Route discovery has been performed, status: 00 Nwk Status: 00 2019-07-27 15:04:54.592 (Zigate d'en bas) UpdateDevice - (Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01) 0:Off 2019-07-27 15:04:54.020 Status: User: Admin initiated a switch command (825/Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01/Off) 2019-07-27 15:04:54.434 Error: (Zigate d'en bas) Command: 0x0092:On/Off failed on Prise Pergola 2019-07-27 15:04:54.434 Error: (Zigate d'en bas) - Device: Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01 NwkID: d16b IEEE: 000d6ffffe30624c 2019-07-27 15:04:54.435 Error: (Zigate d'en bas) - Code: d4 Status: Unicast frame does not have a route available but it is buffered for automatic resend Reply mais si on remet dans l'ordre des timestamps: 2019-07-27 15:04:54.020 Status: User: Admin initiated a switch command (825/Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01/Off) 2019-07-27 15:04:54.075 (Zigate d'en bas) UpdateDevice - (Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01) 0:Off 2019-07-27 15:04:54.427 (Zigate d'en bas) timedOutDevice unit Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01 nwkid: d16b 2019-07-27 15:04:54.434 Error: (Zigate d'en bas) Command: 0x0092:On/Off failed on Prise Pergola 2019-07-27 15:04:54.434 Error: (Zigate d'en bas) - Device: Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01 NwkID: d16b IEEE: 000d6ffffe30624c 2019-07-27 15:04:54.435 Error: (Zigate d'en bas) - Code: d4 Status: Unicast frame does not have a route available but it is buffered for automatic resend 2019-07-27 15:04:54.487 (Zigate d'en bas) Decode8701 - Route discovery has been performed, status: 00 Nwk Status: 00 2019-07-27 15:04:54.592 (Zigate d'en bas) UpdateDevice - (Zigate d'en bas - PERGOLA control outlet_Plug-000d6ffffe30624c-01) 0:Off paraît beaucoup plus logique: erreur au premier envoi, découverte d'une route, ordre exécuté correctement (500ms entre l'ordre donné par domoticz et son exécution réelle) donc il y a bien un mécanisme de retry qqpart! et la première erreur ne devrait pas être signalée comme tel puisque le mécanisme de retry a fonctionné. Mais si on doit découvrir par l'expérience la logique mise en oeuvre dans le firmware, on va jamais s'en sortir. Et la question reste entière: qui fait le retry, suivant quelle logique ? Et si c'était zigbee qui s'en chargeait, on n'aurait pas d'erreur

Martial83 commented 5 years ago

Bonjour, Ce qui me laisse pantois dans tout cet échange, c'est le silence de @fairecasoimeme qui ne prend pas le temps de répondre a des questions à priori simples. Est-ce que celles-ci ne sont pas claires ou sont hors de propos? Merci de répondre ou de nous expliquer pourquoi on n'a rien compris.

Martial83 commented 5 years ago

Bon, d'accord, j'ai oublié de le dire en anglais Okay, I forgot to say it in English Hello, What leaves me speechless in all this exchange is the silence of @fairecasoimeme who does not take the time to answer questions a priori simple. Are these unclear or irrelevant? Thank you for answering or explaining why we did not understand anything.

doudz commented 5 years ago

Et la question reste entière: qui fait le retry, suivant quelle logique ? Et si c'était zigbee qui s'en chargeait, on n'aurait pas d'erreur

Le fait que l'erreur remonte est une bonne chose, même si un retry est effectué par la stack zigbee de façon transparente pour l'utilisateur. Si vous ne souhaitez pas voir l'erreur, il faudrait que l'application, le plugin, qui utilise la zigate ne fasse pas apparaître cette erreur, qui d'une certaine façon est un warning et non une erreur. Car j'imagine que si le retry ne fonctionne pas il y aura un nouveau message d'erreur avec un code différent.

ISO-B commented 5 years ago

He is on vacation at the moment. As @pipiche38 noted that ACK version of command is used in Pluzzy Firmware so I don't think that there is no reason not to use it in this case too. I will try to find time this week(most likely thursday) to implement it so you can start testing with it.

I also had couple words with Pipiche and he told that after error route discovery is triggered and next command goes through successfully. So it seems that 0xd4 is wrong error code, but we can't change that since there is no source code for files that handle that part. Only thing that we can do is to try using ACK version of command to see if it solves this problem.

pipiche38 commented 5 years ago

@ISO-B if the error code is wrong, which I would agree with you, would it make sense to report it to NXP ? Is that issue not yet fixed by them ? Is the current firmware based on a latest NXP ZigBee Pro Stack version ?

Martial83 commented 5 years ago

Thank you @doudz and @ISO-B , @doudz : la question n'est pas là, mais bien sur le fait de comprendre si ce retry est réellement fait ou pas et par quelle couche réseau. @ISO-B : it's a very good new and yes @pipiche did a big and good job. Everyone needs a vacation, we can wait for @fairecasoimeme

pipiche38 commented 5 years ago

Thank you @doudz and @ISO-B , @doudz : la question n'est pas là, mais bien sur le fait de comprendre si ce retry est réellement fait ou pas et par quelle couche réseau. @ISO-B : it's a very good new and yes @PIPICHE did a big and good job. Everyone needs a vacation, we can wait for @fairecasoimeme

I'm sharing @ISO-B view, that most-likely we are getting the wrong code , OR as we do not have the APS ACK we have an incomplete view of the situation, and that is most-likely the main issue.

Let's see when we will have the APS ACK

ISO-B commented 5 years ago

As far as I know we are using latest stack version 1840, which has been released last year. We can try to report it back to NXP, but it will probably take quite long before they will do anything for it. At least based on their response times on their forum. Before they fix it if they fix it we would need some better solution.

pipiche38 commented 5 years ago

Agree, let's sorted out ourselves ... Let see how it behave with the APS ACK

pipiche38 commented 5 years ago

Did further investigation as I suspected some issue on the 'message statement itself'.

I'm not able to find from which documentation I got it and : (1) I didn't find 0xD4 documented in the NXP ZigBee Pro Stack documentation ! (2) In the Firmware source , in zps_nwk_sap.h I found 0xd4 documented as Unicast mode frame on the pending frame

On the other end, I do not understand a word on this statement

Martial83 commented 5 years ago

@pipiche38 I found it in https://www.nxp.com/docs/en/user-guide/JN-UG-3113.pdf ZigBee 3.0 StackUser Guide ZPS_NWK_ENUM_FRAME_IS_BUFFERED 0xD4 Unicast frame does not have a route available but it is buffered for automatic resend.

pipiche38 commented 5 years ago

@ISO-B

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

I think you pointed out the right things, however we knwo also that we have an issue on the New Route Discovery message ( #92 )

fairecasoimeme commented 5 years ago

Hi all, I'm back. I'll try to answer but tell me if I forget somethings.

I'm agree that we can test ack version and I'll merge @ISO-B update (thanks to you) I have to remember to you that you can't secure with 100% of success a radio transmissions. I explain myself :

When you send an acked transmission :

if you don't receive ack, you can have 2 issues : your send is not receive by the device (for multiple reasons) the ack send by device is lost (for multiple reason too) (It's the same problem from device's acked transmission)

When there are a bad PER (Packet error ratio), the first reflex is to increase retries or acknoledges all of messages. But this solution is not magic and can give opposite result that expected, particulary with radio techno which use 1 channel only (like ZigBee).

Indeed, imagine that a channel is a wire. When you send a packet, the channel is occupied and nothing can use this in the same time. Thanks to datarate and frequency, the transmission is quite quick but if you use acks and retries, you can increase the transmissions issues and finally you don't improve the network quality.

To summurize. If you have a bad network due to interferences or other things (it's an example), a busy network is a busy network and if you add traffic, you increase the phenomenon.

However, It's interesting to test with acks and retries still.

But, If there are a lot of lost messages with a ZigBee network, I think you have to improve zigbee network. But I know, the difficulty is to find where and how but It's the only good solutions.

When the PER is < 5-10%, I think the ack / retries processus can help. With more, you have to find why the network is bad.

Martial83 commented 5 years ago

Bonsoir @fairecasoimeme et merci pour la réponse. Désolé de répondre en français, mais mon anglais est assez vieux et je ne veux pas risquer de déformer mes propos. En premier, sachez que je suis totalement d'accord avec ce que vous dites et il nous faut revenir à la question du départ: Je reçois, dans ma log domoticz un message qui me dit: d4 - Unicast frame does not have a route available but it is buffered for automatic resend Donc je demande: Qui fait ce automatic resend, et comment, moi utilisateur, vais-je être prévenu et quand, s'il s'est bien déroulé ou pas ? Là-dessus, je comprends (peut-être à tort) que le firmware utilise, dans le cas cité en exemple, une fonction non sécurisée de la stack zigbee et je demande pourquoi, rien de plus. Donc, avant de vouloir faire des retry ou pas, il faut comprendre qui fait quoi et comment, sans pour autant remettre en cause qui que ce soit. Ceci étant dit, un grand merci à @pipiche38 qui a fait beaucoup pour essayer de comprendre mes problèmes et de les résoudre. Donc pour résumer: que l'on me dise: le protocole a fait tout ce qu'il pouvait, mais tu as trop de perturbations chez toi et l'ordre ne peut pas être exécuté ne me choque pas, à moi de décider quoi faire, mais qu'on me le dise clairement après que je sois certain que le nécessaire a bien été fait (je rappelle que zigbee est supposé être sécurisé, redondant grace aux maillage avec recalcul automatique des routes, etc ). Désolé d'avoir été aussi long ... et merci à tous pour vos efforts. Concernant mon réseau personnel: j'y ai ajouté 3 prises Tradfri qui doivent servir de router de même que 6 lampes Gledopto, j'y ai ajouté un module cc2530+CC2591, puis j'ai ajouté une antenne externe à ma pizigate tout cela pour une villa de 150m2, sur 2 niveaux principaux.

fairecasoimeme commented 5 years ago

Bonjour, Je ne peux pas être sur à 100% mais il me semble que les retries sont gérés pas la stack mais difficile à vérifier car c'est gérés dans les couches basses de la stack et nous n'avons pas accès à tout. Cependant, il y a des indices.. dans le fichier zps_apl_aib.h il y a :

define apscMaxFrameRetries (3UL)

Dans le cas du message d4, dû à des problèmes de route, c'est la ZiGate qui s'en occupe et doit s'en occuper car c'est un message bas niveau. Pour la question, si vous allez être averti, sans acquittement, c'est impossible et avec acquittement pas fiable à 100%. il faut plus partir sur du polling de device pour connaître son état... (mais ça augmente encore le trafic)

Les nombreux messages d4 sont dû à un problème de communication. Les routes sont régulièrement mises à jour et si la communication est mauvaise la route est perdue. Même si la ZiGate, renvoie des demandes de route discovery et des retries, si la communications est trop mauvaise et bien, il y a de grande chance que la "sécurisation" de l'envoie ne change pas grand chose (voir l'empire).

Le Zigbee est sécurisé mais ne peut pas garantir (comme tous les techno radio) 100% de succès. Il ne faut pas oublier que le ZigBee est low power et qu'il n'a pas la puissance du WiFi et des couches jusqu'au TCP. Le protocole ZigBee est beaucoup moins baveux sécurisé etc ... son but est de gérer des infos simples et courtes. Il n'y a pas de grand mécanisme de correction d'erreurs etc...

Du coup si l'environnement n'est pas bon, et bien il va essayer de récupérer mais jusqu'à un certain point. D'ailleurs, côté WiFi, chez vous, quel est votre débit ? en comparaison avec ces capacités ? (Pouvez-vous faire le test en transférant un fichier à travers le WiFi ?)

Me concernant, je pense que je n'ai jamais changé de ligne sur le diagnostique. Cependant, même si on a l'air d'expert, on peut aussi se tromper. Nous ne connaissons pas tout du protocole et ne maitrisons pas votre environnement. Du coup, c'est très difficile d'être catégorique sur votre problème. Nous donnons des pistes et pour moi les pistes ont toujours été les mêmes.

Le 2.4ghz et à faible puissance traverse difficilement les murs, un sous-sol n'est pas optimal (humidité et peu d'ouvertures) mais ça n'explique peut-être pas tout.

Je peux aussi vous proposez de tester la ZiGate-WiFi qui vous permettrait de placer la ZiGate à un endroit plus stratégique et peut-être aussi, par chance, vous éloigner de perturbations.

Voilà mon analyse.

pipiche38 commented 5 years ago

@fairecasoimeme merci de ton commentaire.

Sur l'erreur 0xd4 je partage ton analyse, mais ce qu'on observe, c'est que si on fait un retry - que l'on ne devrait pas faire - au niveau plugin, il apparait que le retry passe et notament vient s'intercaler un Route Discovery Success.

En voyant ça , on a un doute sur le fait que la stack fait bien un retry. A priori un Route Discovery semble bien etre declenché, mais rien sur le retry ..

En tout les cas c'est les observations.

pipiche38 commented 5 years ago

When there are a bad PER (Packet error ratio), the first reflex is to increase retries or acknoledges all of messages. But this solution is not magic and can give opposite result that expected, particulary with radio techno which use 1 channel only (like ZigBee).

@fairecasoimeme is that something to be done at Zigate or App level ?

Martial83 commented 5 years ago

Merci à tous pour vos commentaires. Oui, le wifi chez moi fonctionne, mais avec une portée ridicule (j'ai donc installé un répéteur WIFI). Ma box est au s/sol, comme ma zigate. Je sais pertinemment que chez moi, les signaux ont du mal à passer, c'est pour cela que, après avoir changé les canaux sur ma zigate et sur mon wifi, je me suis équipé de prises Tradfri, d'ampoules Gledopto et d'un routeur cc2530 et, en plus, j'ai soudé une prise ufl sur ma zigate et y ais mis une antenne 2,4Ghz. Ce qui me gène, ce n'est pas tant que ça les erreurs et les retry gérés par le zigbee, mais c'est que autant d'ordres ne s'exécutent pas. Pour le message d4, s'il est interne et géré par la zigate, pourquoi et quand est-il remonté à Domoticz ? Si c'est au bout des 3 retries, ce ne devrait plus être ce message (de bas niveau), mais un message venant de la zigate pour dire que, après 3 retries, elle n'a tjrs pas pu exécuter l'orde.

Je me permet également de m'élever en faux sur ce paragraphe: Il ne faut pas oublier que le ZigBee est low power et qu'il n'a pas la puissance du WiFi et des couches jusqu'au TCP. Le protocole ZigBee est beaucoup moins baveux sécurisé etc ... son but est de gérer des infos simples et courtes. Il n'y a pas de grand mécanisme de correction d'erreurs etc... en vous renvoyant aux documentations existantes sur le zigbee, par exemple dans https://www.nxp.com/docs/en/user-guide/JN-UG-3113.pdf , je vous encourage à lire la page 29 (trop long pour être reproduit ici). De même, je ne peux pas admettre cette réponse:Pour la question, si vous allez être averti, sans acquittement, c'est impossible et avec acquittement pas fiable à 100%. il faut plus partir sur du polling de device pour connaître son état... (mais ça augmente encore le trafic) puisque le protocole est fait pour ça. La couche finale (l'utilisateur par l'ihm de domoticz) DOIT être prévenu si un ordre n'a pu être exécuté ou s'il y a un doute sur sa bonne fin. Il faut donc travailler exclusivement Avec Acquittement. Je rappelle que le zigbee a la prétention d'être utilisé dans l'industrie, là où l'à peu pres n'existe pas, même si nous ce n'est jamais que de la domotique.

Ceci n'est pas, dans mon esprit, une critique du travail qui a été fait, loin de là, mais j'essaye de comprendre, d'exposer mon point de vue, et peut-être faire progresser l'ensemble (moi y compris) Cordialement

fairecasoimeme commented 5 years ago

Si votre WiFi a une portée ridicule et que vous devez rajouter un répéteur, ça confirme donc ce que je dis.

Peu importe le nombre de routeurs que vous avez installé, si votre environnement est perturbé et apparemment il l'est beaucoup, y a pas grand chose qui passe. Y a rien d'étonnant que beaucoup d'ordres ne passent pas.

Exemple: remplissez une bouteille d'eau et faite un petit trou en bas. vous remplissez votre bouteille et quand elle déborde, elle déborde... En rajoutant de l'eau (des ordres) ça ne va pas mieux passer

Ou vous êtes sur l'autoroute des vacances et y a des bouchons, plus personnes avancent, est-ce qu'en rajoutant des voitures (des ordres) que ça va avancer plus vite ou que ça arrivera à destination.

le message d4 est remonté à domoticz directement lorsqu'il est généré. Je ne l'ai peut-être pas précisé mais les retries sont gérés que si les acquittements sont gérés (reste encore à l'implémenter et voir si c'est géré)

Merci pour le rappel à la documentation que je connais. Elle ne remet pas en cause ce que je dis et comparez avec avec les docs WiFi + TCP sur les corrections d'erreurs. Je vous garanti que ça n'a rien à voir. Je n'ai jamais dit qu'il n'y avait pas de mécanismes de corrections d'erreurs pour gérer les interférences ou des environnements bruités. Mais je peux vous assurer qu'il y a des limites. Et si vous reprenez l'exemple de la bouteille ou des bouchons sur l'autoroute, comment ces mécanismes vont changer la donne. Pour rappel, une trame zigbee ne peut pas dépasser 127 octets alors que TCP c'est 1500.

Comme je l'ai déjà dit, on peut tester l'ajout d'acquittement mais je pense que ça ne changera rien chez vous (voir ça empirera). D'ailleurs si c'est l'acquittement qui est perdu, on renvoie une nouvelle commande ? et s'il c'est elle qui est perdue ensuite ? bref, ça n'en fini jamais et vous ne connaitrez jamais l'état de votre device. Assurément, l'acquittement résoudra votre problème.

Travaillant dans l'industrie, en aucun cas le zigbee est un protocole radio utilisé. En industrie, on priorise le câblage et quand ce n'est pas possible (là où l' à peu près est toléré) on n'utilise pas de ZigBee.

Vous ne critiquez pas notre travail, et vous avez le droit d'émettre des avis, conseils etc ... tout est bon à prendre... Mais je pense que vous vous trompez de combat. Vous vous focalisez sur un faux problème de firmware ou de protocole (qui est éprouvé) que vous êtes quasi seul à avoir sur 3000 ZiGate installés. Vous devriez vous concentrez un peu plus sur la résolution de vos problèmes d'interférences et être à l'écoute de mes conseils et propositions déjà donnés à plusieurs reprises.

sortir le Zigbee du sous-sol et voir si ça fonctionne mieux
sortir/couper le wifi et voir si ça fonctionne mieux
couper le répéteur et voir les évolutions
faire la liste des appareils pouvant provoquer des interférences et les éteindre un à un pour voir si ça change
faire des tests hors maison pour savoir si le problème est dans la maison ou l'extérieur.

Je pense que tout ces tests vous permettront de mettre en évidence l'élément perturbateur. Et si rien n'y fait, c'est que le zigbee n'est pas adapté à votre environnement.

L'ajout d'acquittement sera surement du confort et de fiabilisation pour ce qui n'ont pas beaucoup de perturbations (il y en a toujours) mais pour vous ça risque de s'empirer.

Encore une fois libre à vous de suivre mes conseils mais je vous avoue que ça commence à m'épuiser de répéter toujours les mêmes choses sans être pris au sérieux.

Fred

Martial83 commented 5 years ago

Merci et je répète que je suis totalement d'accord avec vos remarques sur la qualité de mon propre réseau que je ne néglige absolument pas. Tout ce que je souhaite, c'est que l'info remonte dans l'ihm pour me permettre de prendre les bonnes décisions et je retiens votre phrase le message d4 est remonté à domoticz directement lorsqu'il est généré. Je ne l'ai peut-être pas précisé **mais les retries sont gérés que si les acquittements sont gérés (reste encore à l'implémenter et voir si c'est géré**) et là nous sommes complètement en accord et c'est bien ma question de départ. Concernant mon taux d'erreurs, il a drastiquement diminué avec mes différents ajouts, je n'en n'ai plus que 2 ou 3 par jour et compte bien, dès que je serai en mesure de le faire, déplacer ma zigate (elle est au s/sol car pas encore intégrée à ma production et elle ne le sera que quand je serai sûr d'en maitriser le fonctionnement)

Pour le zigbee et l'industrie vous pouvez voir: http://www.adwave.fr/industrie.php, bien sûr c'est de la pub, mais la volonté existe réellement. Donc, oubliez la qualité de mon réseau, et voyez, si c'est possible, ce que peut nécessiter cette mise en place des acquittements et s'il elle est opportune bien évidemment. je suis totalement prêt à aider et à participer (avec mes moyens) à tout ceci.

Martial83 commented 5 years ago

En complément et concernant votre liste de conseils: bien évidemment je les considère comme judicieux et j'ai déjà implémenté et testé la majorité d'entre eux et même d'autres, et voici les premiers résultats

sortir le Zigbee du sous-sol et voir si ça fonctionne mieux --> impossible pour le moment
sortir/couper le wifi et voir si ça fonctionne mieux --> fait et même un changement de canal: aucune amélioration
couper le répéteur et voir les évolutions --> le répéteur a été mis en oeuvre récemment et a amélioré la qualité du réseau
faire la liste des appareils pouvant provoquer des interférences et les éteindre un à un pour voir si ça change --> cela a déjà été fait, mais peu peut-être être complété
faire des tests hors maison pour savoir si le problème est dans la maison ou l'extérieur --> c'est le cas: une prise Trafdri communiquant très bien avec la zigate est en visée directe (entre 2 et 10m, sans mur ni rien) avec 4 lampes extérieures et il y a des pertes d'info (une lampe refusant de s'allumer par exemple) Mais tout ceci n'est pas l'objectif de mes interrogations

pipiche38 commented 5 years ago

@fairecasoimeme

le message d4 est remonté à domoticz directement lorsqu'il est généré. Je ne l'ai peut-être pas précisé mais les retries sont gérés que si les acquittements sont gérés (reste encore à l'implémenter et voir si c'est géré)

C'est une excellente nouvelle, car du coup on a une explication sur le comportement.

fairecasoimeme commented 5 years ago

So, I restarted from begining. I re read the source code and I confirm that the transmission from ZiGate use ZPS_eAplAfUnicastAckDataReq. As @ISO-B said, only command 0x0110 didn't use acked transmission. To send ack or non ack packet, we have to play with addressMode. When It's 0x02, It's a acked transmission when It's 0x07, It's a NoAck transmission. But, by default, we only use 0x02 address mode.

We can find all in eZCL_TransmitDataRequest from zcl_transmit.c file

I have to do some specifics tests because we melted a lot of informations and we have to clarify.

@Martial83 If you have only 3 errors by day, It's not the same thing that "a lot of errors". I didn't understand that...

To summurize:

I'll determine (with sniffer) if the transmit messages from ZiGate is really acked .
I'll try to understand (with sniffer) route discovery message and retries from ZiGate

I'll share results and we'll rediscuss on it.

The problem is that I'll could do the job only from 20 august.

Fred

Martial83 commented 5 years ago

Thank you Fred @fairecasoimeme , I had a lot of errors, but since my additions to the network (Tradfri, lamps, a router and an antenna on the pizigate), the number of errors has fallen dramatically. There is no urgency in these problems. The important thing is to understand each other. Of course, if all networks were error-free, life would be too easy. With @pipiche38, we are working on others strange behavior. I let you go back some points if he deems it necessary Martial

fairecasoimeme commented 5 years ago

Well that's it, I did a lot of tests to understand a little better routing.

To the question, are the actions of ZiGate already acked ? The answer is yes : ack

This is an example but the ZiGate will try to reach its target 16 times before giving up. ack routeur

This is for the direct connected objects to the ZiGate.

Let's see the routing now. I do the following operation:

1 ZiGate
1 Ikea router
1 Ikea connected socket (router too) I use only ikea to limit possibles issues

When all it's OK :

test_2_routeurs

We can clearly see the different frames sent and routed by each one. Then, I changed architecture and we also see the routing of datas from router to router. test4_2routeurs_trames

Between each route, the command is acknowledged correctly.

Now, I remove the central router: 0x8912 and here is what happens: test5_sans_routeurikea_toggle_prise_E9_D42

I am trying to do some action on the connected socket 0xAC2C We find the 16 attempts of the ZiGate to reach the first router 0x8912. On ZiGate side we find the command 0x8702 with the status 0xE9 MAC_ENUM_NO_ACK (No acknowledgement received when expected) After, when we send a new action, we receive this :

test5_sans_routeurikea_toggle_prise_E9_D4_3

We can see the famous "route discovery" command. ZiGate attempt 4 times to get good route. This is the 0xD4 status from 0x8072 command.

As we can see, Zigbee protocol use secure mechanism and we don't need to add other things about that. The low layers of the protocol do the job.

BUT when I replug the central router, I observe, sometimes, a strange thing.

1_zwgui

We can observe that the command passed but after, some messages are not good as if the command did not pass. It's a little bit strange and it's occur only one time after router replugged. It's seems to be a little desynchronisation but I think this could cause problems with plugins and this phenomenal can be increased when the network is not good.

For this kind of issue, i think the only thing we can do from ZiGate is to create a better acked status than now. The protocol play with acked MAC part, but this info is not used. I don't know how to proceed yet, but if we imagine to exploit this, I thinks this could be better.

Fred

Martial83 commented 5 years ago

Bonjour Fred et merci pour ces tests. Je vais analyser cela en détail pour être sûr de bien comprendre, mais la 1ère question qui me vient est concernant

I am trying to do some action on the connected socket 0xAC2C
We find the 16 attempts of the ZiGate to reach the first router 0x8912. On ZiGate side we find the command 0x8702 with the status 0xE9 MAC_ENUM_NO_ACK (No acknowledgement received when expected)
After, when we send a new action, we receive this :

Pourquoi doit-on renvoyer l'action pour qu'il découvre la nouvelle route? A noter que je ne vous ai absolument pas sollicité ni vous @fairecasoimeme ni @pipiche38 pendant cette période pour ne pas ajouter des pb à d'autres problèmes mais je suis en face de 2 points étranges

plus aucune erreur dans la log ni sur les widgets domoticz, même et surtout quand l'ordre n'est pas exécuté.
au moins une ampoule ne réagit pas aux ordres envoyés depuis le widget, mais répond très bien à une commande groupée! Encore merci pour tous ces éléments et désolé pour les anglophone, mais mon anglais est tellement mauvais (et google translate étant qqfois loin de bien exprimer nos phrases en français) que j'ai peur de ne pas me comprendre moi-même

Again thank you for all these elements and sorry for the French, but my English is so bad (and google translate being sometimes far from well express our sentences) that I'm afraid not to understand myself

Best regards

fairecasoimeme commented 5 years ago

Non, ce sont des actions manuelles que j'ai effectué. Après avoir débranché le routeur, la première commande envoyée engendre le status 0xe9. Puis si je refais la même action, c'est le status 0xd4.

La première fois il signifie que les 16 retries n'ont rien donné. Du coup, j'imagine que la route est supprimée. la deuxième fois c'est un route discovery qui n'aboutit pas.

Fred

Martial83 commented 5 years ago

Merci pour l’éclaircissement: j'avais mal compris ! Et oui, on voit clairement que le protocole fait bien les retries et semble chercher une nouvelle route, mais comme David Vincent, que jamais il ne trouva: c'est rassurant! Je ne suis pas resté inactif pendant cette période et j'ai dernièrement mis mon router à 50 cm de ma zigate. Les résultats sont mitigés: certaines route se sont considérablement améliorées, mais d'autre se sont dégradées sans que j'y trouve une logique. PS: je suppose que vos traces ne sortent pas par le plugin? Sinon, ça serait intéressant que je mette les mêmes chez moi. A+

fairecasoimeme / ZiGate

Ack Unicast implementation #106

207

define apscMaxFrameRetries (3UL)