Latest revision as of 11:44, 10 August 2012

Introduction

The Advanced IP Camera is a generic device template which aims to utilize more features of modern IP cameras than GSD templates can.

Currently working:

• Image retrieval
• Motion detection events [1]
• Generic Sensor inputs on camera [1]
• Generic Output on camera [1]
• Zoom and Pan (not tested)

[1] Using the "url", "urlPoll" or "httpserver" method, see below for details.

This device template is not meant to be used directly, even though it can. The idea is that this template describes the available options that the Advanced_IP_Camera binary supports, and a device template for a specific make and model should specify the correct options for that device. See the D-Link DCS-2121 or IPCAM02 template as example of how to create a template for a specific camera model.

Creating a device template based on Advanced IP Camera

Create a new device template, check "Implements DCE", enter "Advanced_IP_Camera" as Command Line. Add "Core" as controlled by category, and add a dependency on the "LinuxMCE Advanced IP Camera" software package.

This should make a template that uses the Advanced_IP_Camera binary, and is started automatically on the core.

You now need to enter the specific data for your device. I hope you have already set the manufacturer and model number when creating the template... A DHCP MAC range needs to be added if you want your device to be automatically detected.

Device data for the template

The device data describe options that might be special for your device. You need to add the device datas you need to customize for your device template. Look at the Advanced IP Camera template to see what data is available. Some data are required, like Path.

Other data are optional and depends on what features your camera has. Options:

• AuthUser: Username to authenticate to the camera
• AuthPassword: Password to authenticate to the camera
• Video support: Check if this camera supports video
• Video Settings: URL where video can be retrieved from the camera
• Control path: URL to control the camera
• Configuration: specify what method to use to access the cameras events (motion detection, input changes etc.)

The available options are (this is an example)

eventMethod1=[url,urlPoll,httpserver,ftpserver,smtpserver] (only url,urlPoll and httpserver currently implemented)
eventURL1=[/cgi/web_event.cgi|localhost:25|8080]
eventInterval1=10
controlURL=/cgi-bin/camctrl.cgi?
panUpCmd=move=up
panDownCmd=move=down
- similar for left and right
zoomInCmd=zoom=in
- same for out

If you have several different methods, use eventMethod2, eventURL2 etc...

The panUpCmd, zoomInCmd and similar are appended to the controlURL. The controlURL is not required, and thus it is possible to use a completely different url to control pan and zoom.

All URLs are relative to the root of the device. So the example above will for a pan up, result in a request to http://x.x.x.x/cgi-bin/camctrl.cgi?move=up and includes the authentication (username and password) specified, if any.

Methods

Methods are different ways that the camera provides access to event and control data. There are a few types:

• url : control/data by means of accessing an url on the camera. This type should be used when the camera supports keeping the connection open and sending more data as it becomes available.
• urlPoll : control/data by access an url on the camera, and this needs to polled regulary (specify using eventInterval1=<seconds>), because the camera will close the connection after it has sent its data
• httpserver : camera will send data to a specified http server port
• ftpserver : camera will send data to a specified ftp server port (not implemented yet and unsure about its usefulness)
• smtpserver : camera will send data to a specified smtp server port (not implemented yet and unsure about its usefulness)

All these are valid for data/events, but only url is used for control.

Commands and events

You should select the commands and events that your device is capable of handling. They are not used in any way in the Advanced_IP_Camera binary at the moment, but that might change. Setting these are just the right thing to do.

Related device templates

This allows you to specify any children that should be created anutomatically, if any. For instance, if your camera supports motion detection, a motion detector device should be a children of your camera device. Sometimes cameras also have general input and outputs that can be read and controlled. This requires a generic input and output device to be added under your camera device.

Device data for children

Device data for children can be specified as a list of <PK_DeviceData>|<DataValue>|<PK_DeviceData>|<DataValue>|...etc. Line breaks in the examples below can be replaced by : when entering the "extra" related device data field.

The device templates currently working with the Advanced IP Camera is Motion Detector, Generic Sensor and Generic Input Output.

See the D-Link DCS-2121 or IPCAM02 template for an example.

You need to use only : or line breaks in your configuration, mixing both is not supported

Motion detectors

Motion detectors use the Capabilities data to describe how to look for events. Example on capabilities configuration:

method=1
triggerMethod=pattern
patternOn=motiondetected=1
patternOff=motiondetected=0

This says that this device is using the eventMethod 1 defined in the camera device.

It uses the "pattern" trigger method, which simply checks for the existence of patternOn and patternOff to trigger on/off or sensor tripped changes.

Inputs

Inputs are specified mostly the same way as motion detectors, using the Capabilities device data.

This is an example configuration (for D-Link cameras):

method=1
triggerMethod=pattern
patternOn=gp_input_1=on
patternOff=gp_input_1=off

These parameters are identical in use to the ones for motion detectors.

Outputs

Outputs are configured using the Capabilities device data:

controlMethod=url
on=/dev/gpioCtrl.cgi?out1=1
off=/dev/gpioCtrl.cgi?out1=0

The control method indicates that this output is changed by doing a url access. The on/off parameters are the urls to be accesses to turn the output on and off.

Development notes

I'm looking for information about how other types of cameras implement events and camera controls. To be able to support as many types of camera manufacturers, we need to find out what support we need to implement. So if you want your particular camera supported, either send me a camera to test, or post the required data here.

Current Plans

The medium-term plans are to add support for other types of event methods - ways that the camera informs us about changes in state. Their usefullness must be evaluated first - and as always, if there are no requests for it, there will be no support either.

The medium/long-term plans are to look into video and audio support. Many cameras have a microphone and a speaker. It will be interesting to see if this can be used in LinuxMCE.

Notes

IP Cameras use (afaik) changes in the image/video stream to detect motion. This can be a disadvantage compared to regular PIR (Passive Infrared detectors). While PIRs only detect rapid temperature changes in a particular area, like when a human body(warm body) moves in front of the detector, an IP camera will signal that motion is detected when the image changes from one frame to another. This implies that it does not need to be a warm body motion, but rather any motion at all. It could be a bird flying past your window, or your curtain swaying in the wind. This is probably not what you want, but unfortunately, it is a limitation of image-motion-based camera.

Using the motion wrapper on any analog or IP camera will also result in the same behaviour as pure IP camera motion detection.

So consider your use case and find out what is best suited, a motion-detection capable IP camera, or a PIR, or perhaps even a combination.