IpCamera: New IP Camera Binding

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:

  1. 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.
  2. 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.

Hello to all,

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 :weary:. 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?

Thanks in advanced.

Best regards.

1 Like

How to get help.

IP Camera - Bindings | openHAB

Hello @matt1 ,

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.

Thanks.

Best regards.

Info

Hey,

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.

BR

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).

Thing ipcamera:onvif:OnvifGarage
[
ipAddress=“192.168.123.106”,
onvifPort=“8000”,
username=“user”,
password=“password”,
port=“80”,
onvifMediaProfile=“0”,
ffmpegInput=“rtsp://user:password@192.168.123.106/h264Preview_01_sub”,
onvifMediaProfile=“0”
]

Hope this help. Let me know if you have any additional questions

hi

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)

BR

this is how it looks in my case:

UID: ipcamera:onvif:Reolink
label: Reolink
thingTypeUID: ipcamera:onvif
configuration:
  mjpegOptions: -q:v 5 -r 2 -vf scale=640:-2 -update 1
  ipAddress: 192.168.1.234
  updateImageWhen: "0"
  onvifPort: 8000
  gifPreroll: 0
  ffmpegLocation: /usr/bin/ffmpeg
  ipWhitelist: DISABLE
  mp4OutOptions: -c:v copy -c:a copy
  pollTime: 1000
  password: password
  port: 80
  snapshotOptions: -an -vsync vfr -q:v 2 -update 1
  ptzContinuous: false
  onvifMediaProfile: 1
  username: username
  hlsOutOptions: -strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcodec copy
    -hls_flags delete_segments -hls_time 2 -hls_list_size 4
  gifOutOptions: -r 2 -filter_complex
    scale=-2:360:flags=lanczos,setpts=0.5*PTS,split[o1][o2];[o1]palettegen[p];[o2]fifo[o3];[o3][p]paletteuse

atm I just want to show the livestream. I don´t think its a binding issue, as my TP cam streams 24/7

BR

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…

  1. You have onvifMediaProfile listed twice.
  2. 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.

IP Camera - Bindings | openHAB

@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) [?:?]

You could rule this out by…

  1. remove all cameras from the network, ie unplug them.
  2. restart openHAB to ensure it is a clean restart with no errors already having occurred.
  3. 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.

br-ea659a0dad55: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255
ether 02:42:f6:db:df:81 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::42:fff:fedc:42a8 prefixlen 64 scopeid 0x20
ether 02:42:0f:dc:42:a8 txqueuelen 0 (Ethernet)
RX packets 212373 bytes 30659497 (29.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 410667 bytes 24794209 (23.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.123.10 netmask 255.255.255.0 broadcast 192.168.123.255
inet6 fd00::42a8:f0ff:feae:abdb prefixlen 64 scopeid 0x0
inet6 fe80::42a8:f0ff:feae:abdb prefixlen 64 scopeid 0x20
ether 40:a8:f0:ae:ab:db txqueuelen 1000 (Ethernet)
RX packets 96244329 bytes 110035697774 (102.4 GiB)
RX errors 0 dropped 1475021 overruns 0 frame 0
TX packets 52579638 bytes 30178784527 (28.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7c00000-f7c20000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 10346373 bytes 14879659160 (13.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10346373 bytes 14879659160 (13.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

pubhost_net: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.123.221 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 fe80::e439:31ff:fe61:3a37 prefixlen 64 scopeid 0x20
inet6 fd00::e439:31ff:fe61:3a37 prefixlen 64 scopeid 0x0
ether e6:39:31:61:3a:37 txqueuelen 1000 (Ethernet)
RX packets 6634935 bytes 18135683325 (16.8 GiB)
RX errors 0 dropped 48757 overruns 0 frame 0
TX packets 624172 bytes 42993737 (41.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I searched the forum for a part of the error and found this thread:

IpCamera Discovery error - Setup, Configuration and Use / Installation - openHAB Community

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.

BR

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.

Thing ipcamera:generic:esp32cam
[
ipAddress=“192.168.100.56”,
gifPreroll=1,
pollTime=2000,
ipWhitelist=“DISABLE”,
snapshotUrl=“http://192.168.100.56/capture”,
mjpegUrl=“http://192.168.100.56/stream”,
ffmpegInputOptions="-f mjpeg",
ffmpegOutput="/tmp/openhabcams/",
ffmpegInput=“http://192.168.100.56/stream
]

.gif exists of cause:
grafik

Any Idea’s?

There was a braking change. Read rel ase notes and search this forum.

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”…

thx.

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:
`

Video url=“http://xxx:xxx@xxx.xxx.xxx.xxx/cgi-bin/mjpg/video.cgi?channel=1&subtype=2” encoding=“mjpeg”

`
errors when opening or refreshing a sitemap:

2022-03-03 12:06:23.065 [ERROR] [java.net.CookieManager ] - Invalid cookie for http://xxx.xxx.xxx.xxx/cgi-bin/mjpg/video.cgi?channel=1&subtype=2: secure; HttpOnly
2022-03-03 12:06:23.065 [ERROR] [java.net.CookieManager ] - Invalid cookie for http://xxx.xxx.xxx.xxx/cgi-bin/mjpg/video.cgi?channel=1&subtype=2: secure; HttpOnly

Also strange that on PC I can see video and on android phone with Openhab App no way… Still on OH 2.5, plan to upgrade to 3.2 later this year.