IpCamera: New IP Camera Binding

Tags: #<Tag:0x00007f172df32960> #<Tag:0x00007f172df32898> #<Tag:0x00007f172df327a8>

Uploaded another for you to try :slight_smile:
It should detect the Dahua as a Dahua thing type and it currently does not.
The Reolink seems to have a longer reply and it may have been split into two UDP packets and the second one gets lost.

I would like to tidy those two things up and hopefully the second is done in this build and the first point a trace log should allow me to fix it in the next build.

The logs should be the first place to look, if there was an issue setting that part of the binding up there may be a reason given in the logs. If ffmpeg is not installed or there are permissions issues you will need to look in at least DEBUG level to see the log output telling you that.

BIG THANKS to @matt1

With your event subscription for ONVIF cameras most of my previous scripts seem to be completed now. I have used your new motionAlarm directly from the ONVIF events to trigger video recording. Great job from your side!

As quick protocol:

  • My old cams running ONVIF (version 2.04) do not show event in DeviceManager, but work perfectly with your binding!
  • My very old cams running ONVIF (version 2.01) neither show events in DeviceManager nor work with the binding. Maybe they simply do not support events? Would be tolerable for outdated cams.
  • Surprising my new cams running ONVIF (version 2.20) show events in DeviceManager but do not work with the binding. I will send you TRACE logs on this. Seems format has changed in the ONVIF messages?!

In general thanks a lot the binding is very close to perfection :slight_smile:

UPDATE: The problem with my cams running ONVIF version 2.20 is caused by the new netty library! It does not even connect via ONVIF, does not get RTSP and all the other information, hence also never reaches event subscription and no TRACE of events with new binding possible. I have to roll-back to binding jars from May 2020.

Is it possible to use old netty libs or at least old-style authentication with the new event subscription? What is the difference in the authentication that is used now in Netty.IO?



i had the “Belko b06w- 720p” it works fine with your binding, but I had a problem, I create a gif over a rule and then send it to my pushover.

the problem is the channel “motionalarm” (ipcamera:ONVIF:1921680249:motionAlarm)
when the camera detects a motion the switch goes ON, but after a few seconds it goes to OFF even when the motion not has stoped.

then my rule gets a few times the command to create a gif file, and then he sends a not ready gif file to my pushover, is it possible that the switch doesn’t goes to OFF when motion is still active ?

my rule

rule "Send telegram picture"
    Item motionalarm_camera changed from OFF to ON
        gif_switch.sendCommand(ON) // erstelle gif datei
        Thread::sleep(10000) // warte 20 sekunden
        logInfo("ueberwachungsKamera","Gif erstellt - sende Pushover")   
        sendPushoverMessage(pushoverBuilder("Haustür - Bewegung erkannt.").withAttachment("/usr/share/openhab2/cameratmpfs/8015/ipcamera.gif")) // sende Nachricht mit der gif an pushover

I can’t use the mp4 file because pushover don’t let me send mp4 files. but there I can check if the file is ready

Just a quick one in between:
I just noticed that when automatically discovered in PaperUI I recognized that the Onvif port is kind of detected properly.
However it’s displayed with a decimal point in PaperUI:

Is this related to your implementation or more likely an error in the onvif port response on the camera side?

(I am asking because I also have issues connecting the camera to my synology station)

Thanks -that was the right direction to go:
I now can access the jpg using

When I try to access the mjpeg stream using:
I get:

2020-06-14 12:53:11.464 [DEBUG] [pcamera.internal.StreamServerHandler] - Stream Server recieved request 	GET:/ipcamera.mjpeg
2020-06-14 12:53:11.470 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:/usr/bin/ffmpeg -rtsp_transport tcp -hide_banner -loglevel warning -i rtsp://admin:Ratt3nFr3553@ -qscale:v 5 -r 6 -update 1
2020-06-14 12:53:14.815 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - Guessed Channel Layout for Input Stream #0.1 : mono

System hangs for about 10 minutes without a log entry
Next entry:

2020-06-14 13:02:17.188 [ERROR] [org.openhab.io.net.http.HttpUtil    ] - Fatal protocol violation: org.apache.commons.httpclient.ProtocolException: The server failed to respond with a valid HTTP response
2020-06-14 13:02:17.502 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - All MJPEG streams have stopped, so closing the MJPEG source stream now.
2020-06-14 13:02:17.505 [DEBUG] [pcamera.internal.StreamServerHandler] - Stream Server recieved request         GET:/ipcamera.mjpeg
2020-06-14 13:02:17.505 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - ! Channel was found idle for more than 15 seconds so closing it down. !
2020-06-14 13:02:17.512 [DEBUG] [pcamera.internal.StreamServerHandler] - Stream Server recieved request         GET:/favicon.ico
2020-06-14 13:02:17.649 [DEBUG] [pcamera.internal.StreamServerHandler] - Stream Server recieved request         GET:/ipcamera.jpg

 Is there a network bandwidth / processing power issue because of 5MPix camera on my Raspberry Pi 3B+?

UPDATE_IMAGE setting is OFF.

By the way:
your binding is awesome - so thank you very much for your effort solving a common issue using cameras with openhab.
I just recognized that even detects my ABUS ipcam, where I reverse engineered the web interface years ago.
Now it’s just showing off in the inbox! :slight_smile:

I restarted OH and cleared the cache and tmp files.
Now I can see the jpg as well as the mjpeg stream :
That’s awesome.

Next step is to get PTZ running…

Thanks, glad others find it useful.

Correct OVDM does not do the two different methods that ONVIF offers. The binding does both.
If you have a camera that works in that program, yet does not in the binding check you have todays build and then provide some log in TRACE mode when the binding starts.

That is bad, search forum for why as you only have two threads and you can halt rules from running.
An idea may be to create a virtual switch and use the EXPIRE binding to set it to off after X seconds, use that to debounce the alarm with. All cameras are going to behave differently.

Not the camera, it is Openhab’s framework or how I am using it. Does not cause an issue that I know of.

The 3 and earlier did not have a real 1gb network and it shared with anything on the USB bus, so if you have a SSD on the usb bus… The PI4 was a huge jump forward for the PI range.

No there was two reasons I wrote the netty lib from scratch was to get event support and because I could not fix any bugs that others were reporting… It also lowered the external dependancies so it was win win… Lets just debug the reason why it does not work.

Thanks for your lightning fast support!
That’s an interesting point.
I actually use an SSD on my raspberry.
Finally I found a reason to buy a RPi4

I would recommend the image carrousell widget which cycles through multiple image sources:

I get an Warning when I install the latest binding (from today the 14th.)… Its kinda weird warning. And my cameras are not running:

2020-06-14 18:02:13.540 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.IllegalArgumentException: Duplicate channels ipcamera:ONVIF:Reolink:audioAlarm
	at org.eclipse.smarthome.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:165) ~[?:?]
	at org.eclipse.smarthome.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:141) ~[?:?]
	at org.eclipse.smarthome.core.thing.binding.builder.ThingBuilder.withChannels(ThingBuilder.java:87) ~[?:?]
	at org.eclipse.smarthome.core.thing.binding.ThingFactory.createThing(ThingFactory.java:92) ~[?:?]
	at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.createThing(BaseThingHandlerFactory.java:332) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.getThingFromThingHandlerFactory(GenericThingProvider.java:507) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.getThingFromThingHandlerFactories(GenericThingProvider.java:490) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.createThing(GenericThingProvider.java:433) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.lambda$24(GenericThingProvider.java:898) ~[?:?]
	at java.lang.Iterable.forEach(Iterable.java:75) ~[?:1.8.0_252]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.createThingsFromModelForThingHandlerFactory(GenericThingProvider.java:900) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.lambda$21(GenericThingProvider.java:844) ~[?:?]
	at java.util.concurrent.ConcurrentHashMap$KeySetView.forEach(ConcurrentHashMap.java:4649) ~[?:1.8.0_252]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.thingHandlerFactoryAdded(GenericThingProvider.java:846) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.lambda$23(GenericThingProvider.java:874) ~[?:?]
	at com.google.common.collect.Iterables$4.lambda$forEach$0(Iterables.java:568) ~[?:?]
	at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891) ~[?:1.8.0_252]
	at com.google.common.collect.Iterables$4.forEach(Iterables.java:565) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.handleXmlThingTypesLoaded(GenericThingProvider.java:876) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.onReadyMarkerAdded(GenericThingProvider.java:862) ~[?:?]
	at org.eclipse.smarthome.core.internal.service.ReadyServiceImpl.lambda$0(ReadyServiceImpl.java:52) ~[?:?]
	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) ~[?:1.8.0_252]
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_252]
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:1.8.0_252]
	at java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1699) ~[?:1.8.0_252]
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) ~[?:1.8.0_252]
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) ~[?:1.8.0_252]
	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) ~[?:1.8.0_252]
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) ~[?:1.8.0_252]
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_252]
	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485) ~[?:1.8.0_252]
	at org.eclipse.smarthome.core.internal.service.ReadyServiceImpl.notifyTrackers(ReadyServiceImpl.java:79) ~[?:?]
	at org.eclipse.smarthome.core.internal.service.ReadyServiceImpl.markReady(ReadyServiceImpl.java:52) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.registerReadyMarker(XmlDocumentBundleTracker.java:432) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.finishBundle(XmlDocumentBundleTracker.java:378) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.processBundle(XmlDocumentBundleTracker.java:401) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.access$6(XmlDocumentBundleTracker.java:393) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker$2.run(XmlDocumentBundleTracker.java:363) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_252]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

I did try clear cache, which made no difference.

Going back to the binding from the 13th. my cameras work again.


I have a Yi Home 1080p camera and I use this fw:

It works great, now I just show a snapshot image in openHAB with it and I use the rtsp stream outside openHAB. Both works great.
However installing your binding (ONVIF supported on this fw) it finds the camera, configures it via ONVIF, and it seems to work (it produces snapshots, streams) but after a few minutes it breaks the camera, I’m not able to see the camera output anywhere (not even on its on web interface, and not only the rtsp stream, the snapshot is also gone until I restart the camera).
I know it is hard to debug this as you might not have this kind of camera, but maybe you might have some clue why it breaks the camera.
Removing the Thing from openHAB and restarting the camera, it works as before.

How could I debug this?


Same for me “duplicate audioAlarm” error for all cams due to binding update from today June 14th. The version from June 13th works fine for most of my cams. I can highly recommend this version published yesterday, except of some rare issues still with authentication…

Are there more people facing this problem after the netty lib updates in the binding during June? Maybe you could help me and report the ONVIF protocol versions of your cams from ONVIF Device Manager to see if this is related?

As some cams do not work with the new netty libs, but I appreciate the added value of event subscription via ONVIF very much, let me point to some cool tool… For deeper analysis of ONVIF setup routines I found this tool that has a nice protocol with all received ONVIF messages after setup: https://www.ipcent.com/mobile/onvifer

@matt1 let us know if such log files help you to complement the new netty.io implementation. I have sent you my personal log as private message, just in case it contains private data.

Just wait until the next build before doing anything further as I have an idea and I’ll make a change to see the result.

Yes I made a mistake and my cameras are not ONVIF thing type so I missed that when testing, next build will fix so use the previous build which can still be downloaded in the old builds folder.
The same goes for anyone that has a PTZ camera that fails with the newer builds, there is a build marked as having the previous onvif lib which was a good stable build.

Thank you I will look at it tonight. It is to be expected that there are some teething issues when moving to newly written support, this is why I have asked for TRACE level logs so I can fault find these issues whilst the code is still fresh in my head and I can fix things quickly.

I have always tried to keep the ONVIF non essential to the binding, usually if you provide the URLS manually via the override settings that camera will still work perfectly fine with the only loss of PTZ functions. Onvif is great and I recommend getting a camera with this over one without, however this is going to be an issue forever for some cameras as outside of Openhab you find brand X camera will not work with brand Y NVR. At some point I do have to take the stance that I wont spend 300 hours adding work arounds to get a $20 camera that has flakey software support. Hopefully after the initial teething issues are fixed this will work with 90% of cameras that have a decent reputation online. I doubt I will ever hit 100% :slight_smile:

So far I have no idea what brand or model cameras these are and if they work in Onvif Device manager software. So I am not aiming the above at anyones camera, it is purely an idea to throw out there and an encouragement to get some TRACE logs sent whilst I am happy to look at some logs to see if something silly has gone wrong.

New build 2020-06-15 has these changes:

  • Audio alarm added for ONVIF thing types.
  • A semi poll method used for the Events to lower traffic down. If poll time is 1 second, then you get 1 message per second. Using high poll times may effect how well the event messages work. @rkrisi Does this build allow your camera to keep working?

I saw this happening tonight when I was testing and it may be the camera repeating an old event but with the quick look it does not seem to be timestamped to allow filtering or better parsing. Not enough time to look into this yet. Worth trying the latest build as it now only fetches a single message per poll time.


my cam is ONVIF compatible and I want to add a screenshot to my openhab site. When I click the screenshot button on the cams controls another website opens:

and the picture is shown. When entering the URL manually no picture is shown. I digged deeper into the website code and I found that the access credentials are given in the source code (inside a script) of the page when clicking on the cameras snapshot button, but of course not when entering the url manually:

<img src="snapshot.cgi?user=XXX&amp;pwd=XXX" alt="snapshot" id="snapshot" name="snapshot">

So, should this acutally work with your binding? I have entered my credentials but I still get a blank screen…

Try this in any web browser and if it works then try the binding.


thanks for that, I can open the snapshot in any Browser with this link!

But it still does not work for openhab, maybe I made a mistake in the items file!?

Thing ipcamera:ONVIF:Camera "Keller"

I have the same camera brand (at least the web interface is the same).
It’s named YoLuke and comes from Shenzhen (of course :wink:

My FTP is running well (vsftpd server on RPi).
Maybe you don’t have access rights to the FTP upload folder?
In my vsftpd.conf I have specified :
and in my camera config I have set the path ./IPCam1
which is then /var/www/upload/IPCam1

Have you been able to use the PTZ function?
Dimmer type does not work and it seems, that camera just accepts -1 to 1 for P,T and Z.

Does this mean if my PTZ camera just supports the continous mode, there is no (and will not be) any option to control it by this binding?

Trace shows me:

Onvif reply is:<?xml version="1.0"...

Does this mean, my camera should work with absolute values?
It’s strange though, thaat the range is -1 to 1, so it does not fit to a Dimmer item type.
But with a “regular” number using 0.2 or -0.2 for instance does not work either.

Preset works with PTZ

If I try to create a gif I get:

2020-06-20 11:27:15.439 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:/usr/bin/ffmpeg -y -t 8 -rtsp_transport tcp -hide_banner -loglevel warning -i rtsp://admin:xxx@ -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 /etc/openhab2/html/squirrel/cameratmpfs/ipcamera.gif
2020-06-20 11:27:21.768 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [swscaler @ 0xcbbf60] deprecated pixel format used, make sure you did set range correctly

My camera provides 5 MP on rtsp stream and 800x600 pxl on rtsp stream