-
Notifications
You must be signed in to change notification settings - Fork 59
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
Comments
My understanding was it was no effect to the Xiaomi. |
In my tests, it affected. If the coordinator does not say Leave , the sensor or button remains online and successfully communicates further. |
You have a number of routers doing that, I have brought that issue to Legrand-Netamo as they do so. |
@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). |
I use just xiaomi gateway with zigate firmware, and it seems to reproduce this behavior. 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.
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? |
@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 |
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 ***@***.***> 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 <#349 (comment)>, 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 :-) |
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
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?
The text was updated successfully, but these errors were encountered: