Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xiaomi devices leave instead of rejoin #349

Open
G1K opened this issue Jan 14, 2021 · 15 comments
Open

Xiaomi devices leave instead of rejoin #349

G1K opened this issue Jan 14, 2021 · 15 comments

Comments

@G1K
Copy link

G1K commented Jan 14, 2021

At one time there was a very long discussion of a similar problem. #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?

@pipiche38
Copy link

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.

@G1K
Copy link
Author

G1K commented Jan 14, 2021

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.

@pipiche38
Copy link

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

@fairecasoimeme
Copy link
Owner

@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.

@G1K
Copy link
Author

G1K commented Jan 21, 2021

What is the way out of this situation? As far as I know, there is no such behavior on xiaomi gateways.

@fairecasoimeme
Copy link
Owner

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

@G1K
Copy link
Author

G1K commented Jan 21, 2021

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.

@fairecasoimeme
Copy link
Owner

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 added a commit to openlumi/JN-ZigbeeNodeControlBridge-firmware that referenced this issue Feb 21, 2021
@pipiche38
Copy link

@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

@itProfi
Copy link

itProfi commented Mar 8, 2021

Maybe this help?
https://community.nxp.com/t5/Wireless-Connectivity/zigbee-rejoin/m-p/1159471#M10206
But i not C++ programmer (

@pipiche38
Copy link

@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.

@itProfi
Copy link

itProfi commented Mar 8, 2021

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..

@pipiche38
Copy link

pipiche38 commented Mar 8, 2021 via email

@pipiche38
Copy link

@itProfi @G1K did you make progress ? and got some explanation ?

@samsam-rolon
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants