IPCamera: Blank ImageUrl

That error is probably not from this binding, but you should not ignore it, search forum with parts of the error to find how others have solved it.

How are you trying to use imageUrl? Have you read the documentation for the binding on how to see a snapshot and stream?

I had to give the user “operator” privileges instead of just “User”. That cleared up the warning, but still no image…, also, I am not using the stream and have it set to MPEG4. Will that cause problems?

Also fixed the other error, turns out it was from a bad rule.

Did you read the documentation that covers how to get a stream or snapshot? If so what is confusing in the docs?

IP Camera - Bindings | openHAB

@matt1 Yes sir, I did read the docs and configured accordingly as in my original post. But still no image. Did I forget something? Also, just curious, I did not want to enable motion alarm, can the capabilities not be used independently?

Username and password are set correctly and verified through the browser, but I am seeing this in the logs:

2021-01-01 15:25:45.811 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2021-01-01 15:25:45.905 [TRACE] [g.ipcamera.internal.HikvisionHandler] - HTTP Result back from camera is

Document Error: Unauthorized

Access Error: 401 -- Unauthorized

Authentication Error

2021-01-01 15:25:45.907 [DEBUG] [g.ipcamera.internal.HikvisionHandler] - Unhandled reply->>>>

Document Error: Unauthorized

Access Error: 401 -- Unauthorized

Authentication Error

2021-01-01 15:25:45.934 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2021-01-01 15:25:46.082 [TRACE] [g.ipcamera.internal.HikvisionHandler] - HTTP Result back from camera is :–boundary
Content-Type: application/xml; charset=“UTF-8”
Content-Length: 479


That is normal if the camera is using the DIGEST method for handling user/pass. Ignore it if the binding is working, as it is how digest works. If it does not work then this may be a clue, but I can not tell from a short snippet of the log without knowing more info. HIK cameras allow you to select BASIC auth and this wont happen and uses less bandwidth at a reduced security tradeoff.

The binding can create ‘snapshots.mjpeg’ streams for you even if your camera is not capable of mjpeg. It does this by using the snapshots so read the docs to learn more.

The older HIK cameras prefer the non ISAPI urls and some of the newer ones only work with the ISAPI version. If you click on ‘show advanced’ see your very first picture you posted, you can then change the URL used for the snapshot. The HIK camera also come with the CGI/API turned off by default, have you turned in on in the cameras own setup?

I don’t understand why you are asking this? you do not need to use motion detection at all with the binding and most features work without it. The features that are ‘complimented’ by having it are the autofps.mjpeg stream and also when you use the ‘group’ of cameras to display as a single view as the rotating display of cameras will jump to any that have motion.

Looks (from the trace logs) that the binding is talking to the cameras and getting back capabilities as well as subscribing to events. Seems like the imageUrl snapshot is the only thing not working. What can I provide to help diagnose. I’m trying to see the image in the Items view of Openhab3 after creating an Image item from the thing. The binding reports the camera is online.

Sorry to be a pain, your help is appreciated!!

See my previous reply, if u have a working snapshot URL you can over ride what the binding is trying to use.

The documentation tells you not to do this and to use another method. Try using this widget instead.

As mentioned the 401 replies back from the camera can be normal if the camera is using digest auth so it may be that the default URL is fine and does not need over riding.

I couldn’t find this. I see it says there are several ways to use the imageUrl.

I also tried http://…/ipcamera.jpg using the openhab server IP and unique server port for that camera. Still no image.

The only way I get this to show an image is using the camera snapshot url directly. None of the binding methods give an image.

I’ve tried overriding by providing the snapshot url directly, still no luck.

Also, should I reboot openhab every time I make a config change or will it adapt in real time?


You don’t need to reboot openhab but try rebooting the camera as if you got the password wrong it can lock you out and a reboot resets any lockouts.
It might be best to reboot both and keep the trace log for when the camera connects. The imageURL is only a string of text that tells you the URL to use based on the IP of openhab and the serverPort.

Another cause may be openHAB is setup to use a non connected network card. Go to the settings of openhab and select network settings.

OK, updated and rebooted everything and have some trace logs. From what I can see, everything seems to be ok. Here are some excerpts:

2021-01-02 14:37:45.705 [DEBUG] [era.internal.handler.IpCameraHandler] - File server for camera at has started on port 8000 for all NIC's.
2021-01-02 14:37:45.715 [WARN ] [nhab.core.internal.items.ItemUpdater] - InstantiationException on org.openhab.core.library.types.RawType
2021-01-02 14:37:45.728 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request:GetSystemDateAndTime
2021-01-02 14:37:46.449 [TRACE] [amera.internal.onvif.OnvifConnection] - Onvif reply is:<?xml version="1.0" encoding="UTF-8"?>
...xml response removed
2021-01-02 14:37:46.452 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request:GetCapabilities
2021-01-02 14:37:46.462 [DEBUG] [amera.internal.onvif.OnvifConnection] - Cameras  UTC dateTime is:2021-1-2T22:47:45
2021-01-02 14:37:46.465 [DEBUG] [amera.internal.onvif.OnvifConnection] - Openhabs UTC dateTime is:2021-01-02T22:37:46.465Z
2021-01-02 14:37:46.553 [TRACE] [amera.internal.onvif.OnvifConnection] - Onvif reply is:<?xml version="1.0" encoding="UTF-8"?>
...xml response removed
2021-01-02 14:37:46.557 [DEBUG] [amera.internal.onvif.OnvifConnection] - deviceXAddr:/onvif/device_service
2021-01-02 14:37:46.558 [DEBUG] [amera.internal.onvif.OnvifConnection] - eventsXAddr:/onvif/Events
2021-01-02 14:37:46.560 [DEBUG] [amera.internal.onvif.OnvifConnection] - mediaXAddr:/onvif/Media
2021-01-02 14:37:46.562 [DEBUG] [amera.internal.onvif.OnvifConnection] - We hit an issue parsing url:
2021-01-02 14:37:46.564 [TRACE] [amera.internal.onvif.OnvifConnection] - Camera must not support PTZ, it failed to give a <tt:PTZ><tt:XAddr>:<?xml version="1.0" encoding="UTF-8"?>
2021-01-02 14:37:46.566 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request:GetProfiles
2021-01-02 14:37:46.664 [TRACE] [amera.internal.onvif.OnvifConnection] - Onvif reply is:<?xml version="1.0" encoding="UTF-8"?>
2021-01-02 14:37:46.669 [TRACE] [amera.internal.onvif.OnvifConnection] - String was found:Profile_1
2021-01-02 14:37:46.671 [TRACE] [amera.internal.onvif.OnvifConnection] - String was found:Profile_2
2021-01-02 14:37:46.674 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request:GetSnapshotUri
2021-01-02 14:37:46.689 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request:GetStreamUri
2021-01-02 14:37:46.754 [TRACE] [amera.internal.onvif.OnvifConnection] - Onvif reply is:<?xml version="1.0" encoding="UTF-8"?>
2021-01-02 14:37:46.758 [DEBUG] [amera.internal.onvif.OnvifConnection] - GetSnapshotUri:/onvif-http/snapshot?Profile_1
2021-01-02 14:37:46.781 [TRACE] [amera.internal.onvif.OnvifConnection] - Onvif reply is:<?xml version="1.0" encoding="UTF-8"?>
2021-01-02 14:37:46.784 [DEBUG] [amera.internal.onvif.OnvifConnection] - GetStreamUri:rtsp://;profile=Profile_1
2021-01-02 14:37:49.919 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2021-01-02 14:37:49.952 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Setting up the camera to use Basic Auth and resending last request with correct auth.
2021-01-02 14:37:50.000 [TRACE] [g.ipcamera.internal.HikvisionHandler] - HTTP Result back from camera is     
<!DOCTYPE html>
<html><head><title>Document Error: Unauthorized</title></head>
<body><h2>Access Error: 401 -- Unauthorized</h2>
<p>Authentication Error</p>
2021-01-02 14:37:50.003 [DEBUG] [g.ipcamera.internal.HikvisionHandler] - Unhandled reply- 
<!DOCTYPE html>
<html><head><title>Document Error: Unauthorized</title></head>
<body><h2>Access Error: 401 -- Unauthorized</h2>
<p>Authentication Error</p>
2021-01-02 14:37:50.023 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2021-01-02 14:37:50.919 [INFO ] [era.internal.handler.IpCameraHandler] - The alarm stream was not running for camera, re-starting it now
2021-01-02 14:37:50.928 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2021-01-02 14:37:50.959 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2021-01-02 14:37:52.254 [TRACE] [g.ipcamera.internal.HikvisionHandler] - HTTP Result back from camera is 	:--boundary
Content-Type: application/xml; charset="UTF-8"
Content-Length: 479

The binding looks to be getting a response from Get of imageURL. I’m out of ideas of what to change… Do you need more info from the trace logs?

The next thing to try is seeing if the binding reports that your requesting the jpg when you open this URL in any web browser.


The binding should report that it got a request for this, plus you should see the cameras picture in any web broswer, is that what happens? If no then what happens exactly? If no log then try changing from 8000 to a different port in case that one is already in use. No need to reboot when changing that.

Your camera is using BASIC auth now and that Document Error is normal since it only happens once. Everything does look to be working fine.

Yes!!! Got an image using the url


Awesome! Thanks, I will now try to get it to update in the widget every second or by motion detect!

So what was wrong so we can learn from this and update documentation or…?

If you want every second then use snapshots.mjpeg instead of the ipcamera.jpg

I’m wondering if it was the camera reboot… Otherwise all the settings are the same (therefore user error)

I’ll give snapshots.mjpeg a try From the docs I’m expecting that the mjpeg stream is constructed from the snapshots instead of the streamUrl.

That is correct for autofps.mjpeg and snapshots.mjpeg and this means next to no CPU load.

Discovery…one of the cameras was being stubborn and I just could not get that camera to work using imageUrl. After a lot of checking it turns out that it was running a very old version of firmware. Updated the firmware from v5.2.x to v5.4.5 and image url works.

Hi there,
I do have the same issue - probably.
The imageUrl channel


shows no image (or kind of broken image, just a tiny grey dot is shown):

At least approx. 99 of 100 trials. Sometime I do get the image, but when refreshing the browser there is no picture again. My intention is to send the “current” picture by mail when e.g. motion is detected. But unfortunately I do get only the grey dot as attachement and an error when trying to open the file whithin the mail.

@matt1 you mentioned…

… I also find the ‘Server port’ in several tutorials, but I do not find this to setup in my Thing’s config? Did I something miss out? Or has this been changed, I am on OH 3.3.0.M1 Milestone?

I already checked the readme - which is by the way great since it is detailed described - the second option for a snapshot


in combination with gifPreroll > 0 is also not properly working for me since it seems every 2nd file which is created is empty also. Sometimes snapshot0 is affected and sometime snapshot1 is the first one… That leads to Mails with correct picture attachment, and also sometime to broken image (same as when using ipcamera.jpg / imageUrl). I tried gifPreroll = 1, 15 pictures are then created.

Anyway, using imageUrl would be my favorite approach. Am I doing something wrong as mjpegUrl is working properly?

Edit: I forgot the logs (TRACE)…

2022-02-18 14:53:49.214 [DEBUG] [amera.internal.servlet.CameraServlet] - GET:/ipcamera.jpg, received from
2022-02-18 14:53:49.268 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2022-02-18 14:53:49.277 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is 	:<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <title>401 Unauthorized</title>
  <h1>401 Unauthorized</h1>
2022-02-18 14:53:49.280 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2022-02-18 14:53:49.379 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP: gave a reply with a response code of :500
2022-02-18 14:53:49.380 [DEBUG] [era.internal.handler.IpCameraHandler] - Camera has no Content-Length header, we have to guess how much RAM.
2022-02-18 14:53:59.464 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is 	:--ioboundary
Content-Type: text/plain


Content-Type: text/plain



The cameras are: Doorbird D1101 and D101. Both show the same issue for imageURL. MJPEG URL is working properly.

First please create your own new thread and not post in someone elses that is 1 year+ old…
The gray dot means the camera is offline or can not get a real snapshot so it is keeping the stream alive with a gray dot until the camera fault is fixed.

Create a new thread with TRACE level logs when the camera connects for the first time. Press the PAUSE button on the thing, then un-pause it to trigger this to occur.

The only other thing worth mentioning is that if you have the camera open in another software or app, some cameras from Doorbird brand only allow a single connection at a time. It may even be this binding trying to connect multiple times for the stream and the snapshot that is tripping the camera up. There is a dedicated Doorbird binding you should check out.

honestly my opinion is that post in a thread with exactly the same topic should be prefered as creating a new topic, since it makes it easier for someone in future to find the solution within one thread compared to several ones. But you are right, the guidline mentions that a new thread should be created. Sorry for that!

Let’s discuss in the new thread created by myself, see here.

1 Like