Reolink sensors and cameras randomly and often go "Unavailable" for about 1min 15 seconds

[gh69]

The problem

I don't know exactly when this started happening but it was sometime within the last 1-2 months and I can't exactly nail down if it started with an update to the core or an update to the reolink integration (or randomly) but this issue came on suddenly and is now a consistent issue that I'd never come across before. Randomly, throughout the day, my Reolink cameras and their associated sensors within HA all go into an "Unavailable" state for approx 1 minute and 15 seconds before they return to their normal state...for camera feeds that normal state is "Idle" and for sensors that normal state is "On", "Off", "Clear", etc. I don't see a pattern to how often or when this happens...sometimes it'll happen every few hours and other times it will happen every 5 minutes. It is however always for around a 1 minute and 15 seconds...sometimes a few seconds more and sometimes a few seconds less. In this "Unavailable" state, the camera video feeds are still visible via the HA Overview dashboard and my custom camera specific dashboards. The sensors however (ie "Person", "Pet", "Vehicle", "Motion", "Visitor" etc) do not work at all while "Unavailable". All of my cameras are connected to a Reolink RLN16-410 NVR which itself is connected via ethernet to the same switch as the HA box and I've verified that these 1 min 15 sec outages are not seen when accessing the NVR-connected cameras via a local web-browser, via the native app, or via the NVR's local UI....translation, there doesn't seem to be anything wrong with the NVR itself or the cameras. Has anybody else come across this? I turned on dubug logging on the integration to see if anything unusual popped up and I do see what seems to be corresponding errors that read "error mapping response to channels"...see below for a sample of that.

What version of Home Assistant Core has the issue?

core-2024.1.6

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

config_entry-reolink-c586313577ecf11211f1695716351549.json(1).txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: homeassistant.components.reolink
Source: helpers/update_coordinator.py:332
Integration: Reolink IP NVR/camera (documentation, issues)
First occurred: 19:27:08 (11 occurrences)
Last logged: 21:36:16
Error fetching reolink.CamNVR data: Host 192.168.<redacted>.<redacted>:443 error mapping response to channels, received 82 responses while requesting 121 responses

Additional information

The timestamp on the error log entry "fetching reolink.CamNVR data" has the same exact time as the beginning of one of the 1 minute and 15 second outages, though in this particular case the outage was only 1 min 10 seconds.

[home-assistant[bot]]

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!

Code owner commands

Code owners of `reolink` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign reolink` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

reolink documentation reolink source _{^{(message by IssueLinks)}}

[sezlony]

i have the same problem in #109125, but I thought this might be hardware related, because when my cameras come back alive (from the unavailable state) and jump right into recording, the recording will have an initial greenish tinting which suggests it was a hard reboot of the camera

from my side I can confirm that some kind of random outages exist

[gh69]

i have the same problem in #109125, but I thought this might be hardware related, because when my cameras come back alive (from the unavailable state) and jump right into recording, the recording will have an initial greenish tinting which suggests it was a hard reboot of the camera

from my side I can confirm that some kind of random outages exist

Originally, I was going to link my report to yours since functionally they seemed similar but then I noticed that your logged errors seemed to be connection related. On my end, there doesn't seem to be connection issues. I have 12 cameras on my NVR and the are all wifi cameras so the NVR can't possibly be rebooting them. I've also verified that during the outages, the cameras themselves are still up and viewable. In fact during the 1min 15sec outages, even though the sensors are "Unavailable" and unusable from within HA, the live video feeds in HA are still visible, even though the overlay on each feed says "Unavailable" instead of "Idle".

[sezlony]

I think basically it's the same problem. what makes a difference is I don't have an NVR, but all the other circumstances you described are also present in my case

though I weren't so lucky - yet - to catch an outage and check if live feed was uninterrupted, but I experienced random 1:03ish blackouts and even have recordings from that timeperiod when HA reports the cameras unavailable, despite that they are obviously working

[Johnson145]

I'm also having troubles with sudden unavailabilities. It worked fine before, but started to get very unreliable a few weeks ago. I think I've noticed it the first time during December.

I'm using the Reolink Doorbell via WiFi. A door bell which works only sometimes is not very helpful... However, if I understand your reportings correctly, this does not sound to be device-specific.

In addition to the Reolink integration, I have another device-tracker integration provided by my router. At least for me, it looks like I'm having two different kinds of unavailability:

1. Sometimes the router reports the device to be unavailable, too. In that case, the Reolink integration correctly does the same. Can't identify any pattern in this situation. May also be just simple connection issues with my WiFi. However, it sounds suspicious that you guys have also been talking about two similar, but not identical problems in this thread.
2. The second problem seems to match the description of this issue quite well. Unavailibilities of the Reolink integration are indeed around 1:15m long all the time. Sometimes a little longer, sometimes a little shorter, but no huge variation. In these cases, my router reports the device to actually be available. The Reolink integration states the opposite though. So in this case it does not seem to be about a simple connection issue, but maybe really an integration problem?

Finally, I think it's worth to mention the following excerpt from the docs:

Reolink cameras can support a limited amount of simultaneous connections. Therefore using third-party software [...] or using the ONVIF integration at the same time can cause the camera to drop connections. This results in short unavailabilities of the Reolink entities in Home Assistant. Especially when the connections are coming from the same device (IP) where Home Assistant is running, the Reolink cameras can get confused, dropping one connection in favor of the other originating from the same host IP.

Maybe that's somehow the case here, too? AFAIK, HA should be the only one connecting to Reolink in my case. Maybe it is creating too many connections on its own though?

[sezlony]

here's the history of my most problematic camera, at around 10.15am there was a huge, unprecedented 4 minute blackout, during which the camera recorded as it was supposed to.

there was another (typical) 1:05 long and no more today - yet...

[starkillerOG]

Thank you all for reporting these issues.

First off it is important for me to know how often these unavailabilities happen, if it is only 1x per lets say 3 hours, there is a better change for me to fix it.

Secondly the polling intervall for the reolink integration is 60 seconds (+ the time it takes to make and process the request), that is why you see the camera beeing unavailable for 1:15 -> a single update fails, marking the entities as unavailble and in the next update they become available again.

@gh69 is seeing the error mapping response to channels, received xx responses while requesting xxx responses error. This is indeed a relitively new error, that was not picked up and handled correctly before. I will add some additional logic to retry the command when this happens.

@sezlony I see more connection errors in your case, it could be that handeling the above error better would improve your situation a bit, but I also expect that you are having wifi connection issues. maybe the wifi signal is just not strong enough at the location of the camera for a 100% reliable connection.

@Johnson145 Do you also see the error mapping response to channels, received xx responses while requesting xxx responses error?

[sezlony]

@sezlony I see more connection errors in your case, it could be that handeling the above error better would improve your situation a bit, but I also expect that you are having wifi connection issues. maybe the wifi signal is just not strong enough at the location of the camera for a 100% reliable connection.

yeah, I'm really confused, at first I also suspected it was hardware failure, but I can hardly imagine that simultanously 3 of 4 devices could go wrong with the same sympthomes

I'm using the cams over wifi, the signal is fairly good, RSSI is -53 dBm while Tx/Rx rate is 144 mbits and the distance is 5-6 meters only, so we can say it's not the connection (I cannot test it with cable though)

making sure it's not related to e.g. power issues I started trying different power supplies and I'm using the 3rd brand PSU by now, nothing changed, so I may still be wrong but this suggest me it's not the HW

the 1 min blackouts occur 1-5 times a day, happening absolutely randomly

[gh69]

@starkillerOG This happens quite a bit more often for me than it does for @sezlony. I just did a quick check of the history on one camera's "Motion" sensor and in the last 8 hours I count 48 instances of it going "Unavailable".

[sezlony]

question for those affected with this problem: brand, tpye and firmware of the router you use?

[Johnson145]

Observed the logs for a while. No, I'm not getting the error mapping response to channels, received xx responses while requesting xxx responses error. So I may have a different problem. Maybe indeed closer to #109125.

Originally, I had around 5-50 unavailabilties per day. To double check whether it's WiFi-related, I installed a new repeater right next to the door bell. Setup was good before already, but now it really can't be the WiFi anymore. I do feel the number of occurrences decreased, but I'm still receiving multiple connection errors per day.

The remaining errors vary. For instance, I get the following groupings:

ERROR (MainThread) [homeassistant.components.reolink] Error fetching reolink.xy data: Host 192.168.188.155:443: Timeout error:
Error while requesting ONVIF pull point: Failed to request pull point message: Host 192.168.188.155:443: connection error: Server disconnected.

WARNING (MainThread) [reolink_aio.api] Error while logging out: Host 192.168.188.155:443: Timeout error:
ERROR (MainThread) [reolink_aio.api] Host 192.168.188.155:443: API error: API returned HTTP status ERROR code 502/Bad Gateway.

ERROR (MainThread) [reolink_aio.api] Error while unsubscribing push: Host 192.168.188.155:443: subscription request got a response with wrong HTTP status 400: Bad Request
ERROR (MainThread) [reolink_aio.api] Error while unsubscribing long_poll: Host 192.168.188.155:443: subscription request got a response with wrong HTTP status 400: Bad Request
ERROR (MainThread) [homeassistant.components.reolink.host] Error while requesting ONVIF pull point: Failed to request pull point message: Host 192.168.188.155:443: connection error: Server disconnected.

I'm using AVM's FRITZ!Box devices. The 7590 AX as the main router, a 6000er repeater in Mesh via LAN bridge and now a cheaper 600er repeater right next to the doorbell.

[Gitty-Ruwy]

Reading all of the above comments i feel it's worth mentioning that the fully wired NVR setup i have is also experiencing the same unavailability dropouts. (as most seem to be using Wifi setups) Setup is several camera's POE wired to NVR with single LAN cable to router and HA. Router is an ASUS AC86U running Merlin. First real dropout issues seem to start the 4th of February at around 14:02 (2 PM). (see image below) Any mention prior to that has consistent off/unavailable states, but never longer than ±10 seconds.

Logs regarding "Reolink" seem to be full of "Response payload is not completed" errors. (47 and counting)

Edit:

Reverted my VM to February the 1st and will see if any more dropouts occur.

[sezlony]

this is going to get more and more strange...

I already filed a report to Reolink support hoping they gonna investigate this problem and I advise all to do the same, thus they become aware of it. maybe it's server related issue on their side?

[gh69]

@sezlony I personally have seen no issues with missing time, lost recordings, or unavailable camera feeds via Reolink's app, Reolink NVR's local UI, or web-access to the NVR so for me there is nothing to report to Reolink. (I'm also not using Reolink's cloud service.) My issue is solely with unavailable cameras/sensors through the HA integration. I've verified that during the 1min 15 second unavailable time seen in HA, my cameras and NVR are still working and the associated sensors are also all still working (as seen from the Reolink app, the NVR's web UI, and the NVR's local UI).

[Gitty-Ruwy]

I tend to agree with @gh69. My NVR itself still records and triggers smart detections. Also, the NVR is completely firewalled so no communication with Reolink servers is possible, so it's not like the NVR suddenly performed an update.

Feb 1 install also has dropouts. Still nothing like the one hour long issues like before.

[sezlony]

okay, these might be completely different things, I don't know. I'm just guessing, because on the one hand I'm incompetent, and on the other hand there's no support for this yet...

[gh69]

@sezlony I believe @starkillerOG is looking into it... see his post from 3 days ago

[starkillerOG]

I am looking into it. Just been very busy since I started a new job this week.

I already made some fixes in the upstream library regarding the "error mapping response to channels", that will be released in a patch version soon, just want to bundle some stuff together.

Also note that currently if there are communication issues with the NVR all entities of all camera's will be marked unavailable. I am investigating what happens if there is a communication problem between 1 camera and the NVR, if that causes timeouts/issues when requesting info of that camera it can now also effect the availability status of the rest of the cams connected to the NVR. I am thinking about how to best split this up.

If you want to help, please enable debug logging of the reolink integration, wait until a unavailability occurs, then wait until it becomes available again. Stop debug logging and post the resulting log.txt file here and mention in the post at wich time during debugging the cam became unavailable.

@gh69 thank you very much for the generous sponsering!

[starkillerOG]

@Gitty-Ruwy could you please share the exact error in the log about "Response payload is not completed"? That is a new error to me, so need to investigate what it is and where it is coming from.

[sezlony]

It is simply not worth being offended by my comment, that wasn't intended. english isn't my first language, I might have problems with expressing myself properly, I just really wanted to say that there are no results in this case. Yet. Period. (no matter how much effort I'm trying to put into guessing :D)

I'm outta here, don't want to play the role of the bad cop.

[starkillerOG]

@sezlony I was not offended, nothing to worry about. Just triggered me to give a little status update.

[Gitty-Ruwy]

@starkillerOG

Please note that HA is currently running a backup from a week ago (Feb 01 2024), before the issues really started for me. (though im surpised i'm still seeing these errors in the logs.

Again, still seeing sensor dropouts, but nowhere near as persistent as before reverting to an older backup. (actually quite acceptable in terms of sensor accuracy) If needed i could clone the VM running the non-reverted (not quite a word, is it?) installation (Feb 07 2024) of HA and take a closer look at the logs.

Current logs, Feb 01 2024 install:

Logger: homeassistant.components.reolink
Source: helpers/update_coordinator.py:313
Integration: Reolink IP NVR/camera (documentation, issues)
First occurred: February 7, 2024 at 8:32:46 PM (52 occurrences)
Last logged: 12:19:18 PM

Error requesting reolink.NVR data: Response payload is not completed

Logger: reolink_aio.api
Source: components/reolink/host.py:322
First occurred: February 7, 2024 at 8:32:46 PM (61 occurrences)
Last logged: 12:19:18 PM

Host 192.168.IP.IP:PORT: unknown exception "Response payload is not completed" occurred, traceback: Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/aiohttp/client_proto.py", line 83, in connection_lost uncompleted = self._parser.feed_eof() ^^^^^^^^^^^^^^^^^^^^^^^ File "aiohttp/_http_parser.pyx", line 507, in aiohttp._http_parser.HttpParser.feed_eof aiohttp.http_exceptions.TransferEncodingError: 400, message: Not enough data for satisfy transfer length header. The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/reolink_aio/api.py", line 4069, in send_chunk data = await response.text(encoding="utf-8") # returns str ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 1143, in text await self.read() File "/usr/local/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 1101, in read self._body = await self.content.read() ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/aiohttp/streams.py", line 373, in read block = await self.readany() ^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/aiohttp/streams.py", line 395, in readany await self._wait("readany") File "/usr/local/lib/python3.11/site-packages/aiohttp/streams.py", line 302, in _wait await waiter aiohttp.client_exceptions.ClientPayloadError: Response payload is not completed
Error while unsubscribing push: Host 192.168.IP.IP:PORT: connection error: Cannot connect to host 192.168.IP.IP:PORT ssl:default [Network unreachable].
Error while logging out: Host 192.168.IP.IP:PORT: connection error: Cannot connect to host 192.168.IP.IP:PORT ssl:default [Connect call failed ('192.168.IP.IP', PORT)]

[sezlony]

strange(r) things emerge from the past

gets interesting

[joaquinvacas]

For me, those issues started about a month ago, I have a smart display which was showing 24/7 a image card with live camera on it and now it's stuck, while I can open it manually and from the app itself, so I don't think it's a hard reboot in this case.

Nothing was changed, not a thing (well, HA Core updated from ,2024.1.x to the next small version number)

[fernando155]

In my case is more weird. It started today at 18. Of 5 cameras, the better ones started failing. One is just became unavailable and comes back. The other one it's failing even in reolink app, showing wrong password (but is been working for months). Both things happened in the same time and tbh, I don't know if is even related between ha and reolink or if is the same that the op one.

``Logger: homeassistant.components.reolink Source: helpers/update_coordinator.py:326 Integration: Reolink IP NVR/camera (documentation, issues) First occurred: 20:36:03 (3 occurrences) Last logged: 21:34:57

Error requesting reolink.Garage Front data: 400, message='Expected HTTP/:\n\n b\'<?xml version="1.0" encoding="UTF-8"?>\n<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsdd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:chan="http://schemas.microsoft.com/ws/2005/02/duplex" xmlns:wsa5="http://www.w3.org/2005/08/addressing" xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:wsrfbf="http://docs.oasis-open.org/wsrf/bf-2" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:wsrfr="http://docs.oasis-open.org/wsrf/r-2" xmlns:ns1="http://www.onvif.org/ver20/media/wsdl" xmlns:tdn="http://www.onvif.org/ver10/network/wsdl" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:tev="http://www.onvif.org/\'\n ^', url=URL('http://192.168.xxx.xxx:8000/onvif/event_service')

[starkillerOG]

@fernando155 There has been a NVR firmware update, now when the NVR connects to the camera and no password is set on the camera, the NVR will auto generate some random password which can not be retrieved. That will prevent you from accessing the camera directly because you do not know the password so can not log in. Could be you are experiancing this.

Solution in that case: 1) power down the NVR (unplug power cord). 2) factory reset the camera to which you were not able to connect anymore and gave you a incorrect password prompt. (If the NVR is not powered down it will emidiatly set a new password on the camera, so make sure the NVR is powered down). 3) Connect to the reset camera and set a password you define yourself and remember this password (needed to connect to the camera also in HA). 4) power the NVR back up Now the NVR will be unable to connect to the cam because it does not know the password 5) connect a screen and mouse to the NVR (I know, thats the only way....) 6) using the mouse and screen input the correct password for that camera and the NVR will be able to connect to the camera again.

Now you know the password to directly connect to the camera.

[starkillerOG]

@Gitty-Ruwy I am now catching that aiohttp.ClientPayloadError, see commit: https://github.com/starkillerOG/reolink_aio/commit/5e57640e8d66f0377b36a56d4fda7d9d5a6830e5

[starkillerOG]

The PR that will solve at least a lot of these issues has been merged: https://github.com/home-assistant/core/pull/110959 This will be included in the next HA 2024.2.3 patch release that is coming out in a few days.

If you still experiance issues once you upgraded to HA 2024.2.3, please make a new issue including a debug log showing the errors.

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.

[sezlony]

just a friendly reminder for myself, that testing with ONVIF integration completely eleminates this problem, so my conclusion is that - at least on my part - it was caused by the core integration itself. 😢

I have high hopes that the next update will really fix this, as the reolink integration is more sophisticated and way more livable.

[starkillerOG]

@sezlony note that the ONVIF integration does not poll the camera ever 60 seconds but only renews its subscription every 10 minutes as far as I know. So if the camera drops the ONVIF subscription due to a connection issue for only 1 minute, you will just not know about it with the ONVIF integration.

Same thing in the build-in Reolink integration: I could just ignore the connection drop and not set the entities to unavailable. As a user you would then never know the camera is dropping its connection and was not receiving any data for that 1 minute. That does not fix the issue, but from your user perspective it would look "fixed".

[sezlony]

note that the ONVIF integration does not poll the camera ever 60 seconds but only renews its subscription every 10 minutes as far as I know. So if the camera drops the ONVIF subscription due to a connection issue for only 1 minute, you will just not know about it with the ONVIF integration.

I don't know what you are talking about, but as soon as I see movement on the live feed, the graph and the sensor updates immediately, that's not 10 minutes I'm sure.

As for the other part I don't think ignoring connection drops would be a good thing. The integration is somehow overloading the cameras and that's the cause not the consequence.

[sezlony]

quick follow-up: 2.3 didn't help the thing, my cams keep playing this unavailable thing, only difference is that now it's not visible in the history graph (or in log), but I can see it in the router 😄

[Gitty-Ruwy]

Not sure if this is helpful, but you guys (and gals) be the judge of that;

Having reduced the amount of enabled sensors in HA the downtime has significantly reduced for me. Up to the point that i'm no longer seeing any at all. (except for downtime due to maintenance.)

Primarily using the smart detection sensors. All video feeds are read by an AgentDVR server which in turn is loaded into HA using the integration. (So all direct reolink streams are disabled in HA)

Currently running Core 2024.2.3, Supervisor 2024.02.0 and OS 11.5.

Hope there's anything useful in here. For me, the issue has been resolved.

[gh69]

Hey all. Though I am now seeing some new "Error doing job: Task exception was never retrived" errors in the system log on "components/reolink/select.py", I'm not seeing any functional issues with the integration. Sensors and video feeds are no longer going "Unavailable" in HA and all of my camera-sensor based automations that had stopped working are now all working again so for me, this latest update seems to have resolved the issue as well. Thanks @starkillerOG!

[sezlony]

Having reduced the amount of enabled sensors in HA the downtime has significantly reduced for me. Up to the point that i'm no longer seeing any at all. (except for downtime due to maintenance.)

@Gitty-Ruwy: what sensors did you disable egzactly?

[Gitty-Ruwy]

@sezlony Pretty much anything i'm not actively using; floodlights, general motion sensors, pet sensors, any sensors regarding motion sensitivity, delays. Only the person motion sensors are still active along with manual siren activation and PTZ triggers. Though I feel like disabling the video streams has reduced my issues the most. But i suspect not everyone has the option to run video streams though another server (on the same machine).

[sezlony]

ok, I tried to turn off unneccessary entities, I've now only 9 enabled out of 22, but it's still hiccups, I can't imagine what the f is this, but getting reaaally annoying

I even have push disabled so why are these unsubscribing errors still occur???

Logger: reolink_aio.api
Source: components/reolink/host.py:322
First occurred: 2024. február 25. 20:08:37 (5 occurrences)
Last logged: 14:10:48

Error while unsubscribing push: Host 192.168.1.4:80: connection timeout exception.
Error while unsubscribing long_poll: Host 192.168.1.4:80: connection error: Cannot connect to host 192.168.1.4:8000 ssl:default [Connect call failed ('192.168.1.4', 8000)].
Error while logging out: Host 192.168.1.4:80: connection error: Cannot connect to host 192.168.1.4:80 ssl:default [Connect call failed ('192.168.1.4', 80)]
Error while unsubscribing push: Host 192.168.1.4:80: connection error: Cannot connect to host 192.168.1.4:8000 ssl:default [Connect call failed ('192.168.1.4', 8000)].

[starkillerOG]

@sezlony from your debug log I can see your ONVIF WS base subscription (ONVIF push) does not work. Therefore te integration is falling back to ONVIF Pull Point subscription (ONVIF long polling).

However ONVIF Pull Point subscription means a lot lot more communication with the camera is required in order to receive the motion/AI events withouth much delay. This requires a lot more resources on the camera which can lead to connection drops.

Please try to make ONVIF push working by adjusting your network configuration, see: https://www.home-assistant.io/integrations/reolink/#reducing-latency-of-motion-events

Most likely you either do not have the local HTTP adress of HomeAssistant configured correctly under your network settings in HomeAssistant Or you are using a global SSL certificate meaning the local HTTP adress will not be accisible due to the SSL certificate. Most common solution would be using NGINX

[sezlony]

thanx for pointing that out, that fits my (conspiracy) theory of overloading the cams quite well!

of course I use duckdns so I cannot enter a local unsecured address... I start digging into NGINX, but which addon do you recommend: official proxy or the community run proxy manager?

[sezlony]

Most likely you either do not have the local HTTP adress of HomeAssistant configured correctly under your network settings in HomeAssistant

do you think fixing local address will also fix the ERRORTYPE 5/RTMP playback issues?

[sezlony]

moving on to NGINX from from global SSL is done, I will have results in a few hours whether it solved the ONVIF subscription problems or not

what I already know is ERRORTYPE_5/RTMP playback issues remained

[starkillerOG]

@sezlony have you confirmed the diagnostics data is now reporting that the integration is using ONVIF push?

[sezlony]

@sezlony have you confirmed the diagnostics data is now reporting that the integration is using ONVIF push?

no, because I'm too noob to think of that... but now that you asked I checked diag log and it's clean as a whistle - yet that meas: where to look for the push thing? ❓

is this relevant maybe? doesn't seem right though: "ONVIF enabled": true, "event connection": "ONVIF long polling", "stream protocol": "rtsp",

in respect of debug log there is a lot happening... mind taking a look at it to confirm I'm over my ONVIF problems?

[sezlony]

now I have this one:

Logger: homeassistant.components.reolink.host
Source: components/reolink/host.py:541
Integration: Reolink IP NVR/camera (documentation, issues)
First occurred: 10:07:24 (1 occurrences)
Last logged: 10:07:24

Unexpected exception while requesting ONVIF pull point: 400, message="Expected HTTP/:\n\n b'\\x15\\x03\\x03'\n ^", url=URL('http://192.168.1.4:8000/onvif/event_service')
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client_reqrep.py", line 966, in start
    message, payload = await protocol.read()  # type: ignore[union-attr]
                       ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/streams.py", line 622, in read
    await self._waiter
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client_proto.py", line 224, in data_received
    messages, upgraded, tail = self._parser.feed_data(data)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "aiohttp/_http_parser.pyx", line 557, in aiohttp._http_parser.HttpParser.feed_data
aiohttp.http_exceptions.BadHttpMessage: 400, message:
  Expected HTTP/:

    b'\x15\x03\x03'
      ^

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/reolink/host.py", line 541, in _async_long_polling
    channels = await self._api.pull_point_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/reolink_aio/api.py", line 4726, in pull_point_request
    response = await self.subscription_send(headers, xml, timeout, mutex=self._long_poll_mutex)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/reolink_aio/api.py", line 4523, in subscription_send
    response = await self._aiohttp_session.post(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client.py", line 605, in _request
    await resp.start(conn)
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client_reqrep.py", line 968, in start
    raise ClientResponseError(
aiohttp.client_exceptions.ClientResponseError: 400, message="Expected HTTP/:\n\n  b'\\x15\\x03\\x03'\n    ^", url=URL('http://192.168.1.4:8000/onvif/event_service')

[felixthecat-max]

Also having this

[starkillerOG]

@sezlony this line "event connection": "ONVIF long polling", means you are still using ONVIF long polling, so ONVIF push is not working for you yet. So the camera is not able to reach the homeassistant webhook over http yet using the local adress configured in the HomeAssistant network settings.

[sezlony]

ok but why? it is configured properly in "network", isn't it?

[starkillerOG]

@sezlony yes that setting looks good. Did you remove the global SSL configuration from your configuration.yaml under http:? And did you restart HomeAssistant completly after doing that?

[sezlony]

yes, all was done using this youtube tutorial and I think I got it right, but I don't know how to test more throughly

config.yaml I had this before (needed for duckdns)

# http:
#  ssl_certificate: /ssl/fullchain.pem
#  ssl_key: /ssl/privkey.pem

and I have this now (for NGINX)

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.0/24

edit: adding the HA's IP to the list did result in this: "event connection": "Fast polling"

am I good now with ONVIF?

edit: I can't help it, it falls back to ONVIF long polling, whatever I do...

edit: although everything seem to work fine, now the motion sensors stuck and show there was movement only 2 hour ago, while correct data is 5 hours...

[sezlony]

this thing is killing me, downloaded diagnostics and now it's "event connection": "ONVIF push" without me touching anything

why???