Interoperability of secondary-device hubs

Abstract

Traditional home-automation systems utilize a single hub for controlling secondary devices within a home. The techniques described herein, meanwhile, utilize multiple hubs within the environment and/or located remotely from the environment. For instance, an environment may include multiple electronic devices, each configured to control one or more secondary devices within the environment. In addition, a remote service may be configured to control one or more secondary devices within the environment. As such, each controlling device stores and executes an instance of a control engine, rather than relying on a single instance of a control engine located at a single controlling hub.

Description

BACKGROUND

Homes are becoming more wired and connected with the proliferation of computing devices (such as desktops, tablets, entertainment systems, and portable communication devices) and smart appliances (such as smart light bulbs, thermostats, and the like). In some instances, users are able to use a computing device to control a smart appliance. To provide one example, a user may use an application on his tablet computing device to control settings of a thermostat in the user's home. While secondary devices are becoming more prevalent, ways to interact with these secondary devices continue to evolve.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical components or features.

FIG. 1 is a schematic diagram of an illustrative environment that includes electronic devices configured to control different secondary devices within the environment, such as lights, thermostats, window blinds, audio systems, and the like. In some instances, users may send requests to change states of these secondary devices to these electronic devices, which may in turn cause the secondary devices to change their states in accordance with the user requests.

FIG. 2 shows the electronic devices for controlling the secondary devices in greater detail. As such, each electronic device that controls one or more secondary devices includes a control engine such that control of secondary devices within an environment does not rely on a single hub. Instead, each electronic device configured to control a secondary device—or each “hub”—stores an instance of the control engine for controlling the secondary devices. In addition, a remote service may also store an instance of the control engine, also as illustrated.

FIG. 3 illustrates example details of the control engine from FIG. 2. As shown, each electronic device capable of controlling a secondary device may execute an instance of the control engine.

FIG. 4 shows an example sequence flow for a user issuing a request to change a state of a secondary device in an environment, a first electronic device receiving the request and passing the request to another device in the environment responsible for controlling the secondary device, and that device causing the secondary device to change its state in accordance with the user's request.

FIGS. 5A-B collectively illustrate an example process for electronic devices in an environment taking ownership of secondary devices in the environment, and thereafter causing secondary device to change states in accordance with user requests.

FIG. 6 illustrates an example process of a remote service executing an instance of a control engine for controlling secondary devices within an environment.

FIG. 7 illustrates example components of an electronic device, such as the voice-controlled device of FIG. 1, configured to control one or more secondary devices within an environment.

DETAILED DESCRIPTION

Techniques for controlling secondary devices (or “smart appliances”) are described herein. For instance, one or more secondary devices may reside within an environment, along with one or more electronic devices that communicatively couple with the secondary devices and are configured to control the secondary devices. To do so, the electronic devices may be configured to send control signals to the secondary devices for causing the secondary devices to perform certain operations. For instance, a user in the environment may provide, to one of the electronic devices, a request that one of the secondary devices perform a certain operation. The device, may then send the request to perform the operation directly or indirectly to the secondary device, as described below. Upon receiving a command to perform the operation, the secondary device may perform the operation.

The secondary devices may comprise lights, televisions, audio systems, door locks, garage door openers, washing machines, dryers, dishwashers, coffee makers, refrigerators, doors, automated window shades, tablets, telephones, or the like. That is, the secondary devices may comprise any type of “home-automation” device configured to communicate wired or wirelessly with a controlling electronic device. The controlling electronic devices, meanwhile, may comprise voice-controlled devices, imaging devices, tablet computing devices, televisions, mobile phones, or the like. In some instances, servers that are remote from the environment of the secondary devices may also be configured to control one or more secondary devices within the environment.

Traditional home-automation systems utilize a single hub for controlling secondary devices within a home. The techniques described herein, meanwhile, utilize multiple hubs within the environment and/or located remotely from the environment. For instance, an environment may include multiple electronic devices, each configured to control one or more secondary devices within the environment. In addition, a remote service may be configured to control one or more secondary devices within the environment. As such, each controlling device stores and executes an instance of a control engine, rather than relying on a single instance of a control engine located at a single controlling hub.

Utilizing multiple “hubs” has many benefits. First, because different electronic devices are able to communicate via different wired or wireless protocols, utilizing multiple electronic devices as hubs may expand the number of secondary devices that the home-automation system is collectively able to control. For instance, secondary devices may communicate via an array of wireless protocols, such as via Bluetooth®, ZigBee®, Z-Wave®, TCP/IP, Thread®, HomeKit®, and the like. However, not all electronic devices may be configured to communicate via each of these protocols. As such, by utilizing multiple electronic devices as home-automation hubs, the collective capabilities of all of the electronic devices may be increased, thus increasing the amount of secondary devices within an environment that the home-automation system is able to control.

In addition, by distributing instances of a control engine across multiple electronic devices (or “home-automation hubs”), the resulting system includes redundancy. Therefore, if one electronic device hosting an instance of the control engine goes down, one or more other hubs may still allow the home-automation system to continue functioning.

Next, by providing instances of a control engine on electronic devices located within the local environment of the secondary devices being controlled, the described techniques may reduce latency and increase efficacy of the system. That is, traditional home-automation systems may require user requests to modify state of secondary devices be sent to and processed “in the cloud” (i.e., remote from the environment), while the techniques described herein allow local instances of a control engine to handle these requests. Therefore, the system continues to function even if a network connection between the environment and a remote service is lost (e.g., a user's home or office Internet is down). In addition, the system is able to execute a user's command without the need to interact with a remote service over a network, thus reducing the latency associated with the request. Further, and as described below, the system may route user requests amongst multiple local electronic devices, thus again reducing latency associated with making calls to the remote service.

While the system may include local instance(s) of a control engine as discussed immediately above, in some instances the system may also include an instance of the control engine executing at a remote service. Therefore, the system still allows for control of secondary devices outside of the environment, via communication with the remote service over the network. For instance, a user may utilize an application on his mobile device configured to communicate with the remote service, which in turn communicates with secondary devices in the environment. As such, the user may be able to check the state of secondary devices in his home or office (e.g., “did I leave the lights on?”) and may also be able to control states of the secondary devices (e.g., may be able to turn off the lights from his mobile device).

As introduced above, multiple electronic devices within an environment may store and execute an instance of a control engine that is configured to control secondary devices within the environment. Within this architecture, each controlling electronic device may be responsible for controlling one or more secondary devices within the environment. For instance, a first electronic device may be responsible for controlling the downstairs lights and the downstairs television, a second electronic device may be responsible for controlling door locks in the environment, while a third electronic device may be responsible for controlling the upstairs lights and the thermostat within the environment.

A user may issue a request to change a state (i.e., perform an operation) of a secondary device within the environment in a number of ways. For instance, the user may issue this request via a voice command, a gesture, a graphical user interface (GUI) or the like. When an electronic device within the environment receives the request, the electronic device may initially identify the operation being requested and the secondary device being referenced. For instance, if a user issues a request to turn on a particular light, the electronic device (or another entity) may identify the light that the user is referencing and may identify the requested operation (turn on). After doing so, the electronic device may determine which electronic device within the environment is responsible for controlling the particular light. That is, each instance of the control engine may maintain an up-to-date listing of which electronic devices are responsible for (or “own”) each secondary device within the environment. After identifying the responsible electronic device, the electronic device that received the initial request may route this request to the responsible electronic device.

Upon the responsible electronic device receiving the request, it may also identify the requested operation and the referenced secondary device. After identifying this information, the electronic device may issue a command to the secondary device to change its state in accordance with the request. To do so, in some instances the electronic device may execute, locally, a secondary-device driver associated with the secondary device. In other instances, meanwhile, the electronic device may work with the remote service, which executes, remotely, the secondary-device driver for generating a command to perform the operation (i.e., changing state). In either instance, upon receiving the command to change its state, the secondary device may execute the command and correspondingly change state. For instance, in the example discussed above, the particular light may turn on, in accordance with the user's request. The secondary device may also send an indication back to the controlling electronic device indicating that the secondary device has successfully turned on.

In response to receiving an indication of this success, the responsible electronic device may broadcast this information out to each other instance of the control engine. That is, the electronic device may send this information to other devices within the environment responsible for controlling one or more secondary devices, as well as to the remote service executing the instance of the control engine. As discussed in further detail below, each instance may maintain a current state of each secondary device within the environment. Therefore, in response to receiving this information, each instance may update the state associated with the particular light.

In other instances, meanwhile, electronic devices may subscribe to receive information regarding particular secondary devices. For instance, if the environment includes five devices in addition to the responsible device from the example above, two (for instance) may subscribe to receive state-update information regarding state changes of the particular light. Upon the responsible device receiving an indication from the light that it has successfully turned on, the responsible device may update its stored information regarding the state of the light (from OFF to ON) and may identify the devices that have subscribed to receiving state-update information about the light. The responsible device may then send this updated state information to the subscribing devices, while refraining from sending this information to other devices that have not subscribed to receive information regarding the particular light.

In still other instances, devices (or control engines stored on the devices) may subscribe to individual controlling devices (or “hubs”) rather than the individual secondary devices. That is, a first device may subscribe to receive all updated state information from a second device, regardless of the secondary device to which the state information pertains. As such, whenever the second device successfully changes state of a secondary device that it is responsible for, it may send an indication of this updated state to the first device.

FIG. 1 is a schematic diagram of an illustrative environment 100 that includes electronic devices 104 configured to control different secondary devices 102 within the environment 100. As illustrated, these secondary devices 102 may include lights, thermostats, window blinds, audio systems, refrigerators, door locks, and the like. In some instances, users, such as example user 108, may send requests 106 to change states of these secondary devices 102 to these electronic devices 104, which may in turn cause the secondary devices 106 to change their states in accordance with the user requests. It is noted that in some instances, a device within the environment 100 may both be a controlling device 104, by controlling one or more secondary devices 102, and may also function as a secondary device 102, by performing one or more operations within the environment.

As introduced above and described in further detail below, each of the electronic devices 104 may store and execute an instance of a control engine for communicating with and controlling one or more of the secondary devices 102. In addition, a remote service 110 may store and execute an instance of the control engine, and may interact with and control the secondary devices 102 over a network 112. The network 112 may represent an array or wired networks, wireless networks (e.g., WiFi), or combinations thereof. The remote service 110 may generally refer to a network-accessible platform—or “cloud-based service”—implemented as a computing infrastructure of processors, storage, software, data access, and so forth that is maintained and accessible via the network 112, such as the Internet. Cloud-based services may not require end-user knowledge of the physical location and configuration of the system that delivers the services. Common expressions associated with cloud-based services, such as the remote service 110, include “on-demand computing”, “software as a service (SaaS)”, “platform computing”, “network accessible platform”, and so forth.

When a secondary device 102 is introduced in the environment, or when a secondary device is disconnected from one of the electronic devices 104 that is responsible for controlling the secondary device, one or more instances of the control engines executing on the electronic devices 104 may detect the presence of the secondary device via one or more wireless protocols. For instance, when the user 108 installs a “smart light bulb” or “smart door lock” within the environment, this secondary device may broadcast its presence, which may be detected by one or more of the electronic devices 104. In response to detecting a new secondary device, the instance of the control engine operating on the respective electronic device 104 may store an indication that it is now responsible for controlling this secondary device (i.e., that it is now the “owner” of the secondary device) and may broadcast this information to each other hub (i.e., each of the electronic devices 104 and remote service 112 executing a control-engine instance). In response, each control-engine instance may store an indication indicating that the electronic device that broadcast the message is now responsible for the identified secondary device. In other instances, the control-engine instance that assumed control of the secondary device may only send an indication that it is responsible for the secondary device to those devices that have subscribed. In still other instances, the control-engine instance that assumed control of the secondary device may only send an indication that it is responsible for the secondary device when queried by other devices.

In some instances, more than one of the electronic devices 104 may attempt to claim ownership of a secondary device. In these instances, a conflict-resolution process may be employed. For example, each control engine instance may be programmed such that an electronic device having a smallest device identification number may be deemed the owner of a secondary device if two or more electronic devices 104 attempt to claim ownership of a single secondary device. Of course, while one example conflict-resolution process is described, it is to be appreciated that multiple other processes may be employed.

After an electronic device 104 has claimed responsibility for controlling a particular secondary device, that secondary device may now be controlled within the environment 100 through the electronic devices 104 and/or the remote service. For instance, FIG. 1 illustrates the following example devices: a voice-controlled device 104(1) that includes a microphone and is controllable via voice commands, an imaging device 104(20 that includes a camera and is controllable via gestures, a television 104(3) that may be controllable via voice commands, gestures, or the like, and a set-top box 104(4) that may also be controllable via voice commands, gestures, or the like. While a few example devices have been listed, it is to be appreciated that the electronic devices 104 may include tablet computers, desktop computers, wearable devices, or any other type of computing device. In an example, envision that the television 104(3) initially detected the presence of a light 102(1) within the environment and, hence, claimed ownership of the light 102(1) and broadcast (i.e., sent a message) to each other electronic device 104 and the remote service 110 indicating this ownership. As such, each instance of the control engine executing on the electronic devices 104 and the remote service 112 may store an indication indicating that the television 104(3) is responsible for controlling the light 102(1).

Thereafter, envision that the user 108 issues, to the voice-controlled device 104(1), a voice command 106(1) to turn on the light 102(1). In response, the voice-controlled device 104(1) may generate an audio signal including this voice command and either perform speech recognition on the audio signal to identify the command or send this audio signal to another entity, such as the remote service 110, for performing speech-recognition thereon and identifying the voice command.

After the voice-controlled device 104(1) identifies the voice command, the device 104(1) may identify the requested operation and the referenced secondary device (the light 102(1)). After doing so, the voice-controlled device 104(1) may determine, from its memory maintaining the owners of each of the secondary devices 102 within the environment 100, that the television 104(3) is responsible for controlling the light 102(1). As such, the voice-controlled device 104(1) may pass this request to the television 102(1). In response, the television 102(1) may issue a command or work with the remote service to issue a command for causing the light 102(1) to turn on. Upon receiving such a command, the light 102(1) may turn on, complying with the user's initial request 106(1). In some instances, such as where the remote service 110 performs the speech-recognition on the audio signal to identify the voice command, the remote service 110 may pass the request to the television 104(3) rather than the voice-controlled device 104(1) passing this request.

While the above example describes the user 108 issuing the voice command 106(1) to ultimately control the light 102(1), this request may take other forms. FIG. 1, for instance, illustrates that the user may perform user gestures 106(2), which may be identified by the imaging device 104(2) or other devices that include a camera, for controlling the secondary devices 102. Additionally or alternatively, the user may utilize a graphical user interface (GUI) on a device to issue GUI requests 106(3) for controlling the secondary devices 102.

Within the environment 100 of FIG. 1, each of the secondary devices 102 may be owned by one of the controlling devices 104. Further, each of the devices 104 may store and locally execute an instance of a control engine for controlling the secondary devices that it controls, while also storing indications of the current state of all secondary devices within the environment and indications of which electronic devices 104 own which secondary devices 102. Therefore, the architecture described in FIG. 1 allows the electronic devices 104 to route the user requests 106 to change the state of the secondary devices 102 to the appropriate electronic devices 104, and potentially to the remote service when appropriate. Further, the architecture allows for redundancy by providing multiple control hubs, rather than a centralized hub.

FIG. 2 shows the electronic devices for controlling the secondary devices in greater detail. As illustrated, each electronic device 104(1), 104(2), . . . , 104(N) that controls one or more secondary devices includes a respective instance of a control engine 204(1), 204(2), . . . , 204(N). Each of these control engines 204 represents a home-automation hub that may control one or more secondary devices within the environment 100. In addition, the remote service may also store an instance of the control engine 222.

FIG. 2 further illustrates that each of the controlling electronic devices 104 may be associated with one or more protocols and protocol adapters, each enabling the respective device 104 to communicate via a respective protocol. For instance, these devices may be able to communicate via TCP/IP, Bluetooth®, ZigBee®, Z-Wave®, and/or the like. As such, each respective device 104 may be configured with one or more respective protocol stacks (e.g., a protocol stack corresponding to Bluetooth®) and one or more corresponding protocol adapters to allow the respective device 104 to communicate with a secondary device via the protocol (e.g., Bluetooth®).

In this example, the first electronic device 104(1) includes protocol stacks and protocol adapters 202(1), 202(2), and 202(3), while the second electronic device 104(2) includes protocol stacks and protocol adapters 202(1) and 202(4), and the third electronic device 104(N) includes protocol stacks and protocol adaptors 202(3), 202(4), and 202(5). As illustrated, the first electronic device 104(1) may be configured to communicate with a first secondary device 102(1) via the protocol and protocol adapter 202(1) and with a second secondary device 102(2) via the protocol and protocol adapter 202(3). That is, the first electronic device 104(1) may be responsible for controlling the secondary devices 102(1) and 102(2), and may communicate with these secondary devices via the protocols supported by the protocols stacks/protocol adapters 202(1) and 202(3), respectively.

The second electronic device 104(2), meanwhile, may be responsible for controlling a third secondary device 102(3) and may communicate with this secondary device 102(3) via the protocol stack and adapter 202(4). The third electronic device 104(N) may be responsible for controlling a fourth secondary device 102(4) via the protocol stack and adapter 202(3) and a fifth secondary device 102(5) via the protocol stack and adapter 202(5). Finally, the control engine 222 executing on the remote service 110 may be responsible for controlling (i.e., may be the owner of) a sixth secondary device 102(6).

FIG. 2 further illustrates details regarding each instance of a control engine 204. As illustrated, the control engines 204(1), 204(2), 204(N) may include, respectively, a state database 206(1), 206(2), 206(3), a rules database 208(1), 208(2), 208(3), and an owners database 210(1), 210(2), 210(3). The owners databases 210 may maintain a current listing of which of the electronic devices 104 or the remote service 110 currently owns which of the secondary devices 102. As discussed above, when one of the electronic devices 104 or the remote service 110 claims responsibility for controlling a particular secondary device, that electronic device 104 may broadcast out this ownership. In response, each other electronic device 104 and the remote service 110 may update is owner database 210.

The state database 206, meanwhile, may maintain a current state of each of the secondary devices. State may include binary states (e.g., whether a light is on or off, whether a lock or locked or unlocked, whether a garage door is open or closed) and non-binary states (e.g., a current brightness level of a television, a current color of a smart light bulb, a time at which a coffee maker is set to turn on, etc.). When a control engine of an electronic device 104 or the remote service 110 successfully changes the state of a secondary device, that device 104 or remote service 110 may broadcast out this information in addition to updating its own state database. In response to receiving this information, each respective device 104 and remote service 110 may update its corresponding state database 206.

The rules databases 208, meanwhile, may store one or more rules. Rules may comprise one or more conditions that, when met, result in the execution of one or more operations on one or more secondary devices. In some instances, a user may utilize voice commands, gestures, or GUIs to create one or more rules. For instance, a user may create a rule to turn on his upstairs lights and start the coffee maker at 7:00 am. In another example, the user may create a rule that certain operations should occur when the user leaves his house and when he returns. For instance, the user may set a rule that the garage door should close and the front door should lock when the user is not home, and that the garage door should open and the front door unlock when the user returns home. In this example, when one of the electronic devices 104 senses that the user has left or returned home, that device may execute the rule by, for example, identifying which control engine owns the secondary devices associated with the rule and may issue one or more requests to these control engines to perform the operations dictated by the rule. In one example, the user may be determined to be away from home (thus triggering execution of a rule) when a mobile device of the user is not sensed by any of the devices 104. Conversely, the user may be determined to be arriving home (thus triggering execution of another rule) when one of the devices 104 detects the presence of the mobile device after an absence.

FIG. 2 also illustrates example components of the remote service 110. As illustrated, the remote service 110 may include one or more processors 212 and computer-readable media 214, which may store an accessory registry 216, a rules builder 218, one or more metrics 220, a credentials store 222, and an instance of a control engine 224 that may include some or all of the functionally described below with reference to FIG. 3. The accessory registry includes functionality to allow devices (including the remote service 110) to claim ownership of a secondary device. In addition, the registry 216 may store an instance of the owners databases 210 that maintains the current listing of which of the electronic devices 104 or the remote service 110 currently owns which of the secondary devices 102. The accessory registry 304 may also store indications of the respective capabilities of each secondary device.

The rules builder 218, meanwhile, may include functionality for allowing users to build one or more rules, such as the rules described immediately above. In addition, the rules builder 218 may include functionality for executing rules, also as described above and as described in further detail below with reference to FIG. 3.

The metrics 220, meanwhile, may store any type of information regarding how users interact with the secondary devices 102. For instance, these metrics 220 may include how often a user requests to turn on a secondary device, a typical time of day the user does so, the user's preferred settings of a particular secondary device, and the like. In some instances, the rules builder 218 utilizes the metrics for suggesting rules to the user. For instance, if the user often requests turn on his upstairs lights at 7 am (as indicated by the metrics 220), the rules builder 218 may suggest that the user create a rule for automatically turning on the upstairs lights at 7 am.

The credentials store 222 may store, as permitted by users, one or more sets of user credentials for the provisioning of new secondary devices. For instance, the credentials store 222 may store information needed for secondary device to connect to a user's home WiFi network, such as the network name and password. Therefore, when the user purchases a new secondary device that communicates via WiFi, the remote service 110 may reference the credentials store 222 to obtain the network name and password of the user's WiFi network and may provide this information to the new secondary device, which may use this information to connect to the network. The credentials store 222 may store additional credentials, such as information for connecting to a Bluetooth® device, a Zigbee® device, or the like.

Using the architecture of FIG. 2, a user may issue requests to change states of one or more of the secondary devices 102(1)-(6). The user may issue these requests in a number of ways (e.g., voice, gestures, GUIs, etc.) and to any number of the devices 104 and/or the remote service 110. Upon a particular one of the devices 104 or the remote service 110 receiving a request to change a state of a secondary device, the device 104 or the remote service 110 may identify, from the owners database 210, the identity of the device 104 or remote service 110 responsible for controlling the particular secondary device and may pass the request along accordingly. The owner of this secondary device may thereafter receive the request and may cause the secondary device to perform the requested operation.

FIG. 3 illustrates example details of the control engine from FIG. 2. As shown, each electronic device capable of controlling a secondary device may execute an instance of the control engine. As illustrated, the example control engine includes a rules engine 302, an accessory registry 304, and an outreach component 306. The rules engine 302 may execute the one or more rules 208 when the conditions of the respective rules are met, as described above. Using the example from above, for instance, the rules 208 may include a rule stating that the garage door should close and the front door should lock when the user is not home, and that the garage door should open and the front door unlock when the user returns home. In this example, when one of the rule engine 302 receives an indication that the user has left or returned home, that rule engine 302 may execute the rule by, for example, identifying which control engine owns the secondary devices associated with the rule and may issue one or more requests to these control engines to perform the operations dictated by the rule. In some instances, the rules engine 302 may also allow a user to create one or more rules, as described above with reference to the rules builder 208.

The accessory registry 304, meanwhile, includes functionality to allow the control engines of the devices to claim ownership of a secondary device, as described above. In addition, the registry 304 may store the owners databases 210 that maintains the current listing of which of the electronic devices 104 or the remote service 110 currently owns which of the secondary devices 102. The accessory registry 304 may also store indications of the respective capabilities of each secondary device. The outreach component 306, meanwhile, stores the state database 206 and comprises functionality for sending state updates to other electronic devices 104. When a particular device updates state of a secondary device, the outreach component may broadcast out a message indicating this state update to each other device 104, or to the devices that have subscribed with the outreach component 306 to receive the state updates associated with the particular secondary device or the particular device that issued the command to update the state. The outreach component 306 may also send an indication to other devices when the corresponding electronic device claims ownership of a secondary device. As described above, the outreach component 306 may broadcast this information to one or more of the devices, to devices that subscribe to the device, or may refrain from sending the information until queried by another device.

In addition, the illustrated control engine includes an application server 308, one or more accessory drivers 310, and driver services 312. The application server 308 provides an interface for users to access the respective control engine (e.g., from their client computing devices) for purposes of configuring rules, determining secondary-device states, and the like. In addition, the control engine may store the accessory drivers 310 for certain secondary devices, such as the secondary devices that the respective control engine is responsible for. In other instances, meanwhile, the control engine may utilize secondary-device drivers that are stored remotely, as described above. Finally, the driver services 312 may provide needed services to the secondary-device drivers, such as storage, I/O processing for driver commands, and the like. Finally, the control engine may include one or more protocol stacks and protocol adapters, as discussed above with reference to FIG. 2.

FIG. 4 shows an example sequence flow for a user issuing a request to change a state of a secondary device in the environment 100, a first electronic device receiving the request and passing the request to another device in the environment 100 responsible for controlling the secondary device, and that device causing the secondary device to change its state in accordance with the user's request. This process (as well as each process described herein) is illustrated as a logical flow graph, each operation of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the process.

At “1”, the user 108 issues a natural-language command to “turn on the downstairs light”. That is, the user 108 issues a voice command to change a state of the light 102(1) from off to on. At “2”, in this example the voice-controlled device 104(1) generates an audio signal that includes the request and determines the contents of the voice command. In some instances, this may include performing speech-recognition at the device 104(1), while in other instances this may include sending the audio signal to the remote service 110 and receiving results of the speech-recognition at the device 104(1).

At “3”, the voice-controlled device 104(1) identifies the owner of the referenced secondary device (the light 102(1)) and passes the request to turn on the light to the controlling device. In this example, the voice-controlled device 104(1) determines that the television 104(3) is responsible for controlling the light 102(1) and, therefore, passes the request to the television 104(3). While not illustrated, in some instances where the remote service 110 performs the speech-recognition on the audio signal generated by the voice-controlled device 104(1), the remote service 110 may pass the request to the television 104(3).

At “4”, the television 104(3) receives the request and causes a command to be sent to the secondary device to cause the light 102(1) to turn on, in accordance with the user's request. In some instances, this may include the television executing a secondary-device driver associated with the light to generate a command that, when executed by the light 102(1), causes the light to turn on. In other instances, the television 104(3) may work with the remote service 110 or another entity that executes the secondary-device driver and passes the generated command to the light 102(1). In each instance, at “5” the light 102(1) receives the request to turn on and, in response, executes the requests and turns on. In addition, the light 102(1) may send a notification indicating that it has successfully changed its state to “on” back to the television 104(3).

At “6”, the television 104(3) receives the indication from the light 102(1) that it has turned on and broadcasts this information out to each other controlling device 104 and/or the remote service 110. At “7”, in this example at least the voice-controlled device 104(1) receives the message from the television 104(3) and updates its local database to indicate the updated state of the light 102(1).

FIGS. 5A-B collectively illustrate an example process 500 for electronic devices in an environment taking ownership of secondary devices in the environment, and thereafter causing secondary device to change states in accordance with user requests.

At 502, a first electronic device detects a presence of a secondary device. For instance, upon a secondary device being installed in an environment or upon a secondary device losing its connection with another electronic device, the first electronic device may detect the presence of the secondary device and determine that the secondary device is not currently owned. At 504, the first electronic device determines whether it and the secondary device communicate via a common wireless protocol. For instance, if the first electronic device is able to communicate via TCP/IP and Bluetooth®, the first electronic device may determine if the detected secondary device is also able to communicate via one or both of these protocols. If not, then the process 500 ends at 506 and another electronic device within the environment may later claim ownership of the secondary device.

If, however, the first electronic device determines that it and the secondary device are able to communicate via a common protocol, then at 508 the first electronic device may effectively claim ownership of the secondary device by storing an indication that the first electronic device is responsible for controlling the secondary device and, at 510, may broadcast an indication of such. For instance, the first electronic device may send such an indication over a wired and/or wireless network and/or via one or more short-range wireless protocols. As a block 512 represents, if another device within the environment has also claimed ownership of the secondary device, then a conflict resolution process may occur such that only one of the devices retains ownership of the secondary device.

At 514, the first electronic device may receive a request to change a state of a secondary device within the environment, which may be a secondary device that the first electronic device controls or a secondary device that the first electronic device does not control. At 516, the first electronic device determines whether it is response for controlling the secondary device for which it received a request. If not, then at 518 the first electronic device identifies the responsible electronic device and sends the request along to that device. At 520, the first electronic device may receive an indication from the other device that it has updated the state of the secondary device (after having successfully interacted with the secondary device to change the state). In response to receiving this indication, at 522 the first electronic device stores an indication of the updated state of the secondary device.

If, however, the first electronic device determines at 516 that it is responsible for the secondary device for which it received a request, then at 524 the first electronic device sends a request to the secondary device to change its state in accordance with the request received at the first electronic device. Here, the first electronic device may send this request to the secondary device via one or more wireless protocols that the first electronic device and the secondary device are both configured to communicate with.

FIG. 5B continues the illustration of the process 500. At 526, after sending the request to the secondary device, the first electronic device determines whether it has received an indication from the secondary device indicating that the state change successfully occurred. If not, then at 528 (and potentially after some set amount of time), the first electronic device may output an error message, retry the request, or otherwise handle the error in any other manner. If, however, the first electronic device receives an indication of a successful state change from the secondary device, then at 530 the first electronic device stores an indication of the updated state for the secondary device in the state database of the first electronic device and, at 532, broadcasts an indication of the updated state to other control-engine instances for their updating of their own respective local state databases.

FIG. 6 illustrates an example process 600 of a remote service executing an instance of a control engine for controlling secondary devices within an environment. While FIG. 6 is described as being implemented at the remote service, it is to be appreciated that some or all of this process may be implemented at another entity, such as at one or more electronic devices within an environment.

At 602, the remote service receives, from a first electronic device, a message indicating that the first electronic device is responsible for controlling a first secondary device. In some instances, the remote service receives the message in response to querying the first electronic device. At 604, the remote service stores an indication that the first electronic device is responsible for controlling the first secondary device. At 606, the remote service receives, from a second electronic device, a message indication that the second electronic device is responsible for controlling a second secondary device. In some instances, the remote service receives this second message in response to querying the second electronic device. At 608, the remote service stores an indication that the second electronic device is responsible for controlling the second secondary device.

At 610, the remote service receives a message from the first electronic device indicating an updated state of the first secondary device. In response, at 612 the remote service stores an indication of the updated state. At 614, meanwhile, the remote service receives a request to change a state of a particular secondary device in the environment, which may or may not be owned by the remote service. At 616, the remote service determines whether it is responsible for controlling secondary device associated with the request. If not, then at 618 the remote service sends the request to the electronic device responsible for controlling the secondary device. If, however, the remote service determines that it is responsible for controlling the secondary device, then at 620 the remote service sends a request to the secondary device to update its state. Again, if the secondary device does so successfully, then it may send an indication of this success back to the remote service, which may not only update its own local state, but may also broadcast out this message to other instances of the control engine.

FIG. 7 illustrates example components of an electronic device, such as the voice-controlled device 104(1) of FIG. 1, configured to control one or more secondary devices 102 within an environment. The voice-controlled device 104(1) may be implemented as a standalone device 104(1) that is relatively simple in terms of functional capabilities with limited input/output components, memory, and processing capabilities. For instance, the voice-controlled device 104(1) does not have a keyboard, keypad, or other form of mechanical input. Nor does it have a display (other than simple lights, for instance) or touch screen to facilitate visual presentation and user touch input. Instead, the device 104(1) may be implemented with the ability to receive and output audio, a network interface (wireless or wire-based), power, and processing/memory capabilities. In certain implementations, a limited set of one or more input components may be employed (e.g., a dedicated button to initiate a configuration, power on/off, etc.). Nonetheless, the primary and potentially only mode of user interaction with the device 104(1) is through voice input and audible output.

The voice-controlled device 104 may also be implemented in other form factors, such as a mobile device (e.g., a smart phone or personal digital assistant). The mobile device may include a touch-sensitive display screen and various buttons for providing input as well as additional functionality such as the ability to send and receive telephone calls. Alternative implementations of the voice-controlled device 104 may also include configuration as a personal computer. The personal computer may include a keyboard, a mouse, a display screen, and any other hardware or functionality that is typically found on a desktop, notebook, netbook, or other personal computing devices. These devices, however, are merely examples and not intended to be limiting, as the techniques described in this disclosure may be used in essentially any device that has an ability to recognize speech input or other types of natural language input.

In the illustrated implementation, the voice-controlled device 104 includes one or more processors 702 and computer-readable media 704. In some implementations, the processors(s) 702 may include a central processing unit (CPU), a graphics processing unit (GPU), both CPU and GPU, a microprocessor, a digital signal processor or other processing units or components known in the art. Alternatively, or in addition, the functionally described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), complex programmable logic devices (CPLDs), etc. Additionally, each of the processor(s) 702 may possess its own local memory, which also may store program modules, program data, and/or one or more operating systems.

The computer-readable media 704 may include volatile and nonvolatile memory, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium which can be used to store the desired information and which can be accessed by a computing device. The computer-readable media 704 may be implemented as computer-readable storage media (“CRSM”), which may be any available physical media accessible by the processor(s) 702 to execute instructions stored on the memory 704. In one basic implementation, CRSM may include random access memory (“RAM”) and Flash memory. In other implementations, CRSM may include, but is not limited to, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium which can be used to store the desired information and which can be accessed by the processor(s) 702.

Several modules such as instruction, datastores, and so forth may be stored within the computer-readable media 704 and configured to execute on the processor(s) 702. A few example functional modules are shown as applications stored in the computer-readable media 704 and executed on the processor(s) 702, although the same functionality may alternatively be implemented in hardware, firmware, or as a system on a chip (SOC).

An operating system module 706 may be configured to manage hardware and services within and coupled to the device 104 for the benefit of other modules. In addition, in some instances the device 104 may include some or all of one or more secondary-device drivers 708. In other instances, meanwhile, the device 104 may be free from the drivers 708 for interacting with secondary devices. The device 104 may further including, in some instances, a speech-recognition module 710 that employs any number of conventional speech processing techniques such as use of speech recognition, natural language understanding, and extensive lexicons to interpret voice input. In some instances, the speech-recognition module 710 may simply be programmed to identify the user uttering a predefined word or phrase (i.e., a “wake word”), after which the device 104 may begin uploading audio signals to the remote service 112 for more robust speech-recognition processing. In other examples, the device 104 itself may, for example, identify voice commands from users and may provide indications of these commands to the remote service 112.

The voice-controlled device 104 may also include a plurality of applications 712 stored in the computer-readable media 704 or otherwise accessible to the device 104. In this implementation, the applications 712 are a music player 714, a movie player 716, a timer 718, and a personal shopper 720. However, the voice-controlled device 104 may include any number or type of applications and is not limited to the specific examples shown here. The music player 714 may be configured to play songs or other audio files. The movie player 716 may be configured to play movies or other audio visual media. The timer 718 may be configured to provide the functions of a simple timing device and clock. The personal shopper 720 may be configured to assist a user in purchasing items from web-based merchants.

Generally, the voice-controlled device 104 has input devices 722 and output devices 724. The input devices 722 may include a keyboard, keypad, mouse, touch screen, joystick, control buttons, etc. In some implementations, one or more microphones 726 may function as input devices 722 to receive audio input, such as user voice input. The output devices 724 may include a display, a light element (e.g., LED), a vibrator to create haptic sensations, or the like. In some implementations, one or more speakers 728 may function as output devices 724 to output audio sounds.

A user 108 may interact with the voice-controlled device 104 by speaking to it, and the one or more microphone(s) 726 captures the user's speech. The voice-controlled device 104 can communicate back to the user by emitting audible statements through the speaker 728. In this manner, the user 108 can interact with the voice-controlled device 104 solely through speech, without use of a keyboard or display.

The voice-controlled device 104 may further include a wireless unit 730 coupled to an antenna 732 to facilitate a wireless connection to a network. The wireless unit 730 may implement one or more of various wireless technologies, such as Wi-Fi, Bluetooth, RF, and so on. A USB port 734 may further be provided as part of the device 104 to facilitate a wired connection to a network, or a plug-in network device that communicates with other wireless networks. In addition to the USB port 734, or as an alternative thereto, other forms of wired connections may be employed, such as a broadband connection.

Accordingly, when implemented as the primarily-voice-operated device 104(1), there may be no input devices, such as navigation buttons, keypads, joysticks, keyboards, touch screens, and the like other than the microphone(s) 726. Further, there may be no output such as a display for text or graphical output. The speaker(s) 728 may be the main output device. In one implementation, the voice-controlled device 104(1) may include non-input control mechanisms, such as basic volume control button(s) for increasing/decreasing volume, as well as power and reset buttons. There may also be a simple light element (e.g., LED) to indicate a state such as, for example, when power is on.

Accordingly, the device 104(1) may be implemented as an aesthetically appealing device with smooth and rounded surfaces, with one or more apertures for passage of sound waves. The device 104(1) may merely have a power cord and optionally a wired interface (e.g., broadband, USB, etc.). As a result, the device 104(1) may be generally produced at a low cost. Once plugged in, the device may automatically self-configure, or with slight aid of the user, and be ready to use. In other implementations, other I/O components may be added to this basic model, such as specialty buttons, a keypad, display, and the like.

Although the subject matter has been described in language specific to structural features, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features described. Rather, the specific features are disclosed as illustrative forms of implementing the claims.

Claims

1. A method comprising: detecting, by a first electronic device, a presence of a secondary device within an environment of the first electronic device, the secondary device previously controlled by a second electronic device within the environment that is different from the first electronic device, wherein the presence of the secondary device is detected by the first electronic device based at least in part on the secondary device losing connectivity with the second electronic device;sending, by the first electronic device, a first message to at least one of the second electronic device or a third electronic device in the environment, the first message indicating that the first electronic device is responsible for controlling the secondary device within the environment; andstoring a first indication indicating that the first electronic device is responsible for controlling the secondary device.

2. The method as recited in claim 1, wherein the detecting the presence of the secondary device comprises detecting the presence of the secondary device in the environment at least partly in response to the secondary device being disconnected from the second electronic device.

3. The method as recited in claim 1, wherein the detecting the presence of the secondary device comprises detecting the presence of the secondary device in the environment at least partly in response to the second electronic device experiencing a failure event.

4. The method as recited in claim 1, further comprising: storing a second indication that the secondary device is to perform an operation at a specified time;determining occurrence of the specified time; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

5. The method as recited in claim 1, further comprising: storing a second indication that the secondary device is to perform an operation upon a user exiting the environment;determining that the user has exited the environment; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

6. The method as recited in claim 1, further comprising: storing a second indication that the secondary device is to perform an operation upon a user entering the environment;determining that the user has entered the environment; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

7. The method as recited in claim 1, wherein the first electronic device comprises a voice-controlled device, and further comprising: generating an audio signal based at least in part on sound captured by at least one microphone of the voice-controlled device;sending the audio signal to one or more computing devices that are remote from the environment;receiving, from the one or more computing devices, a second indication of a voice command represented by the audio signal, the voice command related to an operation to be performed by the secondary device; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

8. The method as recited in claim 1, wherein the first electronic device comprises a voice-controlled device, and further comprising: generating an audio signal based at least in part on sound captured by at least one microphone of the voice-controlled device;performing speech recognition on the audio signal to determine a voice command represented by the audio signal, the voice command related to an operation to be performed by the secondary device; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

9. A first electronic device comprising: one or more processors; andone or more non-transitory computer-readable media storing computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising: detecting a presence of a secondary device within an environment of the first electronic device, the secondary device previously controlled by a second electronic device within the environment that is different from the first electronic device, wherein the presence of the secondary device is detected by the first electronic device based at least in part on the secondary device losing connectivity with the second electronic device;sending, a first message to at least one of the second electronic device or a third electronic device in the environment, the first message indicating that the first electronic device is responsible for controlling the secondary device within the environment; andstoring a first indication indicating that the first electronic device is responsible for controlling the secondary device.

10. The first electronic device as recited in claim 9, wherein the detecting the presence of the secondary device comprises detecting the presence of the secondary device in the environment at least partly in response to the secondary device being disconnected from the second electronic device.

11. The first electronic device as recited in claim 9, wherein the detecting the presence of the secondary device comprises detecting the presence of the secondary device in the environment at least partly in response to the second electronic device experiencing a failure event.

12. The first electronic device as recited in claim 9, wherein the non-transitory computer-readable media further stores computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising: storing a second indication that the secondary device is to perform an operation at a specified time;determining occurrence of the specified time; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

13. The first electronic device as recited in claim 9, wherein the non-transitory computer-readable media further stores computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising: storing a second indication that the secondary device is to perform an operation upon a user exiting the environment;determining that the user has exited the environment; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

14. The first electronic device as recited in claim 9, wherein the non-transitory computer-readable media further stores computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising: storing a second indication that the secondary device is to perform an operation upon a user entering the environment;determining that the user has entered the environment; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

15. The first electronic device as recited in claim 9, further comprising at least one microphone, and wherein the non-transitory computer-readable media further stores computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising: generating an audio signal based at least in part on sound captured by the at least one microphone;sending the audio signal to one or more computing devices that are remote from the environment;receiving, from the one or more computing devices, a second indication of a voice command represented by the audio signal, the voice command related to an operation to be performed by the secondary device; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

16. The first electronic device as recited in claim 9, further comprising at least one microphone, and wherein the non-transitory computer-readable media further stores computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising: generating an audio signal based at least in part on sound captured by the at least one microphone;performing speech recognition on the audio signal to determine a voice command represented by the audio signal, the voice command related to an operation to be performed by the secondary device; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

17. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed, cause one or more processors of a first electronic device to perform acts comprising: detecting a presence of a secondary device in an environment of the first electronic device based at least in part on the secondary device losing connectivity with a second electronic device that previously controlled the secondary device;sending, a first message to at least one of the second electronic device or a third electronic device in the environment, the first message indicating that the first electronic device is responsible for controlling the secondary device within the environment; andstoring a first indication indicating that the first electronic device is responsible for controlling the secondary device.

18. The one or more non-transitory computer-readable media as recited in claim 17, wherein the detecting the presence of the secondary device comprises detecting the presence of the secondary device in the environment at least partly in response to at least one of the secondary device being disconnected from the second electronic device or the second electronic device experiencing a failure event.

19. The one or more non-transitory computer-readable media as recited in claim 17, further storing computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising: storing a second indication that the secondary device is to perform an operation in response to a specified condition;determining occurrence of the specified condition; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.

20. The one or more non-transitory computer-readable media as recited in claim 17, further storing computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising: generating an audio signal based at least in part on sound captured by the at least one microphone;determining a second indication of a voice command represented by the audio signal, the voice command related to an operation to be performed by the secondary device; andsending, to the secondary device, an instruction to cause the secondary device to perform the operation.