archive-org.com » ORG » X » XAPAUTOMATION.ORG

Total: 371

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • File:Subaddress.jpg - xAP Automation
    Dimensions User Comment current 23 48 30 April 2006 672x211 27 KB Jamest Talk contribs Sub Address diagram 23 30 30 April 2006 672x211 27 KB Jamest Talk contribs Subaddress diagram You cannot overwrite this file Links The following pages link to this file Protocol definition Protocol v12r Retrieved from http www xapautomation org index php title File Subaddress jpg oldid 1391 Navigation menu Personal tools Log in Namespaces File

    Original URL path: http://www.xapautomation.org/index.php?title=File:Subaddress.jpg (2016-04-26)
    Open archived version from archive


  • File:Source addr.jpg - xAP Automation
    appeared at that time Date Time Thumbnail Dimensions User Comment current 23 49 30 April 2006 672x472 58 KB Jamest Talk contribs You cannot overwrite this file Links The following pages link to this file Protocol definition Protocol v12r Retrieved from http www xapautomation org index php title File Source addr jpg oldid 1393 Navigation menu Personal tools Log in Namespaces File Discussion Variants Views Read View source View history

    Original URL path: http://www.xapautomation.org/index.php?title=File:Source_addr.jpg (2016-04-26)
    Open archived version from archive

  • File:Target addr.jpg - xAP Automation
    appeared at that time Date Time Thumbnail Dimensions User Comment current 19 36 31 March 2009 672x472 64 KB Edward Talk contribs You cannot overwrite this file Links The following pages link to this file Protocol definition Protocol v12r Retrieved from http www xapautomation org index php title File Target addr jpg oldid 2008 Navigation menu Personal tools Log in Namespaces File Discussion Variants Views Read View source View history

    Original URL path: http://www.xapautomation.org/index.php?title=File:Target_addr.jpg (2016-04-26)
    Open archived version from archive

  • File:Wildsource.jpg - xAP Automation
    appeared at that time Date Time Thumbnail Dimensions User Comment current 23 52 30 April 2006 672x465 57 KB Jamest Talk contribs You cannot overwrite this file Links The following pages link to this file Protocol definition Protocol v12r Retrieved from http www xapautomation org index php title File Wildsource jpg oldid 1398 Navigation menu Personal tools Log in Namespaces File Discussion Variants Views Read View source View history Actions

    Original URL path: http://www.xapautomation.org/index.php?title=File:Wildsource.jpg (2016-04-26)
    Open archived version from archive

  • File:Wildtarget.jpg - xAP Automation
    appeared at that time Date Time Thumbnail Dimensions User Comment current 23 52 30 April 2006 672x472 57 KB Jamest Talk contribs You cannot overwrite this file Links The following pages link to this file Protocol definition Protocol v12r Retrieved from http www xapautomation org index php title File Wildtarget jpg oldid 1399 Navigation menu Personal tools Log in Namespaces File Discussion Variants Views Read View source View history Actions

    Original URL path: http://www.xapautomation.org/index.php?title=File:Wildtarget.jpg (2016-04-26)
    Open archived version from archive

  • File:Schema.jpg - xAP Automation
    appeared at that time Date Time Thumbnail Dimensions User Comment current 23 55 30 April 2006 672x471 83 KB Jamest Talk contribs You cannot overwrite this file Links The following pages link to this file Protocol definition Protocol v12r Retrieved from http www xapautomation org index php title File Schema jpg oldid 1402 Navigation menu Personal tools Log in Namespaces File Discussion Variants Views Read View source View history Actions

    Original URL path: http://www.xapautomation.org/index.php?title=File:Schema.jpg (2016-04-26)
    Open archived version from archive

  • Protocol definition - xAP Automation
    capability of small devices Note that in many instances it is possible for devices to identify the originator of a message solely from the uid minimising the requirements for string storage space Addressing Modes On receipt of a message all devices inspect the message header On the basis of the name value pairs contained in the header the device decides whether a message warrants further processing or should be discarded Two alternative addressing schemes are supported to allow devices to determine whether or not they should act on a given message Source Based Addressing A recipient device determines whether the message is of interest by inspecting the source of the message This mode of addressing works well for one to many relationships There are many possible receivers of data broadcast by a temperature sensor located in a particular room for example and they may all intercept the same message concurrently provided they know its source Source based addressing is available to any receiver since it is mandatory for senders to include their source address and the address is guaranteed to uniquely identify the sender If required low powered devices may choose to filter on incoming messages based on the uid rather than the full xAP source address Whilst very limited storage is required to identify the source of incoming messages the use of uid filtering obviously precludes the use of wildcards Target Based Addressing A sending device may wish to target a message at a specific device It does this by including the address of the target device in the header using the target parameter This is particularly true of simple devices which may not be capable of filtering messages that originate from multiple sources For example a command may be sent to a simple curtain controller to close a specific set of curtains The curtain controller need only recognise messages aimed at itself rather than retaining a list of all possible originators Note that the target message is still broadcast however and may also be intercepted by other nodes on the network such as for example a cache which tracks the current status of all devices Whether a device as a receiver chooses to support target addressing is determined by the implementer and is dependent on the functionality offered by the device Wildcarding of Addresses via Header Target addresses may be wildcarded in certain circumstances A matching wildcard address indicates that the entire remaining message whether a single block or multi block message is intended for the recipient If a device supports target addressing it must also support wildcarding of target addresses Wildcards are specified on a per field basis using the reserved characters and The character indicates that any value may be substituted for the current field The character indicates that any further input is matched Thus a device which is identified by an address of a b c d would be expected to respond to messages targeted at a c d but would not consider a message identified by an address a c as a match because no wild card has been explicitly specified for the last element A device identified by an address of a b c d would be expected to respond to messages targeted at a b c Unless explicitly specified the colon sub address separator is treated as being synonomous with a dot separator Exact matching against a colon is only required in situations where wild card filtering against just the sub address element is required Target addresses may be wildcarded by either the sender the receiver or both Source addresses may only be wildcarded by a receiver Wildcarding is simple to implement but surprisingly powerful and can lead to complex control scenarios Basic Wildcard Modes Target based wildcarding From fixed source wildcard target to fixed target filtering receiver Sender targets multiple selected recipients using just one message Useful for control of a group of devices E g all curtain controllers in a single room with individual addresses of acme K400 lounge curtain 0 acme K400 lounge curtain 1 and so on might be collectively targeted by acme K400 lounge curtain Source based wildcarding From fixed source no target to wildcard source filtering receiver The receiver is able to intercept messages from multiple sources through the application of a single filter criteria Useful for low power devices For example a receiver device may match messages from a source acme digitstat in order to display the temperatures broadcast by each thermostat in the house avoiding the need to explicitly list and configure the addresses of each individual thermostat at the receiver New thermostats can also be added at any time without the need to modify the existing configuration Advanced Wildcard Modes Advanced wildcard modes are included here for completeness Any device which is capable of supporting the basic wildcarding methodology is inherently capable of supporting these modes although the relationships between devices rapidly increases in complexity For this reason these modes are unlikely to find widespread application Target based wildcarding From fixed source fixed target to wildcard target filtering receiver Sender targets a recipient Recipient filters target address on wildcard basis Allows for a receiver to easily respond to multiple target addresses which are specified using a single criteria E g a receiving device which supports control of multiple output ports might use a filter acme iodevice port to intercept messages targeted at acme iodevice port 1 acme iodevice port 2 etc Such messages might originate from many different sources on the network From fixed source wildcard target to wildcard target filtering receiver Senders target multiple selected recipients using just one message Multiple senders may be matched since the receiver also matches the target against a wildcard This mode may be used to create specific sets of many to many relationships Restrictions on Wildcarding Note that it is neither legal nor meaningful for a sending device to wildcard its own source The source address should always provide a means of unambiguously identifying the originating device A receiving device must implement target based wildcarding if it supports target based addressing This ensures that any sender can successfully control a receiving device using a wildcard target address A receiving device may implement source based filtering on a wild card basis at the developers discretion The following diagrams illustrate the use of wildcarded addressing Wildcarding of Addresses via Body Multi Block messages only Any multi block message with a wildcarded header address may optionally include additional target filters within each message body This allows selected parts of a message to be targeted at individual receivers The receiver first matches the header target tag On finding a match it may then choose to inspect the target tag in each message block processing the message block if it is a good match Inclusion of the target tag within a message block is optional Message blocks which do not include a target tag are assumed to be aimed at all recipients For example the following message illustrates how multiple message blocks in a single message can be used to achieve selective control over a number of instances of the same device xap header v 12 hop 1 uid FF445500 class a big message source acme fooDevice anInstance aSubInstance target barDevice my block 1 target lounge message block aimed at lounge instance of barDevice my block 2 target bedroom message block aimed at bedroom instance of barDevice my block 3 message block aimed at all instances of barDevice Restrictions on Body Wildcarding Receiver support for Body Wildcarding is not mandatory However if a given message schema is supported by a receiver and that message schema uses body wildcarding then the receiver must correctly apply filtering to that message Message Header Policy Every xAP compliant message must include a xAP header message section It is mandatory that this header is the first section of a xAP message A receiver should discard any mal formed message The order of items in the header is fixed to make parsing easier for simple devices however not all items in the header are mandatory Message Header Structure The xAP header name value pairs are specified as follows The order in which the name value pairs are included in the message header is significant and must follow the order specified here The following header items are mandatory Version v version Header version Reflects the xAP specification against which the message complies Has value 12 for messages complying with this document E g version 12 Hop Count hop hop count Always has value of 1 set by the originator This value will be incremented each time a message traverses a bridge or gateway but not when it traverses a hub E g hop 1 Unique Identifier uid uid Uniquely identifies a particular hardware device on a xAP network The UID is represented as ASCII hex number with all characters in upper case of the form nn dd dd ss The first two digits nn of the UID are reserved for future use and must be FF by default The digits dd dd are assigned at device configuration time to ensure that the hardware device is uniquely identified within the local xAP domain The last two digits identify the device sub address if supported or are otherwise zero E g FF123400 A UID may be no longer than 8 digits in total The UID is usually configured at device installtime Message Class class class type Provides a cue which indicates how the remainder of the message is composed in terms of which schema it uses The xAP group maintain standard message classes and associated schema for common source types and is happy to accept contributions from developers Standard classes can be identified through the use of the reserved prefix xap class Identifies the collection of schema applicable to this message type Identifies the sub schema applicable to this message E g class xap x10 command identifies that the message content that follows on from the header represents a xAP group standard x10 command and should follow a prescribed but implicit format for x10 commands E g class xap x10 status identifies that the message that follows on from the header is a xAP group standard x10 status request and should follow the prescribed but implicit format for x10 status requests Message Source source vendor device instance1 instance2 n sub1 n Provides a means of uniquely identifying the application or device originating this message The uid element is assigned when the device is connected to a xAP network for the first time and is guaranteed to be unique within that network The remaining elements of the address identify a specific end point within a specific device As such they are also required to be unique for a given xAP network Vendor Identifies the vendor of the device or application originating the xAP message Vendor names are managed and allocated upon request by the xAP group to ensure that they are unique This element is fixed and determined by the programmer at design time The vendor id may be no longer than 8 characters Device Identifies the physical device or application originating the xAP message Examples include CM12U an X 10 controller Meteor a caller id unit Outlook the microsoft e mail application This element is fixed and determined by the programmer at design time The device id may be no longer than 8 characters Instance1 instance2 n Identifies this instance of the device or application Typically reflects the geographic location of a device or system e g sitting room First element is mandatory additional elements may added if required The instance field s in conjunction with the vendor and device field uniquely identifies the originator of the message at the level of that instance of the application on a known host on my network and so provides a cue which indicates how the message content should be handled The value of the instance field is usually determined by the end user at the time when the device or application is installed for the first time Each element is delimited by a period sub1 n Optional Used for subaddressing of multi function device or application The value of the field s may be determined either by the programmer at design time or by the end user at run time when the device or application is installed for the first time depending on the application Each element is delimited by a period It is recommended overall length of a source address is limited to 128 characters inclusive of delimiters E g source acme cm12 node0 identifies a CM12U sited at node 0 which is connected to the xAP network using software written by the mythical vendor Acme E g source xapcorp cid home line1 identifies a caller id unit manufactured by the mythical xAPCorp The device is connected to the home phone system s line 1 The following header items are optional Target target vendor device instance1 instance2 n sub1 n Provides a means of targeting a specific application or device family interested in this message or event Devices are not required to support target based addressing but when they do they must also include support for wildcarding of the target address see later Target addressing Vendor Identifies the vendor of the device or application originating the xAP message Vendor names are managed and allocated by the xAP group to ensure that they are unique This element is fixed and determined by the programmer at design time A vendor id may be no longer than 8 characters Device Identifies the physical device or application originating the xAP message Examples include CM12U an X 10 controller Meteor a caller id unit Outlook the microsoft e mail application This element is fixed and determined by the programmer at design time A device name may be no longer than 8 characters Instance1 instance2 n Identifies this instance of the device or application Typically reflects the geographic location of a device or system e g sitting room First element is mandatory additional elements may added if required This in conjunction with the vendor and device field uniquely identifies the originator of the message at the level of that instance of the application on a known host on my network and so provides a cue which indicates how the message content should be handled The value of the instance field is usually determined by the end user at the time when the device or application is installed for the first time Each element is delimited by a period sub1 n Optional Used for subaddressing of multi function device or application The value of the field s may be determined either by the programmer at design time or by the end user at run time when the device or application is installed for the first time depending on the application Each element is delimited by a period It is recommened the overall length of a targetaddress is limited to 128 characters inclusive of delimiters A device should ignore all unknown name value pairs included in the header E g target acme cm12 node0 identifies a message which is explicitly intended to be actioned by a CM12U sited at node 0 which is connected to the xAP network using software written by the mythical vendor Acme Message Body Policy A message generally comprises one or more message blocks Messages which do not include a body are legal the heartbeat message is one such example but they are limited to status reporting and their general use is discouraged Where possible the use of single message block messages is encouraged because they are readily accessible to low power devices Each message block is labelled with a section name Multiple message blocks may share the same name if and only if they use the same schema In array type situations it is recommended that message blocks are labelled with an index e g my block 0 my block 1 to differentiate them Within a message the message block name is used as a cue to indicate the schema used to encode that message block and thus which name value pairs a receiver might expect to find within the message block and their semantic significance Device Monitoring Heartbeats In order to allow health monitoring of all xAP enabled components within the home it is strongly recommended that a xAP enabled device generates a periodic heartbeat It is however recognised that some low end embedded devices may not be able to support this functionality The heartbeat message has the following minimum structure xap hbeat v 12 hop 1 uid FFAABB00 class xap hbeat alive source acme meteor home line1 interval 60 where Version v version Header version Reflects the xAP specification against which the message complies Has value 12 for messages complying with this document E g v 12 Hop Count hop hop count Always has value of 1 set by the originator This value will be incremented each time a message traverses a bridge or gateway but not when it traverses a hub E g hop 1 Unique Identifier uid uid Uniquely identifies a particular hardware device on a xAP network The UID is represented as ASCII hex number with all characters in upper case of the form nn dd dd ss The first two digits nn of the UID are reserved for future use and must be FF by default The digits dd dd are assigned at device configuration time to ensure that the hardware device is uniquely identified within the local xAP domain The last two digits identify the device sub address if supported or are otherwise zero E g FF123400 A UID may be no longer than 8 digits in total The UID is usually configured at device installtime Message Class class class type Indicates that the message is a xAP group standard heartbeat indicating that the device is alive Message Source source vendor device instance Provides a means of

    Original URL path: http://www.xapautomation.org/index.php?title=Protocol_definition&oldid=1613 (2016-04-26)
    Open archived version from archive

  • Log in - xAP Automation
    to XAP Automation Username Password Forgot your password Keep me logged in Help with logging in Retrieved from http www xapautomation org index php title Special UserLogin Navigation menu Personal tools Log in Namespaces Special Variants Views Actions Search Navigation

    Original URL path: http://www.xapautomation.org/index.php?title=Special:UserLogin&returnto=Protocol+definition (2016-04-26)
    Open archived version from archive



  •