Remote device error correction

A method and system for correcting embedded device errors. The method may include receiving a first log generated by a first device though a first channel, receiving a second log generated by the first device that identifies a malfunction of the first device through a second channel, determining a corrective action to cause the first device to cease the malfunction, based at least in part on the second log and an inference model, and sending a message to a second device based at least in part on the corrective action.

BACKGROUND

The “Internet of Things” (hereinafter referred to as “IoT”) includes one or more embedded devices communicating within the Internet infrastructure. These embedded devices (also referred to herein as “IoT devices”) may communicate together to perform various functions such as collecting sensor data and modifying configurations of a device such as a thermostat or lightbulb. Accordingly, IoT results in new, wide-ranging types of applications in which virtually any type of physical object can be configured to provide information about itself or its surroundings and/or may be controlled remotely via client devices over the Internet. For example, the IoT devices may include physical objects such as lightbulbs, thermostats, and fans for a facility. To maintain portability and scalability, the IoT devices are typically designed to have limited functionalities and to connect to other devices using short range network channels such as Bluetooth Low Energy and/or WiFi. In many cases, the IoT devices are unable to connect directly to the Internet and need to be connected to one or more hub devices that can connect to the Internet on behalf of the IoT devices and/or manage operations for the IoT devices.

Many types of errors and malfunctions arise during the deployment and operation of IoT devices. In various situations, these errors and malfunctions may include not being able to connect to the Internet, not being able to receive or install a firmware and/or software update, not having the appropriate permissions or credentials to access a computing resource or service, having a connectivity problem with a router or a hub device, and many other types of errors. In many situations, the errors experienced by IoT devices involve individual correction after a cumbersome troubleshooting process that requires extensive human involvement, and that in some cases requires human-to-human communication between a first person responsible for, and with access to, a deployed IoT device, and a second person with domain specific knowledge regarding technical aspects of the deployed IoT device and its network environment. This approach is difficult and inefficient, results in undue IoT device downtime, and does not scale to large collections of connected IoT devices.

DETAILED DESCRIPTION

Techniques described and suggested herein relate to troubleshooting and correction of errors experienced by IoT devices. In an example, an IoT device running a real-time operating system (RTOS) may generate logs with a format that allows an error identifier to be included in a log when the IoT device experiences a malfunction. The IoT device may be deployed, possibly with other IoT devices, in a device environment, and may be in data communication with computer systems and/or services deployed in a computer resource service provider (e.g., a cloud computing services provider) environment, also referred to herein as a “cloud environment”. In some cases, the IoT device may periodically generate logs and send them to a message broker running in the service provider environment. The cloud environment may include a troubleshooting service with a log processor and a log analyzer running in a data plane. The troubleshooting service may store the received logs in an account data storage portion of a data repository, and may determine whether further action is required with respect to the received logs. In some cases, the troubleshooting service may identify a log as being a log that requires further action based on an error identifier in the log that identifies a malfunction of the IoT device, and the troubleshooting service may determine a corrective action that causes the IoT device to cease the malfunction. In an example, the log analyzer may determine the corrective action based at least in part on an inference model and the error identifier. In some embodiments, the inference model may be an inference model previously generated through a machine learning technique. In some embodiments, the inference model may be an artificial neural network, a support vector machine, a Bayesian inference model, a statistical model, or any other suitable inference model or combination of models. The troubleshooting service may send a message to the IoT device based on the corrective action that may cause the IoT device to execute a corrective action such as installing a firmware update or a digital signature that corrects the identified error, and may cause the IoT device to generate state information and/or a log associated with execution of the corrective action.

In an example, the IoT device may send logs to the message broker of the cloud environment via a router (e.g., a WiFi router) or a hub device during normal operation of the IoT device. In the event of a malfunction relating to connectivity between the IoT device and the router or hub device, the IoT device may generate a log that includes an error identifier indicating the connectivity problem, and the IoT device may attempt to connect to a proxy device (e.g., a smartphone, tablet computer, or laptop computer) operating in the device environment. In an example, the IoT device may have been previously paired with the proxy device, and may automatically connect through a communication technique such as Bluetooth Low Energy (BLE). In an example, a user of the proxy device may initiate the connection with the IoT device if the proxy device had not been previously paired or associated with the IoT device. After the IoT device is connected to the proxy device, the IoT device may send the log to the proxy device.

In an example, the proxy device may determine whether to perform an analysis of the log locally, or whether to send the log to the troubleshooting service in the cloud environment for further analysis. If the proxy device determines that it has sufficient local resources to analyze the log, it may determine a corrective action based on the error identifier and an inference model. If the proxy device determines to send the log to the troubleshooting service, the proxy device may send the log to a message broker in the cloud environment that routes the log to the troubleshooting service. The proxy device may receive data corresponding to a corrective action from the troubleshooting service in response to the sent log. The proxy device may then send data to the IoT device based on the corrective action that was determined locally, or by the troubleshooting service. In an example, the data sent to the IoT device may cause the IoT device to execute a corrective action such as installing a firmware update or a digital certificate.

In an example, an account holder may interact with a control plane of the troubleshooting service operating in the cloud environment through an account interface. The account holder may have access to a portion of a data repository that may include account data storage and inference model storage associated with an IoT device associated with the account holder. In an example, the logs may include an account identifier, a device identifier that can be mapped to an account by the troubleshooting service, or some other identifier that can be mapped to an account by the troubleshooting service. In an example, the account holder may be able to inspect and/or retrieve logs in the account data storage and/or may be able to store, update, and/or change inference models in the inference model storage. In an example, the account holder and/or systems associated with the account holder may be able to communicate with the proxy device via the account interface and the control plane of the troubleshooting service.

As one skilled in the art will appreciate in light of this disclosure, certain embodiments may be capable of achieving certain advantages. For example, some embodiments may reduce IoT device downtime in a networked environment. Some embodiments may improve the security of IoT device troubleshooting and error correction by routing troubleshooting data, including logs and data to cause the execution of corrective actions through a trusted proxy device. Some embodiments may further improve IoT device security and network connectivity by transmitting firmware updates, digital certificates, and other data associated with corrective actions to the IoT device in response to analyzing a log based at least in part on an error identifier. Some embodiments may improve IoT initial device side setup processes by automatically correcting connection errors and/or other types of errors. It will be appreciated that this list of advantages is intended to be illustrative and is not exhaustive of possible advantages that can be achieved in light of this disclosure.

FIG. 1illustrates an example diagram of a network environment100in which logs generated by a device102in a malfunctioning state are analyzed to correct the malfunction in accordance with an embodiment. In an embodiment, the network environment100may include a device environment104and a service provider environment106. In some embodiments, the service provider environment106may provide one or more online services such as a troubleshooting service, a data aggregation service, a processing service, etc. A dashed line108is shown to more clearly illustrate devices that may be considered to be a part of the device environment104, and devices that may be considered to be a part of the service provider environment106, in accordance with an embodiment. In an embodiment, one or more devices of the device environment104may be in data communication with one or more devices of the service provider environment106over one or more networks (not shown for clarity) across the dashed line108, which may include the Internet and/or any combination of wired and wireless networks. Additionally, in various embodiments, any components of the device environment104and/or the service provider environment106may be coupled with any other components of the device environment104and/or the service provider environment106via any combination of wired and/or wireless networks, including cellular wireless networks.

In an embodiment, the device environment104may include the device102. In some embodiments, the device102may be an IoT device that includes a microcontroller, memory, non-transitory computer-readable instructions that cause the IoT device to perform operations described with respect to the device102, a wireless data transmitter, a wireless data receiver, and one or more sensors and/or actuators (not shown for clarity). In an embodiment, the device102may generate logs while running a real-time operating system. In an embodiment, the device environment104may include a hub device110that may act as an intermediary and/or proxy device between the device102and one or more systems of the service provider environment106. Although a single device102is shown for clarity, it should be understood that the device environment104may include additional IoT devices in some embodiments. In some embodiments, the hub device110may be an edge computing device and/or may include a processor, memory, data storage, and non-transitory computer-readable instructions to perform operations described with respect to the hub device110. In some embodiments, the device102may communicate with the hub device110through a WiFi connection, a BLE connection, or any other suitable connection.

In some embodiments, the logs generated by the device102may be transmitted by the device102to the service provider environment106. In some embodiments, the logs may be transmitted in the form of messages using a publish-subscribe-based messaging protocol such as Message Queuing Telemetry Transport (MQTT). A different messaging protocol may be used in other embodiments (e.g., HyperText Transfer Protocol (HTTP)). Merely as an example, the logs may have a format of: [LOG SEQUENCE NUMBER] [DEBUG|INFO|ERROR WARN|CRITICAL] [MODULE] [LOG STRING]. For example, a log may be: [1000] [ERROR] [WIFI] [Failed to connect to Access Point XXXX]. In this example, the log has a log sequence number of 1000 and indicates an error associated with the WiFi module of the device that involves a failure to connect to an access point designated as XXXX. In some embodiments, the sequence number may be used to track the order of the logs. In other embodiments, the order of the logs could be tracked through a timestamp included in the logs, although a timestamp is not required and may not have a position in the log format, such as in the example log format presented above. In some embodiments, the log may include an error code field, or the device102may generate an error code that is placed in the LOG STRING field, where a particular error code represents a particular error. In some embodiments, the device102may include a logs and metrics library, not shown for clarity, that includes instructions that, when executed by a RTOS running on the device102, cause the device102to generate and transmit the logs. In some embodiments, the logs may include one or more metrics relating to one or modules of the device102(e.g., a WiFi module, memory module, sensor module, and/or any other suitable module). In some embodiments, many different types of errors may cause the device102to include an error flag and/or an error code in the log. For example, the device102may be an IoT lightbulb that allows wireless control, and the error may be that the IoT lightbulb is not able to be turned on and/or off by a smart watch, or the device102may be a smart watch that is not able to turn the IoT lightbulb on and/or off. Another error may be caused when the device102is a smart watch that is not functioning properly after a software or firmware update. In some embodiments, the error may be some type of connection failure, such as an endpoint connection failure or a connection failure due to an invalid certificate, missing certificate, incorrect network address, insufficient permission level, or some other reason.

In some embodiments, the logs and metrics library may also cause the device102to maintain a circular buffer to store incoming logs from various modules of the device102. In some embodiments, when the device102malfunctions, a window of logs in the buffer, that may include preceding logs and/or succeeding logs in addition to a log that identifies an error, may be sent to a proxy device and/or a troubleshooting service. In some embodiments, the logs and metrics library may also cause the device102to maintain a connection precedence order for sending the logs. In some embodiments, the connection precedence order may be, in order of priority with highest first: wired Ethernet, WiFi, Bluetooth Low Energy, Standard Bluetooth, wired serial (e.g., Universal Serial Bus (USB), Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C) Bus). However, a different connection precedence order and/or a connection precedence order having other connection techniques may be used in other embodiments. In some embodiments, if the device102is connected to a cloud environment over Transmission Control Protocol/Internet Protocol (TCP/IP), such as over an Ethernet or WiFi connection, the device102may send logs directly to an MQTT topic. If there is a connection failure, such as due to an invalid certificate or endpoint connection failure, an alternate connection mechanism may be used.

In an embodiment, the device environment104may include a router112. In some embodiments, the router112may be a wireless router such as a WiFi router that conforms to one or more Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards. In an embodiment, the device102may communicate with the service provider environment106through the router112. However, it should be understood that the device102may communicate with the service provider environment106through any suitable combination of wired and/or wireless networking components, and that the router112may not be present in some embodiments. In an embodiment, the device environment may include a proxy device114that may act as a proxy device and/or intermediary between the device102and one or more systems of the service provider environment106. In an embodiment, the proxy device114may be a mobile communications device such as a smartphone. In other embodiments, the proxy device114may be some other type of device, such as a tablet device, a laptop computer, a notebook computer, or a desktop computer. The proxy device114may include a processor, memory, data storage, and wireless and/or wired communication network controllers in some embodiments. The proxy device114may include non-transitory computer-readable instructions to perform operations described with respect to the proxy device114and components thereof (e.g., device troubleshooter142). In some embodiments, the device102may attempt to connect automatically to the proxy device114after experiencing a connection failure associated with connection to the service provider environment106, the router112, or the hub device110. In some embodiments, the hub device110and/or the proxy device114may communicate with the service provider environment106through the router112, and/or one or more other networking components, not shown for clarity.

In an embodiment, the service provider environment106may include a message broker116that may route messages to and from the device102through the hub device110, the router112, and/or the proxy device114. In some embodiments, the message broker116may be a MQTT message broker that routes messages based at least in part on MQTT topics identified by the messages. The message broker may be a computer system that includes one or more processors, memory, and non-transitory computer-readable instructions to perform operations described with respect to the message broker116. In some embodiments, messages from the device environment104may pass to and/or from the service provider environment106using some other type of message routing such as through a message server or any other suitable type of message routing.

In various embodiments, a troubleshooting data processor118may be in data communication with the message broker116. In some embodiments, the troubleshooting data processor118may include a log processor120and a log analyzer122. In some embodiments, the log analyzer122may include a plurality of log analyzers to analyze different types of logs and/or logs from different types of devices. In some embodiments, the log analyzer122may include a MQTT log analyzer124, an over-the-air (OTA) log analyzer126, a hub log analyzer128, and a memory log analyzer130. In some embodiments, the log processor120may listen to MQTT topics relating to messages received by the message broker116from the device102. In some embodiments, the troubleshooting data processor118may run in a data plane of a troubleshooting service of the service provider environment106.

The troubleshooting data processor118may be a computer system that includes one or more processors, memory, and non-transitory computer-readable instructions to perform operations described with respect to the troubleshooting data processor118and/or components thereof. In some embodiments, the troubleshooting data processor118or one or more components thereof (e.g., log analyzer122) may be implemented as an application specific integrated circuit (ASIC). The log processor120and/or the log analyzer122may be software modules described by the instructions of the troubleshooting data processor118and run by the one or more processors of the troubleshooting data processor118. In other embodiments, the log processor120and/or the log analyzer122may include their own processor, memory, and computer readable instructions. In some embodiments, the MQTT log analyzer124, the OTA log analyzer126, the hub log analyzer128, and the memory usage log analyzer130are software modules that run as sub-modules of the log analyzer122. In other embodiments, one or more of the MQTT log analyzer124, the OTA log analyzer126, the hub log analyzer128, and the memory usage log analyzer130may be separate computer systems that include one or more processors, memory, instructions to perform log analysis operations, and/or data storage.

In an embodiment, the service provider environment106may include account data storage132and an account interface134to provide access to an account holder136to the account data storage132. In an embodiment, the account holder136may access the account data storage132via a troubleshooting controller138. In some embodiments, the troubleshooting controller138may run in a control plane of a troubleshooting service of the service provider environment106. The troubleshooting controller138may be a computer system that includes one or more processors, memory, and non-transitory computer-readable instructions to perform operations described with respect to the troubleshooting controller138. In some embodiments, the account holder136may be a computer system of a cloud computing services customer (e.g. an original equipment manufacturer (OEM) of the device102or a product-based company that manufactured or is otherwise associated with the device102), operating in a different environment than the service provider environment106. In some embodiments, the account holder136may be in data communication with the account interface134through a network, not shown for clarity. In some embodiments, the account holder136may communicate with the proxy device114via the account interface134and the troubleshooting controller138. In some embodiments, a representative of the account holder136may operate a computer system of the account holder136via a user interface to access account data storage132and/or inference model storage140, and may communicate with the proxy device114via the account interface134and the troubleshooting controller138.

In some embodiments, the troubleshooting data processor118may include a voice analyzer, not shown for clarity, which may take voice input from a user of the proxy device114to determine a device identifier associated with the device102and/or to determine additional information associated with an error of the device102. In some embodiments, the troubleshooting data processor118may analyze one or more logs based at least in part on the voice input to determine a corrective action. In some embodiments, the troubleshooting data processor118may generate a troubleshooting approach based at least in part on the logs, and may communicate the troubleshooting approach to the proxy device114such that the proxy device114is caused to display the troubleshooting approach in text or graphical form, and/or to emit audio signals of synthesized or recorded speech based at least in part on the troubleshooting approach.

In an embodiment, the service provider environment106may include inference model storage140. In some embodiments, the log processor120may associate logs from the device102with a customer identifier and/or a device identifier and store the logs in the account data storage132in association with the customer identifier and/or the device identifier. In some embodiments, the log analyzer122may analyze logs to diagnose issues associated with the device102. In some embodiments, the log analyzer122may determine an inference based at least in part on an inference model and a log. In some embodiments, the log analyzer122may retrieve the inference model from the inference model storage140and may store the inference as a state of the inference model in the inference model storage140. In some embodiments, the log analyzer may determine a corrective action to cause the device102to cease a malfunction, based at least in part on the determined inference. In some embodiments, the account holder136may store one or more inference models in the inference model storage140via the account interface134, and/or may perform other actions via the account interface. In some embodiments, the account interface134is an application programming interface (API). In some embodiments, the account interface134is a graphical user interface (GUI).

In some embodiments, the proxy device114may include a device troubleshooter142that may include a device log analyzer144and a message proxy146. In some embodiments, the device log analyzer144may include more than one type of log analyzer, such as one or more of the log analyzers described with respect to the log analyzer122. In some embodiments, the device log analyzer144may analyze device logs from the device102when sufficient computing resources are available in the proxy device114, and may forward the device logs to the message broker116using the message proxy146for further analysis by the log analyzer122when sufficient computing resources are not available in the proxy device114. In some embodiments, the device troubleshooter142may be an application on the proxy device114that runs in association with a troubleshooting library that includes the device log analyzer144and/or the message proxy146. In some embodiments, the hub device110may include a device troubleshooter similar to the device troubleshooter142, and/or may perform one or more functions described with respect to the proxy device114.

In some embodiments, the service provider environment106includes a proxy device authenticator148to authenticate communications from proxy devices (e.g., proxy device114and/or hub device110). In some embodiments, the proxy device authenticator148authenticates communications from the proxy device114before the proxy device114is allowed access to the troubleshooting controller138. In some embodiments, the proxy device authenticator148may also authenticate communications to the message broker116from one or more devices in the device environment104(e.g. hub device110and/or proxy device114). The proxy device authenticator148may be a computer system that includes one or more processors, memory, and non-transitory computer-readable instructions to perform operations described with respect to the proxy device authenticator148. In some embodiments, the proxy device authenticator may be an authentication layer of a controller interface for the troubleshooting controller138. In some embodiments, the proxy device114may send an authentication request to the proxy device authenticator148and receive an authentication confirmation from the proxy device authenticator148in response to the request, before the proxy device114sends one or more communications to the troubleshooting controller128and/or the message broker116.

FIG. 2illustrates an example flowchart of a process200for troubleshooting a device error in accordance with an embodiment. In an embodiment, the process200may include receiving a log at a block202. In an embodiment, the log may be generated by the device102and received by the service provider environment106(e.g., by the message broker116). In some embodiments, the log may be received from the device102through one of a plurality of different transmission paths, which are also referred to as channels herein. For example, the log may be received through a first channel via the router112, a second channel via the proxy device114, or a third channel via the hub device110. In some embodiments, the log may be stored at a block204. In some embodiments, storing the log at the block204may include storing the log in association with a customer account in a data repository (e.g., in a portion of account data storage132associated with an account identifier of account holder136). In some embodiments, message broker116may route the log to the log processor120, and the log processor120may store the log in account data storage132. In some embodiments, storing the log in association with the customer account may include pooling the log with previously stored logs by storing a log received through a second channel in association with a log previously received through a first channel. In some embodiments, storing the log may include storing the log in association with a device identifier (e.g., an identifier associated with the device102) and/or a device environment identifier (e.g., an identifier associated with the device environment104).

In some embodiments, the process200may include determining, at a decision block206, whether further action is needed. In some embodiments, the log analyzer122may determine whether further action is needed based at least in part on the log. In some embodiments, the log analyzer122may identify the log as being a log that requires further action based at least in part on one or more identifiers in the log. In various embodiments, the one or more identifiers may include an error identifier, a retraining identifier, a message type identifier, and/or any other suitable identifier. In some embodiments, determining whether further action is needed may include parsing the log to extract the one or more identifiers (e.g., with the log processor120or the log analyzer122).

If, at the decision block206, it is determined that further action is needed, the process200may include determining whether a device error is indicated that requires further action at a decision block208. In some embodiments, determining whether a device error is indicated may be performed by the log analyzer122. In some embodiments, determining whether a device error is indicated may be based at least in part on an error identifier in the log that identifies a malfunction of the device that generated the log (e.g., device102). In some embodiments, determining whether a device error is indicated may include parsing the log to extract one or more error identifiers (e.g., with the log processor120or the log analyzer122).

If, at the decision block208, it is determined that a device error is indicated, the process200may include determining a corrective action at a block210. In some embodiments, the log analyzer122may determine the corrective action based at least in part on an inference model and the error identifier. In some embodiments, the error identifier may be an error code, a string in the LOG STRING field of the log, any other suitable error identifier extracted from the log, or a combination thereof. In some embodiments, determining the corrective action may be based at least in part on a module identified in the MODULE field of the log. In some embodiments, determining the corrective action may include selecting a log analyzer from a plurality of log analyzers to analyze the log. In some embodiments, if the log is received as a MQTT message transmission, selecting the log analyzer may include selecting the MQTT log analyzer124. In some embodiments, determining the corrective action may include determining an inference by using at least the error identifier from a first log, and one or more data elements from a second log as inputs to the inference model. In some embodiments, determining a corrective action at the block210may include determining to send a message that will cause the device that generated the log to cease malfunctioning. In some embodiments, determining the corrective action may include determining the corrective action based at least in part on using a device state indicator as an input to the inference model. In some embodiments, the device state indicator may indicate a firmware version running on the device102when the log was generated, a software version running on the device102, an operating status of the device102, or some other state of the device102. In some embodiments, the device state indicator may be included in the log. In some embodiments, the device state indicator may be retrieved from the data repository, and may represent a last known state of the device102.

In some embodiments, at a block212, the process200may include sending a message based at least in part on the corrective action. In various embodiments, the message may be sent by the troubleshooting data processor118to the device102through the message broker116. In some embodiments, the message may be sent to the device102via the proxy device114or the hub device110. In some embodiments, the corrective action may be to send a firmware update, software update, software patch, network configuration data (e.g., one or more network addresses), and/or a digital certificate to the device102. In some embodiments, the process200may return to the block202where one or more additional logs may be received.

If, at the decision block208, it is determined that a device error is not indicated, the process200may include determining whether to retrain an inference model at a decision block214. In some embodiments, determining that an inference model should be retrained at the block214occurs after one or more corrective actions have been determined at the block210in one or more previous passes through the process200. In some embodiments, determining whether to retrain an inference model may be based at least in part on one or more indicators in the log received at the block202. In some embodiments, the log analyzer122may determine whether to retrain an inference model. If, at the decision block214, it is determined to retrain an inference model, the process200may include retraining an inference model at a block216. In some embodiments, retraining the inference model may be based at least in part on a corrective action determined at the block210with respect to a log previously received at the block202. In some embodiments, retraining the inference model may be based at least in part on an indication that the previously determined corrective action was successful (e.g., with a device state identifier and/or one or more log data elements that indicate the corrective action was successful). In some embodiments, retraining the inference model may be based at least in part on an indication that the previously determined corrective action was unsuccessful (e.g., with a device state identifier and/or one or more log data elements that indicate the corrective action was unsuccessful). In some embodiments, retraining the inference model is performed by a retraining module (not shown for clarity) running on one or more processors of the troubleshooting data processor118. In some embodiments, determining a corrective action at the block210may be based at least in part on the retrained inference model when a device error requiring further action is indicated after the inference model has been retrained. If, at the decision block214, it is determined not to retrain an inference model, the process200may include performing other actions at a block218. In some embodiments, the process200may return to the block202where one or more additional logs may be received.

FIG. 3illustrates an example flowchart of a process300for determining a corrective action in accordance with an embodiment. In some embodiments, the log analyzer122described with respect toFIG. 1performs the operations of the process300. In some embodiments, one or more aspects described with respect to the process300may be included in determining the corrective action at the block210described with respect toFIG. 2. In some embodiments, the process300may include selecting an inference model at a block302. In some embodiments, selecting the inference model may include retrieving the inference model (e.g., from inference model storage140). In some embodiments, the inference model may be selected (e.g., by the log analyzer122) based at least in part on a log (e.g., a log received from device102at the block202). In some embodiments, the inference model may be selected from a plurality of inference models based at least in part on a device identifier, a device type identifier, an account identifier, an error identifier, and/or any other suitable data element.

In some embodiments, the process300may include determining the inputs for the selected inference model at a block304. At a decision block306, the process300may include determining whether the inputs include state information. In some embodiments, the state information may include one or more device state identifiers that identify a state of the device that generated the log. In some embodiments, the one or more device state identifiers may include a firmware version identifier that identifies the firmware version running on the device when the log was generated. In some embodiments, the one or more device state identifiers may identify a global state of the device102(e.g., the state of the device102in a finite state machine model of device102operation).

If, at the decision block306, it was determined that the inputs include state information, the process300may include retrieving the state information at a block308. In some embodiments, retrieving the state information may include parsing the log to extract the state information (e.g., a firmware version identifier). In some embodiments, retrieving the state information may include retrieving the state information from a data repository (e.g., account data storage132) based at least in part on one or more data elements in the log (e.g., a device identifier and/or an account identifier), where the retrieved state information may be the last known installed firmware version and/or any other suitable device state information.

In some embodiments, the process300may include determining, at a decision block310, whether the inputs require a previous log. If, at the decision block310, it is determined that the inputs require a previous log, the process300may include retrieving the previous log at a block312in some embodiments. In some embodiments, the previous log may be retrieved from a data repository (e.g., account data storage132). In various embodiments, the previous log may be retrieved based at least in part on one or more data elements in the log. In some embodiments, the previous log may be retrieved based at least in part on one or more of a device identifier, an account identifier, and a sequence identifier. In some embodiments, the process300may include determining a corrective action at a block314based at least in part on the inference model and inputs to the inference model.

FIG. 4illustrates an example flowchart of a process400for troubleshooting a device error with a proxy device (e.g., proxy device114), in accordance with an embodiment. In some embodiments, the process400may include receiving a log at a block402. In an embodiment, the log may be generated by the device102and received by the proxy device114. In some embodiments, the device102may have been previously paired with the proxy device114, and may automatically connect with the proxy device114through a communication technique such as BLE. In some embodiments, a user of the proxy device114may cause the proxy device114to initiate the connection with the device102via a user interface if the proxy device114had not been previously paired or associated with the device102. At a decision block404, the process400may include determining whether to determine a corrective action locally. In some embodiments, the operations of the decision block404are performed by the device log analyzer144. In some embodiments, determining whether to perform the corrective action locally may be based at least in part on the log (e.g., an error identifier in the log). In some embodiments, determining whether to perform the corrective action locally may be based at least in part on determining whether one or more computer resources of the proxy device (e.g., processor type, available memory, availability of an inference model, and/or availability of inputs to an inference model such as previous logs or device state information) are sufficient to determine the corrective action.

If, at the decision block404, it was determined to determine the corrective action locally, the process400may include determining a corrective action at a block406. In some embodiments, operations of the block406are performed by the device log analyzer144. In some embodiments, determining the corrective action may be performed in a similar manner to that described with respect to process300, but the inference model and inputs to the inference model may be retrieved from local storage on the proxy device114rather than from account data storage132and inference model storage140. In some embodiments, it may be determined to determine the corrective action locally at the decision block404even if one or more inputs to an inference model and/or the inference model itself are not currently available on the proxy device114. In some embodiments, determining the corrective action at the block406may include determining whether an inference model and/or inputs to an inference model such as additional logs or device state information are required. If one or more additional items are needed (e.g., the inference model and/or the inputs to an inference model), determining the corrective action at the block406may include retrieving the one or more additional items from the service provider environment106. In some embodiments, the proxy device114may retrieve an inference model from inference model storage140and/or inputs to an inference model such as additional logs, data elements from one or more logs, or device state information from the account data storage132(e.g., via the troubleshooting controller138).

If, at the decision block404, it was determined that the corrective action should not be determined locally, the process400may include sending one or more portions of the log, at a block408, to another computer system for analysis (e.g., service provider environment106). In some embodiments, the one or more portions of the log may be sent by the message proxy146of the proxy device114to the message broker116. In some embodiments, the log may be sent using MQTT over a Web Socket protocol to the message broker116, however it should be understood than any suitable protocol may be used in various embodiments. In some embodiments, a warning may be displayed on the proxy device114if the corrective action is not determined locally. In some embodiments, data corresponding to a corrective action may be received at a block410in response to the sent one or more portions of the log. In some embodiments, the data corresponding to the corrective action may be received by the proxy device114from the message broker116.

In some embodiments, at a block412, the process400may include sending a message to the device that generated the log (e.g., device102), based at least in part on the determined corrective action at the block406or the data corresponding to a corrective action received at the block410. In some embodiments, the message may include a firmware or software update that causes the device to cease malfunctioning. In some embodiments, the message may include a digital certificate that causes the device to have sufficient permissions to access one or more IoT services in a cloud computing environment (e.g., service provider environment106). In some embodiments, the device troubleshooter142directs the proxy device114to send the message to the device102. In some embodiments, at a block414, the process400may include performing other actions (e.g., sending a corrective action taken indicator in association with the log from the proxy device414to the message broker116). In some embodiments, performing other actions at the block414may include receiving an indication of whether the corrective action was successful from the service provider environment106(e.g., from the log processor120or the log analyzer122). In some embodiments, the indication may be automatically generated by the troubleshooting data processor118and provided to the proxy device114after a successful reconnection of the device102to the service provider environment106(e.g., to message broker116) via a communication channel that does not include the proxy device114. In some embodiments, the indication of whether the corrective action was successful may be a device state indicator for the device102. In some embodiments, the proxy device114may generate and send a request for the indication of whether the corrective action was successful to the service provider environment106(e.g., to account data storage132via troubleshooting controller138) before receiving the indication in response to the request.

FIG. 5illustrates aspects of an example system500for implementing aspects in accordance with an embodiment. As will be appreciated, although a web-based system is used for purposes of explanation, different systems may be used, as appropriate, to implement various embodiments. In an embodiment, the system includes an electronic client device502, which includes any appropriate device operable to send and/or receive requests, messages, or information over an appropriate network504and convey information back to a user of the device. Examples of such client devices include personal computers, cellular or other mobile phones, handheld messaging devices, laptop computers, tablet computers, set-top boxes, personal data assistants, embedded computer systems, electronic book readers, and the like. In an embodiment, the network includes any appropriate network, including an intranet, the Internet, a cellular network, a local area network, a satellite network or any other such network and/or combination thereof, and components used for such a system depend at least in part upon the type of network and/or system selected. Many protocols and components for communicating via such a network are well known and will not be discussed herein in detail. In an embodiment, communication over the network is enabled by wired and/or wireless connections and combinations thereof. In an embodiment, the network includes the Internet and/or other publicly addressable communications network, as the system includes a web server506for receiving requests and serving content in response thereto, although for other networks an alternative device serving a similar purpose could be used as would be apparent to one of ordinary skill in the art. In some embodiments, the client device may include one or more processors, memory, and one or more storage devices. In some embodiments, the client device102may implement one or more aspects of the device102, the proxy device114, the hub device110, and/or the account holder136described with respect toFIG. 1, and/or aspects of the process400described with respect toFIG. 4.

In an embodiment, the illustrative system includes at least one application server508and a data store510, and it should be understood that there can be several application servers, layers or other elements, processes or components, which may be chained or otherwise configured, which can interact to perform tasks such as obtaining data from an appropriate data store. Servers, in an embodiment, are implemented as hardware devices, virtual computer systems, programming modules being executed on a computer system, and/or other devices configured with hardware and/or software to receive and respond to communications (e.g., web service application programming interface (API) requests) over a network. As used herein, unless otherwise stated or clear from context, the term “data store” refers to any device or combination of devices capable of storing, accessing and retrieving data, which may include any combination and number of data servers, databases, data storage devices and data storage media, in any standard, distributed, virtual or clustered system. Data stores, in an embodiment, communicate with block-level and/or object-level interfaces. The application server can include any appropriate hardware, software and firmware for integrating with the data store as needed to execute aspects of one or more applications for the client device, handling some or all of the data access and business logic for an application. In some embodiments, one or more of the application servers508and/or one or more of the web servers506may implement one or more aspects of the message broker116, the troubleshooting data processor118, the troubleshooting controller138, and/or the account interface134described with respect toFIG. 1, and/or aspects of the process200described with respect toFIG. 2and the process300described with respect toFIG. 3. In some embodiments, the data store510may implement one or more aspects of the account data storage132and/or the inference model storage140described with respect toFIG. 1.

In an embodiment, the application server provides access control services in cooperation with the data store and generates content including but not limited to text, graphics, audio, video and/or other content that is provided to a user associated with the client device by the web server in the form of HyperText Markup Language (“HTML”), Extensible Markup Language (“XML”), JavaScript, Cascading Style Sheets (“CSS”), JavaScript Object Notation (JSON), and/or another appropriate client-side or other structured language. Content transferred to a client device, in an embodiment, is processed by the client device to provide the content in one or more forms including but not limited to forms that are perceptible to the user audibly, visually and/or through other senses. The handling of all requests and responses, as well as the delivery of content between the client device502and the application server508, in an embodiment, is handled by the web server using PHP: Hypertext Preprocessor (“PHP”), Python, Ruby, Perl, Java, HTML, XML, JSON, and/or another appropriate server-side structured language in this example. In an embodiment, operations described herein as being performed by a single device are performed collectively by multiple devices that form a distributed and/or virtual system.

The data store510, in an embodiment, includes several separate data tables, databases, data documents, dynamic data storage schemes and/or other data storage mechanisms and media for storing data relating to a particular aspect of the present disclosure. In an embodiment, the data store illustrated includes mechanisms for storing production data512and user information516, which are used to serve content for the production side. The data store also is shown to include a mechanism for storing log data514, which is used, in an embodiment, for reporting, computing resource management, analysis or other such purposes. In an embodiment, other aspects such as page image information and access rights information (e.g., access control policies or other encodings of permissions) are stored in the data store in any of the above listed mechanisms as appropriate or in additional mechanisms in the data store510.

The data store510, in an embodiment, is operable, through logic associated therewith, to receive instructions from the application server508and obtain, update or otherwise process data in response thereto, and the application server508provides static, dynamic, or a combination of static and dynamic data in response to the received instructions. In an embodiment, dynamic data, such as data used in web logs (blogs), shopping applications, news services, and other such applications, are generated by server-side structured languages as described herein or are provided by a content management system (“CMS”) operating on or under the control of the application server. In an embodiment, a user, through a device operated by the user, submits a search request for a certain type of item. In this example, the data store accesses the user information to verify the identity of the user, accesses the catalog detail information to obtain information about items of that type, and returns the information to the user, such as in a results listing on a web page that the user views via a browser on the user device502. Continuing with this example, information for a particular item of interest is viewed in a dedicated page or window of the browser. It should be noted, however, that embodiments of the present disclosure are not necessarily limited to the context of web pages, but are more generally applicable to processing requests in general, where the requests are not necessarily requests for content. Example requests include requests to manage and/or interact with computing resources hosted by the system500and/or another system, such as for launching, terminating, deleting, modifying, reading, and/or otherwise accessing such computing resources.

In an embodiment, each server typically includes an operating system that provides executable program instructions for the general administration and operation of that server and includes a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, if executed by a processor of the server, cause or otherwise allow the server to perform its intended functions (e.g., the functions are performed as a result of one or more processors of the server executing instructions stored on a computer-readable storage medium).

The system500, in an embodiment, is a distributed and/or virtual computing system utilizing several computer systems and components that are interconnected via communication links (e.g., transmission control protocol (TCP) connections and/or transport layer security (TLS) or other cryptographically protected communication sessions), using one or more computer networks or direct connections. However, it will be appreciated by those of ordinary skill in the art that such a system could operate in a system having fewer or a greater number of components than are illustrated inFIG. 5. Thus, the depiction of the system500inFIG. 5should be taken as being illustrative in nature and not limiting to the scope of the disclosure.

The various embodiments further can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices or processing devices that can be used to operate any of a number of applications. In an embodiment, user or client devices include any of a number of computers, such as desktop, laptop or tablet computers running a standard operating system, as well as cellular (mobile), wireless and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols, and such a system also includes a number of workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. In an embodiment, these devices also include other electronic devices, such as dummy terminals, thin-clients, gaming systems and other devices capable of communicating via a network, and virtual devices such as virtual machines, hypervisors, software containers utilizing operating-system level virtualization and other virtual devices or non-virtual devices supporting virtualization capable of communicating via a network.