-
Notifications
You must be signed in to change notification settings - Fork 93
Fixes for low performance HA servers #555
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
Fixes for low performance HA servers #555
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR as always <3.
Co-authored-by: Bander <[email protected]>
Co-authored-by: Bander <[email protected]>
Co-authored-by: Bander <[email protected]>
Just FYI, yesterday in my home a source of 2.4GHz interference appeared, leading to high packet loss via WiFi connections. The interference is not continuous: there are some seconds pulses every some minutes. I'm logging calculated delays, if they are big: delta = (time.monotonic() - start) - HEARTBEAT_INTERVAL
if delta > (11-HEARTBEAT_INTERVAL):
self.info(f"Delta {delta} fails {fail_attempt}")
delta = max(0, min(delta, HEARTBEAT_INTERVAL)) Here is extraction from my logs:
"fails 0" means no timeout waiting for a response, even when the delay > 5 seconds. But, if it was not the introduced sleep time correction, some devices might close connections as not active. Now all work just fine! |
For me, it looks like finished. |
I'm yet to find time to update to HA Core 2025.x, and to incorporate your many changes to LocalTuya :(
Meanwhile, I ran many tests with low performance HA server, and, as the result, these are related fixes. I suggest to read commit by commit: they all should be understandable. Yes, I saw all the fixed misbehaviors in real life!
Yes, I saw successful connects after 4.5 seconds. But, regardless, making
TIMEOUT_CONNECT
(was 3) less thanTIMEOUT_REPLY
has not much sense: usually connect is even longer process.I've changed
HEARTBEAT_INTERVAL
to 8.3 because 83 is a big enough prime number. Making periodic tasks with periods of prime numbers decrease the chance of "crowded" periodic events across the whole system.