Jump to content


Give us feedback on Device Status Supervision

device status supervision monitoring

  • Please log in to reply
3 replies to this topic

#1 mcastillo


    Carriots CEO

  • Administrators
  • 34 posts
  • LocationMadrid

Posted 13 May 2013 - 11:25 AM

As you might have notice we have published a post on our blog talking about Device Status monitoring and recommending a Best Practice to do it using Carriots Features. You can read the post here https://blog.carriot...t-applications/


We would like to know what you think of this Best Practice and how you would use it. Please share your experiences with the rest of the community.


Also feel free to make any suggestion on this topic. 


Thank you.




#2 Zambiot


    Advanced Member

  • Members
  • PipPipPip
  • 94 posts
  • LocationAsia

Posted 16 May 2013 - 06:45 AM

Thank you for asking Miguel.  I recently posted a comment on the blog post, but now that I see this forum topic, this is the better place to discuss it.


I think 'OK' should only mean one thing.  It should mean that Data Streams AND Status Streams are arriving within their specified frequency.  Because 'OK' has that initial condition, a shortcut to 'OK' status with either streams arrival, that the meaning of OK is polluted with a conditional.  Therefore, if an application is relying on OK status to mean something, it is now the application that has to build in a check to see if 'OK' really means that Data Streams AND Status Streams have arrived, or if it was just an single initial stream that caused the status.


I've been using Status and Data Streams.  I like having the distinction.  I like knowing if the device is fully responsive.  For instance in my device, status streams would keep posting even though the device may be disconnected from the sensor system (no data streams posting)


I think the naming 'No_data' and 'No_status' are slightly ambiguous, but I have gotten familiar as I use them.  As an example of how I like to think of the different states.


Str: NG, Sta: NG = disconnected (or NG)

Str: OK, Sta: NG = No_status

Str: NG, Sta: OK = No_data

Str: OK, Sta: OK = OK (or Connected)


NG = no good

#3 jpastor


    Development leader

  • Administrators
  • 178 posts

Posted 18 May 2013 - 11:42 AM

Hello Zambiot.


You're right about those OK shortcuts. It was a hot discussion here, both internally and with our customers. We finally adopted this solution because we want to bring more flexibility and support for specific use cases that follows a more straightforward approach.


Those use cases are:

  • Devices that only send data streams. For example a thermometer. Users checks device connectivity by expecting only data streams arrival. So for them there are two status to think about: OK or disconnected. 
  • Devices that only send status streams. For example a machine monitor checking for signal coverage and battery level. It follows the same pattern than the example before, but using status streams.
  • Devices that send data and status streams. In this case, the first stream received will change device status to OK because Carriots don’t know if another type of stream will be received (this follows the previous use cases approach). If no stream of the same type is received, then Carriots will change its status to disconnected according to the corresponding frequency. If another type of stream is received, then all the 4-status logic is applied.


We think this approach allows more flexibility and keeps the logic consistent for each use case. It will be up to each user to choose their use case.


Thanks for your comments!

#4 Zambiot


    Advanced Member

  • Members
  • PipPipPip
  • 94 posts
  • LocationAsia

Posted 18 May 2013 - 02:23 PM

jpastor - thank you, I can see the different cases based on your description.  Maybe this would warrant some setting when creating a device?  Then no compromises anywhere.  

Also tagged with one or more of these keywords: device, status, supervision, monitoring

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users