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

Work around slow discovery procedure #125

Conversation

NanoSector
Copy link

The rate at which this library fires requests at inverters seems too high for the Pocket Wifi to handle, so it eventually locks up and this causes a timeout (perhaps only on inverters which are lower in the inverter list?). Fire requests at a slightly lower rate to prevent this.

I noticed there is a PR in progress which revamps the discovery procedure, but in the meantime this can be a workaround for those using the library in e.g. Home Assistant's integration.

I have tested this with a Solax X3-MIC-10K-G2 inverter and a Pocket Wifi 3.0 (firmware in UI is 3.001.02, firmware from response is 3.008.10). Lower values do not consistently fix the issue (I have tried 0.5 and 0.75).

Credit goes to @joostlek who pointed me at this workaround.

The rate at which this library fires requests at inverters seems too high for the Pocket Wifi to handle, so it eventually locks up and this causes a timeout (perhaps only on inverters which are lower in the inverter list?). Fire requests at a slightly lower rate to prevent this.

I noticed there is a PR in progress which revamps the discovery procedure, but in the meantime this can be a workaround for those using the library in e.g. Home Assistant's integration.

I have tested this with a Solax X3-MIC-10K-G2 inverter and a Pocket Wifi 3.0 (firmware in UI is 3.001.02, firmware from response is 3.008.10). Lower values do not consistently fix the issue (I have tried 0.5 and 0.75).

Credit goes to @joostlek who pointed me at this workaround.
@squishykid
Copy link
Owner

Thanks for taking the time to raise a PR, I really appreciate it. At the moment I’m looking to focus on the approach in #116, since it will only fire a maximum of 4 requests during discovery. There have already been complaints about discovery taking too long, so adding additional delays will probably cause more issues. If you like, feel free to create a PR based on #116, I haven’t had time to finish working on it yet.

@joostlek
Copy link

I was checking the code today, isn't it a suitable idea to move the discovery to the config flow and store the discovered type in the config entry?

@NanoSector
Copy link
Author

@squishykid Thanks for your reply. I can understand why a slower library is annoying for users, however I’d imagine a consistently working library has priority over a super fast one, especially considering many users seem to have this issue in the Home Assistant integration.
I opened this PR as this seems like a decent enough temporary workaround until the refactor gets through. I’m assuming you mean PR #119 and not 116.

As Joost mentioned, storing the discovered model could be a good solution in this case - this bypasses the entire discovery mechanism and should allow instant access provided the user either enters it correctly, or the library has discovered it at least once (which in the HA integration can be done on setup).

@Darsstar
Copy link
Contributor

Darsstar commented Apr 2, 2024

This PR can be closed since #145 has been merged.

@squishykid squishykid closed this Apr 2, 2024
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

Successfully merging this pull request may close these issues.

4 participants