IPCamera: trying to get UniView IPC2122LR2 ONVIF to work

Camera UniView IPC2122LR3

Kernel = Linux 4.19.66-v7+
Platform = Raspberry Pi 3 Model B Rev 1.2
openHAB 2.5.9~S217-1 (Build #217)

bundle:list -s | grep camera
349 x Active x 80 x x org.openhab.binding.ipcamera

wget http://'admin:******'@
--2020-09-19 16:48:56--  http://admin:*password*@
Connecting to connected.
HTTP request sent, awaiting response... 401 UnAuthorized
Authentication selected: Digest realm="48ea63fc82ff", nonce="57eef56abb679b71e12d8ac800f9e26b", stale="false", algorithm="MD5", qop="auth"
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 251513 (246K) [image/jpeg]
Saving to: ‘snapshot.jpg.4’
snapshot.jpg.4                100%[==============================================>] 245.62K   201KB/s    in 1.2s

Camera .thing file

Thing ipcamera:onvif:Darzs
[   ipAddress="", 

Update to the latest version of the binding and then give some TRACE log output of the camera on first connect/start.

bundle:list -s | grep camera
351 x Active x  80 x      x org.openhab.binding.ipcamera

And here is TRACE log with freshly started openhab and ipcamera.things been just saved
ipcamera_20200919.log (826.5 KB)

What else I noticed - mjpeg stream is working (I have a feeling it is not working after frst .things refresh, but on second attempt it is). I mean, using default sitemap file from examples

Text label="Cameras Mjpeg Stream" icon="camera"{Video url="" encoding="mjpeg"}

But ipcamera.jpg request is giving the same ‘was requested but there is no jpg in ram to send.’

Another observation - as I’m clicking around on camera’s sitemap, I see buudaipcamera0.ts and other files been created inside /etc/openhab2/html/cameras folder, but not /etc/openhab2/html/cameras/buuda as specified in ffmpegOutput parameter (though an empty folder ‘buuda’ itself been created there)

UPDATE: this particular I ‘solved’ … by reading the github readme … was not ending it with a slash

Run this to clean out your cache and tmo folders. The behaviour is not normal and the logs don’t seem to match up the way they should which can happen if the cache is an issue. Also power cycle the camera after doing this.

sudo openhab-cli stop && sudo rm -rf /var/lib/openhab2/cache/* && sudo rm -rf /var/lib/openhab2/tmp/* && sudo openhab-cli clean-cache && sudo openhab-cli start

Here is a log file after clearing cache, starting it up … and saving ipcamera.things once openhab loaded:

By the end of the file I had commented out the .things configuration and issued openhab restart (and not sure if managed to get into file).

Thank You!

one thing I realize I missed - restart camera:( Will try it again, but in few hours only.

Can you post if there was any change after doing the cleaning? Is it fixed or is there no change? Your log file is too hard to download so I gave up.

Sorry for the log file, will think of how to share it better. Or share just beginning of it.
To my eye it’s not any better/much different:(

Do you have a password with weird characters in it? Can you try changing the password and only use standard English characters to see if it is a glitch of the binding not handling a different character set. This is the only theory I have that the camera must be refusing the user/pass combination and that causes the binding to try again.

If you enter in ffmpeg instead of the snapshot URL, does everything work fine?

hmm, interesting thought … I don’t have anything weird per-se, but an “!” at end of it … took me a while with curl to figure out I need to quote the password, otherwise was not working. will give it a try in the evening, when get back home and let you know.
attaching a little shorter version of log from morning’s session
ipcamera_20200919_short.log (104.7 KB)
those tons of “Sending camera: GET:” per second - is it also because camera refusing the access?

It’s only a guess but it is the only thing that makes sense. The way DIGEST auth works is you send a request, a 401 error is produced and the binding instantly resends with the auth. If the camera was refusing and sending 401 errors every time it could go out of control.
Does the camera give the choice of basic authentication, can you switch the camera to use that instead?

Soooo, here are two logs. I also changed password to (regular)letters, numbers and “-” instead of “!” (UniView interface did not let me change to letters&numbers only:( and I can not also change to just basic auth).

With cleared cache and restarted camera
ipcamera_20200920.log (442.7 KB)

and cleared cache and snapshotUrl=ffmpeg
ipcamera_20200920_ffmpeg.log (145.7 KB)

I don’t see much change in the behavior with ffmpeg … just a little different error when trying to get the snapshot :slight_smile:

2020-09-20 22:23:28.010 [DEBUG] [era.internal.handler.IpCameraHandler] - Binding has no snapshot url. Will use your CPU and FFmpeg to create snapshots from the cameras RTSP.
2020-09-20 22:23:28.030 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-rtsp_transport tcp -threads 1 -skip_frame nokey -hide_banner -loglevel warning -i rtsp://admin:*****@ -an -vsync vfr -update 1
2020-09-20 22:24:03.629 [DEBUG] [pcamera.internal.StreamServerHandler] - Stream Server recieved request 	GET:/snapshots.jpg
2020-09-20 22:24:03.650 [INFO ] [pcamera.internal.StreamServerHandler] - IpCameras file server could not find the requested file. This may happen if ffmpeg is still creating the file.

If I enter completely wrong password in the .things, then I can see:
Camera is not reachable on ONVIF port:80 or the port may be wrong.
Not sure if it proves it is not a password issue or does not prove anything:)

Last, but not least, it again made openhab slow and karaf irresponsive … didn’t await till memory exception, just commented out things and restarted openhab and all was back normal.

OK I have found some issues in your logs when you were trying to create the snapshots with ffmpeg…

  1. You were asking for snapshots.jpg when you need to ask for /snapshots.mjpeg or ipcamera.jpg

  2. You appear to have deleted the FFmpeg Install Location, it should be /usr/bin/ffmpeg under Linux in most cases… This log looks wrong hence why I suspect this to be the issue…

Starting ffmpeg with this command now:-rtsp_transport tcp -threads 1

  1. As for the original issue, I think it is best I create a custom build for you that has more logging in it to diagnose the issue. I put the wrong password on my camera that has digest and I could not reproduce this but if the camera did not follow the digest standard 100% I can see this being the result. Actually it is pretty simple to check this with curl…

Can you post the output of what happens when you use the wrong password with this?

 curl -v http://admin:wrong@

easiest things first :slight_smile:

[19:08:51] openhabian@openHABianPi:~$ curl -v http://admin:wrong@
*   Trying
* Connected to ( port 85 (#0)
* Server auth using Basic with user 'admin'
> GET /images/snapshot.jpg HTTP/1.1
> Host:
> Authorization: Basic YWRtaW46d3Jvbmc=
> User-Agent: curl/7.52.1
> Accept: */*
< HTTP/1.1 401 UnAuthorized
< Content-Length: 222
< Content-Type: text/plain
< Connection: close
< WWW-Authenticate: Digest realm="48ea63fc82ff", nonce="19a0ff09f63a111182d0e56334140142", stale="false", algorithm="MD5", qop="auth"
< X-Frame-Options: SAMEORIGIN
"Response": {
       "ResponseURL": "/images/snapshot.jpg",
       "ResponseCode": 3,
       "SubResponseCode": 0,
       "ResponseString": "Not Authorized",
       "StatusCode": 401,
       "StatusString": "Unauthorized",
       "Data": "null"
* Curl_http_done: called premature == 0
* Closing connection 0

And exactly same also with the correct password.

With wget though there are two requests in row.
with wrong password

--2020-09-21 19:13:12--  http://admin:*password*@
Connecting to connected.
HTTP request sent, awaiting response... 401 UnAuthorized
Authentication selected: Digest realm="48ea63fc82ff", nonce="4b53f91d22e76b74bbb316cfa679ef9f", stale="false", algorithm="MD5", qop="auth"
Connecting to connected.
HTTP request sent, awaiting response... 401 UnAuthorized
Username/Password Authentication Failed.

and with the correct one

--2020-09-21 19:12:40--  http://admin:*password*@
Connecting to connected.
HTTP request sent, awaiting response... 401 UnAuthorized
Authentication selected: Digest realm="48ea63fc82ff", nonce="7f7512335a79d308089cfc39f162d62c", stale="false", algorithm="MD5", qop="auth"
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 241368 (236K) [image/jpeg]
Saving to: ‘snapshot.jpg.7’

Another thought I had - could some timeouts cause it? I am seeing 1-2seconds (on rare cases even 5) to download the snapshot with wget - maybe it’s taking too long?
root cause for longer than expected responses (I think) is point to point wifi to camera location and few obstacles in line of sight. Plan is to fix it on long run, but for time beeing have to live w it:(

  • sooo, here is trace log with these in .things
    ipcamera_20200921_ffmpeg.log (881.4 KB)
    and /snapshots.mjpeg and /ipcamera.jpg is actually showing something (I got a feeling mjpeg is a single image, but it’s already more than nothing :))

  • and here is tracelog with
    ipcamera_20200921_snapshot.log (337.0 KB)
    and both - snapshots and ipcamera - not showing any image

apologies for being very verbal/text-rich tonight:)
upgraded to latest binding.
cleared cache, restarted.
Also was poking around camera config menus and found authentication type … changed rtsp to basic and http to none (was either digest or none) and /ipcamera.jpg and /snapshots.mjpeg are working!!!
wow … trace log attached
ipcamera_200921_basic.log (196.5 KB)

I suspect your camera may only recognise headers that start with a capital. Netty uses lowercase by default which is correct but it is common for devices to not recognise lowercase. I think it is worth making a build with this change in it for you to try but it may take a day for me to get the time to do it.

Good news that basic is working as that gets you working in the meantime.

I am happy to try it when u have it ready. No rush :slight_smile:
I guess, it is http=none which made it working (no ‘basic’ option on http).
somehow not been able to get the gif(s) yet, but will re-read github and examples to see if I’m not missing smtg.
Thank You so much for your time and support!