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".
  • Protocol definition - xAP Automation
    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 heartbeat

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


  • Schema - xAP Automation
    phone numbers device status and device control These entities can be used in many different contexts A class defines a context within which one or more schema are applied xAP identifies the schema that applies to a given message through the class keyword in the message header For a complete description of the xAP message format see the xAP Specification Schema Basic Status and Control xAP Speech xAP Ping xAP

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

  • Frameworks - xAP Automation
    includes functions for RSS and authentication using both basic and digest types The ocx and sample vb6 source code Visual Basic The Active X control for xAP provides encapsulates a full xAP interface in an easy to use and accessible control The control is divided into two functional areas one associated with delivery of incoming and outbound messages and the other concerned with constructing and deconstructing messages All the messy nitty gritty details related to network communications are hidden The control is suitable for embedding in any Active X aware environment and can be accessed from VB Script allowing any script aware application to take advantage of open xAP communications Source Code ocx C The C programming libraries for xAP provide access to xAP messages and the message transport infrastructure at several levels of abstraction from the lowest level up to a very simple high level messaging paradigm A full xAP compliant application supporting all the major xAP addressing modes can be implemented in around 15 lines of code with no loss of flexibility This power and ease of use is typical of xAP xAP C Library Java Java development for xAP is particularly attractive because of the broad cross platform support available for Java including not only a variety of PC s and mobile devices but also embedded systems such as Tini The first release of the Java SDK is now available It was written with JRE 1 4 2 and includes sample code and Javadoc documentation Please raise any issues on the xAP developer Yahoo mailing list forum Source Code Python Python is a high level intepreted object oriented language It isn t disimilar to say Visual Basic but unlike Visual Basic has the advantage of being supported on a wide variety of hardware platforms The xAP scripting

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

  • Vendor ID - xAP Automation
    2 amx AMX 3 ascentium Mark Harrison 4 barix Barix 5 cat Custom Automation Technology 6 cis Clipsal Schneider 7 control4 Control4 8 cqc Charmed Quark 9 crestron Crestron 10 csi CSI HomeVision 11 dbzoo Brett England 12 domus Mick Davis 13 efundies Jason Bauer 14 ersp Edward Pearson 15 ezy Stef Peelman georg Georgia Qiao gledholt Gledholt Hall homected Homected 16 housebot HouseBot 17 ggr Gene Reeves homeseer HomeSeer 18 csi HomeVision 19 idratek Idratek 20 kcsoft Stuart Booth 21 mcs Michael McSharry 22 mi4 James Traynor 23 mmwave Lehane Kellett 24 mrsoft Mikko Rintala 25 netcomp Kevin Turner 26 n2l Nitrogen Logic 27 nwe Neil Wrightson 28 nws Neil Wrightson 29 nzha Shane Harrison 30 opnode Opnode 31 premise Premise 32 phaedrus Phaedrus 33 phoenix Paul Smith ptrinchi Pierre Trinchi 34 rocket Patrick Lidstone 35 roxydigi Allensbad sanday Sandaysoft 36 safe Safe Consulting stp Stef Peelman tricks Peter Trickett ukusa Kevin Hawkins 37 ursus Claude Bachelet 38 vera micasaverde Vera Control Ltd 39 40 vscp VSCP Ake Hedman 41 wsha WebStudios 42 xFx Edward Pearson 43 xlobby xLobby 44 zz9 Adam Stevens 45 Retrieved from http www xapautomation org index php title Vendor ID oldid 2067 Navigation menu

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

  • HomeSeer 3 xAP plugin - xAP Automation
    As HS3 is new the lack of re written plugins can be a bit of a problem and this thread addresses ways of replicating and realtime synching your HS2 devices in HS3 by using xAP To do this you keep both HS2 and HS3 running both with xAP plugins and HS3 can then be used with synchronised reflections of all your HS plugin devices Also be sure to look over

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

  • xFx-Express Hub - xAP Automation
    the support of applications and therefore focuses on strict validation of xAP messages It is not the role of a hub to be validating messages it should just act as a forwarder of messages This hub the xFx Express Hub is therefore not based on xFx resulting in a more reliable higher performance hub than was possible previously This hub can operate either as a Windows Service normal operation or as a console application useful for debugging Previous xFx hubs have been available in a GUI format this is no longer available Features include Handles both v1 2 and extended v1 3 UID formats Deals gracefully with network unavailability and reconfiguration including DHCP refreshes WiFi drop outs Resume from low power state Hibernate Suspend Away Switches to local mode when no LAN is available allowing xAP applications on a disconnected PC to continue to communicate eg laptop away from home Monitoring via performance counters perfmon xAP counter category Incorporates log4net logging library Works on Vista Download xFx Express hub here Retrieved from http www xapautomation org index php title xFx Express Hub oldid 1956 Categories News Windows Edward Pearson Navigation menu Personal tools Log in Namespaces Article Discussion Variants Views

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

  • Blue 0.1 released - xAP Automation
    come and go It has been tested using a Linksys BT100 USB Bluetooth unit but it should work with any device using the Microsoft stack other stacks may work though This is a beta release and available here http www mi4 biz modules php name Downloads d op getit lid 205 Please report any issues on the xAP yahoo group Retrieved from http www xapautomation org index php title Blue

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

  • Four 0.3 released - xAP Automation
    But thats not all you can also reply to the text message and talk to Four You can do anything via text that you could do via the Four web page Ask for a phone number from switchboard check the weather get device status from Floorplan even control Floorplan There are two catches Firstly you can only receive 250 SMS per week and secondly you must prepend replys with D

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



  •