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".
  • View source for Protocol definition - xAP Automation
    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 Image Source addr jpg 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 Image Target addr jpg 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 Image Wildsource jpg Image Wildtarget jpg 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 BR BR v 12 BR hop 1 BR uid FF445500 BR class a big message BR source acme fooDevice anInstance aSubInstance BR target barDevice BR my block 1 BR BR target lounge BR message block aimed at lounge instance of barDevice BR BR my block 2 BR BR target bedroom BR message block aimed at bedroom instance of barDevice BR BR my block 3 BR BR message block aimed at all instances of barDevice BR BR 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 BR BR v 12 BR hop 1 BR uid FFAABB00 BR class xap hbeat alive BR source acme meteor home line1 BR interval 60 BR BR BR 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 uniquely identifying the application or device family that generated this heartbeat Vendor Identifies the vendor of the device or application originating

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

  • Revision history of "Protocol definition" - xAP Automation
    Talk contribs Transport Wrapper cur last 23 55 30 April 2006 Jamest Talk contribs Standard Message Schema cur last 23 54 30 April 2006 Jamest Talk contribs Device Monitoring Heartbeats cur last 23 53 30 April 2006 Jamest Talk contribs Wildcarding of Addresses via Header cur last 23 52 30 April 2006 Jamest Talk contribs Wildcarding of Addresses via Header cur last 23 50 30 April 2006 Jamest Talk contribs Target Based Addressing cur last 23 50 30 April 2006 Jamest Talk contribs Source Based Addressing cur last 23 48 30 April 2006 Jamest Talk contribs Message Addressing Schemes cur last 23 29 30 April 2006 Jamest Talk contribs Message Addressing Schemes cur last 23 27 30 April 2006 Jamest Talk contribs Message Addressing Schemes cur last 23 26 30 April 2006 Jamest Talk contribs Message Addressing Schemes cur last 23 23 30 April 2006 Jamest Talk contribs Basic Message Structure cur last 23 18 30 April 2006 Jamest Talk contribs Anatomy of a xAP Message cur last 23 17 30 April 2006 Jamest Talk contribs Multiple Network Support cur last 23 16 30 April 2006 Jamest Talk contribs Wildcarding of Addresses via Body Multi Block messages only cur last

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

  • Pages that link to "Protocol definition" - xAP Automation
    File talk MediaWiki MediaWiki talk Template Template talk Help Help talk Category Category talk Filters Hide transclusions Hide links Hide redirects The following pages link to here View previous 50 next 50 20 50 100 250 500 xAP Home Automation protocol links Schema links View previous 50 next 50 20 50 100 250 500 Retrieved from http www xapautomation org index php title Special WhatLinksHere Protocol definition Navigation menu Personal

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

  • Changes related to "Protocol definition" - xAP Automation
    The page size changed by this number of bytes Show last 50 100 250 500 changes in last 1 3 7 14 30 days Hide minor edits Show bots Hide anonymous users Hide logged in users Hide my edits Show new changes starting from 02 46 26 April 2016 Namespace all Main Talk User User talk XAP Automation XAP Automation talk File File talk MediaWiki MediaWiki talk Template Template talk

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

  • Protocol definition - xAP Automation
    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 uniquely identifying the application or device family that generated this

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

  • Information for "Protocol definition" - xAP Automation
    of redirects to this page 0 Page protection Edit default Move default Edit history Page creator Jamest Talk contribs Date of page creation 21 39 30 April 2006 Latest editor Jamest Talk contribs Date of latest edit 12 01 1 October 2006 Total number of edits 27 Total number of distinct authors 1 Recent number of edits within past 91 days 0 Recent number of distinct authors 0 Retrieved from

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

  • Basic Status and Control Schema - xAP Automation
    two digits of the UID header field it is a unique numerical identification equivalent to the human readable sub address name which is everything after the in the source address UID FF123403 Source ACME Controller apartment BedsideLamp It is the responsibility of the programmer to determine the mapping between actual endpoints and subUID s It is generally to be recommended that the subUID s used should be contiguous wherever possible In any event the mapping should be deterministic and documented Definitions xAPBSC cmd Messages in xAPBSC cmd are used to set the state of an Outputs within one device They are typically sent TO a device supporting BSC A message in xAPBSC cmd must set the header field Class to xAPBSC cmd A message in xAPBSC cmd must include a TARGET field in the xAP header This target field must match the device being controlled It may include wildcarding but see the note above A message in xAPBSC cmd will include a body part s titled output state n One body part per endpoint to be controlled will be included and these will be indexed sequentially output state 1 output state 2 etc Thus several endpoints can have their state changed instantaneously This body part contains a series of key value pairs appropriate to the device being controlled Included in every body part is an ID key which is a two hex digit number corresponding to the UID subaddress of the endpoint to be controlled Alternatively a single body part can be used with ID to address all endpoints that match the target address If the two hex digit number given does not match a UID subaddress that exists then no response should be given and no action taken If the two hex digit number does not align with the TARGET address taking into account wildcarding of the subaddress and the internal mapping of targets to UID subaddresses then no response should be given and no action taken The other key values included in the body should be appropriate to the device being controlled ie Binary Level or Stream If the control causes a value to change a xAPBSC event message must be raised in response If the control does not cause the value to change then you should issue a xAPBSC info event Example v 12 hop 1 uid FF123400 class xAPBSC cmd source ACME Controller Central target ACME Lighting apartment output state 1 ID 03 State ON Level 50 output state 2 ID 1B State OFF In this case the xAP device is a lighting controller configured with apartment as the instance ID The message is generally targeted at all UID subaddresses on this device by using the wildcard Within the body two sections change outputs corresponding to subUID 03 BedsideLamp and 1B device 03 we already know to be the BedsideLamp Example v 12 hop 1 uid FF123400 class xAPBSC cmd source ACME Controller Central target ACME Lighting apartment outside output state 1 ID State OFF This

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

  • xAP Speech Schema - xAP Automation
    before speech Should be sent without file extension optional To stop speaking Either just the current spoken message or the entire queue Class tts speak tts stop Stop Current All mandatory tts locate Used for another app to locate a tts app Class tts locate tts locate Locate Yes Response to a tts locate request Class tts service tts voice Voice X Voice name X is sequential mandatory Default Default

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



  •