Events intermittently not processed by Home Assistant

[dmperl]

Describe the bug
occasionally alarms sent from my reolink camera are "lost" and do not trigger Home Assistant automations as expected.

To Reproduce
Repeatedly trigger camera with Person/Pet/Vehicle "alarms" sooner or later you will see that some "alarms" do not get processed correctly by the io handler on Home Assistant

Expected behavior
All alarms should be processed correctly when received by Home Assistant.

Screenshots

A vehicle alarm is generated at 16:25:01 April 8, 2023:

No logbook entry is created on Home Assistant for the corresponding time:

General "history" view. missing event at 16:25

Environment:
Please provide useful information about your environment, like:

• Reolink NVR/camera model
• NVR/camera firmware version
  

Additional context
Add any other context about the problem here.

System information

Version	core-2023.4.1
Installation Type	Home Assistant OS
Development	false
Supervisor	true
Docker	true
User	root
Virtual Environment	false
Python Version	3.10.10
Operating System Family	Linux
Operating System Version	5.15.84-v7l
CPU Architecture	armv7l
Timezone	America/New_York
Configuration Directory	/config

I have a debug log: home-assistant_reolink_2023-04-08T22-07-19.378Zx.log The full log is 67MB. Upload limit is 25MB. Zipped version is 2.9MB (attached)

searching log for "16:24" yields the following excerpt:

2023-04-08 12:09:01.015 DEBUG (MainThread) [reolink_aio.api] Host 192.168.210.131:443: subscription got response status: 200. Payload:
<?xml version="1.0" encoding="UTF-8"?>
<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/ver10/events/wsdl" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tmd="http://www.onvif.org/ver10/deviceIO/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:trc="http://www.onvif.org/ver10/recording/wsdl" xmlns:trp="http://www.onvif.org/ver10/replay/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:trv="http://www.onvif.org/ver10/receiver/wsdl" xmlns:tse="http://www.onvif.org/ver10/search/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:tad="http://www.onvif.org/ver20/analytics/wsdl"><SOAP-ENV:Header><wsa5:To SOAP-ENV:mustUnderstand="1">http://192.168.210.131:8000/onvif/Notification?Idx=12123096</wsa5:To><wsa5:Action SOAP-ENV:mustUnderstand="1">http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/RenewResponse</wsa5:Action><wsse:Security><wsse:UsernameToken wsu:Id="UsernameToken-a4b10738-5628-4f08-93e8-6b6c531e3ed5"><wsse:Username>admin</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">XvT9Hb/E1dbHEB69+YZiOf4Mj3w=</wsse:Password><wsse:Nonce **EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">rN4gjwAVRK6g8SpyZjAnmw==</wsse:Nonce><wsu:Created>2023-04-08T16:09:00.000Z</wsu:Created></wsse:UsernameToken></wsse:Security></SOAP-ENV:Header><SOAP-ENV:Body><wsnt:RenewResponse><wsnt:TerminationTime>2023-04-08T16:24:01Z</wsnt:TerminationTime><wsnt:CurrentTime>2023-04-08T16:09:01Z</wsnt:CurrentTime></wsnt:RenewResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>**

Note:

</SOAP-ENV:Header>SOAP-ENV:Bodywsnt:RenewResponsewsnt:TerminationTime2023-04-08T16:24:01Z</wsnt:TerminationTime>
home-assistant_reolink_2023-04-08T22-07-19.378Zx.zip

[starkillerOG]

I am aware of this issue, have confirmed it lokaly in my setup and found a solution.
The PR for the fix is here: home-assistant/core#91070
It is not merged yet, but is expected for HomeAssistant 2023.4.3

[starkillerOG]

If you appreciate the reolink integration and want to support its development, please consider sponsering the upstream library.

[starkillerOG]

@dmperl when looking at your log more closely I do not see any ONVIF events comming in, what local HomeAssistant URL do you have configured under settings->network?
Did you have a repair issue about the camera not beeing able to reach the webhook?

[dmperl]

Did you have a repair issue about the camera not beeing able to reach the webhook?

YES! I did.

I got this message after the re-start from the 2023.4.0 upgrade:

In configuration.yaml, I have both

  internal_url: "http://192.168.1.7:8123"
  external_url: "https://[myndomain].duckdns.org:[wxyz]"

I re-booted the sever (Raspberry Pi) and the message went away. (or did I just press Ignore??)

Settings -> System -> Network -> Home Assistant URL uh-oh.. Invalid local network URL

I used Duck DNS and Let's Encrypt to set this up. I'm not sure how to setup a local domain URL using the same certificate. Should I go back to the Home Assistant Community Forum?

[starkillerOG]

@dmperl you will have to use something like nginx proxy manager home assistant addon to configure a externall HTTPS URL while keeping a local HTTP URL

[dmperl]

Ok. I think it's better but now the alarm report seems to be delayed by 60 seconds.

Installed and running nginx:

nginx SSL config:

Verified that: Settings -> System -> Network -> Home Assistant URL is AOK, no error messages.
[Internal URL and External URL are the same (use same certificate)]

Enable Reolink debug at 13:22

Trigger event at 13:24;38

Event reported at 13:25:38

Disable debug at at 13:29 (log attached)
home-assistant_reolink_2023-04-10T17-28-39.956Z.log

Thank you for reviewing this. ;-)

[dmperl]

Home Assistant and Camera time are less than 1 second different.

[starkillerOG]

@dmperl I still do not see the ONVIF events comming into HomeAssistant.
It seems like your local URL now shows https://....
What did you configure for the local URL?
Are the camera and HomeAssistant in the same VLAN?

[dmperl]

Originally, I had specified a local IP address for the internal URL. Now I have the same xxxxx.duckdns.org domain name for both internal and external URL values. (I obscured the name in the Home Assistant URL image posted earlier.)

The cameras and the Home Assistant server are on different VLANs but I have enabled some cross traffic, at least to the extent that alarm/event posting works for my Amcrest and Unifi cameras.

I'm very confused now. If no ONVIF events are coming through, what is generating the Person on/off events in the Home Assistant logbook?

[starkillerOG]

@dmperl polling every 60 seconds is used to get the camera state (floodlight etc) but also the motion and AI state as backup for the ONVIF pushes. However relaying soly on the polling is slow and you will miss a lot of events.

You will have to configure a the local HTTP adress while using the HTTPS for the externall adress and using NGINX for the mangement of the certificate.

So change https://....duckdns... to http://192.168.1.IP:8123 under to local URL (whith the correct IP of the HA device).

Lets first see if that works and then worry about the VLAN if it doesnt.

Could you change the local URL, restart HomeAssistant and make another debug log with you generating some motion events?

[dmperl]

When I change the local URL back to an IP address I get this error:

thanks!

[starkillerOG]

@dmperl please remove the SSL certificate configured in your YAML configurations file. (It schould now be configured in NGINX)
And then restart HomeAssistant completly.

[dmperl]

It's in there: nginix:

but if I remove it from my configuration.yaml file (lines 7 & 8)

then my external duckdns login stops working.

I'm confused by this error message:

Invalid local network URL
You have configured an HTTPS certificate in Home Assistant. This means that your internal URL needs to be set to a domain covered by the certficate.

If I replace the local IP address with the duckdns FQDN, the error message "goes away", but neither option (IP address or FQDN) let's the ONVIF events through.

sorry to be so dense.

[starkillerOG]

You will have to remove the ssl_certificate and ssl_key from the http YAML config.
Otherwise it will never work.
You then need to configure NGINX properly to get your externall duckdns login to work again.
I think you will also need the Duck DNS addon to connect to duck dns.
To get NGINX properly configured I will have to refer you to the HA forum/google, I am not a expert in that.

You will also need to have http://192.168.1.IP:8123 in as local URL, otherwise Reolink ONVIF pushes will also never work.

[dmperl]

Got it.

All issues were self-inflicted wounds.

I found the picture that explained the error of my ways here: https://kleypot.com/home-assistant-nginx-unencrypted-local-traffic/

I forgot to change the forwarding port destination from 8123 to ssl/443.

Your last post and a good night sleep helped me pay attention to that detail.

"good" log file attached.

Thanks!!

home-assistant_reolink_2023-04-11T14-45-14.943Z.log

[starkillerOG]

@dmperl Thanks for the feedback.
Good to hear it is finally working for you!
I checked the log and indeed the ONVIF pushes are now comming in :)