Abstract:
The present disclosure relates to a method for discovering, identifying, and cataloguing devices on a network, particularly, devices included in a home automation or building control network. In embodiments, a node information table is populated with generic entries representing potentially-discoverable devices on the network. The table is traverse iteratively and potential devices are queried in turn to determine the type and capabilities of each potential device in the network. Device responses stored in the node information table, replacing generic entries with updated entries representative of actual network devices. Additionally, device responses may be used as a basis for subsequent queries to network devices. After device queries are completed, any remaining generic node information table entries are removed from the table, thereby only entries corresponding to positively-identified network devices remain in the table.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims priority to U.S. Provisional Application Ser. No. 60/991,747, filed Dec. 2, 2007, the entirety of which is hereby incorporated by reference herein for all purposes. 
     
    
     BACKGROUND 
       [0002]    1. Technical Field 
         [0003]    The present disclosure relates to the field of home automation and building control systems, and more particularly, to a method of discovering and mapping a home or building control network without prior knowledge of the topology or member devices thereof. 
         [0004]    2. Background of Related Art 
         [0005]    Home automation and building control systems (hereinafter collectively referred to as home automation systems) provide control and monitoring of electrical and electromechanical devices commonly found within a building, such as a residence or commercial building. An example of a simple home automation system may include a familiar wall-mounted light switch that includes remote-control capability, and a corresponding remote controller that communicates with the switch. A user may then enjoy the convenience of controlling room lighting while relaxing on the sofa, or while lying in bed. A more sophisticated system may include software executing on, for example, a personal computer or dedicated device, in operable communication with a wide variety of sensors, devices and controllers installed throughout the building. Such a system may include the capability to control lighting on a schedule or in response to sensor inputs; to monitor environmental conditions such as temperature and humidity and in response thereto control heating, ventilation, and air conditioning (HVAC) systems accordingly; to coordinate and monitor security devices such as perimeter intrusion detectors, motion detectors, and surveillance cameras; to facilitate the distribution of digital media; to monitor and control convenience and recreation systems, such as irrigation systems (e.g., in-ground sprinklers), garage door openers, pool and spa filtration and heating systems; and to monitor and control other aspects of the home environment (i.e., basement flood detection, refrigerator-freezer temperatures, loss of utility grid power, and the like). 
         [0006]    Examples of home automation devices capable of receiving and/or transmitting home automation commands and/or data include, without limitation, dimmers and switches, remote-controlled outlets, handheld devices, HVAC thermostats, furnaces, air conditioning units, appliances, control panels, display devices, wired and wireless remote controls, motion sensors, blind and drape motors, energy management devices, system controllers, home entertainment systems, access control devices, interfaces, and personal computers. 
         [0007]    A home automation system may provide access to selected features from outside the home. In one example, a telephone interface may be provided wherein the homeowner can dial into the home automation system, authenticate to gain remote access to the system (i.e., enter a predetermined PIN code or password), and access system functions using, for example, voice menus, and spoken or touch-tone responses. More recently, home automation systems that are configured to provide access thereto via the internet to personal computers and wireless devices, such as mobile telephones and smart phones, have become popular. 
         [0008]    Some means of communication between home automation system devices must be provided in order for a home automation system to function. For example, early home automation systems employed hard wiring to interconnect system devices, e.g., system devices are interconnected with cables routed through the building structure. While technically simple to implement, hard wired home automation systems may have disadvantages. Installing the interconnection cable may require an electrician to snake wires through existing walls, floors, and ceilings, a laborious and costly undertaking. Additionally, after devices have been installed at one location, they are not easily moved to a different location unless existing cables are rerouted or additional cables are run. Furthermore, the cost of copper and thus cabling has risen markedly in recent years, thereby significantly adding to the cost of hardwired systems. Hardwired systems also tend to be proprietary in nature whereby components from one manufacturer are incompatible with devices from another manufacturer, which limits consumer choice and increases costs. 
         [0009]    Techniques have been developed whereby home automation modules communicate using signals transmitted over existing electrical (e.g., “mains”) wiring. These techniques, known as powerline carrier signals, operate by transmitting a modulated data signal that is superimposed on the 60 Hz or 50 Hz alternating current line voltage typically supplied by the utility grid. One popular standard for powerline carrier communications is the X10® protocol, which encodes data in 120 kHz bursts synchronized to zero crossings of the 60 Hz or 50 Hz power line current. While X10® provides certain benefits, such as ease of use, interoperability among devices of different manufacturers, and relatively low cost, it may have drawbacks in that signal propagation throughout a building may be compromised by many factors which impairs reliability of the system. For example, an X10® signal may not effectively bridge between phases of an electrical service panel without the installation of a specific X10® phase coupler. X10®™ signals are also susceptible to interference causing spurious activation, deactivation, and malfunction of system devices. In addition, an X10® signal may not propagate well through ground fault circuit interrupter (GFCI) devices, and may be disrupted by switching power supplies commonly found in personal computers and other modern electronic devices. 
         [0010]    Recent advances in wireless networking have enabled the development of home automation communications standards and associated devices with improved reliability and an expanded feature set. Once such standard is the Z-Wave® protocol promulgated by Zen-Sys, Inc. of Fremont, Calif., which defines a wireless mesh networking protocol for home automation. In a Z-Wave® home automation system, each device is a node on a wireless mesh network that can communicate with other network nodes either directly or through the mesh network structure. That is, if two nodes are capable of direct RF communication (e.g., physically located no more than about 30 meters apart without obstructions) a message may be passed directly therebetween. If, however, the nodes are unable to communicate directly (e.g., beyond direct RF communication range or if the signal is sufficiently attenuated by an obstruction), the network will attempt to forward messages from the sending node to the receiving node via successive intervening nodes. A Z-Wave® network includes a routing table describing the network topology which facilitates calculation of routes on the basis thereof. The routing table includes a list of nodes comprising the network, and for each, a list of neighbor nodes that are in direct RF communication range therewith. Using the routing table, it is possible to determine a route by which a message may be delivered from sender to receiver. The routing process ensures that all destination nodes can be reached from any initiator node. 
         [0011]    The Z-Wave® protocol defines three fundamental types of network nodes: controllers, routing slaves, and slaves. A controller can host a routing table for the entire network, calculate routes based upon the routing table, and download routes to slave nodes. One controller is designated as a primary controller which has the authority to include newly-added nodes to, or exclude undesired nodes from, the network. In contrast, a slave node does not contain a routing table, however, a routing slave can contain a number of pre-configured routes assigned by a controller. Any of a controller, routing slave, and slave may act as a repeater for messages destined for other nodes. The Z-Wave® protocol includes a unique identifier called a Home ID to distinguish separate networks from each other, and a unique identifier called a Node ID to address individual nodes in the network. 
         [0012]    A Z-Wave® network is self-organizing whereby nodes are capable of discovering their neighbors and distributing this information to other nodes automatically when a new node is added to the network, or, alternatively, upon request. In addition, a Z-Wave® network is self-healing in that nodes are capable of redirecting network traffic if regions of the mesh become inaccessible. Although a Z-Wave® network may be installed and expanded without requiring the user/homeowner to be involved with intricate details of network management, such automatic configuration extends primarily to the initial configuration and/or installation of Z-Wave® devices. Other aspects of the home automation system, for example, the identification of modules post-installation, requires the user to manually disassociate and re-associate device nodes within the home network. In large networks this may be a tedious and time-consuming task. 
       SUMMARY 
       [0013]    The present disclosure provides a method wherein a network of home or building control devices can be discovered. The presently disclosed method may advantageously use, but does not require, advance knowledge of the devices or network topology. In embodiments, the method may discover wired and wireless networks of home or building control devices. In embodiments, the method may discover static wireless repeater networks of home or building control devices. The presently disclosed method may accept an input of a network identification code to discover only devices on a specified network. 
         [0014]    The disclosed method includes at least one of the following steps: (a) initialization of data table entries for control devices; (b) filling of data tables with generic entries; (c) requests from control devices for specific data to replace generic entries; (d) completing missing data by requesting additional product-specific data from control devices and referencing that data in a table to find complete data; and (e) removal of generic entries for non-existing, undiscoverable or undiscovered devices. 
         [0015]    In embodiments, discovered devices may communicate with additional potentially discoverable devices and accordingly, the disclosed method may iteratively perform steps using discovered devices as repeaters or routing nodes to other devices in an effort to ensure that all devices in the network are discovered. In embodiments, a command may be issued to a device, such as without limitation, a command to activate, to deactivate, and/or to request information from the device. 
         [0016]    In embodiments, the disclosed method discovers a network of devices utilizing the Z-Wave® mesh networking protocol. A network identification code (HOME_ID) may be used to select a particular network of devices to be discovered. A table of entries (NODEINFO table) is provided which includes an entry (NODEINFO entry) for each potential device in the network. Each NODEINFO entry includes information relating to the corresponding device, such as without limitation, the type and capabilities of the device. A NODEINFO request is a device information request sent to a device to directly populate a NODEINFO entry. In embodiments, a device database that includes a priori device data is provided. The device database may include data relating to known network devices extant, for example without limitation, data on all known Z-Wave® devices that may be commercially available at a present time. 
         [0017]    In another aspect, the present disclosure provides method for discovering network devices that includes providing a data table, i.e., a NODEINFO table, having at least one device entry corresponding to a potentially-identifiable network device, such as a Z-Wave® device. The data table is initialized by populating the device entries with generic device data, e.g., placeholder entries. If device data is known, e.g., device data that may have previously been stored, such as without limitation a backup file, the corresponding device data entry is populated accordingly with the known data. Device data is then requested from the network device corresponding to each device entry. If the requested device data is received, the corresponding device entry is populated with the received data. If no device data is received with respect to a device entry, the device entry is nullified, indicating, for example, that no device corresponding to that device entry was discovered. In embodiments, the fact that device data was requested from a device is recorded in the device entry corresponding thereto. 
         [0018]    In yet another aspect a home automation network is disclosed that includes at least one network device node, a home automation network interface in operable communication with the at least one network device node, and a processor operably coupled to the home automation network interface configured to execute a set of programmable instructions for performing a method of network discovery as disclosed herein. 
         [0019]    In still another aspect, a home automation network discovery apparatus is disclosed that includes a processor, which may be operably coupled to a home automation network interface, wherein the processor is configured to execute a set of programmable instructions for performing a method of network discovery as disclosed herein. 
         [0020]    The present disclosure also provides a computer-readable medium storing a set of programmable instructions configured for being executed by at least one processor for performing a method of discovering devices in home automation or building control network in accordance with the present disclosure. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0021]    The above and other aspects, features, and advantages of the present disclosure will become more apparent in light of the following detailed description when taken in conjunction with the accompanying drawings wherein: 
           [0022]      FIG. 1  is a block diagram illustrating a representative operating environment for an exemplary embodiment of a network discovery method in accordance with the present disclosure; 
           [0023]      FIG. 2  is a data block diagram of an embodiment of a network discovery method in accordance with the present disclosure; and 
           [0024]      FIGS. 3A-3D  are flow diagrams illustrating a method for network discovery in accordance with the present disclosure. 
       
    
    
     DETAILED DESCRIPTION 
       [0025]    Particular embodiments of the present disclosure will be described hereinbelow with reference to the accompanying drawings; however, it is to be understood that the disclosed embodiments are merely exemplary of the disclosure, which may be embodied in various forms. Well-known functions or constructions are not described in detail to avoid obscuring the present disclosure in unnecessary detail. It is to be understood that the steps of the disclosed methods may be performed in a different order than presented herein. Therefore, specific structural, functional, and algorithmic details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present disclosure in virtually any appropriately detailed structure. 
         [0026]      FIG. 1  illustrates a representative operating environment  100  for an exemplary embodiment of a method of network discovery in accordance with the present disclosure. Representative operating environment  100  includes computer  101  which can be a personal computer (PC) or a server, which further includes at least one system bus  110  which couples system components, including at least one processor  105 ; a system memory  115  which may include random-access memory (RAM); at least one storage device  120 , such as a hard disk, CD-ROM or DVD-ROM, or other non-volatile storage device, such as without limitation a flash memory device or USB memory stick; and input-output interfaces including display interface  140 , desktop interface  150  and data network interface  160 . System bus  110  may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and/or a local bus using any bus architecture such as without limitation PCI, USB or IEEE 1394 (Firewire). Desktop interface  150  may include an AT keyboard interface, a PS/2 keyboard interface, a PS/2 mouse interface, a USB interface and/or a Bluetooth interface. Data network interface may be a wired network interface such as a 100Base-T Fast Ethernet interface, or a wireless network interface such as without limitation a wireless network interface compliant with the IEEE 802.11 (i.e., WiFi), GSM, or CDMA standard. Representative operating environment  100  includes display  145  which can be a cathode ray tube (CRT) display, liquid crystal display (LCD) or other suitable display; and input devices keyboard  152  and mouse  154 . 
         [0027]    Computer  101  may be operated in a networked environment via at least one network interface  160 , wherein computer  101  is connected to remote devices by a data network  165 , such as a local area network or the Internet, for the transmission and reception of data, such as without limitation accessing remote databases as will be further described herein. 
         [0028]    Representative operating environment  100  further includes home automation network  135 , which can be locally coupled to computer  101  by a home automation interface  130  such as without limitation, a ThinkStick™ Z-Wave® USB adapter. Home automation network  135  may include at least one node  136   a  et seq., which may be a Z-Wave®-compatible device such as a Leviton® Vizia RF® switch, dimmer, fan control, or low-voltage dimmer. 
         [0029]    At least one software program  122  adapted to be executed on computer  101  is stored on storage device  120 , or additionally or alternatively, on a remote network device such as a computer (not explicitly shown) which can be a PC, a web server, a file server, a storage array, or an application server. Software program  122  includes a set of programmable instructions configured to execute on at least one processor  105  for performing a method of discovering network nodes as disclosed herein. Software program  122  may include additional modules, routines, subroutines, objects, components, data structures, and other elements that will be familiar to the skilled artisan, that perform particular tasks. In response to commands entered into computer  101  via, for example, keyboard  152  and mouse  154 , computer  101  can be caused to activate software program  122  which may be an application program. Typically, upon activation software program  122  is loaded into system memory  115  from storage device  120  or remote computer (not explicitly shown) for execution by processor  105  to allow the user to configure and interact with home automation network  135 . 
         [0030]    Referring now to  FIG. 2 , the present disclosure provides a node information table  170 , (i.e., the NODEINFO table) that is configured for storing data associated with at least one node  136   a  et seq. (e.g., member) of the home automation network  135 . In embodiments, the home automation network may be identified by an identifier associated therewith (i.e., a HOME_ID associated therewith). In embodiments, the NODEINFO table includes a number of data entries sufficient to represent the maximum number of nodes of a home automation network  135 . A device database  190  is provided which includes supplemental mode data. Supplemental node data may include, but is not limited to, node data related to node type, manufacturer, device capabilities, hardware version, software version, and/or firmware version. In embodiments, device database  190  includes a priori node data. A priori node data may include data previously collected with respect to prototype or commercially-available home networking nodes. In another aspect, the device database includes data related to devices known to exist. A priori node data may be used to augment or complete information collected from the node or the network. As an example only, a given node may only provide minimal identifying information, such as a manufacturer identifier and a manufacturing date. Using such information to execute a query into the device database, the disclosed method can determine additional or supplemental information about the device. Continuing with the present example, a manufacturer identifier and a manufacturing date may be used to query the device database to determine, for example without limitation, a software version, country of origin, device capabilities, supported device profiles, and/or basic/reserved/security status. The device database may include without limitation, device capabilities (i.e., whether the device is capable of acting as a repeater node), device chipset, and/or device operating frequency. The device database may reside locally or remotely, or may be distributed among and/or between local and remote devices (i.e., servers). In embodiments, the present disclosure provides a method of populating the device database wherein an initial query for a device is performed. If the device is not found in the database, a device request may be issued to the device to obtain the device characteristics, which are added to the device database. In embodiments, the device database is accessed and update via data network, such as the internet, or other public or private data network. In embodiments, device database  190  is included with software program  122 . 
         [0031]    Turning to  FIGS. 3A-3D , the disclosed method begins in the step  210 , and in the step  212  populates a NODEINFO table with generic entries. A NODEINFO is associated with a potential network device, or node. A NODEINFO entry may include the NODE_ID of the device node associated therewith. In the step  214  it is determined whether at least one network device has been previously identified, e.g., whether the device(s) is/are known to be present in the network. If at least one network device has been previously identified, then in the step  216  the NODEINFO entry (or entries) associated with the at least one device(s) is populated with the known information corresponding to the device. These NODEINFO entries may consist of data representing actual potential control devices which, for example, may repeat messages in the network. Any remaining NODEINFO entries (i.e., unknown entries) are deemed potentially discoverable entries (i.e., entries which may potentially but do not yet represent a known device) and are represented by generic entries. If no devices are already known in the network, a NODEINFO table is populated with generic entries for each potential device in the network. 
         [0032]    In the step  218  an iterative control loop (i.e., the NODEINFO loop) is established to traverse each entry in the NODEINFO table wherein in the step  220  the NODEINFO loop termination condition is tested. For each entry in the NODEINFO table, a NODEINFO request is sent to the device in the step  222  and a NODEINFO_SENT flag is set in the corresponding NODEINFO entry. In embodiments, a NODEINFO request is sent via the Z-Wave® protocol. If a NODEINFO request is responded to by the device in the step  224 , the device is categorized as “found” in the step  228  wherein the NODEINFO entry associated with the current node is tagged as “found” and the received NODEINFO request data is stored in the associated a NODEINFO entry. In the step  230  it is determined whether the received NODEINFO response contains complete data, i.e., all NODEINFO response data items are populated, or the received NODEINFO request response contains partial or incomplete data, e.g., wherein one or more response data items are blank, missing, cleared, or unavailable. If the NODEINFO response contains partial data, then in the step  232  the device database  190  is queried to obtain the missing data which is then stored in the associated NODEINFO entry. 
         [0033]    One or more connected node discovery iterations may now be performed in a connected node loop. The maximum number of iterations of this loop may be determined by the maximum number of consecutive devices which can repeat (e.g., forward) a message en route to the destination thereof. In embodiments, for example, in a Z-Wave® network, four iterations may be executed. In the step  234  a message is sent to the current node requesting a list of connected nodes, i.e., those node(s) in direct communication with the current node. A list of connected nodes is received in the step  236 . In the step  238  an iterative control loop is established to traverse each entry in the list of connected nodes wherein the loop termination condition, i.e., whether all connected node have been processed, is tested. For each entry in the list of connected nodes, it is determined in the step  240  whether current connected list node (i.e., the i th  node) has been tagged as “found” or “potentially found”. If not tagged as “found” or “potentially found”, in the step  242  a generic message (e.g., a “ping”) is sent to the i th  connected node. If no response to the generic message is received, the loop iterates in the step  246  and the next i th  connected node is processed. If a response to the generic message is received, the NODEINFO entry of the i th  connected node is marked as “potentially found”. 
         [0034]    In the step  250  it is determined whether a NODEINFO request has been sent to the i th  device. In response to a determination that a NODEINFO request has not been sent to the i th  device, a NODEINFO request is sent to the device in the step  252 . This request may be sent directly, and also may be sent utilizing other devices as repeaters. If the NODEINFO request data is received, in the step  254  the received NODEINFO request data is stored in the associated a NODEINFO entry. In the step  256  it is determined whether the received NODEINFO response contains complete or partial data. If it is determined the received NODEINFO response contains complete data, the loop iterates in the step  246  and the next i th  connected node is processed. 
         [0035]    If the NODEINFO entry for the i th  connected node is incomplete or partial, in the step  258  a request is sent to the device requesting additional information to determine the device&#39;s product type. In one implementation, the product type (e.g., MANUFACTURER_SPECIFIC data) is requested from the device; additionally, the VERSION data may be requested from the device to distinguish the device from others of the same type. In the step  260  it is determined whether such additional information was received. If it is determined additional information was not received, the loop iterates in the step  246  and the next i th  connected node is processed. If, however, it is determined additional information was received, the step  262  is performed wherein part or all of the additional information is used to look up the complete NODEINFO entry data in the device database, and in the step  264  it is determined whether the supplemental NODEINFO data was found. If the supplemental NODEINFO data was found for the device, this complete data is stored as the NODEINFO entry for the device (i.e., the current i th  connected node). The connected node loop iterates in the step  246  and the next i th  connected node is processed, until all connected nodes in the current list of connected nodes have been processed. The NODEINFO loop then iterates in the step  226  and the next NODEINFO entry is processed, until it is determined in the step  220  that the NODEINFO loop has traversed all NODEINFO entries. 
         [0036]    In the step  266  an iterative control loop (e.g., a cleanup loop) is established to traverse each entry in the NODEINFO table wherein in the step  268  the cleanup loop termination condition is tested. In the step  270  it is determined whether the current NODEINFO entry is marked “potentially found”. If the current NODEINFO entry is not marked “potentially found”, the cleanup loop iterates in the step  272  and the next NODEINFO entry is processed. If the current NODEINFO entry is marked “potentially found”, the step  274  is executed wherein a NODEINFO request is sent to the current node and in the step  276  it is determined whether a response was received, i.e., whether NODEINFO data is received from the current node. If NODEINFO data is not received, the cleanup loop iterates in the step  272  and the next NODEINFO entry is processed. If NODEINFO data is received, in the step  278  the received NODEINFO data is stored in the current NODEINFO entry. In the step  280  it is determined whether the received NODEINFO response contains complete or partial data. If it is determined the received NODEINFO response contains complete data, the cleanup loop iterates in the step  272  and the next NODEINFO entry is processed. If the NODEINFO response contains incomplete or partial data, in the step  282  a request is sent to the device requesting additional information. In the step  284  it is determined whether such additional information was received. If it is determined additional information was not received, the cleanup loop iterates in the step  272  and the next NODEINFO node is processed. If, however, it is determined additional information was received, the step  286  is performed wherein part or all of the additional information is used to look up the complete NODEINFO entry data in the device database, and in the step  288  any supplemental NODEINFO data that was found for the device is stored as the NODEINFO entry for the device. The cleanup loop iterates in the step  272  and the next NODEINFO entry is processed, until it is determined in the step  268  all NODEINFO entries have been processed in the cleanup loop. 
         [0037]    For each device entry which was populated with generic data, but for which no corresponding device was successfully discovered, an empty NODEINFO entry is now written in the step  290 , overriding any previous NODEINFO entry for that device, removing the device as a potential device in the network. The disclosed method ends with the step  292 . 
         [0038]    It will be appreciated that variations of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims. Therefore, the herein description should not be construed as limiting, but merely as exemplifications of particular embodiments. The claims can encompass embodiments in hardware, software, or a combination thereof.