Problems with reolink e1 outdoor

Are you using tokens or is the binding using the user and pass in all the URLS? if using tokens which is the default, make sure you update to todays build as I fixed a bug that stops tokens from updating and this may also be the cause of some peoples troubles.

Iā€™m having the same restart Problem with my Reolink RLC-820A and I found a reliable way to reproduce this issue.

In the Onvif PullMessagesRequest you can specifiy a MessageLimit. This defines how much messages are returned on each request.

I tested the PullMessagesRequest in Postman with a MessageLimit of 10 and everything worked perfectly on the latest firmware. But Openhab setā€™s the MessageLimit to 1 to process each message in a separate request. So I tested what happens if I also set the MessageLimit to 1 in my Postman request and the connection was terminated immediately by the camera and I could not get a connection to the onvif port for about 5 minutes. So far this happened everytime I sent a request with MessageLimit 1 to the camera.

I also contacted the Reolink support with this new information. I hope this will help them find the source of the problem.

I am not having it here as I purchased one of these with donations that openHAB users gave to me. You can see what I had to do to get it running here with older firmware and some work arounds to stop other bugs causing issuesā€¦

Thanks for this information. I have had this on the todo list but with a low priority to PullMessages with more than 1, will have to look at this when I get some time and then re-test with every brand of camera.

@matt1 Iā€™ve already compiled a version of the addon with some changes that seems to work fine for my camera.

Iā€™ve uploaded my code changes to GitHub if you want to take a look. I also found some other bugs and did some improvements that I think are making more sense. But I also just started looking into the Onvif documentation, so I donā€™t know if this is all correct and will work for every camera.

You can find my code changes here: Various fixes for IpCamera Ā· TheNetStriker/openhab-addons@f8e8602 Ā· GitHub

Iā€™ve also added GitHub comments there for every change.

Great it looks good, just need to get rid of the commented out code and its ready for a pull request.

Thatā€™s sadly the fact of it, even if you do it ā€˜rightā€™ to your interpretation it does not mean it will work on all the different interpretations different companies have made. Sometimes changing a setting in the camera means it will break, example is the get date and time request with reolink as outlined in my post I gave the link for. I will need to run some big tests so lets move quick so we get 1 milestone for things to be tested in before the next stable comes out in Decā€¦

The changes you made in the file IpCameraHandler.java I am not sure about the removal of the ā€˜renewā€™ request, is that something that you found was necessary to do? Also we should keep the ONVIF thing type as close as possible, so the change to sending CreatePullPointSubscription when the events have stopped is probably worth doing. It will result in 2 requests being sent instead of only 1, so once again if this was a neccessary change is it worth doing it for other ONVIF cameras or is it a work around only for reolink? Maybe better to make these comments in a PR not here on the forum.

Look forward to getting these changes merged, and I will hold off on making changes till you do so as not to create any merge conflicts.

I just got a reply from Reolink regarding the problem. They sent me a new beta firmware. (RLC-820A.4031_2409091860.IPC_523128M8MP)

I just tested the new firmware and the problem with the Onvif service crashing with a MessageLimit of 1 is fixed there. Also in the WSBaseNotification the events are now all sent in a single reply.

There are also two new events in this firmware for my camera:

tns1:RuleEngine/MyRuleDetector/Visitor
tns1:RuleEngine/MyRuleDetector/Package

The Visitor event is already implemented in the OpenHab addon, but the package event is new. But the package event is triggering at the moment. I guess this is still in development.

The only problem I noticed so far is that the two new events are not sent in the first call with PullMessages. Iā€™ve tried with multiple MessageLimit values but I only ever got the first 6 events in one request. The two new events are only ever sent in the second PullMessages request. This is just a small issue and I just reported this to Reolink.

Regarding my changes I have to do some testing first. I noticed that the ā€œThe alarm stream was not running for Reolink cameraā€ log entry was in the log at some times. I guess this could be a timing issue of the pollCameraRunnable because there is a small window where a new connection to the camera is initialized and before the PullMessages request is counting up the pullMessageRequests AtomicInteger. I will try to find a solution for this.

Regarding the Renew request I did take a look at the messages the Onvif Device Manager sends and it sends a Renew request when using PullMessages. So I think it is best to leave the Renew request in the code.

The Onvif Device Manager also sends a renew request when using the Push WSBaseNotification. In this case the notification url (e.g. http://cameraip:8000/onvif/Notification?Idx=10231767) has to be sent to the camera. The question here is if some cameras only support one or the other method to get the events. In case there are cameras that only support the Push notification the addon should support both methods, but not both at the same time for cameras that support both methods. Do you know if this is the case on some cameras?

I would prefer not to discuss this in this thread as it is now offtopic, please create a new thread on the forum, or you can create a PR with your changes, then it can be discussed with the actual code changes. You can always mark a PR as a work in progress if it is not finishedā€¦

I have not seen a camera that supports both ONVIF methods fully yet. Most of them use the PullMessages, probably because people complain when the camera does not work in the Onvif Device Manager program. I was taking the stance that we should try and use PullMessages first and if that does not work, to fall back to using Basic Notification Interface.

See this white paper:

9 Eventing
The ONVIF specification includes three different types of event notifications:
ļ‚· Real-time Pull-Point Notification Interface
ļ‚· Basic Notification Interface (WS-BaseNotification)
ļ‚· Notification Streaming Interface (metadata streaming)

There are examples and guides on how it should be done in there.

I am using my camera for motion dection to switch on some lights. Sometimes it seems to be a bit sluggish.

How to ensure, that this Interface is used?

I just created this new topic to discuss this further.

You can enable TRACE logs and see if PullMessages is getting sent over and over.

Yes, PullMessages ar sent over and over:

2024-11-07 11:36:52.693 [DEBUG] [amera.internal.onvif.OnvifConnection] - No ONVIF Events occured in the last 8 seconds
2024-11-07 11:36:52.694 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: PullMessages to http://192.168.178.50:8000/onvif/PullSubManager?Idx=57791
2024-11-07 11:36:56.918 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: Renew to http://192.168.178.50:8000/onvif/PullSubManager?Idx=57791
2024-11-07 11:36:57.017 [TRACE] [amera.internal.onvif.OnvifConnection] - ONVIF Renew reply is: <?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:tan="http://www.onvif.org/ver20/analytics/wsdl"><SOAP-ENV:Header><wsa5:To SOAP-ENV:mustUnderstand="1">http://192.168.178.50:8000/onvif/PullSubManager?Idx=57791</wsa5:To><wsse:Security><wsse:UsernameToken><wsse:Username>smarthome</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">zhaVrzyefThgdAutSc2rAOZ2VDg=</wsse:Password><wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">LTE5NTg5NjY0OTQ=</wsse:Nonce><wsu:Created>2024-11-07T10:36:56.920Z</wsu:Created></wsse:UsernameToken></wsse:Security></SOAP-ENV:Header><SOAP-ENV:Body><wsnt:RenewResponse><wsnt:TerminationTime>2024-11-07T10:37:07Z</wsnt:TerminationTime><wsnt:CurrentTime>2024-11-07T10:36:57Z</wsnt:CurrentTime></wsnt:RenewResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

How can i achieve that i get Real-time notifications?

You would need to ask Reolink that question. The binding processes it right away, so the camera needs to detect the event and then reply to the PullMessages that stays open with the camera waiting for an event to occur. It is possible that the WS-BaseNotification
method may work better, but someone would need to try it and then compare the two. @TheNetStriker may be able to test it. I have seen people mention that this method may work better with Reolink due to their cameras not liking the resources staying open. In theory the PullMessages way should be faster, as the negotiation of opening a http connection is already done. But as mentioned, itā€™s purely up to the cameras firmware and what is causing your ā€œsluggishā€ response.

I only noticed a small delay when using the Reolink api. With Onvif it was always instant.

Did you set the alert delay to 0 in the Reolink app? It is set to 2 seconds by default.

The delay is not that bad in the end. But sometimes it takes 1-2 seconds, or more? I canā€™t really measure it, because i go into the zone an then ā€œwaitā€ until the light goes onā€¦

Yes.

Because of this i want to understand how this works. Perhaps i can improve something.

When is Onvif used?
I created a ipcamera:reolink thing and set the correct value for onvifPort.

Furthermore the ā€œPullMesagesā€ (over and over) does not seem to be optimal. I could imagine, that it is more instant, when the camera sends the event directly, without asking per polling. But i donā€™t know hat onvif and the reolink api works.

When the Onvif port is set Onvif should be active.

The PullMessages method should not be much slower than the WSBaseNotification in my opinion because the request to the camera is held open for several seconds. If an event happens there should be an immediate response from the camera with the event. Then a new PullMessages request is sent.

Iā€™m currently testing the addon with my changes and optimiziations because my camera did not work at all with the current version. If you would like to test my version I could upload the modified addon somewhere. Maybe my changes also help reduce the delay.

Thats possible if the camera needs to send 5 events, then the older binding would need to ask 5 times and with your changes they would all go through in a single message. Thats why its been on the todo list for a while.