search

Bouni / python-luxtronik

python-luxtronik is a library that allow you to interact with a Luxtronik heatpump controller.
MIT License
37 stars 20 forks source link

Interest in async interface? #133

Open gerw opened 1 year ago

gerw commented 1 year ago

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?

kbabioch commented 1 year ago

Personally I think this might be a good improvement. While I'm not super experienced with asyncio in Python, an asynchronous computing model makes a lot of sense when dealing with sockets, etc.

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.

kbabioch commented 1 year ago

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.

Guzz-T commented 1 year ago

I'm not familiar with await and asyncio, but shouldn't it be enough to add an await to the uses of socket?

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.

kbabioch commented 1 year ago

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.