|Publication number||US20050055108 A1|
|Application number||US 10/969,344|
|Publication date||10 Mar 2005|
|Filing date||19 Oct 2004|
|Priority date||30 Dec 1999|
|Also published as||US6834208, US20030040812|
|Publication number||10969344, 969344, US 2005/0055108 A1, US 2005/055108 A1, US 20050055108 A1, US 20050055108A1, US 2005055108 A1, US 2005055108A1, US-A1-20050055108, US-A1-2005055108, US2005/0055108A1, US2005/055108A1, US20050055108 A1, US20050055108A1, US2005055108 A1, US2005055108A1|
|Inventors||Greg Gonzales, Brian Baker, Sara White|
|Original Assignee||C-Smart Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (16), Referenced by (11), Classifications (11), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation of U.S. patent application Ser. No. 10/154,425, filed May 22, 2002, which is a continuation-in-part of U.S. patent application Ser. No. 09/955,570, filed Sep. 17, 2001, which is a continuation of U.S. patent application Ser. No. 09/751,383, filed Dec. 29, 2000, now abandoned, which claims the benefit of prior U.S. Provisional Patent Application No. 60/173,741, filed Dec. 30, 1999, each of which applications is expressly incorporated herein by reference.
The present invention relates to the field of home automation and control systems and, more particularly, to a method and apparatus for providing distributed control of dynamically created home automation and control system scenes.
Home automation and control systems are used to control the behavior of an environment such as a home or office building. Home automation and control systems allow home occupants to automate and control the use of electrical products and appliances in and around the house. Home automation and control systems create and launch “scenes,” also called house scenes, involving one or more products and appliances. Examples of the types of products and appliances that can be automated and controlled are lighting, entertainment, cooking, heating, air conditioning, window treatments, and landscaping. Examples of specific products and appliances that can be automated and controlled are lights, television sets, sound systems, coffee machines, ovens, furnaces, air conditioners, water heaters, humidifiers and lawn sprinklers. Each product or appliance can be set to a number of different states, i.e., on, off, and, if appropriate, an intermediate level. The controller of an electrical product or appliance, together with its effect on the controlled electrical product or appliance, will be referred to as a “device.” The “load control button” on a device is the button on the device controller that directly controls or affects the electrical product or appliance. The controller may be a physically separate entity from the product or appliance being controlled, or the controller may be physically embedded or integrated into the product or appliance being controlled.
A “scene” includes one (1) or more devices set to a particular state. For example, a morning scene could include the furnace set to 70°, the master bathroom lights on at 50%, the kitchen lights on at 100%, the coffee machine on, the television set in the kitchen on to a particular channel, and the front porch light off. This setting of devices constitutes one scene, and may be triggered by a trigger event also defined by the user, such as the press of a button on a remote control. A different scene may set additional devices and some or all of the members of the one scene to the same or different states. Current home automation and control systems are based on controlling devices through device resources, but these device resources are not interoperable between unlike resources. Current home automation and control systems require someone or something in the programming process to understand the details of the system device resources or each type of device resource in the system to create complex scenes. Current home automation and control systems create and launch scenes using several methods, each of which has significant drawbacks.
One method used by current home automation and control systems is to divide the devices into groups that all respond in basically the same way to a command. Some groups are composed of like type device resources, and other groupings allow mixed type resources, but all like-type device resources are limited to the same actions, i.e., a group command received by like type device resources in the group will force each of those devices to the same state. This method does not provide the flexibility that in one scene some of the same type devices might be on and others off, while in another scene all of the devices might be on. Such an approach is, thus, limited to simple, synchronized scenes. In current home automation and control systems able to create more complex scenes, a central controller is commonly used, with a scene being launched, or triggered, when the central controller detects the trigger event. In response to detecting the trigger event, the central controller sends messages to the devices that are members of the scene directing them to go to their respective scene states. If the central controller fails, scenes can no longer be triggered because the controller can no longer send the necessary messages to the scene member devices to produce the scenes. In effect, if the central controller fails, the entire home automation and control system is rendered unusable. This single point of failure is highly undesirable to users of such systems. Additionally, the use of a central controller creates a heavy load of network traffic, since the central controller must send a message to each scene member device individually. The message traffic on the communication network for a central controller based scene with many member devices grows proportionally with the number of devices. For a scene with a large number of devices, this also causes a time delay time between the start of the scene when the first device gets its message until the last device gets its message. Such heavy network traffic and delay in triggering scene member devices is also undesirable to users of home automation and control systems.
Another method used by current home automation and control systems is to create pre-defined scenes sometimes called home modes. Examples of such home modes are “away” or “home” or “vacation” scenes. A device receiving a scene launch command will know what state the device should be in for the chosen home mode, but the scene state is determined by the manufacturer for a particular device subtype. If the manufacturer defined home mode does not entirely produce the scene state desired by the home user, or different states are desired for the same device types (a night scene has all lights out except a nightlight in the bathroom, as an example) the scene can not be modified. Furthermore, such home automation and control systems can have only one active home mode at a time, and the home mode affects all devices in the system. This is not desirable in a house with multiple users, where each user may want to select a different scene to control the user's local environment at the same time, without affecting any system devices not in the scene desired by the user.
In other current home automation and control systems able to create more complex scenes, a specialized central programming tool is used to create complex scenes that, once programmed, can operate in a distributed fashion, i.e., do not then require a central controller to send multiple messages to set the respective states of multiple devices each time a scene is triggered. However, the central programming tool may or may not be a permanent part of such a home automation and control system; and if the central programming tool is lost or fails, the system cannot be reconfigured. This can be a problem when the user of the home automation and control system wishes to reconfigure the system, particularly when a new home owner finds the central programming tool went with the previous owner's computer or has otherwise been lost.
Also, the central programming tool is typically specialized, in that it is limited to device types that were known or contemplated when the original home automation and control system was installed. Thus, the central programming tool cannot reconfigure the system to incorporate newly developed device types, such as new media players, environmental control devices, etc., for which the programming tool does not have the requisite programming instructions. Thus, adding such new devices necessitates upgrades to the central programming tool. Furthermore, the addition of devices, whether originally contemplated or not, may reach a number exceeding the central programming tool or central controller limitations for number of devices in a scene.
Therefore, in light of the above, there is a need for a distributed and interoperable home automation and control scene method that provides dynamic complex scene creation but does not increase scene launch message traffic proportionally to the number of devices in the scene and that does not require someone or some entity in the programming process to understand the details of the system devices or each type of device in the system to create complex scenes.
In accordance with the present invention a distributed home automation and control system method and apparatus is provided. The method and apparatus creates and launches scenes in a way that does not increase scene launch message traffic proportionally to the number of devices in the scene and does not require someone or some entity in the programming process to understand the device type details of the system. Scenes are created system wide and may be called “house scenes.” “House” in this case means any type of premises, including homes, offices, boats, yards, etc. Each device in the system knows its own device-type details and is capable of dynamically learning the current state of those device-type details such that it can duplicate the current device state in a scene at a latter time without any external entity at any time knowing the device type-details. Instead of a programming tool or central controller learning the scene trigger(s) and scene state for each system device, each individual device learns its membership status in each house scene and the load state of the product or appliance controlled by the device.
In accordance with other aspects of this invention, each house scene is assigned a unique house scene identifier. House scenes are created by each individual member device, when given an indication to learn a new house scene, locally saving its membership status and the load state of the product or appliance associated with the house scene identifier, the product or appliance load state being the current state of the device when the device is given the indication to learn a new scene. When a non-member device is given the indication to learn a new scene, the device need not save any house scene information for that house scene identifier.
In accordance with further aspects of this invention, scene launch commands are generated by the actuation of scene trigger buttons. Trigger buttons may have fixed house scene identifiers associated with them, or a trigger button may learn a system resource house scene identifier to be associated with the actuating trigger button. Preferably, trigger buttons do not have predefined house scene identifiers associated with them. Also, preferably, each trigger button obtains and learns the house scene identifier at the time when it is associated with a house scene. When given an indication to learn a new system resource house scene identifier as a scene trigger, the device locally saves and associates the house scene identifier with the indicated particular scene trigger button. When the scene trigger button that has learned or been associated with a house scene identifier is activated, the activated scene trigger button launches the house scene by broadcasting a launch command to the entire network that contains the associated house scene identifier.
In accordance with yet other aspects of this invention, when a device in the network receives a broadcast scene launch command and the device membership status associated with the received house scene identifier indicates the device is a scene participant of that house scene, the device recalls the locally saved scene state associated with that house scene identifier. This allows one simple, short message containing the scene identifier to launch a scene in normal operation without regard to the number of scene members. The message does not tell the member devices how to implement a particular house scene, it only identifies the particular house scene to be launched. In accordance with yet still other aspects of this invention, alternatively, or in addition, a house scene can be launched by another entity, such as software running on a personal computer or an external controller, that is able to broadcast a scene launch command containing the house scene identifier for that particular house scene. While the system house scene resource is most desirable when the scene launch is broadcast to the network, those skilled in the art will appreciate that for network protocols where network broadcast addressing is not robustly supported or desirable, a scene launch identifier message could be addressed to each scene member device, individually or in a combined addressing scheme.
As will be appreciated from the foregoing description, the invention provides distributed programming and control of a home automation and control system. Each system device maintains scene definitions describing the state settings of the device for each scene in which the device participates as a scene member. Because the scene state setting and programming logic is embedded within each device participant, the control and programming of the system is distributed, thereby eliminating the single point of failure found in previous home automation and control systems. While any device in the system may fail, the other devices will continue to know their scene state settings and operate normally when a scene launch command is received. While any device in the system may fail and not be reprogrammable, such failure will not prevent other devices from being reprogrammable. Other devices will continue to be reprogrammable.
One benefit of the invention is a reduction in the expertise required to create complex scenes when compared to prior art solutions. Only devices need to know the details of their particular type in order to save a house scene state. No specialized knowledge of the devices to be included in a scene is needed by a central controller or centralized programming tool. There is no need for any entity outside the local device to ever know the local device scene setting associated with a particular house scene state, and no central controller is needed to create complex scenes. Each device can potentially be a member of many scenes. There is no limit to the number of system devices that can be members of a house scene. House scenes can include and exclude devices regardless of zone and group boundaries. A new device type can be incorporated into an existing house scene, even though that device type was totally unknown at the time the original scene was developed. No existing entity in the system outside the new device needs to know the details of the type of new device, and no upgrades to any existing device, central controller or programming tool are needed to add the new device to a house scene.
Another benefit of the invention is a reduction in the network traffic required to launch a complex scene as compared to central controller prior art solutions. Only a single trigger message with the scene identifier must be sent to devices participating in a scene in order to launch the scene. There is no requirement for a central controller to send a “set device” command to each different scene member, group, or zone. No other message traffic is necessary. Each device maintains its own scene definition for each scene describing the state of the device for the scene. Therefore, the launch scene command only needs to identify the scene to system devices in order for the scene to be launched. This message protocol allows scene control to be distributed throughout the home automation and control system, and also reduces the delay found in current central-controller-based home automation and control systems between the time a trigger event is received and when the last scene member is activated.
Generally described, the present invention provides a method and apparatus for providing distributed house scene programming and distributed control of a home automation and control system. According to one embodiment of the present invention, each device participating in a home automation and control system is embedded with control logic for providing distributed control. Through the control logic, each device maintains scene definitions describing the state of the device for each scene in which it participates.
When any device in the system receives a request to launch a scene, such as a scene trigger button press on one of the devices, the device broadcasts a scene state change message to all devices within the home automation and control system. The scene state change message identifies to each device a particular scene that should be launched. Each device in the system receives the message and determines whether the device is a participant in the scene. If the device is a participant in the scene, the device adjusts its state according to a scene definition associated with the scene stored in the device. In particular, the device may adjust a controlled electrical load, such as a light or appliance, according to the scene definition by turning the load on, off, or setting the load to some intermediate value. In this manner, a scene may be launched across an entire home automation and control network.
In addition to providing a distributed home automation and control method, the present invention also provides a related computer-readable medium and system for providing distributed control of a home automation and control system.
The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
The present invention is directed to a method and apparatus for providing distributed scene programming and distributed control of a home automation and control system. According to an embodiment of the present invention, a device is provided for use in a home automation and control system that includes control logic for local storage of its house scene participation states. When multiple such devices are utilized throughout a home automation and control system, control of the system is distributed among the devices. Referring now to the figures, in which like numerals represent like elements, an actual embodiment of the present invention will be described.
The home automation and control system 2 typically comprises a number of participating devices connected together by a common bus 4, or some other communication means. In the actual embodiment of the present invention described herein, the bus 4 comprises typical household wiring. Those skilled in the art should appreciate, however, that other types of communications media may be utilized including twisted wire pair, coaxial 10 cable, fiber optic cable, or other similar media. Additionally, wireless communications media, such as infrared (“IR”) or radio frequency (“RF”), may also be utilized to provide inter-device communication.
The devices connected to the bus 4 and participating in the home automation and control system 2 may comprise a wide variety of devices for performing a wide variety of functions. For instance, such devices may include a thermostat control device 6 for controlling temperature, a sensor port device 8 for detecting motion, light, sound, or other activity, a switch device 10 for triggering scenes or controlling an attached load, and a control port device 12 for controlling an attached load, such as a lamp, appliance or motor. Additionally, such devices may include a receiver port device 14 for triggering scenes based on IR or RF signals received from a wireless remote control 16 operated by a user 18. External controllers and systems 24 may also participate in the home automation and control system 2 through the use of a PC Port device 22 produced by C-SMART LLC of Las Cruces, N. Mex. The PC Port device 22 provides an interface between devices compatible with the home automation and control system 2, and devices from other manufacturers that are not natively compatible with the home automation and control system 2.
The user 18 may interact with the home automation and control system 2 through the devices. For instance, the user 18 may utilize the switch device 10 to control a load connected to a control port device 12 or to trigger or launch a house scene. The user 18 may also interact with the home automation and control system 2 through the use of a personal or Internet gateway computer 20. The personal or Internet gateway computer 20 is connected to the bus 4 and may participate in the home automation and control system 2 through the use of a PC Port device 22. The PC Port device 22 provides bi-directional communication support for the personal computer 20. In this manner, a user 18 can interact with the home automation and control system 2 through the computer 20, which is equipped with appropriate software, to interrogate devices, create or launch scenes, and perform other functions. The PC Port device 22 provides bi-directional communication support for the personal computer 20. In this manner, a user 18 can interact with the home automation and control system 2 through the computer 20, which is equipped with appropriate software, to interrogate devices, create or launch scenes. The user 18 may also interact with the home automation and control system 2 through the use of a tabletop controller 26 to launch scenes.
User interaction for programming and controlling the home automation and control system 2 is described in greater detail below.
The home automation and control system illustrated in
Turning now to
Those skilled in the art should appreciate that the house scene programming method of the invention is protocol independent and may be implemented using many types of protocols, such as the Simple Control Protocol, the Universal Plug and Play protocol which is run on a Local Area Network (LAN), the IEEE-1394 protocol, and other protocols known to those skilled in the art. The current embodiment applies this system house scene resource method using as its base communication protocol the CEBus protocol and Home Plug and Play protocol (“HPnP”), both from the CEBus Industry Council, Inc. At the heart of each device is a CEBusŪ microcontroller 30. The CEBusŪ microcontroller 30 comprises a central processing unit 62 and internal memory 64 for executing user programs, paired with functionality for interfacing with a power-line networking protocol, such as the CEBusŪ protocol from the CEBusŪ Industry Council, Inc. As known to those skilled in the art, the CEBusŪ standard (EIA-600) is an open standard for home automation that defines a common language for device communication over various media, including power lines. Those skilled in the art should appreciate that while the CEBusŪ protocol is utilized for device communication in the actual embodiment of the present invention described herein, other types of protocols may also be utilized.
In the actual embodiment of the present invention described herein, the CEBusŪ microcontroller 30 comprises a CEWay PL-One from the Domosys Corporation of Sainte-Foy, Quebec, Canada. The CEWay PL-One is a power line transceiver integrated circuit that integrates the CEBusŪ physical layer and embeds an 8052 microcontroller core. The CEWay PL-One includes 256 bytes of internal data memory, three 16-bit timers/counters, a full duplex serial port, and the ability to access up to 64 kb of external data memory and up to 64 kb of external code memory.
In the embodiment of the invention described herein, the CEWay PL-One is paired with an external random access memory (“RAM”) 32, an external read-only memory (“ROM”) 34, and a writeable non-volatile memory 36, such as flash memory. As will be described in greater detail below, the non-volatile memory 36 may be used to store and retain scene settings for the device when power is removed. These memory devices may also store computer-readable instructions, data structures, program modules, or other data necessary for providing the functionality described herein.
The CEBusŪ microcontroller 30 is also paired to a load 50 through a load controller 52. The load 50 comprises an electrical load, such as that provided by a lamp, electrical equipment, or other home appliance. The load controller 52 may be capable of sensing the level of the load 50 and is capable of setting the load 50 to a particular level. The load controller 52 communicates to the CEBusŪ microcontroller 30 so that sensing the level of the load 50 or setting the load 50 to a particular level may be accomplished under programmatic control. According to the actual embodiment of the present invention described herein, the load controller 52 may comprise a triac, for gradually varying the level of a load, or a relay for switching a load on or off. Other types of load control devices such as latching relays, bi-state relays, or other devices known to those skilled in the art may be utilized. The load 50 and load controller 52 may also be electrically isolated from the CEBusŪ microcontroller 30 through the use of a switch 54, such as an air-gap switch.
The CEBusŪ microcontroller 30 may also interface with an alternating current (“A/C”) power line 58 through the use of a 2-way bus communication driver 56. The 2-way bus communication driver 56 receives data transmitted on the A/C power line 58 and converts this data to a signal compatible with the CEBusŪ microcontroller 30. The CEBus microcontroller 30 may be electrically isolated from the A/C power line 58 through the use of a switch 60, such as an air-gap switch. As known to those skilled in the art, the CEBusŪ microcontroller 30 may also receive electrical power from a power supply 38 and a clock signal from a clock 40.
The CEBusŪ microcontroller 30 also interfaces with several input and output devices. In particular, the CEBusŪ microcontroller 30 interfaces with a light emitting diode (“LED”) controller 44. The LED controller 44 provides functionality for driving one or more LEDs mounted on the device. As will be described in greater detail below, the LEDs may be used to provide an indication to the user as to whether the device is in a normal operation mode, a programming mode, or in another state.
The CEBusŪ microcontroller 30 also receives input from a number of front panel switches 46. The front panel switches 46 may be mounted on a panel of the device accessible to the user. These switches may be utilized to control a local load 50, or to trigger a scene that includes other devices. Additionally, a dedicated setup button 42 may be provided for placing the device into HPnP network configuration modes. According to the actual embodiment of the present invention described herein, the setup button 42 is located behind a face plate of the device to prevent inadvertent selection of the programming mode. Other physical inputs 48 may also be provided to the CEBusŪ microcontroller 30, such as a timer. The front panel switches 46 and the setup button 42 are described in greater detail below with respect to
Referring now to
As described above, the switch device 10 includes the CEBusŪ microcontroller and related circuitry for interfacing with the home automation and control system and for providing the user interface. The switch device 10 also includes one or more buttons 70A-70B. In the actual embodiment of the present invention described herein, one of the buttons, such as 70A, is dedicated for local load control. The local load control button may utilize a dimmer to gradually change the value of the local load to which the switch is connected, such as a light. Alternatively, the local load control button may be utilized in connection with a relay for turning the local load on or off.
If the local load control button utilizes a dimmer, the load button may be held down to gradually ramp the local load up from its current state or to gradually ramp the local load down. The ramp up continues until the load button is released, or until it reaches its maximum value state. The ramp down continues until the load button is released, or until it reaches its minimum value state. The ramp direction, up or down, toggles each time the load button is pressed. Those skilled in the art will appreciate that the indications and actions of the load button control may depend on the type of load being controlled. As will be described in greater detail below, scenes may be assigned to the remaining buttons on the switch device 10. These buttons may then be utilized to trigger the assigned scene. Those skilled in the art should appreciate that the switch device 10 may be provided in a three-button 70A-70C or four-button 70A-70D configuration as shown in
The switch device 10 also includes a visible LED 74. In another actual embodiment of the invention herein described, the LED 74 comprises a tri-state LED capable of displaying the colors red, amber, and green. The LED 74 provides a visual indication to a user regarding the current state of the switch device 10. For instance, one color of the LED 74 may indicate to the user that the switch device 10 is in a programming state and another color may indicate that the switch device 10 is in a normal operating state. The LED 74 may also be flashed in patterns in combination with the colors to provide other types of notifications. The LED 74 is controlled by the LED controller 44 described above with reference to
The switch device 10 also comprises a setup button 42. As will be described in greater detail below, the setup button 42 is utilized to place the switch device 10 into one or more programming modes. In order to avoid inadvertent selection of the setup button 42, preferably, the button is positioned so as to avoid accidental presses. In the actual embodiment of the invention the setup button is mounted behind a switch device cover 78. In order to access the setup button 42, therefore, a user must remove the retaining screws and the switch device cover 78. If the local load control button utilizes a dimmer then the switch device 10 also includes an air-gap switch 72 for electrically isolating the local load from the power source.
As known to those skilled in the art, the CEBusŪ protocol uses 120 v, 60-cycle, electrical wiring to transport messages between devices. Particularly, the CEBusŪ protocol 80 uses spread spectrum technology to overcome communication impediments found within electrical power lines. Spread spectrum signaling works by spreading a transmitted signal over a range of frequencies, rather than using a single frequency. The CEBusŪ protocol 80 spreads its signal over a range from 100 Hz to 400 Hz during each bit in a data packet. However, instead of using frequency hopping or direct sequence spreading, the CEBusŪ protocol 80 sweeps through a range of frequencies as it is transmitted. As mentioned above, the CEWay PL-One from the Domosys Corporation implements the physical layer of the CEBusŪ protocol 80. Other layers of the CEBusŪ protocol 80 may be implemented in software.
One layer above the CEBus protocol 80 sits the Home Plug & Play protocol 82, also from the CEBus Industry Council, Inc. The Home Plug and Play protocol 82 implements the Home Plug and Play Specification that provides a uniform implementation for using the Common Application Language (“CAL”) (EIA-721), from the Electronic Industries Alliance (“EIA”), as a language for inter-device communication. CAL is a high-level command language used by devices for communication over CEBusŪ. The Home Plug and Play protocol 82 provides uniform implementation rules for CAL, accommodates various communication protocols so that it works with multiple home network transports, defines common household objects through an object-oriented language, formalizes status, listener, and request objects, uses loose coupling to share status reports, and provides other functionality as known to those skilled in the art.
A house scene system resource 84, a dynamic resource role model 86, and a simple programming interface (“SPI”) 88 all sit above the Home Plug and Play protocol 82. While the house scene system resource 84, the dynamic resource role model 86 and the SPI 88 can be implemented independently of each other, they are preferably used together. When used together, the house scene system resource 84, the dynamic resource role model 86, and the simple programming interface 88 maximize the benefits provided separately by each of these elements. Therefore, all three are used in the preferred and actual embodiment of the present invention described herein. The house scene system resource 84 when combined with the SPI 88 creates both distributed programming and distributed control with no single point of failure. The dynamic resource role model 86 enables a more efficient and compact implementation of the house scene system resource 84 and the SPI 88.
The dynamic resource role model 86 provides resource management for subscriber-publisher based automation and control system protocols, such as the CEBus 80 and Home Plug and Play 82. In a subscriber-requester based protocol, also called subscriber-publisher protocol, the system consists of device resources made up of “objects” that interoperate with each other depending on their role. The subscriber or member role provides a way for a device resource to be affected by other devices. The requester role provides a way for a device to affect other devices. In normal operation, requester objects from one resource send commands to associated subscriber resource objects. The dynamic resource role model 86 provides dynamic resource object role selection, enables new roles, gives resources the ability to assign allowed roles and provides for role protection. Preferably, the dynamic resource role model 86 allows the same resource object to have multiple roles. A resource object with both requester and subscriber roles can both affect and be affected by one or more resources. The ability for a resource object to function both as a requester and a subscriber simplifies the implementation of system-wide resources such as house scenes that, unlike device specific resource objects, need system wide resource status feedback. The dynamic resource role model 86 provides efficient system wide system resource status updating in the preferred and actual embodiment of the present invention. Further details about the dynamic resource role model 86 are discussed in U.S. patent application Ser. No. 10/153,419, filed May 22, 2002, and entitled “Method and Apparatus for Providing a Dynamic Resource Role Model for Subscriber-Requester Based Protocols in a Home Automation and Control System,” (Attorney Docket No. MSFT118857), the subject matter of which is incorporated herein by reference.
The simple programming interface (“SPI”) 88 provides a simple and consistent user interface for programming scenes and multi-ways within a home automation and control system. The SPI allows unlimited scene member adjustments before finalizing a scene and automatically keeps track of all scene members, thereby reducing scene programming time and error rate. The SPI creates uniquely identified scenes by putting all devices in the home automation and control system in a system wide scene programming mode when starting a programming session. Each and every scene member device is adjusted as many times as desired in any order. When all member devices have been adjusted to the final desired states, a trigger for the scene is selected, completing that programming session. At the end of a programming session, each device knows if its load button has been used to adjust an associated load since the start of the last programming session and not subsequently removed as a scene member. If this condition is met, the device knows that it is part of the scene being programmed and that the device load control state value in the house scene is the current device load control state value. Devices also know that if they have not been adjusted since the start of the last system programming session or have not been adjusted since they were last removed from the scene, they are not part of the scene being programmed in this programming session. The selection of the scene trigger initiates the capture of the created scene, ends the current programming session, and starts a new programming session. Further details of the SPI can be found in U.S. patent application Ser. No. 10/154,403, filed May 22, 2002, and entitled “Method and Apparatus for Providing Distributed Scene Programming in a Home Automation and Control System,” (Attorney Docket No. MSFT118856), the subject matter of which is incorporated herein by reference.
The house scene system resource 84 is described in greater detail below with respect to
As noted above, those skilled in the art should appreciate that while the foregoing protocols are presently preferred and are employed in an actual embodiment of the invention, the present invention is protocol independent and may be implemented using many types of protocols, including, but not limited to, the Simple Control Protocol, the Universal Plug and Play protocol for a Local Area Network (LAN), the Home Plug and Play protocol known as HPnP, the IEEE-1394 protocol, Consumer Electronics Bus known as CEBus, PowerBus, and other protocols known to those skilled in the art.
The actual embodiment of the invention described herein uses as its base communication protocol the CEBus protocol 80 from the CEBus Industry Council, Inc. The CEBus protocol is expanded by the Home Plug & Play protocol 82, also from the CEBus Industry Council, Inc. The CEBus protocol expanded by the HPnP protocol provides a uniform implementation for using the Common Application Language (“CAL”) (EIA-721), from the Electronic Industries Alliance (“EIA”), as a language for inter-device communication. CAL is a high-level command language used by devices for communication over CEBusŪ. The Home Plug and Play protocol provides uniform implementation rules for CAL, accommodates various communication protocols so that it works with multiple home network transports, defines common household objects through an object-oriented language, formalizes status, listener, and request objects, uses loose coupling to share status reports, and provides other functionality as known to those skilled in the art.
The CEBus defined CAL household objects are based on distinct device subsystems that are modeled as resources. Each resource subtype has its own different resource contexts and objects.
The actual embodiment using the CEBus and HPnP protocol defines a system “house scene” resource also called a house scene context. The actual embodiment uses the HPnP defined context channel number method with the house scene resource for the unique scene identifier. Each house scene stored by a device requires a separate house scene resource copy or instance in the device. To enable the device to be a participant of many different house scenes, where the device load level in each house scene may be very different, the device requires an internal device resource instance for each desired house scene. These house scene resource instances are in addition to the applicable CEBus subsystem resource in a device, and act in parallel with the device specific subsystem resource. Each device has multiple instances of the house scene resource, and each resource instance is capable of being assigned a unique house scene resource channel number. The device internal resource instance most recently commanded to action, either one of the house scene resource instances or the subsystem resource instance, has control over the product or appliance controlled by the device controller at any moment. Since the scene “in totality” is the system resource, the devices only have to understand the house scene resource context and objects in order to launch and/or be a participant of a house scene. As long as a totally new device understands the house scene resource, it can be included in a scene with any other subsystem device that understands the house scene resource. An existing device can trigger a house scene containing a new device that may have been created, developed or thought of long after the trigger device was deployed, because the existing device does not need to understand how to communicate with the new device, only with the new device's house scene resource. No device specific subsystem instance is actually required in a device in order to be a participant of a house scene.
This invention is different from traditional CEBus systems. CEBus subsystems cannot talk to each other without an interpreter such as a central controller or a programming tool. While an interpreter can overwrite the normal CEBus subsystem communication to control a different subsystem type, multiple different subsystem types cannot be controlled. CEBus attempts to reduce the number of resource commands needed for one scene by “lumping” together devices so that they all act as a group to achieve the same end state. To achieve individual independent state values, individual device control is required. The HPnP protocol was created to solve CEBus problems, and makes it easier to group together separate resources into zones with unique channel numbers assigned to each zone. The zone members act in unison in the same manner in response to commands sent with their associated zone channel number. Devices of the same subtype cannot be in more than one zone at a time. Thus, the HPnP extension only extends the individual resource control mindset. For example, a scene launch source employing CEBus with HPnP that needs to activate 5 subsystems in a particular scene needs to send 5 different messages originating in 5 different internal contexts to individually control each subsystem type. The HPnP state vector allows one compound command to include sending all the sub-state information for each different subsystem in the scene at once. But if a new subsystem type is added, the scene launcher must be upgraded to know or be programmed to know how to address the new subtype, or the new subtype cannot be added to the scene.
In accordance with this invention, devices participate in house scenes as scene members or scene triggers. A device may both trigger a scene and be a member of that scene, only trigger that scene, only be a scene member, or not be a participant in a scene.
Those skilled in the art will appreciate that a manual indication may be given to a device to learn or capture its scene member state for a house scene. The indication used depends on the manual user programming interface implemented. The actual embodiment of the present invention described herein uses the SPI 88 as its manual user programming interface, where the indication is provided in two parts. In SPI 88 programming, the device receives a device specific manual indication that the device is a scene member that sets the device to the desired scene state, and a later system wide indication to member devices to capture the scene.
The actual embodiment of the present invention also uses the receipt of a special message from the network, called macro 21, as an indication to select a trigger button for a house scene. As previously discussed, macro 21 is one of the available macro numbers defined by CEBus 80 as reserved for manufacturer specific functions. Macro 21 contains within it the house scene identifier and house scene participation status, in this case as house scene trigger.
As previously mentioned, a device may be a member of many house scenes. The load of a device is controlled by the most recent action of a local load adjustment or the most recent scene launched that the device is a member of. A device maintains knowledge of the scene identity currently in control of the device load in the manner shown in
The state machine 900 begins at state 902 when the device is unused from the factory and no scene controls the load. If a house scene launch command is received from a local or remote source while in state 902 and the device is a member of that house scene, the state machine 900 moves to the scene controls load 904 state, with the house scene that was launched becoming the house scene in control of the load. If another house scene launch command for that same house scene is received from a local or remote source while the state machine 900 is in state 904, the state remains the same. If a new house scene launch command for a different house scene is received from a local or remote source and the device is a member of that new house scene, the state machine 900 temporarily proceeds to the old scene compromised state 906. When in the old scene compromised state 906, the state machine compromises the house scene that was in control, sets that particular house scene status to compromised, and broadcasts the scene compromise status to the other devices of the home automation and control system. The state machine 900 then immediately proceeds back to the scene controls load state 904 with the new house scene set as the current house scene in control.
If a local load change occurs when the state machine 900 is in state 904, the state machine proceeds to the old scene compromised state 906. As a result, the house scene that was in control is compromised, resulting in that particular house scene status being set to compromised, and that particular house scene compromise status being broadcast to the other devices of the home automation and control system. The state machine 900 then immediately proceeds back to the no scene state 902. If a local load change occurs when the state machine 900 is in state 902, the state remains unchanged.
A house scene may be defined as having two states when launched, the “on” or activate state where the house scene launch causes all house scene member devices to go to their associated scene states, and the “off” or deactivate state, where all scene members go to a default value. When so defined, the default value may be the device off value, the last manually set device value, the value the device was at when last on, some set value chosen by a programmer, or any other value as defined by the implementation. This concept does not have to be implemented in order to have successful house scenes, but is useful to allow one button to turn scenes “on” and “off.” However, if another scene with the same or some of the same members as a scene that is “on” is launched, the next press of a trigger button that toggles between launching the scene in the “on” and “off” may not meet the user's desire. The next press by the user may be due to a desire to launch the house scene “on,” rather than turn the scene “off.” In accordance with this invention, as described next, the compromised status of the house scene can be used to determine if the next house scene trigger should or should not launch the scene as “on.”
A command message may be used to initiate single step house scene capture when the device does not know its roles in the scene being programmed. The exact form of the command message may vary and depends, at least partially, on the protocol implemented. One actual embodiment of the invention uses one of the available macro numbers (Macro 21) defined by CEBus 80 as reserved for manufacturer specific command functions. This embodiment allows multiple instances of a resource, such as house scenes, to be programmed. The Macro 21 contains information on the resource instance as well as the resource identifier, and resource participation roles. To minimize the length of the Macro 21 command, the actual embodiment determines the action to be taken when a command is received by the presence or absence of expected information in the command. The presence of a valid role implies the command is requesting a binding action. The absence of a valid role implies the command is requesting an unbinding action. The presence of a specific resource instance implies that the action is to effect that particular instance only. The absence of a resource instance indicates that any applicable instance may be acted on.
In block 1102, if the role information has not been included, the action requested is to unbind a resource, because no binding can take place without a resource identifier, and the routine 1100 branches to the error handling block 1114. At block 1114 a test is made to determine if the resource network identifier information was included in the indication message. If the resource network identifier information has been included, the routine 1100 branches to block 1120 where all resource instances bound to the resource identifier are unbound. If the resource network identifier information has not been included, the routine 1100 branches to block 1116 where a test is made to determine if the resource instance information was included in the indication message. If the resource instance information has been included, the routine 1100 branches to block 1122 where the resource instance is unbound. If the resource instance information has not been included, the routine 1100 branches to block 1118 where all the instances of the resource are unbound.
While the foregoing has described the presently preferred embodiment of the invention, as will be readily appreciated by those skilled in the art and others, various changes can be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5187655 *||16 Jan 1990||16 Feb 1993||Lutron Electronic Co., Inc.||Portable programmer for a lighting control|
|US5526358 *||19 Aug 1994||11 Jun 1996||Peerlogic, Inc.||Node management in scalable distributed computing enviroment|
|US5560322 *||11 Aug 1994||1 Oct 1996||Foster Wheeler Energy Corporation||Continuous vertical-to-angular tube transitions|
|US5621662 *||15 Feb 1994||15 Apr 1997||Intellinet, Inc.||Home automation system|
|US5677603 *||23 Dec 1994||14 Oct 1997||British Airways Plc||Lighting system for an aircraft cabin|
|US5699351 *||28 Mar 1996||16 Dec 1997||Peerlogic, Inc.||Node management in scalable distributed computing environment|
|US5706191 *||23 May 1997||6 Jan 1998||Gas Research Institute||Appliance interface apparatus and automated residence management system|
|US5793968 *||10 Mar 1997||11 Aug 1998||Peerlogic, Inc.||Scalable distributed computing environment|
|US5841360 *||22 Oct 1996||24 Nov 1998||Binder; Yehuda||Distributed serial control system|
|US5877957 *||6 Nov 1996||2 Mar 1999||Ameritech Services, Inc.||Method and system of programming at least one appliance to change state upon the occurrence of a trigger event|
|US5920476 *||21 Nov 1996||6 Jul 1999||Hennessey; John M.||Computer controlled movement of stage effects and stage installation employing same|
|US5959536 *||15 Oct 1996||28 Sep 1999||Philips Electronics North America Corporation||Task-driven distributed multimedia consumer system|
|US6192282 *||30 Sep 1997||20 Feb 2001||Intelihome, Inc.||Method and apparatus for improved building automation|
|US6466234 *||28 May 1999||15 Oct 2002||Microsoft Corporation||Method and system for controlling environmental conditions|
|US6545434 *||1 Nov 2001||8 Apr 2003||Lutron Electronics Co., Inc.||Multi-scene preset lighting controller|
|US6640141 *||7 May 2002||28 Oct 2003||Ameritech Services, Inc.||Automation system and method for the programming thereof|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7356040 *||10 Jan 2001||8 Apr 2008||Telefonaktiebolaget Lm Ericsson (Publ)||Communication system, method and controller for routing calls within private networks distributed among geographically distant zones|
|US7667968||21 May 2007||23 Feb 2010||Exceptional Innovation, Llc||Air-cooling system configuration for touch screen|
|US7680745 *||29 Jan 2007||16 Mar 2010||4Homemedia, Inc.||Automatic configuration and control of devices using metadata|
|US7745743||13 Dec 2006||29 Jun 2010||Huawei Technologies Co., Ltd.||Method and device for controlling switch between appliances|
|US7953678||26 Jan 2010||31 May 2011||4Homemedia, Inc.||Automatic configuration and control of devices using metadata|
|US8812419 *||10 Jun 2011||19 Aug 2014||Google Inc.||Feedback system|
|US8930444 *||18 Jul 2011||6 Jan 2015||Samsung Electronics Co., Ltd||Apparatus and method for controlling remote user interface servers using a multicast message in a home network|
|US20040233929 *||26 Jan 2004||25 Nov 2004||Hall Tobin J.||System and method of controlling network devices|
|US20120016930 *||19 Jan 2012||Samsung Electronics Co., Ltd.||Apparatus and method for controlling remote user interface servers using a multicast message in a home network|
|EP1848155A1 *||11 Oct 2006||24 Oct 2007||Huawei Technologies Co., Ltd.||Method and device for controlling equipment switching|
|EP2000867A1||3 Jun 2008||10 Dec 2008||Somfy Sas||Method for configuring a home automation system reacting to a weather event|
|U.S. Classification||700/22, 700/23|
|Cooperative Classification||H04L12/2823, H04L12/2803, H04L12/282, H04L2012/285, H04L12/2814|
|European Classification||H04L12/28H3B, H04L12/28H, H04L12/28H2D|
|26 Jan 2005||AS||Assignment|
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: AGREEMENT AND PLAN OF LIQUIDATION;ASSIGNOR:C-SMART CORPORATION;REEL/FRAME:015610/0070
Effective date: 20020826
|15 Jan 2015||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001
Effective date: 20141014