I think I posted about this recently in this thread, see litterally 2 of my posts above… I’m not surprised that for some cameras the snapshot creating stream gets closed, as I don’t use this part of the binding, it has not gotten the attention that other areas of the binding have gotten. See that post for other ways to work around the issue.
I think the following are true:
The binding should auto re-open the stream if the camera closes it as this has already been done to a number of the other features the binding has.
Your idea to make it work on demand is good and it should be just achievable, as for it to work ffmpeg would need to be able to supply a snapshot in under 5 seconds, and from basic tests I did a long time ago, it takes around 4 seconds on an ARM based setup that is not stressed with other tasks.
It probably makes sense to implement both changes and then give the user an option to disable the non stop stream if they wish.
As always the question is who will make the changes? as the above is probably 20 to 30 hours of work to complete and I would rather spend this time on changes that reward my own setup or spend time with my family. As mentioned there are ways to work around it mentioned in my post above as well as doing it with a script. Best to raise this as an issue on github and see how many people request it, up until the last person above, no one had raised this as an issue.
EDIT: @m-home
I had a look in the code and noticed that when creating snapshots from RTSP the channel called pollImage can be used to start and stop the process, so it should already be possible to stop the creation of the snapshots and free up resources by using this channel. It could also be used to restart the process in rules if it has stopped.
Sorry to ask this directly to everyone. I have trying for the last half a day to integrate Reolink E1 Pro cameras with the binding but with no success . Thied to find some answers in the forum but I did not find any.
I tried with onvif camera and rtsp/http camera things, but I do not seem to get the configurations right because I have no image. The camera does not have http access, only rtsp stream and PTZ control. It works fine in Onvif device manager though.
Could some that has a working configuration for these cameras post it here so that I can have a go at it?
Will do so. Just have to reproduce the test and look at the logs. If I do jot find a way I am going to document all the steps and logs to post in a new thread.
What is the default log level of the binding? I am asking this so that I can revert it back after testing.
i also use a RLC 520 and atm the only thing I would need is a livestream. Unfortunately, after some time, the stream stops. Sometimes after a few hours, sometimes after a few days.
I have da RPI4 with openhab 3.2.
IP cam via cable.
Maybe you can share your settings (does motion detection work ?)
On the other hand I use a TP Lip Tapo, which streams 24/7 since the beginning of the year.
Upgrade to openHAB 3.3 Milestone 1 as the binding has an improvement that will auto restart the mjpeg stream if the camera reboots, goes offline or drops out.
This user has reported it works. Just bear in mind that ONVIF can send the motion to one of two different channels depending on which type of motion is setup.
This is how I defined the thing. I use a habpanel to view 3 cameras if motion is detected. The cellMotionAlarm changes state if the camera detects motion. I used a substream to reduce the load on the server. I am running OH in docker on a i5, 2.9Ghz and 3 streams in full resolution created significant load (at least on OH 3.2).
as suggested, I updated to 3.3 M1. Now it stops working again, although it states online in the UI.
In the logs I get the following.
2022-02-18 20:03:34.212 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ipcamera:onvif:Reolink' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Connection Timeout: Check your IP and PORT are correct and the camera can be reached.
after a few seconds
2022-02-18 20:03:38.223 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ipcamera:onvif:Reolink' changed from OFFLINE (COMMUNICATION_ERROR): Connection Timeout: Check your IP and PORT are correct and the camera can be reached. to ONLINE
But the stream stopped at 20:03:40 (at least this time is stated in the camera feed)
You do not need to include the user:pasword@ the binding will handle it without this so that the password is only in one place and hidden in a password field. It works both ways thou, I just think it makes it easier to change your password and then only update it in 1 place.
Further to this minor point I have these as well…
You have onvifMediaProfile listed twice.
onvifMediaProfile is 0 but you are wanting to use substream 1 so you can make this onvifMediaProfile = 1 and then rely on full auto discovery of the url by the binding and not over ride the ONVIF system. IE you can then leave out the ffmpegInput and it should be auto found and supplied by ONVIF.
Since you have a working setup, can you tell me (to help the other people) if the auto discovery and setup is not working correctly? Why have you needed to provide the url manually? If there is an issue, it needs to be looked at as to why, so it can be fixed, but so far no one is reporting there is a problem, nor providing the logs to show what happens.
Do you have the sub stream enabled in the cameras setup? Most cameras come with substreams disabled, does 0 the mainstream work before you try moving to a value of 1? I do not know Reolink cameras at all so I do not know the default settings and capabilities.
@Daniel_OH
Really it is pointless asking people to guess at what is wrong. The correct and fast way is to read the very first section of how to get help and follow it. I need logs that show exactly what is going on AND it placed in its own separate thread.
@matt1
Thank you for the hint, I removed the duplicate onvifMediaProfile.
The reason for using the ffmpegInput was to have a known good input to view substream 1
I tried to use the discovery but it did not work. I assumed this was due to using not supported cameras or similar. I still have 4 other Reolink cameras which should support ONVIF. When scanning I get the error below.
2022-02-19 13:59:49.364 [ERROR] [nternal.DiscoveryServiceRegistryImpl] - Cannot trigger scan for thing types ‘[ipcamera:hikvision, ipcamera:onvif, ipcamera:foscam, ipcamera:doorbird, ipcamera:generic, ipcamera:dahua, ipcamera:instar, ipcamera:amcrest]’ on ‘IpCameraDiscoveryService’!
io.netty.channel.ChannelPipelineException: org.openhab.binding.ipcamera.internal.onvif.OnvifDiscovery$2 is not a @Sharable handler, so can’t be added or removed multiple times.
at io.netty.channel.DefaultChannelPipeline.checkMultiplicity(DefaultChannelPipeline.java:600) ~[?:?]
at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:202) ~[?:?]
at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:381) ~[?:?]
at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:370) ~[?:?]
at io.netty.bootstrap.Bootstrap.init(Bootstrap.java:262) ~[?:?]
at io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:311) ~[?:?]
at io.netty.bootstrap.AbstractBootstrap.doBind(AbstractBootstrap.java:272) ~[?:?]
at io.netty.bootstrap.AbstractBootstrap.bind(AbstractBootstrap.java:268) ~[?:?]
at org.openhab.binding.ipcamera.internal.onvif.OnvifDiscovery.discoverCameras(OnvifDiscovery.java:220) ~[?:?]
at org.openhab.binding.ipcamera.internal.IpCameraDiscoveryService.startScan(IpCameraDiscoveryService.java:70) ~[?:?]
at org.openhab.core.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:195) ~[?:?]
at org.openhab.core.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:377) ~[?:?]
at org.openhab.core.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:362) ~[?:?]
at org.openhab.core.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:211) ~[?:?]
at org.openhab.core.io.rest.core.internal.discovery.DiscoveryResource.scan(DiscoveryResource.java:105) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.4.5]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.4.5]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.4.5]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.4.5]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.4.5]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.4.5]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298) ~[bundleFile:3.4.5]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:217) ~[bundleFile:3.4.5]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) ~[bundleFile:3.1.0]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273) ~[bundleFile:3.4.5]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) ~[bundleFile:9.4.43.v20210629]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434) ~[bundleFile:9.4.43.v20210629]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.43.v20210629]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:82) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) ~[bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:386) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.43.v20210629]
at java.lang.Thread.run(Thread.java:829) [?:?]
remove all cameras from the network, ie unplug them.
restart openHAB to ensure it is a clean restart with no errors already having occurred.
Scan for cameras and if it only happens when a camera is on the network, but does not if there are none then it would need to be looked at from a camera causing the binding to crash.
I have looked at the coding the error gives me some hints so thanks for posting it. I suspect it may be caused by a bug handling multiple network cards. My system only has 1 network card so I never see that error. Its possible that if your using on a system with wifi and wired network cards it may be hitting a bug that I can not reproduce with only 1 network. In this case it would be happening with every raspberry pi owner and I would be stunned why no one has reported it yet.
If you could help narrow down the cause that would be great.
Also separately the discovery I was really referring to was what happens when a camera connects that is already added as an ONVIF thing. It talks to the camera and asks for the date and time and any URLs that the camera has and more. This handshake is what I am keen to see as you should not have to give any URLS to the binding, if the camera is truly ONVIF compatible. If there is a bug in this area it would be great to squash it.
I am using a docker container on amd64. The OH container runs network_mode: host. The host has a macvlan defined named pubhost_net as there is multiple docker containers on the same host having their own IP. Shall I provide a trace of such a discovery?
Unplugging all cameras is a quite time consuming action I would like to avoid BUT I am willing to do it to help to improve the binding.
1 user also with Docker, another I will have to assume does not use Docker as they use openhabian.
I have a USB network card laying around so I can try adding it to mine and see if I can reproduce the error. It may be a rights issue accessing the network card. This is certainly not my strong area but I suspect it has nothing to do with the cameras and more to do with accessing the NIC network cards.
I’m sorry that I’m not clear in my wording here. Currently it seems to work again without me changing anything. the only thing I can think of as a difference to the TP Link camera is that the TP Link is connected directly to the switch, while the Reolink is supplied via powerline. and therefore perhaps a little less reliable.
After upgrading from OH3.1 to OH3.2 there are some changes with the binding…
3.1: Request a snapshot with the URL http://192.168.xxx.xxx:54321/ipcamera.jpg <= was working fine (incl. recorded .gif)
3.2: Request a snapshot with the URL http://openhabIP:8080/ipcamera/{cameraUID}/ipcamera.jpg <= not working for myself anymore.
Hi @matt1 , I’ve read through several threads, your git commits, the docu etc.
I cannot finde any reason or issue, just read and followed the 3.2 addon docu carefully…
Nevertheless, it’s not working for me, that’s why I’m asking here…
EDIT:
Seems that I found the issue…
UUID is not “ipcamera:generic:esp32cam” it’s just “esp32cam”…
how to get rid off errors in the logs for Video URL ? I have Dahua cam which has 3 streams and for 3rd one I configured in cam as mjpg which want to show in a sitemap:
`
. Thied to find some answers in the forum but I did not find any.
