Patent Publication Number: US-9432208-B2

Title: Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Application Ser. No. 61/167,135, filed by Grohman, et al., on Apr. 6, 2009, entitled “Comprehensive HVAC Control System”, and is a continuation-in-part application of application Ser. No. 12/258,659, filed by Grohman on Oct. 27, 2008 now abandoned, entitled “Apparatus and Method for Controlling an Environmental Conditioning Unit,” both of which are commonly assigned with this application and incorporated herein by reference. This application is also related to the following U.S. patent applications, which are filed on even date herewith, commonly assigned with this application and incorporated herein by reference: 
     
       
         
           
               
               
               
             
               
                   
               
               
                 Serial No. 
                 Inventors 
                 Title 
               
               
                   
               
             
            
               
                 12/603,464 
                 Grohman, 
                 “Alarm and Diagnostics System and Method 
               
               
                   
                 et al. 
                 for a Distributed-Architecture Heating, 
               
               
                   
                   
                 Ventilation and Air Conditioning 
               
               
                   
                   
                 Network” 
               
               
                 12/603,534 
                 Wallaert, 
                 “Flush Wall Mount Control Unit and In- 
               
               
                   
                 et al. 
                 Set Mounting Plate for a Heating, 
               
               
                   
                   
                 Ventilation and Air Conditioning System” 
               
               
                 12/603,449 
                 Thorson, 
                 “System and Method of Use for a User 
               
               
                   
                 et al. 
                 Interface Dashboard of a Heating, 
               
               
                   
                   
                 Ventilation and Air Conditioning 
               
               
                   
                   
                 Network” 
               
               
                 12/603,382 
                 Grohman 
                 “Device Abstraction System and Method 
               
               
                   
                   
                 for a Distributed-Architecture Heating, 
               
               
                   
                   
                 Ventilation and Air Conditioning 
               
               
                   
                   
                 Network” 
               
               
                 12/603,526 
                 Grohman, 
                 “Communication Protocol System and 
               
               
                   
                 et al. 
                 Method for a Distributed-Architecture 
               
               
                   
                   
                 Heating, Ventilation and Air 
               
               
                   
                   
                 Conditioning Network” 
               
               
                 12/603,527 
                 Hadzidedic 
                 “Memory Recovery Scheme and Data 
               
               
                   
                   
                 Structure in a Heating, Ventilation and 
               
               
                   
                   
                 Air Conditioning Network” 
               
               
                 12/603,490 
                 Grohman 
                 “System Recovery in a Heating, 
               
               
                   
                   
                 Ventilation and Air Conditioning 
               
               
                   
                   
                 Network” 
               
               
                 12/603,473 
                 Grohman, 
                 “System and Method for Zoning a 
               
               
                   
                 et al. 
                 Distributed-Architecture Heating, 
               
               
                   
                   
                 Ventilation and Air Conditioning 
               
               
                   
                   
                 Network” 
               
               
                 12/603,525 
                 Grohman, 
                 “Method of Controlling Equipment in a 
               
               
                   
                 et al. 
                 Heating, Ventilation and Air 
               
               
                   
                   
                 Conditioning Network” 
               
               
                 12/603,512 
                 Grohman, 
                 “Programming and Configuration in a 
               
               
                   
                 et al. 
                 Heating, Ventilation and Air 
               
               
                   
                   
                 Conditioning Network” 
               
               
                 12/603,431 
                 Mirza, 
                 “General Control Techniques in a 
               
               
                   
                 et al. 
                 Heating, Ventilation and Air 
               
               
                   
                   
                 Conditioning Network” 
               
               
                   
               
            
           
         
       
     
    
    
     TECHNICAL FIELD 
     This application is directed, in general, to HVAC systems and, more specifically, to a system controller and methods of use thereof. 
     BACKGROUND 
     Climate control systems, also referred to as HVAC systems (the two terms will be used herein interchangeably), are employed to regulate the temperature, humidity and air quality of premises, such as a residence, office, store, warehouse, vehicle, trailer, or commercial or entertainment venue. The most basic climate control systems either move air (typically by means of an air handler having a fan or blower), heat air (typically by means of a furnace) or cool air (typically by means of a compressor-driven refrigerant loop). A thermostat is typically included in a conventional climate control system to provide some level of automatic temperature and humidity control. In its simplest form, a thermostat turns the climate control system on or off as a function of a detected temperature. In a more complex form, the thermostat may take other factors, such as humidity or time, into consideration. Still, however, the operation of a thermostat remains turning the climate control system on or off in an attempt to maintain the temperature of the premises as close as possible to a desired set point temperature. Climate control systems as described above have been in wide use since the middle of the twentieth century and have, to date, generally provided adequate temperature management. 
     SUMMARY 
     One aspect provides a method of manufacturing an HVAC data processing and communication network. In an embodiment, the method includes configuring a first system device and a subnet controller. The first system device is configured to receive an initial value of a specified dependent parameter. The subnet controller is configured to determine that a value of the specified dependent parameter has been changed to a modified value after the first system device receives the initial value. The subnet controller is further configured to send to the first system device, in response to the determining, a message updating the specified parameter with the modified value. 
     Another aspect provides a HVAC data processing and communication network. In an embodiment, the network includes a first system device and a subnet controller. The system device is configured to receive an initial value of a specified dependent parameter. The subnet controller is configured to determine that a value of the specified parameter has been changed to a modified value after the first system device receives the initial value. The subnet controller is further configured to send to the first system device, in response to the determining, a message updating the specified parameter with the modified value. 
     Yet another aspect provides a subnet controller. In an embodiment, the subnet controller includes a physical layer interface and a local controller. The physical layer interface is configured to couple to a data bus. The local controller is configured to receive messages via the data bus from a first and a second system device, and to determine from the received messages that an initial value of a specified dependent parameter supplied to the first system device by the second system device has been changed to a modified value after the first system device receives the initial value. The local controller is further configured to send to the first system device, in response to the determining, a message via the data bus updating the specified parameter with the modified value. 
    
    
     
       BRIEF DESCRIPTION 
       Reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: 
         FIG. 1  is a high-level block diagram of an HVAC system according to various embodiments of the disclosure; 
         FIG. 2  is a high-level block diagram of one embodiment of an HVAC data processing and communication network; 
         FIG. 3  is a block diagram of a local controller of the disclosure; 
         FIG. 4  is a block diagram of a networked HVAC system device of the disclosure; 
         FIG. 5  is a schematic diagram of a representative physical layer interface; 
         FIGS. 6A and 6B  illustrate example configurations of a networked HVAC system; 
         FIG. 7  illustrates a method of manufacturing an HVAC data processing and communication network; 
         FIG. 8  illustrates bus connections between two subnets; 
         FIG. 9  illustrates a method of manufacturing an HVAC data processing a communication network to display messages in one or more of a plurality of languages; 
         FIG. 10  illustrates an example protocol stack; 
         FIG. 11  is a method of conveying information related to relative humidity to a display screen; 
         FIG. 12  is a method of updating installer parameters; 
         FIG. 13  illustrates an example diagram of states of the HVAC system; 
         FIG. 14  is a method of automatically updating a device parameter; 
         FIG. 15  is a method of displaying parameter dependencies; and 
         FIG. 16  is a method of manufacturing the HVAC system. 
     
    
    
     DETAILED DESCRIPTION 
     As stated above, conventional climate control systems have been in wide use since the middle of the twentieth century and have, to date, generally provided adequate temperature management. 
     However, it has been realized that more sophisticated control and data acquisition and processing techniques may be developed and employed to improve the installation, operation and maintenance of climate control systems. 
     Described herein are various embodiments of an improved climate control, or HVAC, system in which at least multiple components thereof communicate with one another via a data bus. The communication allows identity, capability, status and operational data to be shared among the components. In some embodiments, the communication also allows commands to be given. As a result, the climate control system may be more flexible in terms of the number of different premises in which it may be installed, may be easier for an installer to install and configure, may be easier for a user to operate, may provide superior temperature and/or relative humidity (RH) control, may be more energy efficient, may be easier to diagnose, may require fewer, simpler repairs and may have a longer service life. 
       FIG. 1  is a high-level block diagram of a networked HVAC system, generally designated  100 . The HVAC system  100  may be referred to herein simply as “system  100 ” for brevity. In one embodiment, the system  100  is configured to provide ventilation and therefore includes one or more air handlers  110 . In an alternative embodiment, the ventilation includes one or more dampers  115  to control air flow through air ducts (not shown.) Such control may be used in various embodiments in which the system  100  is a zoned system. In an alternative embodiment, the system  100  is configured to provide heating and therefore includes one or more furnaces  120 , typically associated with the one or more air handlers  110 . In an alternative embodiment, the system  100  is configured to provide cooling and therefore includes one or more refrigerant evaporator coils  130 , typically associated with the one or more air handlers  110 . Such embodiment of the system  100  also includes one or more compressors  140  and associated condenser coils  142 , which are typically associated with one or more so-called “outdoor units”  144 . The one or more compressors  140  and associated condenser coils  142  are typically connected to an associated evaporator coil  130  by a refrigerant line  146 . In an alternative embodiment, the system  100  is configured to provide ventilation, heating and cooling, in which case the one or more air handlers  110 , furnaces  120  and evaporator coils  130  are associated with one or more “indoor units”  148 , e.g., basement or attic units that may also include an air handler. 
     For convenience in the following discussion, a demand unit  155  is representative of the various units exemplified by the air handler  110 , furnace  120 , and compressor  140 , and more generally includes an HVAC component that provides a service in response to control by the control unit  150 . The service may be, e.g., heating, cooling, humidification, dehumidification, or air circulation. A demand unit  155  may provide more than one service, and if so, one service may be a primary service, and another service may be an ancillary service. For example, for a heating unit that also circulates air, the primary service may be heating, and the ancillary service may be air circulation (e.g. by a blower). 
     The demand unit  155  may have a maximum service capacity associated therewith. For example, the furnace  120  may have a maximum heat output (often expressed in terms of British Thermal Units (BTU) or Joules), or a blower may have a maximum airflow capacity (often expressed in terms of cubic feet per minute (CFM) or cubic meters per minute (CMM)). In some cases, the demand unit  155  may be configured to provide a primary or ancillary service in staged portions. For example, blower may have two or more motor speeds, with a CFM value associated with each motor speed. 
     One or more control units  150  control one or more of the one or more air handlers  110 , the one or more furnaces  120  and/or the one or more compressors  140  to regulate the temperature of the premises, at least approximately. In various embodiments to be described, the one or more displays  170  provide additional functions such as operational, diagnostic and status message display and an attractive, visual interface that allows an installer, user or repairman to perform actions with respect to the system  100  more intuitively. Herein, the term “operator” will be used to refer collectively to any of the installer, the user and the repairman unless clarity is served by greater specificity. 
     One or more separate comfort sensors  160  may be associated with the one or more control units  150  and may also optionally be associated with one or more displays  170 . The one or more comfort sensors  160  provide environmental data, e.g. temperature and/or humidity, to the one or more control units  150 . An individual comfort sensor  160  may be physically located within a same enclosure or housing as the control unit  150 , in a manner analogous with a conventional HVAC thermostat. In such cases, the commonly housed comfort sensor  160  may be addressed independently. However, the one or more comfort sensors  160  may be located separately and physically remote from the one or more control units  150 . Also, an individual control unit  150  may be physically located within a same enclosure or housing as a display  170 , again analogously with a conventional HVAC thermostat. In such embodiments, the commonly housed control unit  150  and display  170  may each be addressed independently. However, one or more of the displays  170  may be located within the system  100  separately from and/or physically remote to the control units  150 . The one or more displays  170  may include a screen such as a liquid crystal or OLED display (not shown). 
     Although not shown in  FIG. 1 , the HVAC system  100  may include one or more heat pumps in lieu of or in addition to the one or more furnaces  120 , and one or more compressors  140 . One or more humidifiers or dehumidifiers may be employed to increase or decrease humidity. One or more dampers may be used to modulate air flow through ducts (not shown). Air cleaners and lights may be used to reduce air pollution. Air quality sensors may be used to determine overall air quality. 
     Finally, a data bus  180 , which in the illustrated embodiment is a serial bus, couples the one or more air handlers  110 , the one or more furnaces  120 , the one or more evaporator condenser coils  142  and compressors  140 , the one or more control units  150 , the one or more remote comfort sensors  160  and the one or more displays  170  such that data may be communicated therebetween or thereamong. As will be understood, the data bus  180  may be advantageously employed to convey one or more alarm messages or one or more diagnostic messages. All or some parts of the data bus  180  may be implemented as a wired or wireless network. 
     The data bus  180  in some embodiments is implemented using the Bosch CAN (Controller Area Network) specification, revision 2, and may be synonymously referred to herein as a residential serial bus (RSBus)  180 . The data bus  180  provides communication between or among the aforementioned elements of the network  200 . It should be understood that the use of the term “residential” is nonlimiting; the network  200  may be employed in any premises whatsoever, fixed or mobile. Other embodiments of the data bus  180  are also contemplated, including e.g., a wireless bus, as mentioned previously, and 2-, 3- or 4-wire networks, including IEEE-1394 (Firewire™, i.LINK™, Lynx™), Ethernet, Universal Serial Bus (e.g., USB 1.x, 2.x, 3.x), or similar standards. In wireless embodiments, the data bus  180  may be implemented, e.g., using Bluetooth™, Zibgee or a similar wireless standard. 
       FIG. 2  is a high-level block diagram of one embodiment of an HVAC data processing and communication network  200  that may be employed in the HVAC system  100  of  FIG. 1 . One or more air handler controllers (AHCs)  210  may be associated with the one or more air handlers  110  of  FIG. 1 . One or more integrated furnace controllers (IFCs)  220  may be associated with the one or more furnaces  120 . One or more damper controller modules  215 , also referred to herein as a zone controller module  215 , may be associated with the one or more dampers  115 . One or more unitary controllers  225  may be associated with one or more evaporator coils  130  and one or more condenser coils  142  and compressors  140  of  FIG. 1 . The network  200  includes an active subnet controller (aSC)  230   a  and an inactive subnet controller (iSC)  230   i . The aSC  230   a  may act as a network controller of the system  100 . The aSC  230   a  is responsible for configuring and monitoring the system  100  and for implementation of heating, cooling, humidification, dehumidification, air quality, ventilation or any other functional algorithms therein. Two or more aSCs  230   a  may also be employed to divide the network  200  into subnetworks, or subnets, simplifying network configuration, communication and control. Each subnet typically contains one indoor unit, one outdoor unit, a number of different accessories including humidifier, dehumidifier, electronic air cleaner, filter, etc., and a number of comfort sensors, subnet controllers and user interfaces. The iSC  230   i  is a subnet controller that does not actively control the network  200 . In some embodiments, the iSC  230   i  listens to all messages broadcast over the data bus  180 , and updates its internal memory to match that of the aSC  230   a . In this manner, the iSC  230   i  may backup parameters stored by the aSC  230   a , and may be used as an active subnet controller if the aSC  230   a  malfunctions. Typically there is only one aSC  230   a  in a subnet, but there may be multiple iSCs therein, or no iSC at all. Herein, where the distinction between an active or a passive SC is not germane the subnet controller is referred to generally as an SC  230 . 
     A user interface (UI)  240  provides a means by which an operator may communicate with the remainder of the network  200 . In an alternative embodiment, a user interface/gateway (UI/G)  250  provides a means by which a remote operator or remote equipment may communicate with the remainder of the network  200 . Such a remote operator or equipment is referred to generally as a remote entity. A comfort sensor interface  260 , referred to herein interchangeably as a comfort sensor (CS)  260 , may provide an interface between the data bus  180  and each of the one or more comfort sensors  160 . The comfort sensor  260  may provide the aSC  230   a  with current information about environmental conditions inside of the conditioned space, such as temperature, humidity and air quality. 
     For ease of description, any of the networked components of the HVAC system  100 , e.g., the air handler  110 , the damper  115 , the furnace  120 , the outdoor unit  144 , the control unit  150 , the comfort sensor  160 , the display  170 , may be described in the following discussion as having a local controller  290 . The local controller  290  may be configured to provide a physical interface to the data bus  180  and to provide various functionality related to network communication. The SC  230  may be regarded as a special case of the local controller  290 , in which the SC  230  has additional functionality enabling it to control operation of the various networked components, to manage aspects of communication among the networked components, or to arbitrate conflicting requests for network services among these components. While the local controller  290  is illustrated as a stand-alone networked entity in  FIG. 2 , it is typically physically associated with one of the networked components illustrated in  FIG. 1 . 
       FIG. 3  illustrates a high-level block diagram of the local controller  290 . The local controller  290  includes a physical layer interface (PLI)  310 , a non-volatile memory (NVM)  320 , a RAM  330 , a communication module  340  and a functional block  350  that may be specific to the demand unit  155 , e.g., with which the local controller  290  is associated. The PLI  310  provides an interface between a data network, e.g., the data bus  180 , and the remaining components of the local controller  290 . The communication module  340  is configured to broadcast and receive messages over the data network via the PLI  310 . The functional block  350  may include one or more of various components, including without limitation a microprocessor, a state machine, volatile and nonvolatile memory, a power transistor, a monochrome or color display, a touch panel, a button, a keypad and a backup battery. The local controller  290  may be associated with a demand unit  155 , and may provide control thereof via the functional block  350 , e.g. The NVM  320  provides local persistent storage of certain data, such as various configuration parameters, as described further below. The RAM  330  may provide local storage of values that do not need to be retained when the local controller  290  is disconnected from power, such as results from calculations performed by control algorithms. Use of the RAM  330  advantageously reduces use of the NVM cells that may degrade with write cycles. 
     In some embodiments, the data bus  180  is implemented over a 4-wire cable, in which the individual conductors are assigned as follows: 
     R—the “hot”—a voltage source, 24 VAC, e.g. 
     C—the “common”—a return to the voltage source. 
     i+—RSBus High connection. 
     i−—RSBus Low connection. 
     The disclosure recognizes that various innovative system management solutions are needed to implement a flexible, distributed-architecture HVAC system, such as the system  100 . More specifically, cooperative operation of devices in the system  100 , such as the air handler  110 , outdoor unit  144 , or UI  240  is improved by various embodiments presented herein. More specifically still, embodiments are presented of treating HVAC components abstractly in a manner that decouples the HVAC physical layer from the HVAC logical or network layer. In many cases, more sophisticated control of the HVAC system is possible than in conventional systems, allowing expanded feature availability to the user and more efficient operation of the system. 
       FIG. 4  illustrates a system device  410  according to the disclosure. The system device  410  may be referred to briefly herein as a “device  410 ” without any loss of generality. The following description pertains to the HVAC data processing and communication network  200  that is made up of a number of system devices  410  operating cooperatively to provide HVAC functions. Herein after the system device  410  is referred to more briefly as the device  410  without any loss of generality. The term “device” applies to any component of the system  100  that is configured to communicate with other components of the system  100  over a wired or wireless network. Thus, the device  410  may be, e.g., the air handler  110  in combination with its AHC  210 , or the furnace  120  in combination with its IFC  220 . This discussion may refer to a generic device  410  or to a device  410  with a specific recited function as appropriate. An appropriate signaling protocol may be used to govern communication of one device with another device. While the function of various devices  410  in the network  200  may differ, each device  410  shares a common architecture for interfacing with other devices, e.g. the local controller  290  appropriately configured for the HVAC component  420  with which the local controller  290  is associated. The microprocessor or state machine in the functional block  350  may operate to perform any task for which the device  410  is responsible, including, without limitation, sending and responding to messages via the data bus  180 , controlling a motor or actuator, or performing calculations. 
     In various embodiments, signaling between devices  410  relies on messages. Messages are data strings that convey information from one device  410  to another device  410 . The purpose of various substrings or bits in the messages may vary depending on the context of the message. Generally, specifics regarding message protocols are beyond the scope of the present description. However, aspects of messages and messaging are described when needed to provide context for the various embodiments described herein. 
       FIG. 5  illustrates one embodiment of the PLI  310 . The PLI  310  includes a CAN-enabled microcontroller  510 , a CAN transceiver  520 , and a termination and protection circuit  530 . The transceiver  520  constantly monitors the RSbus  180 , including during the transmission of its own messages. In many cases, this ability of the transceiver  520  to monitor itself is advantageous to determining a corrective action taken by the device  410  when arbitration is lost during a message arbitration phase of bus communication, or when an error condition occurs. 
     In some embodiments, up to four subnets may be connected to a single RSbus  180 . Typically one aSC  230   a  is connected to the RSBus  180  for each subnet. For embodiments in which multiple subnet controllers  230  are present in a single subnet, one of the subnet controllers is typically designated as the aSC  230   a  and controls the subnet. Thus, in such embodiments there may be up to four active subnet controllers on the RSbus  180 . The total number of devices  410  is typically limited by design choices to a maximum value. In some embodiments, the number of devices  410  connected to the RSBus  180  at any given time is limited to 32. Those skilled in the art will appreciate that the limit may be greater or fewer than 32. Moreover, while an integer power of 2 may be chosen for convenience, the number of devices  410  is not limited to numbers in this set. 
     The PLI  310  includes resistors R 1  and R 2 . In an example embodiment, R 1  and R 2  are 60V-rated Positive Temperature Coefficient resistors and work as resettable fuses. Illustrative resistors include RXE010 by Raychem (Tyco), MF-R010 by Bourns, or 3610100600 by Wickmann, or equivalent. A resistor R t  may be a 1% metal film resistor. R t  provides a complement termination resistance to the differential input i+/i−. R 1 , R t  and R 2  form a series resistance R term  at the differential input that provides a termination resistance to i+/i−. The value of R term  may be different for different devices  410 . A capacitor C 1  provides EMI decoupling of the differential input. 
     Diodes D 1 , D 2 , D 3  and D 4  provide transient voltage suppression. In an example, D 1  D 2 , D 3  and D 4  rated at 10V, 600 W. D 5  is an optional LED that provides visual feedback that the device  410  is capable of receiving a bus message. D 5  may be advantageously located adjacent a connector that receives i+/i− on each device  410 . In some embodiments, R 1 , R 2 , D 1 , D 2 , D 3 , and D 4  are not used when an appropriately configured transceiver  520  is used. 
     It should be noted that a CAN transceiver, e.g., the transceiver  520 , can draw significantly more current from V cc  when it is transmitting a dominant bit than when it is idle. Good design practice takes the peak load of the transceiver  520  into account when providing power thereto. In some embodiments, V cc  is 5V or greater to allow for the recessive state of the RSbus  180  to be 2.5V. 
     The RSbus  180  provides the ability to connect multiple HVAC systems, e.g., multiple instances of the system  100 , together on one bus. When done, it is preferred that the connection between the systems  100  is made at a central interior location such as the furnace  120 . It is also preferred in these embodiments to only connect i+/i− from each system  100 , while leaving the R and C wires unconnected. This approach recognizes that each system  100  typically provides at least one separate transformer to power the R and C lines associated with that system  100 . The transformer is typically located with an indoor unit such as the furnace  120  and also earth grounded there so it will often be convenient and most robust to connect the several data busses  180  at the location of the furnaces  120  associated with the several systems  100 . 
     Each device  410  may be configured to transmit data on the RSbus  180  at one or more data rates. In some embodiments, the devices  410  may be configured to use a selected one of a plurality of data rates that the device  410  is capable of supporting. For example, the device  410  may be configurable to communicate at about 10 k baud, 20 k baud, 33.3 k baud, 40 k baud, 50 k baud, 62.5 k baud, 83.3 k baud, 100 k baud and 125 k baud. In some embodiments, the network transmission speed is configured to be about 40 k baud as a balance between transmission speed and reliability. 
     Communication between the devices  410  is generally governed by a communication protocol. An example of a suitable protocol is provided by the Bosch CAN network as defined by the Bosch CAN2.0B standard. While it is recognized that any suitable communications standard is contemplated by the disclosure, this description refers without limitation to various example embodiments using the Bosch CAN standard. 
     The network allows for Peer-to-Peer (PTP) communication. Each device  410  may communicate with another device  410  via a message. The Bosch standard provides, for example, a 29-bit message identifier which allows for up to 2 29  (536,870,912) unique messages to be defined and used. Thus a master bus controller is typically unnecessary. However, in various embodiments the SC  230  controls HVAC functionality, stores configurations, and assigns addresses during system auto configuration, e.g. 
     In various embodiments, it may be convenient or may significantly simplify system design to use various levels of abstraction with respect to components and data structures used in the system  100 . Such abstraction may simplify design and specification of the system  100 , and may provide a basis for communication between designers and between a system manufacturer and installers or users of the system  100 . 
     In an advantageous embodiment, the network  200  is configured so that each device on the RSBus  180  is a logical device. A logical device is a device that may be independently addressed for communication purposes within the network  200 . A particular logical device may or may not be physically co-located with another logical device. Thus in some cases a device, for example without limitation the comfort sensor  260 , may be embodied in a standalone physical device. In other cases the device may be a “virtual” device, meaning the device is an integral part of a combination with another logical device while remaining independently addressable. In one aspect, independently addressable devices are regarded as being coupled independently to the data bus  180 . As a nonlimiting example, a comfort sensor  260  may be integrated with a subnet controller  230 . Each of the comfort sensor  260  and the subnet controller  230  are separate logical devices, though the combination may appear as a single physical entity. 
     In one embodiment of the disclosure, the system  100  includes a logical subnet controller (LSC). In general, the subnet controller  230  is a logical part of a physical device  410  on the network  200 . Functions of the SC may include configuration of the system  100  and implementation of an HVAC control algorithm. The SC  230  may store system configuration information. In various embodiments, the SC  230  is physically located in an enclosure that also includes one or both of a comfort sensor  260  and a UI  240 . However, the SC  203  may be placed with any other device  410  in the network  200 . If the network  200  includes more than one SC  230 , a negotiation algorithm may determine which controller acts as the active subnet controller  230   a . Those SC  230  that are not active may operate in a listen-only mode. The LSC is a virtual device that may be defined for any device  410 . In some embodiments, it is preferred that the LSC is co-located with the UI  240 . 
       FIG. 6A  illustrates an example of an HVAC system subnet  600 A. The subnet  600 A includes four devices configured to communicate over a communication bus  610 . In various embodiments the communication bus  610  is an RSBus. The subnet  600 A includes an indoor unit illustrated without limitation as an instance of the IFC  220 , an instance of the aSC  230   a , an instance of the UI  240 , and an instance of the comfort sensor  260 . These networked devices form a subnet. The UI  240  allows an operator to interact with the networked devices, set temperature set points, etc. The comfort sensor  260  provides temperature information to other devices on the subnet  600 A. The comfort sensor  260  may include, e.g., a transducer that converts a temperature or RH to an electrical signal for further processing. The active subnet controller  230   a  provides overall control to the subnet  600 A. 
     The subnet  600 A illustrates a typical minimum set of functional elements of a networked HVAC system of the disclosure, e.g., a controlling device, a controlled device, a feedback device and an operator interface. For example, in a temperate climate, a residential HVAC system may have a means to heat the residence, but may not require cooling. Thus, the furnace  120  may be sufficient to maintain year-round comfort in the residence. Other minimum HVAC systems are possible, as will be apparent to one skilled in the pertinent art. For example, the IFC  220  could be replaced by heat pump controller, or the UI  240  could be replaced by the UI/G  250  to provide remote programmability. 
       FIG. 6B  illustrates an embodiment of a more general case of a subnet, here designated  600 B. In addition to the components of the subnet  600 A, the subnet  600 B includes an outdoor unit  144  and associated controller. The outdoor unit  144  may be, e.g., a heat pump or an air conditional compressor/condenser unit. An instance of the outdoor sensor  270  may be installed to provide outdoor temperature or humidity data to the aSC  230   a  for use in a control algorithm, e.g. An instance of the UI/G  250  may provide an interface between the subnet  600 B and an external communication network, e.g. the internet. Such connectivity provides a means for control, configuration or data collection to an external entity such as an installer or manufacturer. 
       FIG. 7  illustrates a method of the disclosure, generally denoted  700 , of manufacturing an HVAC data processing and communication network, such as the network  200 . The method  700  is described without limitation with reference to components of the network  200 . The method  700  begins with a step  710  that may be entered from any appropriate state of the system  100 . In a step  720 , a controller, e.g., the SC  230 , is configured to control the device  410  via the data bus  180 . In a step  725 , the SC  230  is configured to be addressed over the data bus  180 . In a step  730 , an environmental sensor, e.g. the comfort sensor  260 , is configured to provide environmental data to the SC  230  via the data bus  180 . In an optional step  740 , the comfort sensor  260  is further configured to be addressed via the data bus  180  independently of the SC  230 . For example, the SC  230  and the comfort sensor  260  may have different equipment type numbers that are used to direct messages over the data bus  180 . In a step  750 , a user interface, e.g., the UI  240  or the UI/G  250 , is configured to provide access by an operator to the network  200 . For example, the UI  240  may allow manual parameter entry via a screen, and the UI/G may allow parameter entry via a desktop computer configured with appropriate software. In a step  760 , the user interface is configured to be addressed via the data bus  180  independently of the SC  230  and the comfort sensor  260 . Again, the user interface may be configured to have an equipment type number. The method  700  ends with a step  770 . 
     Each of active subnet controller  230   a , user interface  240  and comfort sensor  260  can be embodied in an individual autonomous unit that may be coupled with the communication bus  610  anywhere within the structure, e.g., residence, in which the subnet  600 A is installed. Thus, the subnet controller  230   a , the user interface  240  and the comfort sensor  260  are not necessarily located together or even within the same indoor space. Alternatively, any two or more of subnet controller  230   a , user interface  240  and comfort sensor  260  may be combined in a single physical control unit  620  and the remaining, if any, of the aSC  230   a , user interface  240  and comfort sensor  260  may be an individual autonomous unit. In this alternate embodiment, the combined unit (i.e., any two or more of the aSC  230   a , user interface  240  and comfort sensor  260 ) and the remaining, if any, of the aSC  230   a , user interface  240  and comfort sensor  260  may be coupled with the communication bus  610  anywhere within the subnet  600 A. Whether or not any two or more of the aSC  230   a , user interface  240  and comfort sensor  260  are combined in a single physical unit, the aSC  230   a , user interface  240  and comfort sensor  260  are logically separate devices as far as communication on the communication bus  610  is concerned. Similarly, the user interface  240  and comfort sensor  260  are logically separate devices as far as communication on the bus  610  is concerned. They may be housed together in the control unit  620 , as shown in  FIG. 6A , or may be housed in separate physical units. 
     As described previously, the aSC  230   a  may control HVAC functionality, store configurations, and assign addresses during system auto configuration. The user interface  240  provides a communication interface to provide information to and receive commands from an operator. The comfort sensor  260  may measure one or more environmental attributes that affect user comfort, e.g., ambient temperature, relative humidity (RH) and pressure. The three logical devices  230   a ,  240 ,  260  each send and receive messages over the communication bus  610  to other devices attached thereto, and have their own addresses on the subnet  600 A. In many cases, this design feature facilitates future system expansion and allows for seamless addition of multiple sensors or user interfaces on the same subnet. For example, an upgraded subnet controller may be provided with a replacement indoor unit. The upgraded subnet controller may automatically take over operation of the subnet without removal of a previously existing subnet controller. The aSC  230   a  may be upgraded, e.g., via a firmware revision. The aSC  230   a  may also be configured to release control of the subnet  600 A and effectively switch off should another subnet controller present on the subnet  600 A request it. 
     In another more generalized example, a system device  410  is preloaded with feature or parameter data associated with another system device  410 . For instance, a replacement system device  410  may include feature or parameter data associated with a demand unit  155 , e.g. the furnace  120 . The replacement device  410  in some cases may be an SC  230  included with a replacement demand unit  155 . In various embodiments the replacement system device  410  replaces a similar system device  410 . For example, a similar device  410  may be a UI  240  replacing a UI  240 , an SC  230  replacing an SC  230 , etc. 
     In some cases, the replacement system device  410  may replace a UI  240 . The replacement UI  240  may include feature or parameter data associated with the demand unit  155 . The feature or parameter data may include, e.g., parameter values, definitions and strings associated with operation of the demand unit  155 . The feature or parameter data held by the replacement UI  240  may provide updates to functionality provided by the demand unit  155 , e.g. 
     The aSC  230   a  may be configured to publish a first message to the demand unit  155  instructing the demand unit  155  to publish at least some of the feature or parameter data stored thereby when the replacement UI  240  is installed in the system  100 . In various embodiments, the first message is published during a commissioning process of the system  100 . In some cases, the aSC  230   a  is configured to instruct the demand unit  155  to publish only those feature or parameter data not preloaded on the replacement UI  240 . The aSC  230   a  may publish one or more messages instructing the replacement UI  240  to publish the preloaded data so the demand unit  155  can determine those features or parameter data not included in the preloaded data set. 
     Configuring the control unit  620  as logical, independently addressable blocks advantageously provides flexibility in the configuration of the subnet  600 A. System control functions provided by the aSC  230   a  may be placed in any desired physical device, in this example the control unit  620 . Alternatively, e.g., the aSC controller  230   a  could be placed within a physical enclosure of the furnace  120 , while maintaining independent addressability. The location of these control functions within any particular physical enclosure need not affect other aspects of the subnet  600 A. This abstraction provides for seamless upgrades to the subnet  600 A and ensures a high degree of backward compatibility of the devices present in the network. The approach provides for centralized control of the system, without sacrificing flexibility or incurring large system upgrade costs. 
     For example, the use of the logical aSC  230   a  provides a flexible means of including multiple control units  150  on a same network in a same conditioned space. The HVAC system, e.g., the system  100 , may be easily expanded. The system retains backward compatibility, meaning the subnet  600 A may be updated with a completely new type of equipment without the need to reconfigure the system. Moreover, the functions provided by the subnet controller may be logically placed in any physical device, not just the control unit  620 . In some cases, where an upgrade requires subnet controller functionality not provided by a subnet controller already present in the system  100 , a new subnet controller may be installed in the system  100  without the need to remove a previously installed subnet controller. In some cases, the new subnet controller may be installed, if desired, in new or replacement equipment. Thus, for example, a replacement furnace having functionality not supported by an installed subnet controller may have an upgraded subnet controller having the necessary functionality installed within the furnace enclosure. When the furnace is installed in the HVAC system  100 , the subnet controller within the furnace may take control of the subnet on which the new furnace is installed, thereby providing the overall system functionality required by the new furnace. The physical separability of the active subnet controller  230   a , the user interface  240 , and the comfort sensor  260  also provides the manufacturer of the subnet  600 A greater flexibility in selecting these devices, from various suppliers. 
       FIG. 8  illustrates a detailed connection diagram of components of a network  800  according to one embodiment of the disclosure. The network  800  includes a subnet  810  and a subnet  850 . The subnet  810  includes an air conditioning (AC) unit  815 , a UI/G  820 , an outside sensor (OS)  825 , a furnace  830 , and a control unit  835 . The control unit  835  may house an aSC  230   a , a user interface  240  and a comfort sensor  260 , each of which is independently addressable via a data bus  180   a . The subnet  850  includes a furnace  855 , a heat pump  860  and a control unit  865 . The control unit  865  houses an aSC  230   a , a user interface  240  and a comfort sensor  260 , each of which is independently addressable via a data bus  180   b . In various embodiments and in the illustrated embodiment each individual subnet, e.g., the subnets  810 ,  850 , are each configured to be wired as a star network, with connections to all devices therein made at a furnace or air handler associated with that subnet. Thus, e.g., each of the devices  815 ,  820 ,  825 ,  835  is connected to the data bus  180   a  at the furnace  830 . Similarly, each device  860 ,  865  is connected to the subnet  850  at the furnace  855 . Each furnace  830 ,  855 , generally representative of the indoor unit  148 , may include a connection block configured to accept a connection to the RSBus  180 . For example, two terminals of the connection block may be 4-pin connectors. In one embodiment, one 4-pin connector is dedicated to connecting to an outdoor unit, for example the connection from the furnace  830  to the AC unit  815 . Another 4-pin connector is used to connect to equipment other than the outdoor unit, e.g., from the furnace  830  to the UI/G  820 , the OS 825, and the control unit  835 . A third connector may be a 2-pin connector configured to connect one subnet to another subnet. In the network  800 , e.g., the subnet  810  is connected to the subnet  850  via a wire pair  870  that carries the i+/i− signals of the serial bus. As described previously with respect to the furnace  120 , a transformer located at the furnace  830  may provide power to the various components of the subnet  810 , and a transformer located at the furnace  855  may provide power to the various components of the subnet  850  via R and C lines. As illustrated, the C line may be locally grounded. 
     The description now turns to aspects of configuration of devices on the RSBus  180  ( FIG. 2 ). Each system device  410  is configured to include various data useful in configuration and management of the system  100 . The data may be stored, e.g., in nonvolatile memory located on the system device  410 , e.g., the NVM  320 . Stored parameters may include one or more of those listed in Table I below, wherein some parameters are shown with a brief description of the purpose thereof. Each system device  410  is preferably configured with these parameters by a manufacturer/supplier of the system device  410  prior to delivery to a system integrator/installer. 
     
       
         
           
               
               
             
               
                 TABLE 1 
               
               
                   
               
               
                 Parameter 
                 Detail 
               
               
                   
               
             
            
               
                 Control Serial Number 
                   
               
               
                 Control Part Number 
                   
               
               
                 Software Revision Number 
                   
               
               
                 Hardware Revision Number 
                   
               
               
                 Device Designator 
                 A unique number, containing 
               
               
                   
                 control&#39;s MAC layer 
               
               
                   
                 address. 
               
               
                 Protocol Revision Number 
                 The revision of the RSBus 
               
               
                   
                 specification that the 
               
               
                   
                 device conforms to. 
               
               
                 The name of all device alarms in 
                   
               
               
                 ASCII text format in all languages 
                   
               
               
                 supported. 
                   
               
               
                 The text for all User Messages used 
                   
               
               
                 in ASCII and/or Unicode text format 
                   
               
               
                 in all languages supported. 
                   
               
               
                 Equipment Type name encoded in 
                   
               
               
                 ASCII and/or Unicode text format in 
                   
               
               
                 all languages supported. 
                   
               
               
                 The name of all supported features 
                   
               
               
                 and parameters in ASCII and/or 
                   
               
               
                 Unicode text format in all 
                   
               
               
                 languages supported. 
               
               
                   
               
            
           
         
       
     
     The system device  410  may optionally be configured to include the parameters shown in Table 2 either by the manufacturer/supplier or by the integrator/installer. 
     
       
         
           
               
               
             
               
                 TABLE 2 
               
               
                   
               
               
                 Parameter 
                 Detail 
               
               
                   
               
             
            
               
                 Device Product Level 
                 Designation of the device&#39;s 
               
               
                   
                 position in the integrator&#39;s 
               
               
                   
                 product line. 
               
               
                 Equipment Part Number 
                 A part number of HVAC equipment 
               
               
                   
                 in which the device is 
               
               
                   
                 installed. 
               
               
                 Equipment Serial Number 
                 A serial number of HVAC 
               
               
                   
                 equipment in which the device 
               
               
                   
                 is installed. 
               
               
                 Unit Capacity 
                 A thermal capacity of the HVAC 
               
               
                   
                 equipment in which the control 
               
               
                   
                 is installed. 
               
               
                   
               
            
           
         
       
     
     In various embodiments, one or more of the following design features may be employed in the system device  410 . Implementation of these features is within the ability of those skilled in the pertinent art. As described earlier, the system device  410  includes the NVM  320 . Such memory may be used for various purposes, such as alarms or parameter storage. The device may be configured by the manufacturer to default to subnet 0, and have a subnet priority set to 0. The device  410  may be configured to write, read and erase the NVM  320 . Of course this list of design features is not exclusive of other design features within the scope of the disclosure. 
     Each device  410  may be configured to store various data in its NVM  320 , including without limitation: parameter values pertaining to that particular device  410 ; relevant parameters pertaining to features or parameters of other devices  410  on the subnet; a value uniquely identifying the device  410  on the subnet (subnet ID); and a value identifying the equipment type of the device  410 . 
     The following data may also be stored by the NVM  320 , though the need for persistent storage may be less than the aforementioned parameters: 
     Any relevant parameter values of other devices  410  in the subnet or other subnets 
     Data associated with any feature/functions provided by the device  410   
     The aforementioned parameters are generally regarded as privileged or critical to the intended operation of the device  410 . It is thus generally preferred that these parameters be clearly separated from other information that may be stored in the NVM  320 , such as current alarms, diagnostic information, statistics, etc. The privileged/critical parameters may also be protected by a checksum and/or CRC so that the integrity of these data can be confirmed upon powering up the device  410 . In some cases, the SC  230  has separate CRCs for each device data backup. This enables the SC  230  to recover specific devices independently if needed when acting as the aSC  230   a.    
     Each device  410  typically has a receive buffer to accommodate transfer protocol data transfers. The buffer may be provided, e.g., by the RAM  330 . It may be preferred that the buffer be at least 256 bytes deep. The needed depth may be significantly greater for a device that supports multi-channel transfer protocol. 
     In some cases, the device  410  may provide textual information to a user in the form of informational, alert and/or alarm strings. Such functionality may be provided, e.g., by the UI  240 , but a display may be included on any device  410  as desired. The system  100  may be implemented to support any written language desired. Typically, the choice of language is driven by market factors. Thus, in the North American market, the system may be configured to support English, Spanish and/or French. One language, e.g. English, may be selected as a primary/default language, with the system  100  providing any number of optional secondary languages upon a user action to select the secondary language desired for a particular locus. Thus, each user interface  240  or UI/G  250  to the system can be configured in a different language, as desired by the local device operator. Multiple user interfaces  240  and UI/Gs  250  can co-exist, each using a different language. Thus, for example, one UI  240  located at a first location in a premises may display messages in English, while another UI  240  in the same or a different subnet and located at a second different location in the premises may display messages in Spanish. 
     Each device may include character string representations of its alarms, parameter, feature, user messages, etc. encoded in all supported languages and stored in the NVM  320 . Additionally, the UI/G  250  may locally store names of supported alarms, parameter and feature sets in one or all supported languages. Local storage advantageously reduces the amount of traffic on the network and facilitates quicker interfacing with the user. 
     In an embodiment, a plurality of user messages are identified by unique numbers, referred to herein as text IDs. The user messages are stored as character strings. A text ID may be used as a pointer to a character string stored in memory. The actual text strings associated with the text IDs may be customized for a particular language configuration. A particular message may be regarded as being any character string that conveys a particular concept. For example, the concept “comfort sensor error” may be rendered in any number of written languages, but each rendering is the same message, because each conveys the concept rendered in English as “comfort sensor error.” 
     The plurality of stored character strings may include a number of different messages, each being rendered in at least one, but typically two or more languages. The message strings can be stored on the UI  240  or in another device  410 . When the UI  240  is to display a character string in a given language, it may issue a request that includes a text ID corresponding to that message to the device  410  on which the character string corresponding to that message is stored. A language ID value may also be sent to identify the desired language. The device  410  that receives the request may then provide the requested string, e.g., the desired message rendered in the desired language, over the RSBus  180 . The character string may then be displayed by the UI  240 . Optionally, the character string may be buffered by the UI  240 , e.g., in the RAM  330 , or may be stored locally by the UI  240  so retrieval from another device  410  is not necessary. 
       FIG. 9  illustrates a method generally designated  900  of manufacturing an HVAC data processing a communication network to display messages in one or more of a plurality of languages. The method  900  is described without limitation with reference to components of the network  200 . The method  900  begins with a step  910  that may be entered from any appropriate state of the system  100 . In a step  920 , the device  410  is configured to store a plurality of character strings. The strings may include, e.g., status or error messages. In a step  930 , the device  410  is further configured to associate a text ID with each of the character strings. In a step  940  the device is further configured to recall a predetermined character string in response to receiving a first message, via the network  200 , that includes a predetermined text ID associated with the predetermined character string. In some embodiments, the first message also includes a language ID. In a step  950  the device is further configured to send, via the network, a second message including the predetermined character string. The second message may be received, e.g., by the UI  240  and displayed thereby. The method  900  ends with state  960  from which a calling routine may resume operation. 
     The system  100  may be configured to limit allowed configurations of devices  410 . For example, it may be determined that certain configurations of the system  100  are undesirable or incompatible with proper operation of the various devices  410 . In various embodiments, initialization of the system  100  includes a commissioning operation in a commissioning state in which the various devices  410  in the subnet are assigned credentials to operate on the subnet. The aSC  230   a  may be configured to ignore a request made during the commissioning state from a device  410  outside a permitted configuration set from registering with the SC  230  to prevent undesired or unpredictable operation that might otherwise result. 
     In some cases, the aSC  230   a  is configured to allow only one instance of a type of device  410  to operate on a subnet. For example, the following device  410  types are generally limited to a single instance in the system  100 : a furnace, a coil blower (a.k.a. an air handler), a twinning kit, and a furnace equipment interface module. In some cases, e.g., this limitation results in exclusion of a system  100  configured with a furnace and a coil blower, or with two furnaces (without the twinning kit). The aSC  230   a  may be configured to register only one instance of these devices on the network subnet, optionally in the following order: twinning kit, furnace, coil blower, and furnace equipment interface module. 
     Generally, it is also desirable to limit the system  100  to include only one outdoor unit per subnet, e.g., the condenser coils/compressor  140 , unless a twinning kit is used. Thus, e.g., a system  100  operating with a single subnet may be configured to exclude a configuration that includes a separate air conditioner and a heat pump/air conditioner. The aSC  230   a  may be configured to register only one of these devices on the subnet, and to optionally do so in the following order: heat pump/air conditioner, stand-alone air conditioner, and dual-fuel interface module. 
     As described earlier, the number of physical devices may be limited to a desired number, e.g., 32. However, such limitations may not be necessary with respect to logical devices. In some embodiments, there is no limit on number of logical devices in each physical device, other than a limit imposed by address space in a message string. 
     HVAC functions performed by the devices  410  may be classified into groups called services. A service is a distinct function performed by the system  100  with a goal to provide certain functionality to the user. In most cases, this functionality includes maintaining a temperature, and optionally an RH, in the conditioned space. 
     The devices  410  may be configured to implement a protocol referred to herein and in the claims as an RSBus Protocol Stack.  FIG. 10  illustrates an example protocol stack, generally designated  1000 . It may be preferable from the viewpoint of a system integrator that component suppliers comply with the architecture embodied by the RSBus Protocol Stack to improve quality of system testing and product reliability. 
     An application  1010  interacts with the protocol stack  1000 . The application  1010  may be an HVAC application, e.g., a set of control routines, running the aSC  230   a  to operate the system  100  to maintain a temperature of a living area. The interface between the application  1010  and the stack  1000  may be implemented using three function calls, e.g., as follows: 
     a send function  1012  initiated by the application  1010  to allow sending data on the data bus  180 , or requesting data from the data bus  180 , 
     a callback function  1014  initiated by the stack  1000  to inform the application  1010  of a relevant event, and 
     a control/status function  1016  initiated by the application  1010  to check or change the state of the stack  1000 . 
     The stack  1000  consists of four layers. A first layer  1020  is an RSBus abstraction layer. In the layer  1020  specific data are translated into manageable function calls. The layer  1020  may be associated with dedicated resources  1025 , including RAM and NVM. A second layer  1030  is a network layer. The layer  1030  may be implemented by a network protocol such as CAN, and may be based on an appropriate standard such as ISO-15765-2. The layer  1030  may be associated with dedicated resources  1035 , including RAM and NVM. A third layer  1040  is a data link layer. The layer  1040  may be implemented by a data link protocol such as CAN, and may include a microprocessor CAN cell, CAN driver software, and may include bus transmission error handling. The layer  1040  may be associated with dedicated resources  1045 , including RAM and NVM. A fourth layer  1050  is a physical layer. The layer  1050  includes such physical elements as bus wires, RSBus connectors, the RSBus interface circuit such as the circuit  530 , and CAN transceivers such as the transceiver  520 . 
     Turning now to  FIG. 11 , illustrated is a method generally designated  1100  of conveying information related to relative humidity to a display screen. In some embodiments the method is used in a diagnostic mode of the system  100 . A method of manufacturing the system  100  may include configuring appropriate components thereof to implement the method  1100 . The method  1100  is illustrative of acquisition and display of data by the UI  240 . In a step  1110 , a device  410  that includes a means of capturing a parameter of interest acquires the parameter value. For example, a device  410  may include a temperature and RH sensor. The device  410  acquires the current ambient temperature and RH and in a step  1120  forms a message including the temperature and RH data. In a step  1130  the device  410  publishes the message on the RSBus  180 . The publishing may be in response to a periodic update schedule, e.g., every minute. The device  410  may optionally include data indicating that the temperature or RH value is an indoor or an outdoor value. In a step  1140 , the UI  240  reads the message. The UI  240  may be configured to monitor all messages from the device  410  and parse the messages to determine a course of action. In the current example, the UI  240  determines that the message includes temperature and/or humidity, and whether the data pertains to an indoor or outdoor ambient. In a step  1150 , the UI  240  formats and displays the data on a display. The display may be, e.g., a component of a wall-mounted controller. 
     In one embodiment, the UI  240  reads four messages that are sent from the SC  230  to populate indoor/outdoor temperature and RH values on the display. Thus, the SC  230  generates one message for each indoor and outdoor temperature and RH. The SC  230  may acquire the temperature and RH data from a comfort sensor  260 , e.g., interpret the data and then format the messages and then to the UI  240  over the RSBus  180 . 
     In one embodiment, a level of abstraction is employed between a device  410  reporting a feature or parameter, e.g., temperature, and the UI  240 . Thus, for example, information about features and parameters, such as feature/parameter lists, values, formats, text strings and limits may be stored within the device  410 . The UI  240  need not store any of these data locally. When a device  410  is commissioned, e.g. configured at installation, the information stored thereon may be obtained by the UI  240  via a series of messages generated by the device  410 . 
     This approach advantageously simplifies expandability, because when a device  410  is added or modified the UI  240  software need not be upgraded. Moreover, separate messages may be used to transfer a plurality of definitions and strings to the UI  240 . The volume of data transferred, and the resulting time required to commission the device  410 , may be reduced when the UI  240  is preloaded with certain feature and parameter definitions, such as a format or name. 
       FIG. 12  illustrates a method generally designated  1200  for manufacturing an HVAC data processing a communication network. The method  1200  is described without limitation with reference to components of the network  200 . The method  1200  begins with a step  1210  that may be entered from any appropriate state of the system  100 . In a step  1220 , the device  410  is configured to locally store feature or parameter data related to an operation thereof. In a step  1230 , the SC  230  is configured to direct the device  410  to publish the data to the network  200 , e.g., to other devices therein configured to listen to and read messages containing the feature or parameter data. The method  1200  ends with state  1240  from which a calling routine may resume operation. 
     Turning now to  FIG. 13 , illustrated is a state diagram  1300  that describes aspects of various embodiments of operation of the system  100 . The state diagram  1300  may be implemented, e.g., as a state machine such as a microcontroller. The state diagram  1300  generally brings the system  100  from a reset state  1310 , such as may be entered immediately upon powering up, to an operating normal operating state  1360 . The state diagram  1300  advances from the reset state  1310  to a subnet startup state  1320 . In the state  1320 , the aSC  230   a  may, e.g., provide messages to devices  410  in the network  200  to synchronize the devices  410  with each other. The state diagram  1300  advances from the state  1320  to a commissioning state  1330 . In the state  1330 , as described further below, the aSC  230   a  may invoke a commissioning process to install operating parameters in the various devices  410 . The state diagram  1300  advances from the state  1330  to an installer test state  1340 . In the state  1340 , the aSC  230   a  may test the functionality of the various devices  410 . The state diagram  1300  advances from the state  1340  to a link state  1350 . In the state  1350 , the subnet controllers of a plurality of subnets may link the subnets for proper operation. The state diagram  1300  advances from the state  1350  to a normal operation state  1360 . In the state  1360 , the device  410  operates normally to, e.g., actively control the temperature of the premises in which the system  100  is installed. It is expected that the system  100  will operate in the state  1360  for the vast majority of its operating life. 
     The commissioning process differs from subnet startup  1320  in that the former requires that the network configuration steps, e.g., the subnet startup state  1320 , have been completed before commissioning can start. In some circumstances, beyond the scope of this discussion, the state  1320  may advance directly to the installer test state  1340  as indicated by a transition  1325 . The commissioning process may be, e.g., a number of states of a state machine or microprocessor configured to execute various commands. Included in the state machine states may be two states referred to for convenience as a Parameter_Scan state and a Parameter_Update state. 
     In the Parameter_Scan state, the active subnet controller, e.g., the aSC  230   a , may direct all devices  410  via bus messages to publish current values of some or all of their locally stored parameters. The publishing may include an indication of whether the queried device  410  is enabled or disabled. The queries may be generated sequentially, once per queried parameter, and may result in a separate response from the queried device  410  to each query. The SC  230  may then relay the responses to the UI  240  or UI/G  250 , as applicable. The UI  240  or UI/G  250  may then update its memory to reflect the status of the latest parameter values. 
     The system  100  may configure the devices  410  in a configuration mode, which may be one or more subroutines that operate as a result of power-up, e.g. In the configuration mode, the UI  240  or UI/G  250  may interpret the data acquired from the devices  410  in the Parameter_Scan state to determine if there is any ambiguity or conflict among the data, such as regarding the parameter data format, definition or name. The UI  240  or the UI/G  250  may be configured to query the device  410  that is the source of the ambiguity or conflict for further information on each parameter. When any ambiguities or conflicts are resolved, the UI/G  250  may advance to the Parameter_Update state. 
     In the Parameter_Update state, the SC  230  (aSC) the installer (a service technician, e.g.) may interact with each device of the system  100  via the UI  240  and update installer parameters thereon. (The following description also pertains to embodiments in which the installer communicates with the system  100  via the UI/G  250 .) Installer parameters may include, e.g., various adjustable values that determine aspects of performance of the system  100  that may be modified by the installer. 
     In some cases, one parameter on a first device  410  may depend on the state of another parameter on the first device  410 , or on a parameter on a different second device  410 . A parameter X that resides in a first device  410 , “device A,” is a dependent parameter of a second device  410 , “device B,” if device B requires the current value of parameter X for proper operation. Such a dependent parameter is referred to as a cross-dependent parameter. For example, a heat pump may have a parameter that indicates a cooling or heating capacity. An air handler may be configured to provide air flow in proportion to the heating or cooling capacity of the heat pump. In this case, the capacity parameter is a cross-dependent parameter of the air handler. 
     In some embodiments, during the commissioning state  1330 , each device  410  publishes its parameter values one by one over the data bus  180 . Other devices update themselves with any needed dependent parameter values by listening to the messages on the data bus  180  while a scanning step, described further below, is in progress. The aSC  230   a  may then request confirmation from each device  410  that each needed dependent parameter values has been obtained by that device  410 . 
     In some cases, however, a dependent parameter value on device B may become invalid if an installer changes that value manually on device A during the commissioning process. In some embodiments, the UI  240  advantageously interrogates each device  410  for a list of dependent parameters upon which that device relies for proper operation. If the installer modifies any of these dependent parameters, e.g., a parameter on device A that is a dependent parameter of device B, the UI  240  provides the updated parameter to the affected device, e.g., device B, as soon as the original device, e.g., device A, confirms that new value is accepted. 
     A device  410  may have a parameter that depends on the value of another parameter on the device  410 . For example, a furnace with an integrated blower may scale the blower output to the furnace capacity. The blower may be associated with a parameter A 10  that is proportional to a parameter A 1  associated with the furnace capacity. The parameter A 10  is an “internally dependent” parameter. In some cases, another device  410 , e.g. UI  240 , may have a need for the value of an internally dependent parameter of another device  410 , e.g., the IFC  220 . For example, the UI  240  may display the value of the internally dependent parameter to the installer upon request. 
     During the commissioning state  1330 , a scanning step may be performed in which each device  410  publishes its parameter values over the data bus  180 . Other devices  410  are configured to listen for parameters that are relevant to their operation. The listening devices update themselves with any needed parameter values when they recognize a relevant parameter message as being relevant. The aSC  230   a  then instructs, via an appropriately configured message, each device  410  to publish the identity of any needed dependent parameters missed during the scanning step. The aSC  230   a  may then direct the appropriate device holding the needed parameter to publish that parameter. 
     Some device parameters may need to be configured differently depending on the presence or state of other components in the system  100 . For example, as described earlier, an air handler  110  blower capacity may be set differently for heat pumps that have different heating and cooling capacities. 
     The device  410  may address this issue by looking at the published features and parameters from all other relevant devices  410  on the subnet. Continuing the example of the blower, the air handler  110  blower can determine the type of outdoor unit it is matched with from the commissioning process. The air handler  110  may then self-configure to the extent of adjusting its parameters according to the data known to it. The air handler  110  may then send the parameters resulting from the self-configuration to the SC  230 , the UI  240  and the UI/G  250  so these devices have a correct record of the air handler  110  parameters. 
       FIG. 14  illustrates a method of the disclosure generally designated  1400  of automatically updating a device parameter. The method  1400  begins with a step  1410 , which may be entered, e.g., during a configuration state of the system  100 . In a step  1420 , the UI  240  sends a new value of a parameter B 1  to the IFC  220 . The IFC  220  has a cross-dependent parameter A 1  that depends on the value of B 1 . The IFC  220  also has an internally dependent parameter A 10  that depends on the value of A 1 . In a step  1430  the IFC  220  sets the value of A 1  as appropriate to the value of B 1 , and the value of A 10  as appropriate to the value of A 1 . In a step  1440 , the IFC  220  sends the updated value of A 10  first to the UI  240 . In a step  1450 , the IFC  220  sends the updated value of A 1  to the UI  240 . Then, in a step  1460 , acknowledges the receipt of the parameter B 1  by, e.g., sending a message to the UI  240  including the value of B 1 . The method  1400  ends with a step  1470  from which operation of a calling routine may resume. 
     The method  1400  advantageously communicates the dependency of A 10  on A 1  to the UI  240 . In various embodiments, the UI  240  would otherwise have no knowledge of the existence of A 10  since it is an internally dependent parameter. The UI  240  may have knowledge of the dependence of A 1  on B 2  after completion of the scanning step. Thus, the UI  240  may expect to receive the value of A 1  prior to the acknowledgement of B 1 . In the present embodiment, the UI  240  is configured to recognize the receipt of A 10  prior to A 1  as indicating the dependence of A 10  on A 1 . The UI  240  may then properly handle the parameter A 10 , including, e.g., displaying the value thereof. 
     In some cases, parameters of the device  410  may be cross-dependent across multiple devices. For example, parameter AP 1  from device A is dependent on parameter BP 2  in device B, but BP 2  may in turn be dependent on the value of a parameter CP 3  from device C. If CP 3  is changed, AP 1  and BP 2  may both be affected. In some preferred embodiments both AP 1  and BP 2  are checked and corrected if necessary. Parameters that change based on the change of an intervening dependent parameter are referred to as secondary parameters. In many cases it may be desirable to inform the user or installer of the existence of secondary parameters to ensure that such parameters are properly configured. 
       FIG. 15  illustrates a method generally designated  1500  of displaying parameter dependencies to the user on the UI  240  that advantageously informs the user or installer of changes to secondary parameters. In a step  1510  the UI  240  changes a parameter value on a device  410 , e.g., A. In a step  1520 , the device  410  that owns A, and/or other devices  410 , sends the updated values of secondary parameters to the UI  240 . In a step  1530 , the UI  240  displays the secondary parameter and highlights parameter values associated therewith. In a step  1540 , the UI  240  forces the user to acknowledge the secondary parameter values. The forcing may take the form, e.g., of requiring the user to confirm the value before the UI  240  exits the menu item in which the parameter values are being displayed. In some embodiments, the UI forces the user to confirm the value of each secondary parameter. 
     Conventional HVAC systems require a manual assignment of interface IDs of a temperature sensor and a user interface via a user-selectable hardware device, such as a dip switch, jumper wire, or the like. Thus, conventional procedure is generally undesirable in the context of embodiments of the disclosure, wherein simplicity of configuration and self-configuration are broad objectives. 
     Accordingly, a method of the disclosure provides a means for automatically selecting and assigning comfort sensor and UI IDs. Broadly, the method employs a physical address of a device  410  (e.g. a comfort sensor  260  or a user interface  240 ) as well as a bus address thereof to assign an ID to the device  410 . An equipment ID is generated therefrom and embedded in an equipment type number. 
     In one embodiment, a comfort sensor  260  and a UI  240  are physically located in a same physical package, e.g. a wall-mountable enclosure. Devices located in a same physical package share a same physical address referred to herein as a device designator (DD). Thus, the CD and the UI share a same physical address. However, two such devices may have a different logical address. 
       FIG. 16  illustrates a method of the disclosure generally designated  1600  of manufacturing an HVAC system, e.g. the system  100 . In a step  1610 , the system  100  assigns to each UI  240  during a system initialization process a unique address, referred to herein as a UIID. In a step  1620  this unique address is embedded in an equipment type number and then assigned to the UI  240 . The UI with the largest DD is assigned the highest (or lowest) available ID, which is dependent on the total number of devices discovered in the system. Another UI, if present, is assigned the next highest (or lower) available ID. The assignment process is repeated until all UI devices are assigned a UIID. The UI equipment type number is computed as a sum of the UIID and a first hexadecimal offset value selected for use with user interfaces. In a nonlimiting example for discussion purposes, the first hexadecimal value is $Offset1, and the UI equipment type number is determined as:
 
UI Equipment Type Number=UIID+$Offset1.
 
     In a step  1630 , the system  100  assigns each comfort sensor  260  a unique comfort sensor ID, CSID, that is embedded in the equipment type number of the CS. For a CS embedded in a control unit, the system  100  sets the CSID equal to the UIID of the associated control unit. The comfort sensor  260  may be reported to the installer/user with the CSID. 
     The equipment type number of the CS is then determined as a sum of the CSID and a second hexadecimal value selected for use with comfort sensors  260 . In a nonlimiting example for discussion purposes, the second hexadecimal value is $Offset2, and the CS equipment type number is determined as:
 
CS Equipment Type Number=CSID+$Offset2.
 
     In a step  1640 , the CS equipment type number is assigned to the CS. 
     The values of $Offset1 and $Offset2 may be determined by system design considerations. 
     When the UI and the CS are not physically located in the same enclosure, the system  100  may assign during subnet startup a unique address and ID to each UI and CS. The address may then be embedded in the equipment type. For each UI and CS a device ID may be determined by an arbitration scheme as described previously. The device equipment number, e.g. the CSID or the UIID, is then determined as the device ID determined via the arbitration scheme plus a base equipment type number. 
     Those skilled in the art to which this application relates will appreciate that other and further additions, deletions, substitutions and modifications may be made to the described embodiments.