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:
`
Your using the camera directly and not the binding, so I am confused why your posting in this thread? Read the bindings documentation and then open your own new thread.
Yesterday my livestream of the Reolink stopped again - time on the camera was 23:23:07.
These are the logs around this period.
I think it has nothing to do with your binding or openhab (As the TP Link works most of the time), but maybe someone had the same issue and can tell me what wo change on the camera. openhab_log_20220304.txt (50.9 KB)
If I am correct, channels are for when there is a STATE like a light globe is ON or OFF, and rebooting does not have a state, as it is something that you trigger to occur. It is only temporary and you are not able to know the difference between rebooting and the camera being offline. I believe what would be considered the correct way to do it, is implement it as an ACTION which would require you to setup a rule to trigger the action when the switch is moved.
This then makes it almost just as easy to create a script and call the script when the switch is moved with a rule. To be clear I don’t like this answer I am giving and wish it was simple to create a switch for an action that takes zero arguments. It should be simple, to just add a camera and get advanced actions available in the main UI without the need to research and spend 20+ minutes setting it up when it should be available to add when your creating some equipment in the model.
Sadly after a quick github search it appears that actions still are not fully supported by mainUI/core
This is something which is best raised as a request in github, especially as I am busy on another binding at the moment and a post in this long thread is only going to get lost.
Since I always had problems with the Livestream, I have now test an own Rasperry PI in use for the IP Camera Binding. The only binding installed is the IP Camera binding.
Nevertheless, the stream stops after some time.
However, the binding shows me both cameras as online.
I have a copy from the live logging attached as well as the logfile from this afternoon. According to the camera image, the stream stopped at 17:51. Im am running on openhab 3.3 snapshot
I thought maybe its due to the powerline, but for test purposes I connected both cameras directly to the switch. At the time of the failure, both were directly connected to the switch
