Status Device Supervision for better IoT applications

Share This

In this article we want to share with you our vision on how we can supervise the status of devices to create better IoT or M2M applications. This is a Best Practice that we recommend and it is based on our experience in developing large corporate M2M projects.

Normally M2M developers check the status of a device with only 2 possible Status: Disconnected or OK. They can do so by checking Data Streams and their expected frequency. Like in this diagram:

2 Status Device Supervision

You can also program your device to keep an open connection with the server to know if your device is connected or disconnected. But under the IOT paradigm where Internet and Energy resources need to be smart managed, this approach is highly dissuaded.

Lets take an example project where we need to supervise the status of a device:

Project Scenario:

Imagine a project where you build an RFID reader controlling a door opening. When a RFID tag is read, it sends a data stream to Carriots and if credentials are granted then Carriots sends an order to the PLC that opens the door. This door should be opened at least one time in a workday and exceptionally in a weekend. Imagine that as part of your project you need to monitor the status of the RFID reader to make sure it is OK. Carriots could check if a data stream has been received in a time range, a day and then check if the reader is working correctly.

Following this example, checking the RFID reader health is a matter of tracking data streams once a day. But if in a weekend the reader is not used, it seems that the reader is not working properly. So, for checking if RFID reader is alive its better done by sending status streams periodically and expect their reception in Carriots in a defined time range, independently from data streams.

So in order to help developers create better applications, Carriots has implemented some unique features, related to device supervision, that are optional to use. Lets review them and how you can take advantage of them.

Carriots features related to Device Status:

At Carriots we wanted to improve this basic functionality with the possibility of:

  • Having extra statuses based on information status information of the device and application data sent by the device.
  • Having the possibility to program actions based on status changes.

When a Carriots device is created there are two kinds of streams that can be sent associated to that device: data streams and status streams. Those streams can be controlled in order to expect the reception of one of them in a time range.

Carriots offers two device properties to check streams expected reception in a time range.

  • Data Stream Frequency – It is a number representing the time range in which a data stream should be received for that device. Expressed in minutes.
  • Status Stream Frequency – It is a number representing the time range in which a status stream should be received for that device. Expressed in minutes.

When a stream is not received within the expected time range, Carriots changes it’s inner status and fires an event.

Possible Device Statuses at Carriots:

These are the different inner device status in Carriots:

  • Disconnected – no status stream nor data stream received in the expected time range defined by “Status Stream Frequency” and “Data Stream Frequency” device’s properties.
  • No_data – no data stream received in the expected time range defined by “Data Stream Frequency” device’s property. Status stream received.
  • No_status – no status stream received in the expected time range defined by “Status Stream Frequency” device’s property. Data stream received.
  • OK – Data and status streams received in the expected time range defined by “Status Stream Frequency” and “Data Stream Frequency” device’s properties.

This diagrams shows how the flow of status change:

4 Status Device Supervision in Carriots

Programming actions on Status Change Event:

When Carriots detects stream absence within a defined time range the event “Event Device Change State” is fired. When a device changes its inner status, Carriots raise an event and injects the context to be used in listeners and rules scripts. A status change implies two statuses: one before the change takes place and the other when the change is done. For example, a device can be in a “no_data” status and may change to “disconnected” or from “OK” to “no_status” and so on.

With this feature you can program a Listener in Carriots with a Groovy scripts that can perform pretty much any action that you want, from activating a repair procedure to detect that an abnormal behaviour in the application.

You can get more information on this, by reading our documentation on Device Inner Status.

Please let us know what you think of these features by posting your comments to this post.

Alvaro Everlet

Mr. Everlet is an experienced manager and business oriented technical solution provider. His skills help companies successfully build Internet of Things Solutions that meet both their technical and business goals providing: business modelling, competitive analysis, technology framework definition and implantation, action plans, engineering supervision ending with marketing and sales assessment. Lecturer at IE International Business School.

Mr. Everlet earned his Bachelor of Science in Computer Science from The Polytechnic University of Madrid and King Juan Carlos University. Holds also a Master in Business Administration from the Business Management School (EAE) of Madrid.
Alvaro Everlet

Share This
Alvaro Everlet

About Alvaro Everlet

Mr. Everlet is an experienced manager and business oriented technical solution provider. His skills help companies successfully build Internet of Things Solutions that meet both their technical and business goals providing: business modelling, competitive analysis, technology framework definition and implantation, action plans, engineering supervision ending with marketing and sales assessment. Lecturer at IE International Business School. Mr. Everlet earned his Bachelor of Science in Computer Science from The Polytechnic University of Madrid and King Juan Carlos University. Holds also a Master in Business Administration from the Business Management School (EAE) of Madrid.

One response to “Status Device Supervision for better IoT applications”

  1. Avatar Zambiot says:

    Carriots – I really like having the multiple data states as I have made good use of Status Streams and Data Streams. However, I disagree, and wish it would change, that the first data or status stream takes the device’s status directly to OK. This indication then is a false sense that both data and status has been received. Instead on an application side I have to implement some conditional logic to see if it was a first stream or not. This is messy. To get the full value from the states of No Status, No Data and OK, there should not be any shortcuts or conditions to OK. It is or it isn’t. OK should only represent one state and not be conditional.

    Thank you for creating this platform and thinking through all these topics.