ZiGate
ZiGate copied to clipboard
fairecasoimeme
Xiaomi devices leave instead of rejoin
At one time there was a very long discussion of a similar problem. https://github.com/fairecasoimeme/ZiGate/issues/38
It seems then a fix was made with an increase in the timeout ~ 3.0e
//#define ZED_TIMEOUT_INDEX_DEFAULT ZED_TIMEOUT_256_MIN
//MODIF FRED Pour les loupés de transmissions XIAOMI (ne corrige pas mais limite le PB)
#define ZED_TIMEOUT_INDEX_DEFAULT ZED_TIMEOUT_16384_MIN
https://github.com/fairecasoimeme/ZiGate/blame/4c6fa257c66215c34849e0030ede610fb03f8c6a/Module%20Radio/Firmware/src/sdk/JN-SW-4170/Components/ZPSNWK/Include/zps_nwk_nib.h#L120-L122
But as of version 3.1b https://github.com/fairecasoimeme/ZiGate/blame/master/Module%20Radio/Firmware/README.md#L46 , this behavior has been reverted back to 256 minutes. As a result, if the device did not show signs of life for 4 hours, then the coordinator will kick it out of the network and ask to restart it, but not all devices come back. In the exchange protocol, we see only a message about the exit from the network, but not about the fact that the exit was initiated by the coordinator himself.
https://github.com/fairecasoimeme/ZiGate/blob/master/Module%20Radio/Firmware/src/sdk/JN-SW-4170/Components/ZPSNWK/Include/zps_nwk_nib.h#L120-L122
@fairecasoimeme I could not find anywhere why such a decision was made, please tell me?
My understanding was it was no effect to the Xiaomi. Basically this is due to a bug on Xiaomi devices whcih when the receive from a router a Leave + Rejoin are leaving without rejoining and a manual reset must be done on the Xiaomi.
In my tests, it affected. If the coordinator does not say Leave , the sensor or button remains online and successfully communicates further. They don't come back, but you don't have to tell them to come out. Re-pair a mountain of sensors or a remote control that is in deep sleep mode before pressing the button.
You have a number of routers doing that, I have brought that issue to Legrand-Netamo as they do so. A router can decide that a ZED should leave the network to rejoin this is part of the Zigbee standard. The issue is Xiaomi didn't implement the Rejoin when receiving a Leave command
@pipiche38 is right, Xiaomi aqara implement a false rejoin procedure. When a Xiaomi decide to leave due to non activities, It should execute a rejoin procedure but no, It pass in sleep mode directly.
What is the way out of this situation? As far as I know, there is no such behavior on xiaomi gateways.
To my knowledge, no way out. I was sniffed for a long time, Xiaomi gateway with aqara sensor and I don't see any special packet for that. I finished to succeed to lose a sensor with no rejoin procedure too. (I put aluminium paper to reduce the radio power). So, the only difference is radio power between Xiaomi gateway and ZiGate. If someone find an explication, i will be happy but I think there is not any. Fred
I use just xiaomi gateway with zigate firmware, and it seems to reproduce this behavior. A few details and instructions are here. https://github.com/openlumi/openlumi.github.io
Now I'm testing a clean example from NXP with which zigate starts, we'll look at the results later.
Ooh, It's interesting.... If you can reproduce, It means that there is a way to stop this.
Now I'm testing a clean example from NXP with which zigate starts, we'll look at the results later.
To my mind, there will be the same issue.
@G1K I do not understand the purpose of extending from 4 hours to more than 11 days, while any Xiaomi end device send an APS message at least every 50 minutes.
Without this change we have no issue with Xiaomi/Aqara devices.
Or you are doing test with a Lumi device that I don't know. Could you please clarify and also clarify how you are doing the test, as indeed, if you remove for instance the battery of the device then you are testing an other topic
Maybe this help? https://community.nxp.com/t5/Wireless-Connectivity/zigbee-rejoin/m-p/1159471#M10206 But i not C++ programmer (
@itProfi @G1K I think that you are then referring to a Xiaomi which going to stay Off for more than 4 hours (like a battery outage) I would tend to agree this was the fix which has been removed in 31e. Ok
But the main problem of Xiaomi getting removed from the network is not that issue, it is that they go a Leave request (with rejoin) from the router they are connected to and they leave but NEVER rejoin.
But if the Xioami problem, why 6 pcs Xiaomi door sensor works perfectly on DIY firmware ZESP https://t.me/zesp32 I try many times off Lumi Coordinator (based on jn5169) and no one leave the network. I think (not sure) this firmware based on NXP Zigbee HA..
I have 7 Lumi.Weather on a ZiGate across my home on firmware 31d, and no leave as well, as soon as they are on a router which doesn’t send any Leave/Rejoin (which was the case with the Netatmo-Legrand router and for which I reported the issue).
So yes, the point you are referring is that if I remove the battery of the Xiaomi by 5 hours or more and then I bring a new battery then the Xiaomi will be kick-out due to the parameter you are referring.
But that is not the main issue, the main issue is when a router is requesting a device to leave with rejoin (because the Link Quality is not good for example), then the Xiaomi do not return to the network, because they indeed leave but don’t rejoin.
On 8 Mar 2021, at 21:44, itProfi [email protected] wrote:
But if the Xioami problem, why 6 pcs Xiaomi door sensor works perfectly on DIY firmware ZESP https://t.me/zesp32 https://t.me/zesp32 I try many times off Lumi Coordinator (based on jn5169) and no on leave the network. I think (not sure) this firmware based on NXP Zigbee HA..
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fairecasoimeme/ZiGate/issues/349#issuecomment-793063410, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7IKWUGXE6X4U6IAHSLH3LTCUZLPANCNFSM4WC5E73Q.
I just sold all my Xiaomi devices. I'm mooving to SonOff, Zigbee 3.0 compliant :-) I still follow the thread because I'm very intrested
