-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
Interest in async interface? #133
Comments
Personally I think this might be a good improvement. While I'm not super experienced with So I would definitely vote with "yes" here. On the other hand it might introduce some complexity and will make it harder to debug / maintain / contribute / test. So let's see what the others think about it. |
What I'm missing in general (and that is not related to this feature necessarily) is a roadmap / milestones. Currently we just implement new features and introduce (breaking) changes all over the place with no particular order / plan. Ideally we should come up with a plan / strategy, i.e. for milestone A we want to have X, Y, Z. For milestone A+1 (=B) we can then focus on XX, YY, ZZ, etc. But let's discuss this at another place. |
I'm not familiar with Allowing a break before each function call would, in my opinion, increase execution time rather than decrease it. After all, the CPU registers are overwritten with every thread change. |
I don't think that this is what we need to worry about (at this point in time). (Technically there is hyper threading, etx.), so switching contexts is not expensive at all. Also when dealing with network sockets, register timing is really not critical, since it is orders magnitudes faster. The main advantage of asynchronous computation is that you can process data as it comes in and don't have to busy wait for it. Maybe we should summarize what our current problem is that we're trying to solve here and only introduce the additional complexity once it is needed. |
Out of curiosity, I tried to implement an asynchronous version of the socket connection to the heat pump, see https://github.com/gerw/python-luxtronik/tree/async. (Beware: this is not polished and, e.g., lacks some basic error handling)
Is there any interest in adding an async version to the main branch? I have seen that HomeAssistant is async-based, would it be beneficial for the integration?
The text was updated successfully, but these errors were encountered: