IpCamera: New IP Camera Binding

Mike5 · December 12, 2021, 11:22am

thank you with the http 500 error! it works now

Here is the tracelog after trigger the motion alarm:

2021-12-12 12:20:09.840 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is 	:-- myboundary
Content-Type: text/plain
Content-Length:39
Code=AudioMutation;action=Start;index=0
:
2021-12-12 12:20:10.146 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is 	:-- myboundary
Content-Type: text/plain
Content-Length:38
Code=AudioMutation;action=Stop;index=0
:

My AudioAlarm Item is linked with the audio alarm channel, showing “NULL”.

matt1 · December 12, 2021, 12:55pm

issue found other cameras are using this without the space after --, will need to add some code to handle this.

edit: @Mike5 the fix which needs to be tested, is in the precompiled jar linked with todays date on it in the threads first post here.

IpCamera binding - Breaking changes and new features in 3.2 Milestone 3 and newer - Add-ons / Bindings - openHAB Community

Mike5 · December 13, 2021, 5:36pm

it works!
AudioAlarm, MotionAlarm and LastMotion is now correct filled
Thank you for this fast “bug” fix. You are my hero!

justjosh · December 15, 2021, 12:23pm

Is there a way to reboot the camera by cli? The mjpeg stream crashes so much it’s unreliable and I would like to just try using a cron script to just reboot the camera every hour.

matt1 · December 15, 2021, 11:24pm

Some brands of cameras do have that ability in the API. Usually searching the ipcamtalk forum will turn up a copy of the API in pdf format. The ipcamera.mjpeg stream will not survive a camera rebooting (on the long todo list of things to look into), the two snapshot based streams should survive if you have the latest binding version.

Lukas_1st · December 17, 2021, 12:19pm

Hi matt1,

I have a similar problem as Marcin had, i.e. when I try to view the stream from the camera, I have a preview for a few seconds and then the image is frozen.

Log

2021-12-17 13:18:33.108 [DEBUG] [amera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.1.28
2021-12-17 13:18:35.591 [DEBUG] [amera.internal.servlet.CameraServlet] - Now there are 0 ipcamera.mjpeg streams open.
2021-12-17 13:18:35.593 [DEBUG] [amera.internal.servlet.CameraServlet] - All ipcamera.mjpeg streams have stopped.

There is difference when I try to call

curl http://user:pass@192.168.1.28:8080/live/mjpeg --verbose

I receive the following answer:

*   Trying 192.168.1.28...
* TCP_NODELAY set
* Connected to 192.168.1.28 (192.168.1.28) port 8080 (#0)
* Server auth using Basic with user 'user'
> GET /live/mjpeg HTTP/1.1
> Host: 192.168.1.28:8080
> Authorization: Basic Y2FtX3VzZXI6bHVndTA2MDc=
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 200 OK
< ETag: "1639433438000"
< Content-Type: text/html
< Content-Length: 1215
< Server: Jetty(9.4.43.v20210629)
<
<!doctype html><html><head><meta charset="utf-8"><meta http-equiv="Content-Security-Policy" content="default-src * 'self' 'unsafe-inline' 'unsafe-eval' data: gap: content: blob:; style-src 'self' 'unsafe-inline';"><meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,minimum-scale=1,user-scalable=no,minimal-ui,viewport-fit=cover"><meta name="theme-color" content="#e64a19"><meta name="format-detection" content="telephone=no"><meta name="msapplication-tap-highlight" content="no"><title>openHAB</title><meta name="apple-mobile-web-app-capable" content="yes"><meta name="apple-mobile-web-app-status-bar-style" content="black-translucent"><link rel="apple-touch-icon" href="/res/icons/apple-touch-icon.png" type="image/png" sizes="180x180" crossorigin="use-credentials"><link rel="icon" href="/res/icons/favicon.svg" type="image/svg+xml" sizes="any" crossorigin="use-credentials"><link rel="icon" href="/res/icons/128x128.png" type="image/png" sizes="128x128" crossorigin="use-credentials"><link rel="manifest" href="/manifest.json" crossorigin="use-credentials"><link href="/css/app.css" rel="stylesheet"></head><body><div id="app"></div><script src="/js/app.js"></script></body></html>* Connection #0 to host 192.168.1.28 left intact

Before changing in version 3.2 - new URL’s
http: // openhab: 8080 / ipcamera / <<cameraUID>> /ipcamera.mjpeg
the cameras (Foscam) worked properly.

matt1 · December 18, 2021, 1:44am

That is not the URL that the binding has hard coded into it for foscam, you have changed it to something else?

Try the URL that is here and let me know if the url needs to be changed from the default value. I dont have a foscam here to test with.

How to get the MJPEG stream of Foscam camera using a CGI command?-Foscam Support - FAQs

It is not returning a stream but instead a webpage. If it used to work then it may have done a redirect to a stream from that html code, I don’t know.

justjosh · December 18, 2021, 4:49pm

Actually I was asking if there was a way to use the CLI to reboot the openhab item linked to the cam. Otherwise the entire OH becomes unusable without a full reboot.

Lukas_1st · December 18, 2021, 10:03pm

Ok, it was my mistake. After applying the correct URL, I receive a very similar response to Marcin

*   Trying 192.168.1.17...
* TCP_NODELAY set
* Connected to 192.168.1.17 (192.168.1.17) port 88 (#0)
> GET /cgi-bin/CGIStream.cgi?cmd=GetMJStream&usr=user&pwd=pass HTTP/1.1
> Host: 192.168.1.17:88
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-type:multipart/x-mixed-replace;boundary=ThisString
* no chunk, no close, no size. Assume close to signal end
<
--ThisString
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 1419)
* Closing connection 0

Is this the same problem? And, could it say that the new version of binding has cut out the use of sepcific ip cams? Before the changes in 3.2 version, everything was working fine.

When I tried to put the contents of the stream into the file, the connection was not broken.

Chud_WY · December 19, 2021, 1:58pm

Hello everyone, I am taking the first steps with OH3, several Hikvision and HiWatch (the same API) cameras are connected to my OH3 as things (thingTypeUID: ipcamera: hikvision), I receive motion detector events from them (Motion Alarm channel). I tried to disable/enable the motion detection by channel Enable Motion Alarm and it also works - the VMD turns on and off, BUT, then i find the problem, after turning on (every time) the detector settings (sensitive and percent) resets by default. Is this a binding error or is there something wrong with my settings?

matt1 · December 20, 2021, 12:25am

Try changing your alarm settings, and then pause and unpause the camera thing. Then see what happens. The binding stores the last lot of settings to speed up the changes, so if you changed the settings in the cameras control panel after the binding had already stored/cached the info, then that would explain the issue. Pause and unpause the camera thing, also sending a REFRESH command to the channel will also do it.

Chud_WY · December 20, 2021, 12:52pm

Big thaks for your help. It solved half of the problem. The settings are now not reset, but only in the “normal” mode, if the settings were made in the “expert” mode, they are reset to “normal” mode.
it looks like binding does not save motion detection expert mode settings

Sebastian_Neu · December 21, 2021, 8:08am

Hi, I get the following error when I start the automatic search. I have installed the latest RC.

Any ideas?

2021-12-21 09:05:10.282 [TRACE] [camera.internal.onvif.OnvifDiscovery] - Device replied to discovery with:<?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:tdn="http://www.onvif.org/ver10/network/wsdl"><SOAP-ENV:Header><wsa:MessageID>urn:uuid:9ffc87ed-7c55-4c8c-bd1b-58ba507ed7ab</wsa:MessageID><wsa:RelatesTo>uuid:50c4ab04-848f-4194-a703-03ddcec27645</wsa:RelatesTo><wsa:ReplyTo SOAP-ENV:mustUnderstand="true"><wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address></wsa:ReplyTo><wsa:To SOAP-ENV:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To><wsa:Action SOAP-ENV:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</wsa:Action><wsdd:AppSequence InstanceId="0" MessageNumber="4"></wsdd:AppSequence></SOAP-ENV:Header><SOAP-ENV:Body><wsdd:ProbeMatches><wsdd:ProbeMatch><wsa:EndpointReference><wsa:Address>urn:uuid:f87724f0-1787-4e12-ab8b-4567327b23c6</wsa:Address></wsa:EndpointReference><wsdd:Types>tdn:NetworkVideoTransmitter</wsdd:Types><wsdd:Scopes>onvif://www.onvif.org/name/Unknown onvif://www.onvif.org/Profile/Streaming</wsdd:Scopes><wsdd:XAddrs>http://10.0.0.60</wsdd:XAddrs><wsdd:MetadataVersion>0</wsdd:MetadataVersion></wsdd:ProbeMatch></wsdd:ProbeMatches></SOAP-ENV:Body></SOAP-ENV:Envelope>
2021-12-21 09:05:10.286 [INFO ] [camera.internal.onvif.OnvifDiscovery] - Camera found at xAddr:http://10.0.0.60
2021-12-21 09:05:10.288 [ERROR] [nternal.DiscoveryServiceRegistryImpl] - Cannot trigger scan for thing types '[ipcamera:onvif, ipcamera:foscam, ipcamera:doorbird, ipcamera:generic, ipcamera:dahua, ipcamera:instar, ipcamera:amcrest, ipcamera:hikvision]' on 'IpCameraDiscoveryService'!
java.lang.StringIndexOutOfBoundsException: begin 7, end -1, length 16
	at java.lang.String.checkBoundsBeginEnd(String.java:3319) ~[?:?]
	at java.lang.String.substring(String.java:1874) ~[?:?]
	at org.openhab.binding.ipcamera.internal.onvif.OnvifDiscovery.searchReply(OnvifDiscovery.java:112) ~[?:?]
	at org.openhab.binding.ipcamera.internal.onvif.OnvifDiscovery.processCameraReplys(OnvifDiscovery.java:131) ~[?:?]
	at org.openhab.binding.ipcamera.internal.onvif.OnvifDiscovery.discoverCameras(OnvifDiscovery.java:230) ~[?:?]
	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) [?:?]

matt1 · December 21, 2021, 9:05am

Not sure it will help but first upgrade to 3.2 Stable and then reboot twice. If you have not rebooted a few times after doing a upgrade its possible that is the cause.

Lukas_1st · December 21, 2021, 12:23pm

@matt1, is it possible to return to the previous way of transmitting from those ip cameras that are not properly supported in version 3.2?

I described the problem above.

matt1 · December 21, 2021, 10:59pm

Yes it is very simple with openHAB. Just run the latest 3.2 Stable core and you uninstall the merged binding and drop in the jar into the addons folder.

You can find a range of older binding versions here:
Index of /openhab/IpCameraBinding/OldVersions/ (pcmus.com)

Just before killing the old serving code I made a build with “dual servers” in it and that build is named that way. I would not recommend mixing and matching the old and new URLS from the same camera. Stick to only using the URLS from one of the methods otherwise it may/will loose track of how many streams are open. The build that was from before the new methods is also there, just look at the date stamps.

paglatz · December 22, 2021, 12:34am

Hi All,

i upgraded yesterday also to OH3.2 and with it, upgraded the new ipcamera binding. I have adapted the path of my webview item to the new mjpeg url definition.

Video url="http://192.168.1.1:8080/ipcamera/1234567890/ipcamera.mjpeg" encoding="mjpeg"

My video is now showing up again, but it has massive picture fragments, is flickering all the time and is really not nice to look at. Prior to the upgrade (so with OH3.1 and normally installed binding) everything worked like charm.

Logging in into the webcam (INSTAR IN-9020) everthing seems to be fine. I have also stopped and restarted the binding as well as restarted the webcam. Also rebooted the pi but still no improvements. I am running OH on default 8080 port, is this maybe causing an issue?

Are there any hints how to fix these issues?

Thanks
Patrick

matt1 · December 22, 2021, 1:01am

Best to start a new thread and also include some TRACE level logs that show what happens when the very first ipcamera.mjpeg is requested.

I used to have this happen when I spammed the refresh button on my browser when watching the stream. I suspect it occurs when 2 streams come from the camera to the binding at the same time and if that is happening the logs will show it. Pausing and unpausing the camera should reset it.

No not the cause and it is the best to keep things on the defaults.

One thing you can try is just playing with the cameras settings for the mjpeg stream, increase and decrease the quality settings and such to see if it changes the size of the packets which may help. I tested it with an Instar camera here and it works fine so have a play with the settings and I will do that here to see if it can be reproduced.

Instar cameras can have the user/pass inserted into the URL, so you can always do that and use the cameras URL directly and not through the binding.

paglatz · December 25, 2021, 11:44am

Hi @matt1,

will follow your suggestion and create a new thread including the TRACE logs. In the meantime i will play around with the settings.

The only thing i am wondering about is, why there was absolutely no problem with OH3.1.

Will notify you when the new thread is created (family keeps me busy these days).

Thanks Patrick

osztrovszky · December 25, 2021, 10:34pm

Hello,
I also have ipcamera problem since OH3.2.
I upgraded from OH3.1 where HLS stream was working fine.
Now HLS URL gives 404 error.
If I turn on debug log for ipcam binding, I see that the ip is missing from the source URL in the ffmpeg command. Is it a bug maybe in this new version?

Regards,
Zsolt