Onvif camera error message

During the integration of my Reolink camera RLC-511 WA I unfortunately have a problem and an error message appears. Since I haven’t been able to find a solution for many hours, I’m now turning to the community.
When using the “Onvif IP Camera” binding and calling “http://192.168.1.2:77790/ipcamera/daa5362ac2/ipcamera.mjpeg” in the Firefox browser, I get the following message:

HTTP ERROR 500 java.lang.StringIndexOutOfBoundsException: String index out of range: -1
URI:	/ipcamera/daa5362ac2/ipcamera.mjpeg
STATUS:	500
MESSAGE:	java.lang.StringIndexOutOfBoundsException: String index out of range: -1
SERVLET:	org.ops4j.pax.web.service.spi.model.ServletModel-47
CAUSED BY:	java.lang.StringIndexOutOfBoundsException: String index out of range: -1
Caused by:

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.base/java.lang.String.substring(String.java:1837)
	at org.openhab.binding.ipcamera.internal.handler.IpCameraHandler.getTinyUrl(IpCameraHandler.java:489)
	at org.openhab.binding.ipcamera.internal.handler.IpCameraHandler.openCamerasStream(IpCameraHandler.java:672)
	at org.openhab.binding.ipcamera.internal.servlet.CameraServlet.doGet(CameraServlet.java:186)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550)
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434)
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:82)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
	at org.eclipse.jetty.server.Server.handle(Server.java:516)
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388)
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:386)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
	at java.base/java.lang.Thread.run(Thread.java:829)

I have OH3 running in Docker. also Motioneye

Thanks for creating a new thread. This seems to be reported by a number of users that have done a recent firmware update on the cameras. See here for more details, but the short answer is it appears to be a bug in the latest firmware so it needs to be reported to Reolink support.

IpCamera: New IP Camera Binding - Add-ons / Bindings - openHAB Community

@DieterK
It may be an idea to implement this API mentioned in this thread and use that instead of using the onvif events? Other brands that have an API all do this, they connect via onvif to gain PTZ features and do not use the event side of onvif, and instead use their own api method to gain motion and more advanced information. I do not know if the API has an advantage over the ONVIF method other than it looks like it works behind their NVR’s which probably is a reason in itself to consider taking this path, you interested in testing?

Setting up NVR-based Reolink cameras - Add-ons / Bindings - openHAB Community

Hi Skinah,

i have two “news” on that, one good one bad.

bad first

I gave up comunicating with Reolink support!

Although i pointed them to the very exact protocol element causing the issue, i haven’t received ANY detail.

Nothing whether they tried or even managed to reproduce the issue.

There are plenty of emails they promissed to escalate to designer and to come back, actually without any response, week by week complaining from my side!

Useless to say, that there was no finger pointing or blaming.

good news

I managed to improve/extend the IP camera binding.

It’s now capable of handling multiple IE within one message, i.e. MessageLimit set to higher number than 1

Looks like Reolink camera is stable with this (fingers crossed)

I as well added few further functionalities to the ip camera binding:

  • PET detected (tested)

  • human detected (tested)

  • car detected (not tested - due to lack of car in my garden ;-))

Not sure what API in the thread you are exactly referring to …

I experienced calling the Reolink CGI script to retrieve AI details (pet, human, car detection) at the point in time motion has been detected, in some cases doesn’t work out!

Either the AI algorithm still works (you are to fast calling the script) or the result already passed by (range is about 0 to 6 seconds).

After i got the extended binding working, i even experienced e.g. pet detection event before a motion event was raised (in rare cases even w/o any motion event).

Maybe worth to mention that still Reolink events beings raised do not map 1:1 with what they record (no idea on whether this is limited to RLC-811A).

Hopefully this will be fixed with a newer release.

Haven’t reported this yet due to limited / zero progress on the more serious issue :frowning:

The binding extensions i added (similar to initial code) don’t make use of a XML parser.

I don’t feel really comfortable with this, but didn’t want to turn the code upside down.

This would have required more detailed tests with other camera types as well, i fear.

Will continue some tests, this and maybe next week.

Up to now camera seems to be stable, as mentioned above.

For convinience attached some ONVIF test cases (explicitly mentioning MessageLimit being set to 1)!

https://www.onvif.org/wp-content/uploads/2017/02/ONVIF_DeviceIO_Test_Specification_17.01.pdf

https://www.onvif.org/wp-content/uploads/2019/07/ONVIF_Receiver_Test_Specification_19.06.pdf

I wiill show up again end of next week on how to proceed further.

Especially

  • risk on further Reolink interface changes (firmware is in beta stadium) breaking the extension

  • how to do code review

Dependant on above, if and where to apply the changes (trunk and/or backport to recent release branch)?

Best regards,

Dieter

Thank you for diagnosing the cause and now also making the change needed. I agree this is better as it is then the same as Onvif Device Manager. The advantage of moving to be the same as ODM is, it is easier for a company to test and confirm on their end compared to setting up openHAB for testing :slight_smile:

Just submit a PR in the openhab addons repo making sure to do the digital signoffs. Then I can do a review there. Once it is submitted for a review it can be added to the marketplace for others to try out and test while it goes through the review. I can test any changes against other brands so don’t worry about that, just keep the number of changes as low as possible so as not to tax the volunteers that do the review. Having said that if you see a way that is more efficient/cleaner or easier to understand, then some extra work doing the review is worth it.

Try this link which this is not my upload or server so use virus protection and common sense.
https://bit.ly/3rWxG6e

Sorry I was too quick to reply and did not read the post fully. Do you mind posting what is supplied to the binding as the mjpeg URL in the things setup? what is supplied in the IP Adress feild? The error is looking like the mjpeg url perhaps does not contain the IP in it or something is going wrong with either of those two input strings. Once I know those 2 inputs, I can look at the code to see what is going wrong using the error you gave in your first post.

Hi Skinah,

thanks for the details!

I had a look into the API.

Actually i wasn’t able to find anything related to events, which forces us to poll :frowning:

Not sure one can treat this as a real option?!

Just a few minutes ago (after weeks of zero progress and hunting for feedback) i received a knife package (i.e. not officially available yet) from Reolink, they claimed they’ve fixed the issue.

I’ll test it of course and will report further.

Anyway, i propose to stay with our earlier timeline and way forward (i.e. get the binding extension in).

Best regards,

Dieter

Since I don’t have any to test with I missed that and yes it would be a negative to poll instead of the onvif event based methods. Best to message me directly or leave to a github review, as I was wrong and this thread is not about the same issue as your fix address’s.