Patent Description:
Architectural coverings such as roller blinds, vertical window coverings, horizontal window coverings, and spring-loaded window coverings provide shading and privacy. Such architectural coverings often include a motorized assembly coupled with a covering fabric or other shading material. In particular, a motor rotates a rotational member, such as a roller tube or lift rod, to raise, lower, retract, extend, reposition, etc. the cover or shading material. Architectural coverings often include a controller to monitor and/or control operation of the motorized assembly. Such controllers often include a control interface such as a remote-control interface to receive operation instructions. <CIT> discloses a method of distributing programs to a plurality of nodes within a network using a gateway. <CIT> discloses systems and methods for controlling a plurality of devices in a home automation system.

Methods and apparatus to control architectural coverings are disclosed herein. In particular, implementations include an apparatus to control architectural coverings. Implementations of such an apparatus will be described with reference to the following drawings, which are not to be considered as limiting, but rather, are illustrations of examples of manners of implementing principles of the disclosure. Many other implementations will occur to persons of ordinary skill in the art upon reading this disclosure.

Disclosed herein are example methods and apparatus to control architectural coverings. Some disclosed examples include a hub that is a computing device that communicates with and controls the operation of the architectural coverings (e.g., a hub that communicates with a controller integrated with the architectural coverings). For example, the hub may be a system-on-a-chip (SoC) that is programmed to control the operation of the architectural coverings via wireless communication with respective controllers of the architectural coverings. In some disclosed examples, the hub is installed in a building at which the architectural coverings are installed and/or is in a wireless communication range of the architectural coverings. For example, the hub may direct a controller of an architectural covering to operate a motor of the architectural covering to change a position of the architectural covering.

In accordance with one aspect of the disclosure, a hub as disclosed herein facilitates the distribution of software instructions to the architectural coverings. In some disclosed examples, the software instructions are distributed from a repository (e.g. a repository that utilizes cloud storage) to the architectural coverings. The software instructions may be firmware updates, software application updates, operational instructions, etc. In some disclosed examples, the software instructions are distributed by the hub that communicates with the repository and the architectural coverings. In some disclosed examples, the hub stores the software instructions at the hub before distributing the software instructions to the architectural coverings. In some disclosed examples, the hub communicates with the architectural coverings via a wireless connection. In some such examples, the wireless connection utilizes a wireless communication protocol that is different from a communication protocol utilized in communicating with the repository. In some disclosed examples, the hub pushes information about software instructions to the architectural coverings by transmitting an advertisement to the architectural coverings, wherein the advertisement identifies information about available software instructions (e.g., version information, device compatibility information, etc.).

In one aspect of the disclosure, the hub serves the software instructions to an architectural covering in response to a request (a pull request) for the software instructions (e.g., the architectural covering may transmit a request to the hub in response to determining that software instructions identified in the advertisement are associated with the architectural covering). In some disclosed examples, the software instructions are transmitted to the architectural covering in chunks that are sized based on an information included in the request. Thus, in some such examples, the software instructions are pulled from the hub by the architectural coverings only when the architectural coverings determine that the software instructions are desired/needed, which may reduce the bandwidth usage that would be associated with the hub pushing the software instructions out to architectural coverings. Furthermore, by allowing the architectural coverings to include transmission parameters (e.g., the sizes to be used for the chunks of the software instructions) in the request, the hub may be utilized with architectural coverings utilizing a variety of communication capabilities (e.g., wired connections, wireless connections, low and high bandwidth connections, etc.).

In accordance with one aspect of the disclosure, the hub communicates with a home control system such as GOOGLE HOME™, AMAZON ALEXA™, APPLE HOMEKIT™, etc. In some disclosed examples, the hub translates an instruction(s) received from the home control system into a command(s) to be transmitted to an architectural covering(s). As used herein, a home control system may be a control system utilized in any type of location such as a house, a business, a public location, an outdoor location, etc. In some disclosed examples, a single instruction is translated into multiple commands transmitted to the architectural covering(s). In some disclosed examples, multiple instructions are translated into a single command transmitted to the architectural covering(s). In some disclosed examples, the hub transmits response information to the home control system in response to the instruction(s) (e.g., information identifying a position of the architectural covering(s)). In some examples, the response information transmitted to the home control system is simulated by the hub when the hub does not have the actual information (e.g., when the hub retrieves position information from the architectural covering(s) at a rate that is less than the rate at which the home control system expects and/or requires a response).

In accordance with one aspect of the disclosure, an environment includes a hub communicatively coupled with a gateway that couples the hub to a repository via a network. For example, the network may be the internet. The hub is also communicatively coupled with one or more architectural coverings. For example, the hub may be coupled to the architectural coverings using wireless communication. The architectural coverings each include control circuitry that operates the respective architectural covering and communicates with the hub. For example, the control circuitry may control a motor to drive movement of an architectural covering.

As mentioned above, in accordance with one aspect of the disclosure, the repository stores software instructions for the architectural coverings. For example, the software instructions may be firmware, software applications, etc. for execution by the control circuitry of the architectural coverings. The hub retrieves the software instructions from the repository. In some such examples, the hub collects identification information from the architectural coverings and transmits the identification information to the repository to retrieve software instructions only for the architectural coverings in communication with the hub. The identification information may include model number, manufacturer information, serial number, and the like and to request software information such as software identification information, software version information, and the like.

In accordance with one aspect of the disclosure, the hub transmits an advertisement to the architectural coverings identifying software instructions that have been retrieved by the hub and are available for distribution to the architectural coverings. In some examples, the advertisement includes information about which architectural coverings are compatible with the software instructions, which version(s) of the software instructions are available, a size of the software instructions, etc. Upon receipt of the advertisement, the circuitry of the architectural covering compares the information contained in the advertisement with the corresponding parameters of the architectural covering to determine if the software instructions are to be retrieved. For example, the circuitry may determine that the software instructions are not to be retrieved if the software instructions are not compatible with the particular architectural covering (e.g., the advertisement information identifies a model number that is different than a model of the architectural covering) and/or if the version of the software instructions is older than a version that is already installed at the architectural covering. Alternatively, the circuitry may determine that the software instructions are to be retrieved when the software instructions are compatible with the architectural covering and the version of the software instructions is newer than a currently installed version. In some examples, a user setting may also be analyzed when determining if the software instructions are to be retrieved. For example, a user setting may indicate if software instruction updates are desired and/or a user may be notified to provide an input to confirm installation when new software instructions are identified.

In accordance with one aspect of the disclosure, when the circuitry determines that software instructions are to be retrieved, the circuitry transmits a request for the software instructions to the hub. In one aspect of the disclosure, the request includes an indication of a chunk size into which the software instructions are to be split. In one aspect of the disclosure, the request also includes an indication of which chunk is requested to be sent by the hub. For example, the request may indicate that the software instructions should be split into chunks of <NUM> kilobyte each and chunk number <NUM> is currently requested. In one aspect of the disclosure, the circuitry will transmit requests for each of the chunks until the entirety of the software instructions is received at the architectural covering.

As mentioned above, in one aspect of the disclosure, by retrieving the software instructions with the hub, the architectural coverings do not need to communicate with the repository. Accordingly, the architectural coverings do not need to include network interfaces that facilitate communication with the repository. For example, the architectural coverings may include limited communication hardware that supports communication with the hub but would not support communication with the repository. Additionally, when a hub is in communication with multiple architectural coverings that utilize the same software instructions, the software instructions for the multiple architectural coverings may be downloaded once by the hub and distributed to the multiple architectural coverings to reduce the bandwidth and computing resources that would be associated with multiple downloads by each of the architectural coverings. Furthermore, when the hub stores the software instructions downloaded from the repository, the architectural coverings can retrieve the firmware from the hub even when the hub is no longer in communication with the repository. For example, the hub may be transported to a location that does not provide access to a network and the software instructions may be transmitted to architectural coverings at the location once the architectural coverings establish a connection with the hub.

In some examples, the hub retrieves software from the repository and transmits the software to the architectural coverings without the need for a user to instruct the retrieval and transmission. Alternatively, a user may instruct the operation of the hub. For example, the user may provide instructions via a user interface such as a portable computing device (e.g., a smartphone).

In accordance with some aspects of the disclosure, the hub includes an interface to receive instructions from home control systems. For example, the instructions may be instructions to raise a covering, lower a covering, move a covering to a particular position (e.g., <NUM>% open), power on, power off, etc. In some such examples, the home control systems are devices that can communicate with environmental devices in a home, business, or other building(s). For example, the environmental devices may include lights, thermostats, windows, etc. In some disclosed examples, the home control systems cannot communicate directly with architectural coverings. For example, the home control systems and the architectural coverings may not support compatible communication protocols. Furthermore, the hub and the architectural coverings may not support compatible instruction sets. Thus, the hub operates as a bridge between the home control systems and the architectural coverings to translate both instructions and communication protocols allowing communication between the home control systems and the architectural coverings.

As mentioned above, in accordance with some aspects of the disclosure, the hub generates a simulated response to transmit to the home control system. For example, while the hub may query the position and/or state of an architectural covering, the hub may not determine a position and/or may not determine an operating state of an architectural covering at a time that the home control system expects a response. To provide a response to the home control system, the hub may generate a simulated response to report a position and/or state of an architectural covering. In accordance with some aspects of the disclosure, when a movement of an architectural covering is requested, the hub queries the architectural covering two times separated by a known amount of time to determine a speed based on the change in position over the amount of time. For example, if the architectural covering reports a <NUM>% open position at a first time and reports a <NUM>% open position a second time queried after <NUM> seconds, the hub determines that the covering is closing at a speed of (<NUM>%-<NUM>%)/<NUM> = <NUM>% per second. In other examples, any number of measurements may be collected and the speed may be recalculated (e.g., <NUM>, <NUM>, <NUM>, repeated measurement after an increment of time, etc.). In accordance with some aspects of the disclosure, the speed may be determined a first time that an architectural covering is controlled by the hub and may be stored for retrieval and use in simulation during later operations. In other examples, the speed may be calculated each time an architectural covering is operated, may be calculated periodically or aperiodically, or at any other time. In accordance with some aspects of the disclosure, the position of an architectural covering may be reported as a percent open, a percent closed, a distance from open and/or closed, a percent titled, a degree of tilt, etc..

In accordance with some aspects of the disclosure, the hub estimates a position of the covering based on the determined speed and the last known position. In some examples, the last known position is a position that is stored at the hub. In other examples, the last known position is a position determined by querying the architectural covering. In accordance with some aspects of the disclosure, when an architectural covering is commanded by the hub to move to a target position, the hub determines a time at which the target position will be reached using the aforementioned calculation of the speed and determining an amount of time needed to move to the target position based on the speed. At the time estimated for the architectural covering to reach the target position, the hub reports to the home control system that the movement is completed and the architectural covering is stopped. In accordance with some aspects of the disclosure, the hub also queries the state and position of the architectural covering at the estimated time and stores the final position reported by the architectural covering. In accordance with some aspects of the disclosure, if the target position does not match the position returned by the architectural covering and/or the architectural covering reports that it is still moving, the architectural covering reports an exception, an error, an alert, etc. to the home control system.

In accordance with some aspects of the disclosure, a hub may include the above-disclosed capabilities for communicating software instructions to architectural coverings and the above-disclosed capabilities for interoperation with a home control system. In other implementations, the hub may only include the above-mentioned capabilities for communicating software instructions to the architectural coverings. In still other implementations, the hub may only include the above-mentioned capabilities for interoperation with a home control system.

Turning now to the figures, <FIG> illustrates an example of an environment <NUM> including a hub <NUM>, a gateway <NUM>, a network <NUM>, a repository <NUM>, a home control system <NUM>, and architectural coverings <NUM>, <NUM>, and <NUM>. In other examples, environment <NUM> may include any number of architectural coverings (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.). According to the illustrated example, hub <NUM> is communicatively coupled to repository <NUM> via gateway <NUM> and network <NUM>, hub <NUM> is communicatively coupled to home control system <NUM> via gateway <NUM>, and hub <NUM> is communicatively coupled to architectural coverings <NUM>, <NUM>, and <NUM>.

Hub <NUM> of the example of <FIG> is a microprocessor-based SoC. Alternatively, hub <NUM> may be implemented by any other type of computing device such as a desktop computer, a laptop computer, a server, an embedded computing device, etc., or any combination of computing devices. An example implementation of hub <NUM> is described in conjunction with <FIG>. Processes that may be implemented by hub <NUM> are described in conjunction with <FIG> and <FIG>.

Gateway <NUM> communicatively couples hub <NUM> with network <NUM> and home control system <NUM>. Gateway <NUM> may be a modem, a router, a switch, a hub, an access point, or any other network device or combination of devices. For example, gateway <NUM> may be a modem that includes a router having wired and/or wireless network interfaces for an internet protocol (IP) network(s). In some examples, the hub <NUM> and the gateway <NUM> may be integrated in a single device.

Network <NUM> communicatively couples gateway <NUM> and repository <NUM>. In some examples, network <NUM> couples gateway <NUM> and, thereby, hub <NUM> with information providers such as time server, remote command servers, etc. Network <NUM> may be any type of network including a wide area network, a local area network, a wired network, a wireless network, or any combination of networks. According to the illustrated example, network <NUM> is the Internet.

Repository <NUM> stores software instructions for distribution to architectural coverings. The software instructions may be firmware, firmware updates, software applications, software application updates, operating systems, operating system updates, etc. Repository <NUM> may be a cloud storage system. The example repository <NUM> includes a server to serve the software instructions to hub <NUM> in response to requests. In some examples, the repository <NUM> receives an identification of an architectural covering and/or version information and returns the software instructions relevant to the architectural covering and/or software version. A process that may be implemented by repository <NUM> is described in conjunction with <FIG>.

Home control system <NUM> is a controller to control operation of devices within a home, business, or other building or location. For example, home control system <NUM> may implement GOOGLE HOME™, AMAZON ALEXA™, APPLE HOMEKIT™, etc. Home control system <NUM> may connect with multiple devices for input and/or control. For example, home control system <NUM> may receive instructions via a user mobile device.

While environment <NUM> in the example of <FIG> includes the home control system <NUM>, other examples of environment <NUM> may not include home control system <NUM>. For example, home control system utilization may not be desired, hub <NUM> may not include an interface to a home control system, etc..

Architectural coverings <NUM>, <NUM>, and <NUM> are motorized coverings that are controlled by a local controller <NUM>, <NUM>, and <NUM>, respectively. Local controllers <NUM>, <NUM>, and <NUM> receive command(s) from the hub <NUM> to control the operation of the motorized architectural coverings <NUM>, <NUM>, and <NUM>. For example, local controller <NUM>, <NUM>, and <NUM> may receive a command to lower the architectural covering and may operate a motor of the architectural covering to lower the covering. In another example, local controller <NUM>, <NUM>, and <NUM> may receive a command to tilt the architectural covering and may operate a motor to tilt the covering. In some examples, local controllers <NUM>, <NUM>, and <NUM> transmit status information and/or responses to the instructions back to hub <NUM>.

Architectural coverings <NUM>, <NUM>, and <NUM> may be any type of covering that at least partially covers an architectural element such as a window, a door, an opening, a wall, etc. For example, architectural coverings <NUM>, <NUM>, and <NUM> may be one or more of roller shades, stacking/tiered shades, corded shades, cordless shades, vertical shades, horizontal shades (e.g., Venetian blinds), window shutters, projection screens, or any other motorized covering. Architectural coverings <NUM>, <NUM>, and <NUM> may include one or more coverings. Architectural coverings <NUM>, <NUM>, and <NUM> may include the option to raise and lower the covering (or move in any other direction) and/or may include the option to tilt the covering (e.g., tilt slats within the covering).

Architectural coverings <NUM>, <NUM>, and <NUM> are communicatively coupled with hub <NUM> via wired and/or wireless communication. According to the illustrated example, architectural coverings <NUM>, <NUM>, and <NUM> communicate with hub <NUM> utilizing a wireless communication protocol in the <NUM> spectrum utilizing a command set specific to architectural covering operation. The wireless communication protocol includes a simplified set of instructions that relate to the operation of architectural coverings. In some such examples, the wireless communication protocol may include an Application Programming Interface (API) that supports commanding movement of architectural coverings, receiving requests to provide identification and/or software information, broadcasting identification and/or software information, receiving broadcasts of software availability, retrieving software, etc. Accordingly, the wireless communication may be sufficiently simple to enable local controllers <NUM>, <NUM>, and <NUM> to be implemented with limited computing resources by eliminating the need to support standard wireless communication protocols (e.g., BLUETOOTH® wireless communication protocol from the Bluetooth Special Interest Group, WI-FI® wireless communication protocol from the Wi-Fi Alliance, etc.) and/or robust protocols such as IP, transmission control protocol (TCP), etc. Alternatively, architectural coverings <NUM>, <NUM>, and <NUM> may support other wireless communication protocols including BLUETOOTH® wireless communication protocol, BLUETOOTH® low energy (BLE) wireless communication protocol, WI-FI® wireless communication protocol, frequency hopping wireless communication protocols, ZigBee® wireless communication protocol from the ZigBee Alliance, X10 wireless communication protocol, infrared communication protocols, acoustic communication protocols, ethernet protocols, cellular protocols, Z-Wave® wireless communication protocol from Zensys, digital enhanced cordless telecommunications (DECT) wireless communication protocol, powerline communication protocols, universal powerline communication protocols, etc..

A process that may be implemented by repository <NUM> to install updated software instructions is described in conjunction with <FIG>.

In accordance with one aspect of the disclosure, the hub is implemented as a particularly programmed processor such as a system-on-a-chip. In accordance with another aspect of the disclosure, one of more components of the hub may be implemented as separate hardware elements. For example, the hub may include a processor coupled to a first communication device(s) for communicating with the gateway and a second communication device(s) for communicating with the architectural coverings. In some such examples, the hub may also include a coprocessor to support communication with certain external devices (e.g., to perform validation required for communication with certain external devices such as APPLE™ iOS mobile user devices). In some examples, the hub includes user interface elements such as light emitting diode (LED) indicators, buttons, displays, input devices, etc..

<FIG> is a block diagram of an example of an implementation of hub <NUM>. Hub <NUM> of <FIG> includes a network interface <NUM>, a home control interface <NUM>, a command translator <NUM>, a command datastore <NUM>, a wireless covering interface <NUM>, an antenna <NUM>, a software collector <NUM>, a software datastore <NUM>, and a covering enumerator <NUM>. In some examples, hub <NUM> may not interface with a home control system and, thus, may not include home control interface <NUM>, command translator <NUM>, and command datastore <NUM>. In some examples, hub <NUM> may not distribute software instructions to architectural coverings and, thus, may not include software collector <NUM>, software datastore <NUM>, and covering enumerator <NUM>. In some other examples, hub <NUM> may include covering enumerator <NUM> to provide information about architectural coverings to home control interface <NUM> and/or command translator <NUM>.

Network interface <NUM> communicates with networked devices such as repository <NUM> and home control system <NUM> via gateway <NUM>. Additionally or alternatively, networked devices may communicate directly with network interface <NUM>. Network interface <NUM> includes a wired interface to communicate with wired networks and devices and a wireless interface to communicate with wireless interfaces and devices. Network interface <NUM> may connect to a network by obtaining an IP address for use in communicating with devices connected to the network. Data received by network interface <NUM> is transmitted to home control interface <NUM> and software collector <NUM>.

Home control interface <NUM> implements an application programming interface (API) to communicate with home control system <NUM> or other home control devices via network interface <NUM>. Home control interface <NUM> transmits received instructions to command translator <NUM>. In systems and/or events in which responses to instructions are received from architectural coverings <NUM>, <NUM>, and <NUM>, home control interface <NUM> receives such responses from command translator <NUM> and transmits them to home control system <NUM> via network interface <NUM>. In systems and/or events in which home control system <NUM> expects a response to instructions, but architectural coverings <NUM>, <NUM>, and <NUM> do not send a response, do not send a response at a rate requested by home control system <NUM>, and/or do not provide all information requested by home control system <NUM>, home control interface <NUM> may receive a simulated response from command translator <NUM> and may be transmit the simulated response to home control system <NUM> via network interface <NUM>. For example, command translator <NUM> may transmit an estimated position calculated based on an estimated operating speed and an operating state (e.g., running) to home control interface <NUM>.

Command translator <NUM> facilitates intercommunication between home control system <NUM> and architectural coverings <NUM>, <NUM>, and <NUM> in an environment in which the instruction set/command set of the home control system <NUM> and architectural coverings <NUM>, <NUM>, and <NUM> are not compatible and/or are otherwise not the same. To translate communications, command translator <NUM> interfaces with command datastore <NUM> that stores rules, expressions, instructions, definitions, and the like that define how to translate communications between home control system <NUM> and architectural coverings <NUM>, <NUM>, and <NUM>. For example, command datastore <NUM> may indicate that an instruction from home control system <NUM> is to be translated to a particular command for architectural coverings <NUM>, <NUM>, and <NUM>, and/or may indicate that an instruction from home control system <NUM> is to be translated to multiple commands for architectural coverings <NUM>, <NUM>, and <NUM>, and/or may indicate that home control system <NUM> expects a response to an instruction, and/or that architectural coverings <NUM>, <NUM>, and <NUM> will not generate a response or a response will not be available to indicate that command translator <NUM> is to generate a simulated response, etc..

In some examples, hub <NUM> may interface and/or be capable of interfacing with multiple different home control systems (e.g., home control systems provided by multiple manufacturers). In such examples, datastore <NUM> may store rules, expressions, instructions, definitions, and the like that define how to translate communications from the multiple different home control systems. For example, a first instruction from a first home control system and a second, different, instruction from a second home control system may be translated to the same command for the architectural covering. In some examples, the multiple home control systems each include their own datastores, support their own encryption and decryption protocols, application programming interfaces, etc. The datastores of the home control systems may store measurement data to support the home control systems.

Command translator <NUM> transmits commands to wireless covering interface <NUM> for transmission to architectural coverings <NUM>, <NUM>, and <NUM>. Command translator <NUM> also receives responses, if sent, from architectural coverings <NUM>, <NUM>, and <NUM> via wireless covering interface <NUM>. Command translator <NUM> transmits received responses to home control system <NUM> via home control interface <NUM>. If information stored in command datastore <NUM> indicates that home control system <NUM> expects a response in reply to a transmitted instruction and indicates that architectural coverings <NUM>, <NUM>, and <NUM> do not transmit responses or responses are not requested at a fast enough rate, command translator <NUM> generates a simulated response. For example, command translator <NUM> may generate a default response, and/or may generate a response based on an estimate (e.g., by estimating the position of a covering or estimating a status of a covering), and so forth. For example, to reduce bandwidth, reduce utilization of computing resources at architectural coverings <NUM>, <NUM>, and <NUM>, and/or reduce battery usage at architectural coverings <NUM>, <NUM>, and <NUM>, command translator <NUM> may not request the current position of a covering at a rate that matches a rate requested by home control system <NUM>. For example, home control system <NUM> may request that a covering position be reported every second during movement of the covering, but in some aspects of the disclosure, command translator <NUM> may query the covering position only two times during a movement. Accordingly, command translator <NUM> determines a speed at which the covering is moving by dividing the distance travelled between the two measurements by the time that elapses between the two measurements. Command translator <NUM> determines a current position of the covering at any time by determining the distance that the covering has travelled since the last determined position (e.g., last position reported during a query of the architectural covering, last known position retrieved from storage, last estimated position, etc.) based on the estimated speed and the time that has elapsed. Additionally, command translator <NUM> reports to home control interface <NUM> that covering has reached a target position when the time for the covering to reach the target position from a current position based on the estimated speed has elapsed.

Wireless covering interface <NUM> communicates wirelessly with architectural coverings <NUM>, <NUM>, and <NUM> via antenna <NUM>. In some other examples, antenna <NUM> may be integrated in the wireless covering interface <NUM> (e.g., may not be an external antenna). In some examples, antenna <NUM> may be removably connected to wireless covering interface <NUM>. In some examples, hub <NUM> may not include antenna <NUM>. For example, antenna <NUM> may be replaced by an infrared emitter to emit infrared communications, a speaker to emit acoustic communications, etc. According to the illustrated example, wireless covering interface <NUM> utilizes a simplified wireless communication protocol that does not use IP or transmission control protocol (TCP) to send/receive a limited set of instructions for controlling operation and updating of architectural coverings <NUM>, <NUM>, and <NUM>. Wireless covering interface <NUM> communicates within the <NUM> radio frequency spectrum. For example, wireless covering interface <NUM> may utilize a proprietary communication protocol that is designed for communicating with architectural coverings <NUM>, <NUM>, and <NUM>. Alternatively, hub <NUM> may utilize any type of communication interface(s) for communicating with architectural coverings <NUM>, <NUM>, and <NUM>.

Software collector <NUM> communicates with repository <NUM> via network interface <NUM> to identify and retrieve software instructions for storage in software datastore <NUM> and distribution to architectural coverings <NUM>, <NUM>, and <NUM> via wireless covering interface <NUM>. Software collector <NUM> determines identification information and software information for architectural coverings <NUM>, <NUM>, and <NUM> from covering enumerator <NUM>. Software collector <NUM> also communicates with architectural coverings <NUM>, <NUM>, and <NUM> via.

Covering enumerator <NUM> determines identification and software information for architectural coverings <NUM>, <NUM>, and <NUM> via wireless covering interface <NUM>. For example, covering enumerator <NUM> may broadcast a request, a query, and/or any other type of polling for architectural coverings <NUM>, <NUM>, and <NUM> to identify themselves and identify software information, and/or architectural coverings <NUM>, <NUM>, and <NUM> may broadcast identification information and/or software information that is received by covering enumerator <NUM>, and/or architectural coverings <NUM>, <NUM>, and <NUM> may detect the presence of hub <NUM> and transmit identification information and software information to covering enumerator <NUM>, etc. The identification information collected by covering enumerator <NUM> may include model number, manufacturer information, serial number, and the like. The software information collected by covering enumerator <NUM> may include software identification information, software version information, information about supported communication protocols, information about support commands, and the like.

Command datastore <NUM> and software datastore <NUM> in the example of <FIG> are flash storage. Alternatively, command datastore <NUM> and/or software datastore <NUM> may be any type of storage such as, for example, a database, a file, a cache, a buffer, etc..

While an example manner of implementing hub <NUM> of <FIG> is illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, network interface <NUM>, home control interface <NUM>, command translator <NUM>, wireless covering interface <NUM>, software collector <NUM>, covering enumerator <NUM>, and/or, more generally, example hub <NUM> of <FIG> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of network interface <NUM>, home control interface <NUM>, command translator <NUM>, wireless covering interface <NUM>, software collector <NUM>, covering enumerator <NUM>, and/or, more generally, example hub <NUM> of <FIG> could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of network interface <NUM>, home control interface <NUM>, command translator <NUM>, wireless covering interface <NUM>, software collector <NUM>, and/or covering enumerator <NUM> is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, hub <NUM> of <FIG> may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices.

Flowcharts representative of example machine readable instructions for implementing environment <NUM> including hub <NUM>, repository <NUM>, and controllers <NUM>, <NUM>, <NUM> of architectural coverings <NUM>, <NUM>, and <NUM> of <FIG> and/or <NUM> are shown in <FIG>. In the examples of <FIG>, the machine readable instructions comprise a program for execution by a processor such as processor <NUM> shown in example processor platform <NUM> discussed below in connection with <FIG>. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a memory associated with processor <NUM>, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or a Blu-ray disk, but the entire program and/or parts thereof could alternatively be executed by a device other than processor <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowchart illustrated in <FIG>, many other methods of implementing hub <NUM> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, a Field Programmable Gate Array (FPGA), an Application Specific Integrated circuit (ASIC), a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.

As mentioned above, the example processes of <FIG> may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. Thus, whenever a claim lists anything following any form of "include" or "comprise" (e.g., comprises, includes, comprising, including, etc.), it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim. As used herein, when the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term "comprising" and "including" are open ended.

The flowcharts of <FIG> illustrate a process in which repository <NUM>, hub <NUM>, and controllers <NUM>, <NUM>, and <NUM> communicate to transfer software instructions stored at repository <NUM> to controllers <NUM>, <NUM>, and <NUM> for installation.

Program <NUM> of <FIG> begins when repository <NUM> receives a software request from hub <NUM> (block <NUM>). The software request includes an identification of the architectural coverings <NUM>, <NUM>, and <NUM> and information about software at the architectural coverings <NUM>, <NUM>, and <NUM>. Repository <NUM> determines if it has any software instructions for the identified architectural coverings <NUM>, <NUM>, and <NUM> (block <NUM>). For example, repository <NUM> may determine if it has stored any software instructions associated with the architectural coverings <NUM>, <NUM>, and <NUM> that have a newer version than the version identified in the request from the hub. When repository <NUM> does not have any updates, repository <NUM> transmits a response to hub <NUM> indicating that there are no updates (block <NUM>). Alternatively, repository <NUM> may not transmit a response when there are no updates. When repository <NUM> has updates, repository <NUM> transmits the updates to hub <NUM> (block <NUM>). Alternatively, repository <NUM> may transmit an indication of the updates and/or a notification of the updates and/or a location at which the updates may be retrieved, etc. and the hub <NUM> may later retrieve the updates. After transmitting a response to hub <NUM> (block <NUM> or block <NUM>), the program of <FIG> ends.

<FIG> is a flowchart representative of instructions that may executed by a processor to implement hub <NUM> to interact with repository <NUM> operating according to <FIG>. <FIG> is described with reference to the examples of <FIG> and <FIG>. Alternatively other implementations of environment <NUM> and/or hub <NUM> may be utilized in conjunction with the processes illustrated in <FIG>.

Program <NUM> of <FIG> begins when covering enumerator <NUM> generates a list of architectural coverings <NUM>, <NUM>, and <NUM> that are communicatively coupled with hub <NUM> via wireless covering interface <NUM> and antenna <NUM> (block <NUM>). Covering enumerator <NUM> determines data about connected architectural coverings <NUM>, <NUM>, and <NUM> (block <NUM>). For example, the data may include identification information and software information for architectural coverings <NUM>, <NUM>, and <NUM>.

Software collector <NUM> transmits a software update request corresponding to connected architectural coverings <NUM>, <NUM>, and <NUM> to repository <NUM> via network interface <NUM> (block <NUM>). The software update request includes the data collected about connected architectural coverings <NUM>, <NUM>, and <NUM> by covering enumerator <NUM>. Software collector <NUM> determines if repository <NUM> has responded with software updates (block <NUM>). If there are no software updates, control returns to block <NUM> to continue monitoring for updates. For example, hub <NUM> may check for new updates periodically and/or aperiodically (e.g., daily, weekly, monthly, upon detection of a newly connected architectural covering, upon user initiation, and/or any combination of these events).

When repository <NUM> responds with software update(s) (block <NUM>), software collector <NUM> stores the software updates in software datastore <NUM> (block <NUM>). Software collector <NUM> transmits, via wireless covering interface <NUM>, an advertisement of the software updates to architectural coverings <NUM>, <NUM>, and <NUM> to which the software updates apply (block <NUM>). For example, software collector <NUM> may only advertise to ones of architectural coverings <NUM>, <NUM>, and <NUM> that utilize the retrieved software and for which the software update would be an update (e.g., a newer version). Alternatively, software collector <NUM> may broadcast or otherwise transmit an advertisement to all connected architectural coverings <NUM>, <NUM>, and <NUM> to let architectural coverings <NUM>, <NUM>, and <NUM> decide which software updates to retrieve from hub <NUM>. The advertisement includes an identification of architectural coverings compatible with the software, a version of the software, and a size of the software.

After transmitting the advertisement (block <NUM>), software collector <NUM> receives a software update request from one or more of architectural coverings <NUM>, <NUM>, and <NUM> (block <NUM>). For example, software collector <NUM> may operate as a server from which architectural coverings <NUM>, <NUM>, and <NUM> may request and retrieve software updates identified in advertisements. Software collector <NUM> accesses datastore <NUM> to retrieve the requested software update(s) (block <NUM>) and transmit the requested update(s) to architectural coverings <NUM>, <NUM>, and <NUM> via wireless covering interface <NUM> and antenna <NUM> (block <NUM>). In the illustrated example, the request identifies a size of chunks into which the software is to be divided and identifies a chunk to be transmitted. The software collector <NUM> divides the software into chunks identified by the size and transmits the requested chunk. The architectural coverings <NUM>, <NUM>, and <NUM> will transmit requests for each chunk until the full software is received successfully. Control returns to block <NUM> to continue monitoring for further software updates as described in conjunction with block <NUM>. Additionally or alternatively, hub <NUM> may continue receiving software updates requests at block <NUM>.

In some examples, hub <NUM> may transmit software updates in the advertisement so that the architectural coverings do not need to request/retrieve the updates. Alternatively, in some examples, hub <NUM> may not transmit advertisements (e.g., architectural coverings may poll hub <NUM> to determine if any updates are available and, in response, may download available updates from hub <NUM>).

<FIG> is a flowchart representative of instructions that may executed by a processor to implement controller <NUM>, <NUM>, and <NUM> of architectural coverings <NUM>, <NUM>, and <NUM> to interact with hub <NUM> according to <FIG>. <FIG> is described with reference to the examples of <FIG> and <FIG>. Alternatively other implementations of environment <NUM> and/or hub <NUM> may be utilized in conjunction with the processes illustrated in <FIG>.

Program <NUM> of <FIG> begins when controller <NUM>, <NUM>, and <NUM> receives a software update advertisement from hub <NUM> (block <NUM>). Controller <NUM>, <NUM>, and <NUM> determines if the advertised software update corresponds to the respective covering (block <NUM>). For example, controller <NUM>, <NUM>, and <NUM> determines if the software update is compatible with controller <NUM>, <NUM>, and <NUM>, respectively, and architectural coverings <NUM>, <NUM>, and <NUM>, respectively. Controller <NUM>, <NUM>, and <NUM> also determines if a version of the software update is newer than a version of corresponding software already installed at controller <NUM>, <NUM>, and <NUM>. Controller <NUM>, <NUM>, and <NUM> may additionally determine if the software update is to be installed by checking with a user setting (e.g., a setting that indicates if software updates should be automatically installed). When the software update does not correspond to the respective controller <NUM>, <NUM>, and <NUM>, controller <NUM>, <NUM>, and <NUM> dismisses the advertisement (block <NUM>) and control returns to block <NUM> to await the next software update advertisement.

When the software update corresponds to the respective controller <NUM>, <NUM>, and <NUM> (block <NUM>), controller <NUM>, <NUM>, and <NUM> determines if a version of the software update is newer than a version of corresponding software already installed at controller <NUM>, <NUM>, and <NUM> (block <NUM>). Controller <NUM>, <NUM>, and <NUM> may additionally determine if a software update is to be installed by checking with a user setting (e.g., a setting that indicates if software updates should be automatically installed). When the software update is not newer, controller <NUM>, <NUM>, and <NUM> dismisses the advertisement (block <NUM>) and control returns to block <NUM> to await the next software update advertisement.

When the software update is newer (block <NUM>), controller <NUM>, <NUM>, and <NUM> transmits a request for the software update to hub <NUM> (block <NUM>). In the illustrated example, controller <NUM>, <NUM>, and <NUM> identifies a size of chunks into which the software is to be divided for transmission and identifies a particular chunk that is requested for transmission. In such an example, block <NUM> is requested until all chunks are requested and received by controller <NUM>, <NUM>, and <NUM>. For example, controller <NUM>, <NUM>, and <NUM> may determine the number of chunks based on the chunk size and the size of the software reported in the software advertisement. Thus, according to the example of <FIG>, controller <NUM>, <NUM>, and <NUM> pulls the update from hub <NUM> rather than hub <NUM> pushing the update to controller <NUM>, <NUM>, and <NUM>. Utilizing a pull approach may reduce the computing resources consumed by hub <NUM> as compared with a push approach. In addition, the pull approach enables controller <NUM>, <NUM>, and <NUM> to control when and if software updates are retrieved (e.g., software updates may be pulled/retrieved at a time in which architectural covering <NUM>, <NUM>, and <NUM> are not expected to be utilized). In response to receiving the software update, controller <NUM>, <NUM>, and <NUM> installs the received software update (block <NUM>). Control then returns to block <NUM> to await the next software update advertisement.

In some aspects of the disclosure, the hub may translate one or more instructions from a home control system into one or more commands to operate an architectural covering. For example, an instruction to open a covering of an architectural covering may be translated into a command to move in a particular direction to a target position. In another example, an instruction from the home control system may be translated to the hub starting a task, a batch of commands, or any other collection of commands and/or activites. For example, the hub may translate an instruction from the home control system to move a covering to a targeted position into a trigger to perform a task that includes one or more of sending a command to the covering to start movement, querying the architectural covering to determine position information to determine a speed of the covering, reporting the position of the covering and the operating state one or more times to the home control system during the movement, notifying the home control system when movement of the covering has stopped or is estimated to have stopped, etc. For example, <FIG> illustrates an example process that may be triggered during an instruction from a home control system to move a covering, the process may be performed to generate and send simulated response information during movement of a covering.

<FIG> is a flowchart representative of instructions that may executed by a processor to interface hub <NUM> with home control system <NUM>. <FIG> is described with reference to the examples illustrated in <FIG> and <FIG>. Alternatively other implementations of environment <NUM> and/or hub <NUM> may be utilized in conjunction with the processes illustrated in <FIG>.

Program <NUM> of <FIG> begins when home control interface <NUM> receives an instruction(s) from home control system <NUM> via network interface <NUM> (block <NUM>). Command translator <NUM> selects a first instruction (block <NUM>) and retrieves a corresponding covering command(s) from command datastore <NUM> (block <NUM>). The retrieved command(s) is recognized by controller <NUM>, <NUM>, and <NUM> of architectural coverings <NUM>, <NUM>, and <NUM> even if the instruction(s) received from home control system <NUM> are not understood by controller <NUM>, <NUM>, and <NUM>. Command translator <NUM> transmits the retrieve command(s) to controller <NUM>, <NUM>, and <NUM> via wireless covering interface <NUM> (block <NUM>). If the received instruction(s) identify a particular one and/or subset of the architectural coverings <NUM>, <NUM>, and <NUM>, command translator <NUM> transmits the associated command(s) to the identified one and/or subset.

After transmitting the covering command(s) (block <NUM>), command translator <NUM> determines if there are additional instruction(s) to be processed (block <NUM>). When there are additional instruction(s) to be processed, control returns to block <NUM> to select and process the next instruction(s).

When there are no additional instruction(s) to be processed (block <NUM>), command translator <NUM> determines if the received instruction(s) request a response (block <NUM>). In the illustrated example, architectural coverings <NUM>, <NUM>, and <NUM> do not transmit responses to hub <NUM> (e.g., do not report operating status, do not report covering position, etc.). To satisfy the request of the instruction(s) for a response, command translator <NUM> generates a simulated response (block <NUM>). For example, the simulated response may estimate a position of the covering and/or may indicate that the instruction was processed successfully and the request operation has completed and/or may generate simulated position information (e.g., a single position and/or multiple positions to simulated the procession of movement of the covering), etc. An example process for generating a simulated response is described in conjunction with <FIG>. Home control interface <NUM> transmits the simulated response to home control system <NUM> via home network interface <NUM> (block <NUM>). After transmitting the response, the program of <FIG> ends. Alternatively, control may return to block <NUM> to generate and transmit a plurality of responses (e.g., to simulate the movement of a covering).

While <FIG> illustrates that blocks <NUM>-<NUM> are performed after blocks <NUM>-<NUM>, some or all of the block may be performed in parallel. For example, after transmitting a first command to architectural coverings <NUM>, <NUM>, and <NUM>, command translator <NUM> may begin handling responses to the first command while continuing to process further instructions received from home control system <NUM>.

While the example program <NUM> illustrated in <FIG> includes transmitting a single command at block <NUM> and transmitting a single response to the home control system in block <NUM>, implementations of hubs in accordance with the principles of the invention disclosed herein may transmit any number, combination, and order of commands, responses, and notifications. For example, when initiating movement (e.g., raising or lowering a covering, tilting a covering, etc.), a home control system may send an instruction to the hub. The hub may respond with an indication that the position of the covering is the last position known to the hub and that the covering is moving prior to transmitting a command to the covering to initiate movement. Alternatively, the hub may transmit the command before transmitting the response. Likewise, the hub may query the architectural covering to determine a position and/or operating state of the covering prior to transmitting a response to the home control system indicating the position and/or operating state of the covering. Any number of responses may be interposed between commands and any number of commands may be interposed between responses. In accordance with the principles of the invention disclosed herein, the timing of transmitting responses to the home control system may dictated by a protocol associated with the home control system. For example, the home control system protocol may indicate that a response must be transmitted upon the hub receiving an instruction from the home control system and/or must be transmitted periodically during a movement of the covering. In some examples, the home control system protocol may indicate that a notification must be transmitted when movement of the covering stops.

As mentioned above and set forth by example in <FIG>, any number of the responses may be sent to the home control system may be satisfied using simulated information. In accordance with some aspects of the disclosure, some responses may be satisfied using information queried from the architectural coverings (e.g., a position determined by querying the architectural covering) and some responses may be satisfied using information that is estimated. Utilizing estimated responses reduces the resource utilization of the architectural coverings by reducing the number of queries that are performed while still satisfying the home control system protocol. For example, if the home control system protocol indicates that the hub is to report a position of the covering every two seconds during movement of the covering, the hub may estimate one or more of the positions instead of querying the architectural covering for the position at the time that each response is transmitted. In accordance with some aspects of the disclosure, the hub retrieves a stored movement speed for an architectural covering to be moved and/or determines a movement speed for the architectural covering by querying the covering for one or more positions during a movement to determine a change in position over time.

<FIG> is a flowchart representative of instructions that may executed by a processor to generate a simulated response to be provided to home control interface <NUM> to be provided to home control system <NUM>. <FIG> is described with reference to the examples illustrated in <FIG> and <FIG>. Alternatively other implementations of environment <NUM> and/or hub <NUM> may be utilized in conjunction with the processes illustrated in <FIG>.

Program <NUM> of <FIG> begins when hub <NUM> has been commanded by home control system <NUM> to operate, for example, architectural covering <NUM>. Command translator <NUM> determines an initial position of architectural covering <NUM> from command datastore <NUM> (block <NUM>). For example, command translator <NUM> may retrieve a position that was stored in command datastore <NUM> after previously determining a final position due to a prior movement of architectural covering <NUM>. Alternatively, command translator may query architectural covering <NUM> for the initial position of architectural covering <NUM> via wireless covering interface <NUM>.

According to the illustrated example, command(s) are sent to architectural covering <NUM> to start movement of architectural covering <NUM> at block <NUM>, prior to beginning the program <NUM> of <FIG>. Alternatively, in accordance with the principles of the invention, the command(s) to start movement may be transmitted after block <NUM> of <FIG>. For example, a command may be transmitted to architectural covering <NUM> to initiate movement to a target position based on a target identified in the instruction(s) from home control system <NUM>.

Command translator <NUM> transmits the current position and an indication that the covering is moving to home control system <NUM> via home control interface <NUM> (block <NUM>). In accordance with some aspects disclosed herein, the position and movement are reported upon movement being instructed (e.g., prior to querying the position of the covering) to more quickly report the position and operating state to home control system <NUM>.

According to the illustrated example, after reporting the initial position and movement (block <NUM>), command translator <NUM> queries, via wireless covering interface <NUM>, architectural covering <NUM> to request a first position of the covering (block <NUM>). For example, command translator <NUM> may wait a period of time (e.g., <NUM> second, <NUM> seconds, <NUM> seconds, etc.) for the covering to have begun movement and then query architectural covering <NUM> for the first position. Command translator <NUM> determines if the response to the query indicates that the covering is at an expected position (block <NUM>). For example, command translator <NUM> may compare the first position with the initial position to determine if the covering is moving. Alternatively, command translator <NUM> may utilize a previously determined speed of the covering to determine an expected position based on the retrieved position and a time elapsed between movement being instructed and retrieval of the first position in block <NUM>.

When the covering is not at an expected position (e.g., is not moving) (block <NUM>), command translator <NUM> reports an exception to home control system <NUM> via home control interface <NUM> (block <NUM>). For example, an exception may be an alert, a warning, an error, etc..

When the covering is at an expected position (block <NUM>), command translator <NUM> determines if a movement speed has been previously stored for architectural covering <NUM> (block <NUM>). For example, command translator <NUM> may access command datastore <NUM> to determine if a speed is stored in association with an identification of architectural covering <NUM>. The identification may be a serial number or other unique identifier of the covering in examples in which the speed is stored for the particular architectural covering. In other examples, the identification may be a model number or other identification associated with a type, model, covering length, or other group of coverings that are expected to operate at the same speed and, thus, the same speed may be estimated for all coverings in the group. In accordance with principles of the invention disclosed herein, a stored speed may be discarded and/or recalculated based on aging (e.g., recalculated every six months), based on a number of times the speed was calculated (e.g., a speed may be recalculated for a threshold number of movements and, for example, averaged until it is validated), etc. When a speed has previously been determined and/or stored for architectural covering <NUM>, control proceeds to block <NUM> to utilize the speed in reporting the position of the covering.

When a speed has not been previously determined for a covering (or the speed is otherwise determined to be recalculated), command translator <NUM> waits a set amount of time (block <NUM>). According to the illustrated example, command translator <NUM> waits <NUM> seconds. Alternatively, any other time may be utilized such as <NUM> second, <NUM> second, <NUM> seconds, <NUM> seconds, etc. Command translator <NUM> then queries architectural covering <NUM> for a second position (block <NUM>).

Command translator <NUM> determines a movement speed based on the first position, the second position, and the set time (block <NUM>). According to the illustrated example, command translator <NUM> subtracts the first position from the first position and divides the result by the set time to determine a rate of movement of architectural covering <NUM>. Command translator <NUM> stores the speed to update the simulation utilized for the covering (block <NUM>). For example, command translator <NUM> may store the speed in the command datastore <NUM> in a record that associates the speed with an identification of architectural covering <NUM>.

Command translator <NUM> then reports the current position of architectural covering <NUM> to home control system <NUM> via home control interface <NUM> (block <NUM>). For example, command translator <NUM> determines the position by tracking an amount of time elapsed since a last known position (e.g., the second position) and determines the current position by multiplying the elapsed time by the rate and adding to or subtracting from (depending on the direction of movement) the last known position.

Command translator <NUM> then determines if the covering is estimated to be at the target position (block <NUM>). Command translator <NUM> determines if architectural covering <NUM> is at the target position by comparing the requested target position (e.g., sent in a command from home control system <NUM>) with an estimated position (e.g., a position determined by the speed of movement and a last known position). If the architectural covering <NUM> is not at the target position, control returns to block <NUM> to continue updating home control system <NUM> with updated position information. For example, the position information may be reported at a rate dictated by home control system <NUM>. Accordingly, command translator <NUM> may continue to report a position of architectural covering <NUM> during movement of architectural covering <NUM>. For example, home control system <NUM> may present an animated user interface illustrating the ongoing movement and position of architectural covering <NUM>. While example program <NUM> transmits the position after blocks <NUM>, <NUM>, and <NUM>, the command translator <NUM> may report a position at any time prior to, during, and/or after running a simulation of architectural covering <NUM>. For example, command translator <NUM> may transmit a position of architectural covering <NUM> in response to each query of the position of the covering (e.g., after block <NUM>, after block <NUM>, after block <NUM>, and/or after block <NUM>).

When architectural covering <NUM> is at the target position (block <NUM>), command translator <NUM> sends a notification to home control system <NUM> via home control interface <NUM> (block <NUM>). The notification is a report indicating that the covering has stopped moving and the position is the target position. Command translator <NUM> then queries architectural covering <NUM> to determine a third position (block <NUM>). According to the illustrated example, the third position is a final position at which architectural covering <NUM> has stopped following the movement. Command translator determines if the third position is an expected position for architectural covering <NUM> (block <NUM>). For example, command translator <NUM> may determine if the third position is the target position requested by home control system <NUM> for the movement. Command translator <NUM> may also determine if architectural covering <NUM> indicates that movement has stopped as expected once architectural covering <NUM> reaches the target position. When the third position is not the expected position, control returns to block <NUM> to report an exception to home control system <NUM>. When the third position is the expected position, command translator <NUM> stores the determined speed and the third position in the command datastore <NUM> (block <NUM>). For example, command translator <NUM> may store the third position in the record containing the speed for architectural covering <NUM> and in association with an identification of architectural covering <NUM>.

<FIG> is a block diagram of an example processor platform <NUM> capable of executing the instructions of <FIG>, <FIG>, and <FIG> to implement hub <NUM> of <FIG> and/or <NUM>. The processor platform <NUM> can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, or any other type of computing device.

For example, the processor <NUM> can be implemented by one or more integrated circuits, logic circuits, microprocessors, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor <NUM> implements home control interface <NUM>, command translator <NUM>, software collector <NUM>, and covering enumerator <NUM>.

The volatile memory <NUM> may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. In this example, non-volatile memory <NUM> includes command datastore <NUM> and software datastore <NUM>.

In this example, interface <NUM> includes network interface <NUM> and wireless covering interface <NUM>, which may be coupled to antenna <NUM>.

The output devices <NUM> can be implemented, for example, by at least one of display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a printer, and/or speakers). The interface circuit <NUM> of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip, and/or a graphics driver processor.

The interface circuit <NUM> of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network <NUM> (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).

The coded instructions <NUM> of <FIG> and/or <NUM> may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that example methods, apparatus and articles of manufacture have been disclosed that facilitate control updating of architectural coverings. In some examples, a disclosed hub facilitates interfacing architectural coverings with home control systems. The hub allows home control system to interact with architectural coverings even when architectural coverings are not communicatively coupled with the home control system and/or even when architectural coverings do not include an interface (e.g., an API) that can be accessed by the home control system. In some examples, a hub facilitates retrieval and installation of software instructions on architectural coverings. The hub accesses a repository via a network to retrieve software instructions even when architectural coverings cannot communicate on the network. Retrieving software instructions with the hub and distributing to a plurality of architectural coverings may reduce bandwidth on the network. Furthermore, to reduce computing resource load on the hub associated with pushing updates to architectural coverings (e.g., initiating transfer of the updates at the hub), the architectural coverings may retrieve/pull the software instructions from the hub. For example, the architectural coverings may poll the hub for a list of updates (e.g., periodically, aperiodically, in response to a user initiation, etc.) and/or the hub may transmit an advertisement of available updates (e.g., an advertisement that includes information about the updates but does not include the updates) to the architectural coverings. Based on the response to the polling and/or the advertisement, the architectural coverings may initiate retrieval of the updates from the hub (e.g., by transmitting a request for the updates to the hub).

Claim 1:
An apparatus comprising:
a network interface (<NUM>) configured to communicatively couple said apparatus with a repository (<NUM>) via a network;
a wireless covering interface (<NUM>) configured to communicatively couple said apparatus with a first architectural covering (<NUM>, <NUM>, <NUM>) having a local controller (<NUM>, <NUM>, <NUM>), the local controller being implemented with limited computing resources;
a covering enumerator (<NUM>) configured to determine information about the first architectural covering; and
a software collector (<NUM>) configured to:
retrieve software for the first architectural covering from the repository; and
in response to receiving a request for the software from the first architectural covering, transmit the software to the first architectural covering;
wherein said network interface is configured to communicatively couple said apparatus with the repository (<NUM>) utilizing a first communication protocol and said wireless covering interface is configured to communicatively couple said apparatus with the first architectural covering utilizing a second communication protocol different from the first communication protocol;
wherein the second communication protocol includes a simplified set of instructions that relate to the operation of architectural coverings; and
wherein said request for the software is received using the second communication protocol; and
wherein the software is transmitted to the first architectural covering using the second communication protocol.