core: Reolink integration still does not trigger binary_sensor.visitor
The problem
This problem was marked as solved in issue #91041 after release of 2023.4.5
Unfortunately, the issue is still there, sometimes the visitor sensor is unavailable for couple minutes and when it is working again it does not trigger anymore till the integration is reloaded manually.
I am on latest Reolink Firmware: V3.0.0.2033_23041302 Local URL: https://homeassistant.local:8123 and https://192.168.1.XX:8123 I don’t use VLAN’s I do use SSL certificate and it is added like this in my config:
http:
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
For the time being, I set up an automation to reload the integration when the sensor is unavailable.
I will add some log information below when it becomes unavailable.
What version of Home Assistant Core has the issue?
core-2023.7.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Reolink IP NVR/camera
Link to integration documentation on our website
https://www.home-assistant.io/integrations/reolink
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
##### ERROR 1: #####
Logger: homeassistant.components.stream.stream.camera.reolink_video_doorbell_poe_sub
Source: components/stream/__init__.py:434
Integration: Stream (documentation, issues)
First occurred: 03:32:55 (4 occurrences)
Last logged: 03:34:00
Error from stream worker: Error opening stream (INVALIDDATA, Invalid data found when processing input) rtsp://****:****@192.168.1.XX:554/h264Preview_01_sub
Error from stream worker: Error opening stream (ERRORTYPE_111, Connection refused) rtsp://****:****@192.168.1.XX:554/h264Preview_01_sub
Error from stream worker: Error opening stream (ERRORTYPE_110, Operation timed out) rtsp://****:****@192.168.1.XX:554/h264Preview_01_sub
##### ERROR 2: #####
Logger: homeassistant.components.reolink
Source: helpers/update_coordinator.py:229
Integration: Reolink IP NVR/camera (documentation, issues)
First occurred: 03:35:16 (1 occurrences)
Last logged: 03:35:16
Timeout fetching reolink.Reolink Video Doorbell PoE data
##### ERROR 3: #####
Logger: homeassistant.components.reolink.host
Source: components/reolink/host.py:448
Integration: Reolink IP NVR/camera (documentation, issues)
First occurred: 03:39:07 (1 occurrences)
Last logged: 03:39:07
Error while requesting ONVIF pull point: Failed to request pull point message: Host 192.168.1.XX:443: connection timeout exception.
##### ERROR 4: #####
Logger: reolink_aio.api
Source: components/reolink/host.py:362
First occurred: 03:39:10 (2 occurrences)
Last logged: 03:39:10
Error while unsubscribing push: Host 192.168.1.XX:443: subscription request got a response with wrong HTTP status 400: Bad Request
Error while unsubscribing long_poll: Host 192.168.1.XX:443: subscription request got a response with wrong HTTP status 400: Bad Request
After 4 or 5 minutes, everything works again, except the visitor sensor, which will be available but does not trigger anymore.
Additional information
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 20 (10 by maintainers)
Let me know if you are experiance missing doorbell presses later on. For now I will regard this issue as beeing resolved.
@starkillerOG So far I didn’t notice missing doorbell presses indeed, I have an automation to trigger some Google Nest Hubs playing sound and those have been working since the update. Thanks!
@Efekent no I dont need the logs for now, let first see if these changes work. If not I will look further using debug logs.
Thanks for the support, much appreciated!
@Efekent After a full day of unplugging and plugging in the network cable of my test camera I figured it out 😃 I was able to create connection errors in this way and observe how the integration recoverd, and spotted some strange behaviour. Eventually I figured out what was going on:
When using ONVIF long polling, the long poll request would obtain a shared mutex lock, blocking all communication to the camera from other requests for up to 60 seconds. This includes the requests needed to re-subscribe to the ONVIF long polling. Therefore this not only made the integration extremly slow when using ONVIF long polling, it could also lead to nasty situations in which the integration was not able to recover fast from temporary network errors.
I fixed these issues (together with some additionally found bugs) in the upstream reolink_aio library and released version 0.7.6. This PR https://github.com/home-assistant/core/pull/97464 will make HA use that new version.
Additionally I found another problem: once the network was lost, the old long_polling request would first need to timeout which takes 5 minutes. I fixed that in this PR: https://github.com/home-assistant/core/pull/97465, such that upon re-subscription to the ONVIF long polling, the old long_polling request is emidiatly canceled and a new one is started such that we can start receiving events again as soon as we resubscribe.
Once those 2 PRs are merged, there is a good change that your problems go away. I will let you know when they are incorporated in a new HA (beta) release such that you can test them.
If you appreciate the reolink integration and want to support its development, please consider sponsering the upstream library or purchase Reolink products through this affiliate link.
@starkillerOG thanks for fast reply. I don’t run any programs which have access to the doorbell, however I do have a third party NVR which uses ONVIF connection of the doorbell, I don’t see any disconnects on the NVR, but it might cause HA integration loose its connection like you mentioned.
I will turn on the debug mode, but it does not happen that often, so I am not sure if I can prevent visitor events accruing. It happens once or twice a day, sometimes skip one day, here how often happened last week: 21 july 1x 22 july 1x 23 jully 2x 24 july 1x 25 july 0x 26 july 1x 27 july 1x Time frame is every day different when it occurs.
I will report back when it happens with the debug log.