Closed Daniel-dev22 closed 1 week ago
Hey there @starkillerog, mind taking a look at this issue as it has been labeled with an integration (reolink
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
reolink documentation reolink source (message by IssueLinks)
@Daniel-dev22 I looked at your logs and the integration code. The integration will try to subscribe to ONVIF push and if that fails to ONVIF long polling, but will not actually wait untill it gets a succesfull push. It will only wait on the subscription request. Even if you have https configured, that should still work. Moreover ONVIF long polling should work even if you have a SSL configured and can only use HTTPS.
So from the code side of things everything looks good.
I see in your logs that you are getting timeouts on the original subscription requests, that should not be happening, even if you have global SSL and only HTTPS. Most likely the ONVIF port (8000) is blocked.
Could you open up port 8000 between homeassistant and your Reolink camera/NVR?
Are motion/AI detections comming in withouth much delay on your HomeAssistant binary sensors?
Could your share a full debug log.txt file just after startup?
I would like to see what the communication is.
I see the diagnostics data is showing "ONVIF long polling", but from your error log:
Error while requesting ONVIF pull point: Host 192.168.2.11:443: failed to request pull point message, not yet subscribed
It seems to me that is not working.
So I am wondering if it is falling back to Fast polling as it should or not, I think something is wrong there in the code.
Are motion/AI detections comming in withouth much delay on your HomeAssistant binary sensors?
@starkillerOG yeah I just checked and motion detections are coming in. I can try opening port 8000 and restart. I was previously running in docker host mode but I still had this issue so not sure if opening 8000 would fix it but worth a shot.
I should add that the container has full access to the doorbell IP they are on the same subnet as I'm using the container with an ipvlan so there's no firewall rules in the way.
Could your share a full debug log.txt file just after startup?
Should I turn debug on for the integration as well?
@starkillerOG
I opened port 8000 so home assistant container had access to it and noticed that didn't help.
Here's the logs from startup. You can see it gets stuck for quite awhile blocking startup. reolink_debugging.txt
Now that I see the debug logs is this the true issue?
Finished fetching reolink.Doorbell.firmware data in 76.613 seconds (success: True)
My cameras have 0 Internet access.
@Daniel-dev22 I think you are right, I also see Error checking Reolink firmware update at startup from Doorbell, possibly internet access is blocked
So indeed I think the issues is that the doorbell has no internet acces and therefore the firmware update check will fail. Unfortunetelly there is no way beforehand to know if the camera has internet access or not, besides just trying and getting a timeout.
So besides allowing the camera internet access I don't see a way to resolve this startup delay.
One tiny possibility would be to check if all update entities are disabled and then not do the firmware check, but that would require quite some additional code, will look if I have some time to implement that.
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 , do firmware update checks need to be done during startup? Can't this check be delayed until after startup?
@starkillerOG , do firmware update checks need to be done during startup? Can't this check be delayed until after startup?
That's what I thought.. not sure why this is critical to startup. With home assistant startup getting faster this is going to be a major thing holding back startup.
I think I'm having the same problem. My cameras are not allowed to talk to the internet at all. When I start home assistant with 2023.5.3 code, even with logger config homeassistant.components.reolink: debug
, I find that my devices do not appear at all, and there is nothing in the logs. I don't understand how a device setup can fail without a log entry at debug, and I suspect something is off plan but I don't know what.
Long ago, maybe December, I had gotten a backtrace that my https URL was not acceptable. I applied a patch:
--- components/reolink/host.py.dist 2023-09-06 08:08:12.627786598 -0400
+++ components/reolink/host.py 2023-10-13 15:33:06.288763433 -0400
@@ -435,10 +435,10 @@
self._base_url = get_url(self._hass, prefer_external=True)
except NoURLAvailableError as err:
self.unregister_webhook()
- raise ReolinkWebhookException(
- f"Error registering URL for webhook {event_id}: "
- "HomeAssistant URL is not available"
- ) from err
+ #raise ReolinkWebhookException(
+ # f"Error registering URL for webhook {event_id}: "
+ # "HomeAssistant URL is not available"
+ #) from err
webhook_path = webhook.async_generate_path(event_id)
self._webhook_url = f"{self._base_url}{webhook_path}"
and with that, startup proceeds, and everything works except it's onvif push instead of webhook. I'm sure that's not the right patch; the idea is that instead of failing setup if the camera doesn't like the webhook URL, just skip the webhook and let it do onvif push.
I realize we can't fix the bug in reolink firmware that https webhooks don't work, but it seems we can just treat such camaras as "let's pretend there is no webhook facility and use ONVIF poll/push", perhaps with a NOTICE log line.
I am seeing log lines that firmware checks are timing out. Which is fine, and doesn't seem to impair anything. It's certainly not fatal. So I think @Daniel-dev22's issue might be the webhook registration throwing an error that isn't visible, and not at all about firmware.
This should be fixed in HA 2024.7.0 as I no longer wait for the firmware check in the startup process. If you still have issues once updated to HA 2024.7.0 (released on July 3th), please let me know by opening a new issue.
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.
This should be fixed in HA 2024.7.0 as I no longer wait for the firmware check in the startup process. If you still have issues once updated to HA 2024.7.0 (released on July 3th), please let me know by opening a new issue.
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.
Awesome thank you!
The problem
The reolink integration blocks startup every time I restart.
I have home assistant behind https and I just read that reolink doesn't support pushing events to https. I suspect that is the cause for delay in the integration before it falls back to onvif poll and eventually starts the integration.
I have no plans to make home assistant available via http and I am ok with the performance hit in the difference between onvif push and onvif poll.
What version of Home Assistant Core has the issue?
2024.2.2
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Container
Integration causing the issue
reolink
Link to integration documentation on our website
No response
Diagnostics information
config_entry-reolink-ca893e7fd07cadc2c2886c6e898422ac-1.json
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Then