-
-
Notifications
You must be signed in to change notification settings - Fork 32.6k
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
Fix ONVIF Transport #35932
Fix ONVIF Transport #35932
Conversation
oyi... can you check it out after the refactor? Shutdown is graceful for my devices... |
yes, I'll check it out locally and test 👍 |
I can also modify the upstream lib to allow passing in client session while still creating a new Transport class. Not sure if that will solve both issues though. |
I was able to reproduce @frenck:
|
We already create a new Transport class for each camera... So that won't help. |
I think the issue is a transport per service. There are multiple services (event/media/device) that all create their own transport in the parent lib if none is passed in: https://github.com/hunterjm/python-onvif-zeep-async/blob/async/onvif/client.py#L114-L119 |
yeah, testing something like that now... if I can get my dev environment to play nicely. |
That didn't fix it unfortunately. Apparently zeep thinks they are calling an underlying sync |
Meh, indeed, upstream issue :( |
This change just got bigger, but I was able to handle session creation/closing in a new |
Upstream change: openvideolibs/python-onvif-zeep-async@c457f73 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me, this works like a charm 👍
Tested with 3 different camera's, all not ONVIF certified.
* allow lib to create AsyncTransport * fix transport close issue
Proposed change
There is an issue that occurs on some devices with re-using the same
AsyncTransport
across multiple services which appears to occur with request queues on pending requests. The responses appear to be associated with the improper requests when they come back. This was exposed in 0.110.1 when we moved fetching URLs toasync_added_to_hass
. The library already handles creating a newAsyncTransport
andClientSession
if no transport is passed in, so this will let it do so.Type of change
Example entry for
configuration.yaml
:# Example configuration.yaml
Additional information
Checklist
black --fast homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.The integration reached or maintains the following Integration Quality Scale: