-
Notifications
You must be signed in to change notification settings - Fork 41
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
Asyncio client for HTTP #154
base: master
Are you sure you want to change the base?
Conversation
@jlusiardi do you have any thoughts about where i'm going with this? I think there are 2 directions i'd like to go in:
Option 1 might be better in the short term so I can iterate quickly on the Home Assistant. But then there is an option 3 where we start with option 1 and then merge back together when things are more battle tested. |
so why not option 2? After the merge all the tools / the api should work like before and we have one code base to work on? |
That's indeed why i prefer option 2 - i just don't want to put pressure on you to review a bunch of code for a framework you aren't familiar with AND a flurry of pull requests with me nagging, and then a bit after that nagging for releases :-) If you are up for that lets crack on with option 2! |
ok, so i will try to have a look at the code as fast as possible ;) |
/me hops up and down excitedly ;) |
could we integrate the tests into |
Probably, I used pytest for these because I’m more used to it’s output when something fails and have no idea how to write asyncio tests without it. What are the chances I can persuade you to switch to pytest :) (it can run all the existing tests as they are) |
Ok, |
That's weird - they pass here on 2 different macs (though skipped the BLE ones). Python 3.7.3. Which use of RAW is failing for you? The new (temporary) one in |
(Have updated CI on this branch to use pytest and its running now) |
I rebased this on master so the review diff no long contains the accessoryserver.py changes. I'll be able to do the same again when we have merged the other 2 PRs. |
Thanks for all the merges so far - have rebased this based on the latest round and got rid of the code that i'm now able to share with the synchronous client \o/ |
Have rebased and it now reuses the same pair setup state machines as the sync clients. |
What can we do to make progress here?
The current status is:
There are still some bits of logic that could be shared between the sync and sync client - around parsing and serializing data for/from the API calls. But these are less pressing I think. Let me know if you think thats a blocker. |
Hey,
For further PRs:
If you are confident after your QA with HASS.IO I will sure merge it! |
That's good news! Then:
And then i'll let you know! BLE is definitely on the cards - i have started sketching it out in a branch a bit but wanted to stabilise the HTTP client first. I'm looking at this library - the author is a homeassistant user and has been quite responsive. After i asked they have kindly added descriptor reading support for us already and it seems it can potentially work on windows and mac as well. |
c30e5f4
to
05799b7
Compare
6f0ab85
to
e9e7d97
Compare
Hi @jlusiardi I found a bit of time this month to work on this. It looks like CI might be broken for macs on master though. I have "fixed" it but it installs a python 3.6 instead of a python 3.5. I couldn't get python 3.5 working again. I wanted to point out homekit/aio/main.py - you should be able to test this branch with the CLI yourself:
|
Hi @Jc2k, I will give it a good look when I’m back home, because all the HomeKit hardware is there. The CI should be fixable earlier though. Joachim |
@Jc2k The way the PR currently is, you've got |
Good spot. Fixed the argparse definition for those 2. |
I took the code for a spin with my Honeywell Lyric alarm controller, and can confirm the aio branch works well: Let me know if there are other tests you'd like to see. |
I tested it with my Insignia garage opener and it seems to be working well: https://gist.github.com/eugr/fc454156292c90407afe347b8e782094 |
@PaulMcMillan @eugr thanks for the updates! Really pleased that the basics seem to be working for a range of devices! @jlusiardi rebased + pushed a few more tests this morning. Mac CI has broken again in a different way this time. Seems to be setting up python without an ssl module now :/ Tried using the |
@Jc2k: have you tried Python from MacPorts distribution instead? It’s a completely separate install that does not use system libraries unlike Homebrew. |
I have been running this branch of homekit_python with @Jc2k branch of home-assistant for a few weeks without any issues. I have linked a Xiaomi Aqara Hub (HomeKit version) with some door and temperature sensors and everything works great and instantaneously. I can see the sensors updated on real time and also enable and disable the Hub's alarm. No issues at all on Home-Assistant log. |
we should investigate why the checks are failing on OS X, i think. |
Any update on this pull request ? |
Hi @stoprocent, the PR sounds promising, but will still introduce a huge amount of code duplication. Because of that I am still a little unsure. |
Yeah i was worried about that too. There is more that can be done on that front, but its just going to make this PR even bigger. And ultimately there will be duplication, especially if we want a CLI so we can test the async code outside of other projects. But going asyncio native is the only way forward for HomeKit in HomeAssistant. The async <-> sync bridge is a big pain there. I guess it might be easier for me to spin this out into its own project like |
This is a draft so you can see where I am headed, so far i've got pair-verify and get_characteristics working against an accessoryserver test case.
As discussed in #151/#152/#153: It's going to be really hard to have the synchronous send/receive semantics and spontaneous event semantics mixing with a blocking API without decending into threading hell. Therefore I have been looking into an asyncio which will let us handle that case better.
This will be in addition to the existing API, and we won't break that API when adding asyncio support. The CLI tools will continue to use the synchronous API.
I've used core homekit_python as much as possible. However some of the pieces i wanted to use require adapting to work with asyncio. For now I have copied these into the aio folder, and i'll de-duplicate as seperate small PR's to make it easier to review.
I'm trying to keep the user facing API as similar as possible, only making operations that do network IO awaitable.
Under the hood things are a little bit different but should still be familiar apart from sprinkling
await
andasync
keywords everywhere. The most notable differences are:select
and network i/o timeouts. But this means we have push rather than pull based logic for the HTTP parsing.request()
method that blocks/awaits on a reply. To make it so we can i create a stack of Future objects. I add one to a stack and return it every time we make a request. These futures are then fired as we parse results in data_received in the order they were added (FIFO, i guess).I think it's going to be harder to avoid code duplication in the BLE backend, but hopefully will be able to do /something/...