IpCamera: New IP Camera Binding

Clean and cache and temp folders and reboot, search this forum for how. The event stream is not staying open so no alarms will work until that is sorted and it may be you did not clean the cache when changing binding versions.
401 errors are normal for digest auth it is how it works just ignore.

Thanks for the reminder, I should have cleaned the cache already. After running “sudo openhab-cli clean-cache” the log is no longer full of 401 errors:

24-Jun-2019 15:53:19.860 [DEBUG] [org.openhab.binding.ipcamera                      ] - BundleEvent STARTED - org.openhab.binding.ipcamera
24-Jun-2019 15:53:19.896 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - initialize() called.
24-Jun-2019 15:53:20.896 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - About to connect to the IP Camera using the ONVIF PORT at IP:192.168.0.68:80
24-Jun-2019 15:53:21.382 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Fetching the number of Media Profiles this camera supports.
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Checking the selected Media Profile is a valid number.
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Fetching a Token for the selected Media Profile.
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - About to fetch some information about the Media Profiles from the camera
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - *********** Media Profile 0 details reported by camera at IP:192.168.0.68 ***********
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Camera will use this Media Profile unless you change it in the bindings settings.
24-Jun-2019 15:53:21.855 [INFO ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - This can be used to stream HLS with low CPU overhead
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 is named:VideoEncoder_1
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video encoder      :H_264
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video quality      :5.0
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video resoltion    :3840 x 2160
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video bitrate      :10240
24-Jun-2019 15:53:21.856 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - *********** Media Profile 1 details reported by camera at IP:192.168.0.68 ***********
24-Jun-2019 15:53:21.856 [INFO ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - This can be used to stream HLS with low CPU overhead
24-Jun-2019 15:53:21.856 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 is named:VideoEncoder_2
24-Jun-2019 15:53:21.856 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video encoder      :H_264
24-Jun-2019 15:53:21.858 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video quality      :3.0
24-Jun-2019 15:53:21.858 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video resoltion    :640 x 480
24-Jun-2019 15:53:21.858 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video bitrate      :768
24-Jun-2019 15:53:21.858 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - About to interrogate the camera to see if it supports PTZ.
24-Jun-2019 15:53:22.563 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Camera is reporting that it does NOT support Absolute PTZ controls via ONVIF
24-Jun-2019 15:53:22.564 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Finished with PTZ with no errors, now fetching the Video URL for RTSP from the camera.
24-Jun-2019 15:53:23.625 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:23.634 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have  opened  a  brand NEW channel:0    GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:23.636 [INFO ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - IP Camera at 192.168.0.68:80 is now online.
24-Jun-2019 15:53:23.642 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - 401: Mark to re-use,  the channel:0     GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:23.642 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - Setting up the camera to use Basic Auth and resending last request with correct auth.
24-Jun-2019 15:53:23.642 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Setting up the BASIC auth now, this should only happen once.
24-Jun-2019 15:53:23.642 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:23.642 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:0     GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:23.920 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.
24-Jun-2019 15:53:23.930 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0    URL:/Streaming/channels/101/picture
24-Jun-2019 15:53:30.635 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:30.649 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:0    GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:30.649 [WARN ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - The alarm checking stream was not running. Cleaning channels and then going to re-start it now.
24-Jun-2019 15:53:30.649 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/Event/notification/alertStream
24-Jun-2019 15:53:30.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have  opened  a  brand NEW channel:1    GET:/ISAPI/Event/notification/alertStream
24-Jun-2019 15:53:30.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:30.656 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have  opened  a  brand NEW channel:2    GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:30.945 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.
24-Jun-2019 15:53:30.946 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0    URL:/Streaming/channels/101/picture
24-Jun-2019 15:53:35.635 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:35.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:0    GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:35.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:35.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:2     GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:35.951 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.
24-Jun-2019 15:53:35.953 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0    URL:/Streaming/channels/101/picture
24-Jun-2019 15:53:40.634 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:40.636 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:0    GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:40.636 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:40.636 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:2     GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:40.942 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.
24-Jun-2019 15:53:40.943 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0    URL:/Streaming/channels/101/picture

It still doesn’t appear to be receiving intrusion alarms from the camera though. I’ll check the config on the camera again in case the firmware update broke it.

New Raspberry Pi 4 released with a much stronger CPU and a 4GB RAM option!
I assume this would be awesome for this binding, right @matt1?

Awesome is too strong of a word as we have had clones that could do this for years already and it is still only a fraction of the CPU power of x86 based systems which are getting very efficient. Yes it is a lot better compared to previous Pis and all the concerns I have over older Pis are solved with the Pi4. I have a clone which is probably similar to the Pi4 and I average 33% cpu load so at some stage I will need to upgrade to something even bigger…

The next step up would be something like this which could double as a NAS/media server with Openhab in a docker container (see open media vault project):

https://www.hardkernel.com/shop/odroid-h2/

4 watts power draw at idle and the cost is about twice the Pi4 for probably twice the CPU power and more IO options.

The Intel Nuc J5005 which is a similar CPU to the above Odroid, with a bigger graphics card added in. So the H2 has better IO options and lower cost than the Nuc of similar specs.

Of course the Pi4 is a lot easier and cheaper to swap out if the hardware fails which is why I am in no hurry to change until I actually need the bigger CPU as prices only fall and newer hardware gets released.

I checked the code and it all seems fine, I suspect you will need to tick the notify Alarm/surveillance center or something similar for it to work.

As mentioned the 401 is normal when using DIGEST and now your camera is using BASIC instead which is why they stopped.

To fault find you should open this url in a broswer and see if the alarm reaches the stream or not…

cameraIP/ISAPI/Event/notification/alertStream

Try it in a few different browsers if you do not see text or use curl.

You were right, it was the “Notify Surveillance Centre” option that had become unticked. The camera I’m working on at the moment is a Hikvision DS-2CD2085FWD-I and upgrading it to V5.6.0 build 190507 seems to have reset a few configuration parameters. I’ve upgraded the firmware on it several times before and not had this issue.

I’ve also configured my rules to use Pushover instead of Telegram and this allows me to see the animated GIFs. It does look like only a single frame of an animated GIF is supported by Telegram, either in the binding or on the mobile/desktop client.

In case this helps anyone else my camera intrusion detection rule currently looks like this:

rule "Create front door camera GIF when front door camera intrusion detected"
when
    Item CameraFrontDoor_IntrusionAlarm changed from OFF to ON
then
    logInfo("Dev", "Front door camera intrusion detected, triggering camera GIF creation...")
    
    sendPushoverMessage(pushoverBuilder("Front door intrusion alarm triggered..."))

    CameraFrontDoor_CreateAnAnimatedGIF.sendCommand(ON)
end

rule "Send front door camera GIF via Telegram"
when
    Item CameraFrontDoor_CreateAnAnimatedGIF changed from ON to OFF
then
    
    sendPushoverMessage(pushoverBuilder("Sending GIF from front door").withAttachment("/etc/openhab2/html/tmpfs/ipcamera.gif"))
end

Thanks for all your help :slight_smile:

New build 2019-06-26 has these changes:

  • Minor bug fixes
  • New ability for all brands to now turn off updating the IMAGE channel so you can instead use the new url to fetch the ipcamera.jpg
    I have been noticing a jump in CPU usage when I add extra cameras which does not make sense. This jump stems from the Openhab backend and how it handles the image, so if you turn this off you gain more CPU back as you add in extra cameras. It should also stop the event.log getting spammed if you are not filtering out the image event updating.
  • Brands which use event streams now have a different way to handle idle channels and it will create a warning when the stream is not staying open.

Because the binding has a new CONFIG parameter, it is necessary to delete and re-add your cameras if you are not using textual config. If you setup the cameras with a things file (well done) this happens magically when you reboot making your life easier.
Everyone should clean the cache and tmp folders as with every change to the addons folder.

@higgers
Thanks for sharing your rules I’m sure people will find them useful and it shows how much simpler it is instead of using thread:sleep to wait for files to be created. Just one tip, that is controls are set to UNDEF when Openhab reboots, so I would change your rule to be the following otherwise it may not work on the first alarm after a reboot.

CameraFrontDoor_IntrusionAlarm changed to ON

I would leave the second rule as is because I will at some stage make any errors in creating the GIF set the control to UNDEF to stop rules like that from triggering if an error occurs.

1 Like

@matt1 can you give some info about the new IMAGE channel update feature? How to turn off? Also i have rebooted, using things files only, but i don’t see any changes or new CONFIG parameter…

Did you clean and cache and tmp folders and then reboot? This is a must otherwise the older version is in the cache and explains why u see nothing.
It is a new switch that can be made false by adding this to things file.

UPDATE_IMAGE=false

Drops cpu usage by more than half so it is a big change.

Yesy i cleared cache etc. the jar file is from 26-06-2019:11:27 so it is the latest one… Don’t know why but after adding the UPDATE_IMAGE=false to each camera it stops updating the image channel, so it’s the new release already. But the updateImageNow channel doesn’t work anymore; shouldn’t this update the image channel?

Hi@matt1,
why do I get IPs in streamUrl items as http://0.0.0.0:54320/ipcamera.mjpeg ?

I also discovered that there is wrong translation of passowrds with special characters like i.e. “!” (exclamation mark). It is being translated to “%21%21”

I also tried to get PTZ working with my FOSCAM cameras without success so far :frowning: I guess the above issue may be part of the problem.
Things are configured like:

Thing ipcamera:FOSCAM:camerakitchen [
IPADDRESS="192.168.1.111", PORT=9988, PASSWORD="FakedPass!!", USERNAME="openuser", POLL_CAMERA_MS=60000, SERVER_PORT=54321, ONVIF_PORT=8888,
FFMPEG_INPUT="rtsp://192.168.1.111:9988/videoMain",
FFMPEG_OUTPUT="/tmp/camera1/",
IP_WHITELIST="(192.168.1.50)(192.168.1.80)(192.168.1.81)(192.168.1.82)(192.168.1.83)(192.168.1.104)"
]

This shows that the binding could not find a network connection to use that was considered ‘site local’ or something went wrong when checking this condition. The 0.0.0.0 means it may still work if you just use the url with the IP of your openhab server as the binding has connected to all available network connections. Did you get a warning or error in the logs?

So a single ! gets converted to double %21 ? if so then that is an issue to look at as it should convert to a single %21 What platform are you running Openhab on, is it mac?

It may be related to the PTZ issue but I doubt it. PTZ is handled by an onvif library which I did not write and has not been updated in many years, there are a few newer java libraries being written but they do not support PTZ yet. You can get a lot more info as to what is wrong if you turn on debug or trace level logs when the camera is first connecting. Without the log I cant comment on what is wrong.

Maybe I need to change things so feel free to give feedback but currently that is how it will operate. If you turn off the image it will not update and the update image now channel will only start and stop the fetching of the snapshot from the camera every poll period.
The binding defaults to always fetching a snapshot and that channel will do nothing unless you play with the image update events option. There are now three controls which effect snapshot or image channel.

Unfortunately the name of the controls is set unless I make a breaking change to rename them which I am not keen on.

Does the new option mean it’s possible to turn on image updating for a period of time when the intrusion switch (or another switch) is turned on?

No that is not currently possible unless you also stop the snapshots from being fetched.

I wish openhab had a three way switch. NONE, snapshot only, snapshot and image being the three states. But it currently does not hence why I’m trying to find an easy to understand way that works for all people…

New Update image config stops all image updates and no way to turn them back on.
Existing updateImageNow channel will start and stop the snapshot fetching into ram from the camera, and if the update Image config is on it starts and stops the image then, however when the channel is off you also loose snapshots which halt two features from working…

  1. preroll for gif creation
  2. URL snapshot which I only just added.

One way I could change it is to repurpose the new config to select what the updateimagenow channel starts up on when Openhab is restarted. Then turn the updateimagenow control to start and stop the image and leave the snapshot getting fetched the entire time. If you edit the choices in the Update-snapshot/Image when config drop down list you can then turn off the snapshot fetching via this control.

If you have an idea let me know as I am happy to change it whilst the feature is new and not many people have installed the newer version of the binding.

No sorry, it’s my mistake, there should be !! that is %21%21. Why this is translated this way? Is this a result of conversion of url address string to URI compliant form?

What do you mean by “site local” ? I will review TRACE log for this.

@zacofunny
New build 2019-06-28 now uploaded to fix a bug in the ONVIF connection if you used special characters in the user or pass. Only effected Foscam users.

Correct you can not have a space or certain characters in a URL and if you enter them in a browser it will do the conversion for you before sending to the camera. If the binding gets a snapshot it will be working, if it is not working then please let me know but that so far looks normal and is not a bug unless it fails to work.

Site local is a network that can not be reached from the web without port forwarding. Ie 192.168.0.xxx range is site local which it appears your using that for your network so it is interesting that this occurred which is why I asked if you were using Mac or what platform openhab is running on?

Can somebody help me i configed my (chinese) Onvif PTZ Camera.

PTZ is working with Onvif Device manager.

My ipcamera.things

Thing ipcamera:ONVIF:001 [ IPADDRESS=“192.168.178.34”, PASSWORD=“12345”, USERNAME=“admin”, ONVIF_PORT=80, PORT=80, SERVER_PORT=50001, POLL_CAMERA_MS=2000, FFMPEG_INPUT=“rtsp://admin:admin@192.168.178.34:554”, FFMPEG_OUTPUT="/tmp/camera1/"]`

But i get this info in the logs

2019-06-29 23:28:45.188 [WARN ] [ing.ipcamera.handler.IpCameraHandler] - Following NPE occured when trying to connect to the camera with ONVIF.java.lang.NullPointerException
2019-06-29 23:28:45.191 [ERROR] [ing.ipcamera.handler.IpCameraHandler] - Since an NPE occured when asking the camera about PTZ, the PTZ controls will not work. If the camera does not come online, give the camera the wrong ONVIF port number so it can bypass using ONVIF and still come online.
2019-06-29 23:28:45.207 [INFO ] [ing.ipcamera.handler.IpCameraHandler] - IP Camera at 192.168.178.34:80 is now online.
2019-06-29 23:28:45.293 [INFO ] [ing.ipcamera.handler.IpCameraHandler] - IpCamera file server for camera 192.168.178.34 has started on port 50001

What can I do to get the PTZ working? That would be the most important thing for me. Thanks in advance

In your addons folder is a file called javax.xml.soap-api-1.3.7.jar Try changing this file to an older version which you can download them from here…

https://mvnrepository.com/artifact/javax.xml.soap/javax.xml.soap-api

You will need to make sure only 1 version is in the folder at a time and after changing the contents of the addons folder you will need to clean the cache and tmp folders and reboot.

I have only ever seen this once with my cameras and it was caused by using 1.4.0 version of that file.

Also posting the output from your logs in TRACE mode that shows a single camera connecting would also be helpful to look into it. The readme has info on log modes.

Tried I but unluckyly no success

This is my trace log:

13:52:21.743 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Fetching the number of Media Profiles this camera supports.
13:52:24.812 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Checking the selected Media Profile is a valid number.
13:52:24.816 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Fetching a Token for the selected Media Profile.
13:52:24.820 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Auto fetching the snapshot URL for the selected Media Profile.
13:52:27.963 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - About to fetch some information about the Media Profiles from the camera
13:52:27.967 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - *********** Media Profile 0 details reported by camera at IP:192.168.178.34 ***********
13:52:27.970 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Camera will use this Media Profile unless you change it in the bindings settings.
13:52:27.973 [INFO ] [ding.ipcamera.handler.IpCameraHandler] - This can be used to stream HLS with low CPU overhead
13:52:27.976 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 0 is named:VideoEncoder_1
13:52:27.980 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video encoder       :H_264
13:52:27.983 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video quality       :10.0
13:52:27.987 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video resoltion     :1920 x 1080
13:52:27.990 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video bitrate       :0
13:52:27.993 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - *********** Media Profile 1 details reported by camera at IP:192.168.178.34 ***********
13:52:27.997 [INFO ] [ding.ipcamera.handler.IpCameraHandler] - This can be used to stream HLS with low CPU overhead
13:52:28.000 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 1 is named:VideoEncoder_2
13:52:28.003 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video encoder       :H_264
13:52:28.006 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video quality       :10.0
13:52:28.009 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video resoltion     :640 x 360
13:52:28.012 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video bitrate       :0
13:52:28.015 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - About to interrogate the camera to see if it supports PTZ.
13:52:33.715 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Camera is reporting that it supports PTZ control with Absolute movement via ONVIF
13:52:33.719 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Checking Pan now.
13:52:39.172 [WARN ] [ding.ipcamera.handler.IpCameraHandler] - Following NPE occured when trying to connect to the camera with ONVIF.java.lang.NullPointerException
13:52:39.176 [ERROR] [ding.ipcamera.handler.IpCameraHandler] - Since an NPE occured when asking the camera about PTZ, the PTZ controls will not work. If the camera does not come online, give the camera the wrong ONVIF port number so it can bypass using ONVIF and still come online.
13:52:39.180 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.178.34:80/onvif/snapshot
13:52:39.197 [TRACE] [.ipcamera.internal.MyNettyAuthHandler] - MyNettyAuthHandler is now setup for      GET:/onvif/snapshot
13:52:39.200 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - Have  opened  a  brand NEW channel:0     GET:/onvif/snapshot
13:52:39.206 [INFO ] [ding.ipcamera.handler.IpCameraHandler] - IP Camera at 192.168.178.34:80 is now online.
13:52:39.212 [DEBUG] [ding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0     URL:/onvif/snapshot
13:52:39.221 [INFO ] [ding.ipcamera.handler.IpCameraHandler] - IpCamera file server for camera 192.168.178.34 has started on port 50001


 14:27:02.099 [hingStatusInfoChangedEvent] - 'ipcamera:ONVIF:001' changed from INITIALIZING to OFFLINE (CONFIGURATION_ERROR): Camera failed to report a valid Snaphot URL, try over-riding the Snapshot URL auto detection by entering a known URL.