The present invention relates to a method and a system for monitoring a connection status of a device, in particular an IoT device.
Nowadays vast amount of user devices, in particular IoT (Internet of Things) devices, such as appliances, are able to be remotely controlled by through cloud entities. This means that many messages are exchanged between the cloud and controlled devices (objects). Many of those messages may be lost due to lack of connectivity on a device side, due to for example home network not connected to the Internet, device power off, insufficient Wi-Fi signal quality.
There are several existing solutions to control the connection status. One is to send messages to a device and then wait for an acknowledgment. In case the device is not connected the acknowledgment will not come back, so after a certain number of retries it will be declared disconnected. The other solution is to send a probe message (a “ping”) to the device to monitor the connection status. The real status is known up to the moment of answer received, but the information becomes obsolete immediately after. In both cases several messages are sent to the device when it is connected to verify that it still is, and when it is not connected to understand that it is not.
A US patent application US20090013064 discloses a method to support a sleep mode for an embedded device. The method comprises transmission of MQTT messages, including a LWT message, but for the purpose of buffering of messages that are directed to a sleeping device and it does not deal with monitoring the status of the device to communicate the status to another remote device.
The existing solutions provide a poor user experience as discovering an unconnected device require fairly long timeouts and unnecessary transmission of messages.
Therefore, there is a need to provide a solution to allow knowing the connection status of a network device that will reduce transmission of messages and the response time.
There is disclosed a method for monitoring, by a device manager at a back-end server a connection status of a device accessible via a network by a broker using MQTT (Message Queuing Telemetry Transport) commands, the method comprising performing at the broker the steps of: establishing a handshake connection with the device; receiving from the device an LWT (Last Will and Testament) message; notifying the device manager about the device connection status as connected; periodically sending to the device at least one probe message; and if no response to the probe message is received from the device, sending the LWT message to the device manager to notify the device manager about the device connection status as disconnected.
The method may further comprise communicating the device status from the device manager to remote devices.
There is also disclosed a non-transitory computer readable storage medium comprising instructions that, when executed by a computer, enable monitoring a connection status of a device in accordance with the method as described above.
Further, there is disclosed a back-end server for monitoring a connection status of a device accessible via a network, the back-end server comprising: a device manager configured to monitor the connection status of the device; and a broker configured to communicate with the device using MQTT (Message Queuing Telemetry Transport) commands by: establishing a handshake connection with the device; receiving from the device an LWT (Last Will and Testament) message; notifying the device manager about the device connection status as connected; periodically sending to the device at least one probe message; and if no response to the probe message is received from the device, sending the LWT message to the device manager to notify the device manager about the device connection status as disconnected.
The device manager is configured to communicate the device status to remote devices.
Further details and features of the present invention, its nature and various advantages will become more apparent from the following detailed description of the preferred embodiments shown in drawings, in which:
Some portions of the detailed description which follows are presented in terms of data processing procedures, steps or other symbolic representations of operations on data bits that can be performed on computer memory. Therefore, a computer executes such logical steps thus requiring physical manipulations of physical quantities.
Usually these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. For reasons of common usage, these signals are referred to as bits, packets, messages, values, elements, symbols, characters, terms, numbers, or the like.
Additionally, all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Terms such as “processing” or “creating” or “transferring” or “executing” or “determining” or “detecting” or “obtaining” or “selecting” or “calculating” or “generating” or the like, refer to the action and processes of a computer system that manipulates and transforms data represented as physical (electronic) quantities within the computer's registers and memories into other data similarly represented as physical quantities within the memories or registers or other such information storage.
A computer-readable (storage) medium, such as referred to herein, typically may be non-transitory and/or comprise a non-transitory device. In this context, a non-transitory storage medium may include a device that may be tangible, meaning that the device has a concrete physical form, although the device may change its physical state. Thus, for example, non-transitory refers to a device remaining tangible despite a change in state.
A device 100 represents a device (an IoT device, an appliance) which is controlled by a mobile application 151 run on a controlling device 150, such as a smartphone 150 or the like.
The system comprises a cloud solution operations module 160 providing software as a service (SaaS) operation 161.
The system further comprises a back-end server 140 comprising a service enablement back-end 141 module for allowing administration of the server 140, a device manager 143 for managing control devices, a machine to machine (M2M) back-end for communicating with the devices 100 and an MQTT broker module 144 responsible for receiving messages, filtering messages and sending messages to subscribed clients. The MQTT broker 144 is also responsible for the authentication and authorization of clients.
The back-end server communicates with the devices 100 via a network, preferably via the Internet 130.
The device 100 comprises a connectivity module 120 with a data model and protocol module 121 for communicating via an antenna 122, a connectivity agent (CA) 123 for handling the connection by means of an MQTT client 124 which generally represents a device with an MQTT Library connected to an MQTT broker over any kind of network. The connectivity module 120 translates the signals from/to the internal circuits/units of the device 100 such as a device main control unit 111 a UI (User Interface) or service port 112 and memory 113.
As described above, in the solution presented herein, the MQTT broker 144 is instructed to send a message to a cloud endpoint on a behalf of device endpoints each time the link between the MQTT broker and the device endpoint is interrupted, to notify that device endpoint state is “DISCONNECTED”. And every time the MQTT connection is restored, the device endpoint immediately sends a message (see
This allows the cloud endpoint to know the current connection status of every device at any moment without sending cyclic probe messages to device endpoints. This allows to reduce the amount of transmitted messages in case of an active connection (no need to actively monitor the connectivity status) and in case of a disconnection (no need to send messages waiting for a response to verify the restoration of the connection). As a result, the end user sees immediately the connectivity status of the device without delays due to timeout of probe messages.
While the invention presented herein has been depicted, described, and has been defined with reference to particular preferred embodiments, such references and examples of implementation in the foregoing specification do not imply any limitation on the invention. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader scope of the technical concept. The presented preferred embodiments are exemplary only, and are not exhaustive of the scope of the technical concept presented herein.
Accordingly, the scope of protection is not limited to the preferred embodiments described in the specification, but is only limited by the claims that follow.
Number | Date | Country | Kind |
---|---|---|---|
EP16201834.5 | Dec 2016 | EP | regional |