-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
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
Add webhook support to onvif #91485
Add webhook support to onvif #91485
Conversation
Hey there @hunterjm, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
Now we need a way to test if the webhook is working and the camera can reach hass |
Need to keep running pull points until the webhook gets its first callback so we know hass is reachable |
Track time interval is probably a bad choice. Should do call later in a finally instead in case renew takes a while or restart |
Should use config entry id for webhook id so it's easy and to cleanup later |
I've beat this up the best I can. I'm going to move some of the code to the lib to reduce this a bit |
Lots of power pulls with both webhook and pull point. Everything recovers well |
I'm happy with this now. Need to split out those two parts into the lib |
I ended up with a smart plug that reboots the camera over and over again to make sure it resumes |
Existing problem but if I power cycle the camera while motion is detected its never cleared because we don't clear the events when we loose the subscription. That would be a bit difficult to be sure we can. For a future PR |
I'm happy that is recovers well when the power is cycled many times. |
We should have a failed state for when the initial pull point or notify subscription can't happen because the camera doesn't support it or has a quirk that prevents it from working We can also cleanup the sensor and binary sensor a bit more |
I have one that doesn't support pull point but supports webhooks
|
and the reverse
|
I've done hundreds of restarts now and everything always comes up now. Previously it had a 15-35% failure rate. |
I will do another PR after this to clear stale events when a renew fails (it will need a remote protocol retry as well because of http://datatracker.ietf.org/doc/html/rfc2616#section-8.1.4) but its outside the scope of this PR and I didn't want to make this any bigger edit: #91567 |
Going to squash this since I'm going to build on top of it and I don't think anyone has looked at it yet 🤞 |
This will fix all the motion sensors being in a stuck on state when the camera reboots needs #91485
If/when mvantellingen/python-zeep#1369 gets merged we can simplify this all a bit |
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.
This looks good (and works well for me locally).
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
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.
Thanks, @bdraco 👍
../Frenck
Proposed change
Add webhook support to ONVIF
Upstream changelog: openvideolibs/python-onvif-zeep-async@v1.2.11...v1.3.0
Compliant cameras are required to support event notifications (webhooks) or PullPoint subscriptions. Some implement both, and we now support both. Webhook support means we can support events on another subset of devices. We will automatically switch over to webhooks as soon as the first webhook is received to ensure that the webhook is reachable by the camera.
Webhooks are generally preferred since they have lower latency (at least for most of the tested cameras) and are better for motion events than the long poll of the pull point, which must be restarted when events happen. Webhooks are more efficient since we have much less activity when nothing is happening with the camera, which is anticipated to be the state most of the time. Additionally its less overhead to process the webhook than it is to do the long polling.
Adjust subscriptions to 3 minutes and renew when they are at 50% expiry. Previously if Home Assistant was restarted and the unsubscribe was not processed, it with tie up the slot for 24h, and events would stop working. If you restarted Home Assistant a few times, events would be broken until the next day because all the slots were full. This is especially likely to happen for cameras that do not implement unsubscribe.
Relative times are used everywhere since it's clear that vendors implement time zone support poorly or never update for daylight savings time changes. This should fix a whole class of issues related to time zones since we never need to care about which timezone the camera supports. There are a significant amount that don't event support utc
I've done a full range of performance testing on this PR to make sure its efficient as well.
Type of change
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
.To help with the load of incoming pull requests: