Use gattlib by default (for Home Assistant)
TechHummel opened this issue · 10 comments
Hi rytilahti,
due to Home Assistant's upgrade to Python 3.10, it does not support bluepy anymore. Since python-eq3bt does support gattlib, using gattlib by default and bluepy optionally should make python-eq3bt work with Home Assistant again.
Would switching the dependencies and publishing a new version be ok with you? If so, I can prepare a pull request.
Thanks!
Hi @TechHummel, yeah, I saw that bluepy is becoming unsupported. Assuming gattlib still keeps working (for some reason I'm having version conflicts for the libboost_python310.so here), changing the library to depend on it per default makes sense. If gattlib does not work either, this library should be migrated to add a new bleak backend and make it default.
Feel free to open a PR to do the necessary changes, I'll update my system and retry testing the gattlib support prior making a new release.
Yes, bleak is much better than gattlib, and using it would also give support for windows & mac platforms. However, it is also an asyncio library, so I'm not sure how easy feat it would be to create a backend using it to this project. I'm not personally interested on putting the effort to make that happen, but I can review PRs and make releases as needed :-)
See the linked PR for converting the homeassistant integration to allow configuring these devices using the UI. While working on that I realized that it would be a good idea to wrap the backend library exceptions to make the integration code cleaner. Currently the integration imports backend-specific modules (bluepy.btle.BTLEException) which we should get rid off, and same obviously applies to exceptions potentially raised by the gattlib backend.
@TechHummel if you have multiple thermostats, it would be great if you could give that PR a quick try, preferably in a non-production environment. It's still very WIP as I'm not really familiar on homeassistant-specifics, but based on my tests 1) devices are now automatically discovered if not configured in the YAML, 2) the UI can be used to add devices using the mac address, 3) the existing thermostats from configuration.yaml are imported and the configuration file can be cleaned up afterwards.
@rytilahti Thank you so much for your effort and the PR!
I own three thermostats (with firmwares that do not require pairing).
I can test your PR in around two weeks if that's good enough?
with firmwares that do not require pairing
Little bit off topic but with which firmware version does this pairing-requirement start?
on-topic: Thank you for your effort in bringing the eq3 functionality back!
with firmwares that do not require pairing
Little bit off topic but with which firmware version does this pairing-requirement start?
@TechHummel that will be fine, thanks!
edit: Also, I suppose pairing could also be implemented to this lib and the newly added config flow. That will require more work though, so I'm not going to work on that at this point but PRs are welcome as always!
The linked PR adds a bleak backend, as it seemed to be rather easy to implement by just wrapping asyncio calls to be run inside an internal event loop. It seems to work just fine based on some precursory testing, but more testing is welcome pre-merge so feel free to give it a try :-)
Considering the small number of people using this integration, I feel the manual pairing process is good enough!
Thanks again for your effort!