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:
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:
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:
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.