xAP Zoneminder Schema

[pete_c]

I've utilized Zoneminder now for maybe something like 8 years or so. I implemented ZMxAP as an additional benefit to utilizing ZM.

Additionally I did some multipage DIY on building a Zoneminder box based on Ubuntu 11.XX. The "candy" for said build documentation was to be able to utilize xAP for "connecting" the box to the Home automation network. I have been using the messages to drive events on the Homeautomation server and its worked well.

I currently utilize Zoneminder xAP / 8 analogue and 5 IP cameras on one Ubuntu 11.04 box. I trigger events today based on xAP broadcasts. Mostly utilize "alarm" generated events based on motion detection algorithms as defined by Zoneminder. A package delivery generates a video, series of emailed pictures, text messages, etc. (something like maybe 4-5 distinct and concurrent events).

http://www.zoneminder.com/wiki/index.php/Zmxap

The current message I see is:

xap-header
{
v=12
hop=1
uid=FFEA0900
class=xAPBSC.info
source=zm.zoneminder.ZM-XAP-HOUSE
pid=1319
}
output.state
{
State=on
}

I use these messages just fine to drive events. I have just been told though that the message does not comply with the xAPBSC schema. The source does not contain a full end point address (no subaddress component).

As defined in the wiki:

UID=FF123403
Source=ACME.Controller.apartment:BedsideLamp

[Kevin]

Yes - it's close to BSC but not quite there. BSC uses subaddressing to define , within the header, which of several internal endpoints are being reported. To do this (in xAP v1.2) the last two hex digits of the UID represent a numeric ID for the internal enpoint that is between 01 and FE ie 253 internal endpoints can be supported. 00 and FF are reserved. Each endpoint also has a sub address name that is appended to the source address after a ':' In your example you will see that endpoint 03 has a name 'BedsideLamp'.

ZoneMinder is using the 'reserved' 00 address - which is the address of the whole application , and not an endpoint ID. Additionally there is no sub address name. Actually the UID and Source are consistent - it's just that xAPBSC.info messages report endpoints and not the main application.

xAPBSC , although simple in purpose is quite involved in implementation. It is a bi-directional schema using subaddressing and wildcarding and supports discovery. It should be completely implemented in order to preserve the near plug and play integration that BSC provides.

I don't know what the info message is reporting ? What is 'on' as reported in the message and are there other things that ZM reports. Does it for example report movement in each zone or for each camera separately and if so how does it indicate which zone or camera has detected movement.

For example the cameras might be numbered 1-10 and if movement was detected on camera 9 named FrontDoor you might generate a message such as

xap-header
{
v=12
hop=1
uid=FFEA0909
class=xAPBSC.event
source=zm.zoneminder.ZM-XAP-HOUSE:FrontDoor
pid=1319
}
output.state
{
State=on
}


If you can provide a bit more info on what/how ZM reports over xAP that would be helpful.

Such info could also be presented this way...

xap-header
{
v=12
hop=1
uid=FFEA0900
class=Security.Event
source=zm.zoneminder.ZM-XAP-HOUSEpid=1319
}
Trigger
{
Camera=FrontDoor
Cause=Motion
Area=3
}

but here the 'context' of the data value is being set by other parameter(s) within the block, rather than in the header. We try to discourage this now because it makes it harder to extract specific data . Using sub addressing is the recommended approach - with or without BSC.

xap-header
{
v=12
hop=1
uid=FFEA0993
class=Security.Event
source=zm.zoneminder.ZM-XAP-HOUSE:FrontDoor.3
pid=1319
}
Trigger
{
Cause=Motion
}

K

[pete_c]

Let me generate an alarm message from ZM both forced and real such that you can see what the message looks like.

These are Optex combo security cams with both PIR / camera stuff built in.

Forced alarm.

xap-header
{
v=12
hop=1
uid=FFEA0902
class=VMI.AlarmEvent
source=zm.zoneminder.ZM-XAP-HOUSE:Front-Door
pid=1319
}
Alarm
{
AlarmFrames=243
AlarmId=46312
AvgScore=255
Cause=Forced Web
Duration=11.97
Frames=263
MaxScore=255
State=off
TotalScore=61965
}

Here's a driveway cam alert event. I've been trying to manually create an event from the front door cam and now I think the neighbors are wondering what I am doing?

xap-header
{
v=12
hop=1
uid=FFEA0901
class=VMI.AlarmEvent
source=zm.zoneminder.ZM-XAP-HOUSE:Driveway
pid=1319
}
Alarm
{
AlarmId=46316
Cause=Motion
Duration=0.00
State=on
ZoneData=DW-1,
}

[Kevin]

Those are actually OK - and you can see the pairing of a UID with the source name, including a sub address.

The UID is just a shortform numerical representation of a source address for ease of processing. Each are uniquely paired.

However these examples aren't using the xAPBSC schema , as your initial post showed. Instead they use class=VMI.AlarmEvent which is ZM's own schema, which is also fine.

Does he use xAPBSC at all elsewhere - or is it just that one message in your first post and what does the 'state=on' reported in that message mean ?

K

[pete_c]

Kevin,

I haven't paid much attention to the messages other than triggering events based on alarm events generated from ZMXAP.

The first message - ZM-XAP-HOUSE is the only message which indicates:

class=xAPBSC.info
source=zm.zoneminder.ZM-XAP-HOUSE

state=on means that its enabled from what I can tell.

Here's a quickie picture.

[Kevin]

Ahh OK - I thought that was your original question...

It is an invalid message in that it doesn't conform to the BSC specification, although it's unlikely to cause any problems. If there were additional xAPBSC messages that could have been more of an issue. One for correction as a minor issue in a later version maybe.

K

[pete_c]

Thanks Kevin. Its a great application.