locked
Device connectivity status via device twin - is it possible? RRS feed

  • Question

  • HI,

    What is the best way to obtain the device connectivity status based on the operations monitoring messages? What we are trying to achieve is to implements a heartbeat functionality, and thus to show on a dashboard whether the device is currently connected, last errors executing commands, etc. 

    Is there a way to put such status information in the device twin? I think this is a right place to keep the last status.

    And last: is it possible view Stream analytics to store status messages in a database and if yes - how?

    Thanks in advance,

    Ivan Dragoev

    UPDATE:

    After digging in the documentation I managed to find that the device identity should have the connectivity information. However it is not recommended to use it in production, and it is suggested to be implemented manually.

    But when I think about device identity and the device twin, I came to the conclusion, that the first one should only be a "description" of the device - type, commands, etc. The device twin, should be more about the current state of the device, including the connectivity status, errors, etc.

    Thus, we have to deal only with device twins and rarely we are going to ask device identity.

    Ivan Dragoev


    • Edited by Ivan Dragoev Wednesday, November 9, 2016 3:49 PM Update
    Wednesday, November 9, 2016 1:15 PM

Answers

  • The device identity properties are all listed here. Most are read-only so it was never intended to store dynamic device state/properties.  The device twin has been designed specifically for this purpose.

    By nature, the device twin is fully customizable.  It's up to the device application to set reported properties and the backend application to set desired properties.  The twin can accommodate whatever model is required for the particular IoT solution.

    To your question, we don't have this functionality today.  In a very near release we plan to add change notification ability to reported properties in the twin (desired properties already has this).  This would allow to easily keep track of any device property changes in a storage end-point of your choice.


    - Briton, Microsoft Azure IoT Engineering

    • Marked as answer by Ivan Dragoev Tuesday, November 15, 2016 1:00 PM
    Friday, November 11, 2016 8:52 PM

All replies

  • Ivan, you are correct, the device identity registry is designed to be used to manage the per-device credentials for access to your IoT Hub. While it does store information on connection state, this information should only be used for development and debugging purposes, not for real-time operations management.

    We do have intentions of adding a real-time heartbeat service capability to provide the functionality you describe and we hope to have more information on this soon.  For the time being, however, you should look into using the device twin and/or direct methods to retrieve, store, and query device connectivity state.  This functionality is currently in preview but will be made generally available later this month.


    - Briton, Microsoft Azure IoT Engineering


    Wednesday, November 9, 2016 5:40 PM
  • Briton,

    - thanks for this great news. I hope that the C# SDK for device will be available also (now is only for Node.js).

    Roman 



    • Edited by Roman Kiss Wednesday, November 9, 2016 10:21 PM
    Wednesday, November 9, 2016 10:20 PM
  • Hi Briton,

    Thanks for the reply.

    In the tutorials and dev guides, the device identity also keeps a description of device commands and properties. Now, having the device twin, I think it is better that to the twin itself and to leave the identity to keep only identity -related data - keys, etc. Thus it will be much more consistent than how it is now.

    Some of the device we are working on can change their profile - dynamically add new direct methods and properties, because the devices are extendable.

    What do you think about this suggestion?

    And one last thing: we want to track and store any device twin changes in a log - probably in a table store. Is there an endpoint that we can use to implement such "on property change" functionality?

    Thanks.


    Ivan Dragoev

    Thursday, November 10, 2016 8:37 AM
  • Coming very soon Roman, stay tuned :).

    - Briton, Microsoft Azure IoT Engineering

    Friday, November 11, 2016 8:39 PM
  • The device identity properties are all listed here. Most are read-only so it was never intended to store dynamic device state/properties.  The device twin has been designed specifically for this purpose.

    By nature, the device twin is fully customizable.  It's up to the device application to set reported properties and the backend application to set desired properties.  The twin can accommodate whatever model is required for the particular IoT solution.

    To your question, we don't have this functionality today.  In a very near release we plan to add change notification ability to reported properties in the twin (desired properties already has this).  This would allow to easily keep track of any device property changes in a storage end-point of your choice.


    - Briton, Microsoft Azure IoT Engineering

    • Marked as answer by Ivan Dragoev Tuesday, November 15, 2016 1:00 PM
    Friday, November 11, 2016 8:52 PM
  • Hi Briton,

    is there a plan for device twins JSON documents be available as an input reference for ASA stream job? Now, we have to use an additional worker role for exporting the device twins JSON documents to the blobs.

    Thanks

    Roman



    • Edited by Roman Kiss Friday, November 11, 2016 10:00 PM
    Friday, November 11, 2016 9:59 PM
  • Hey Roman, same answer as above.  Once we have reported property change notifications in the twin, this will become a much easier thing to do.  Look for more information on this feature very soon.

    - Briton, Microsoft Azure IoT Engineering

    Friday, November 11, 2016 10:46 PM
  • Briton,

    - using a reported change notification for updating "my device twins storage" to make a reference to the ASA job is a workaround solution. From the IoT architecture and conceptual point of the view, it should be IoT Hub allows to make a "plug&play" pipeline of the device twins JSON documents as an input reference to the stream job. Exactly the same way like we have it today for data stream. 

    In other words, the device twins storage (supposing this is a blob storage) should be its storage account, key, container and path name was available for input referencing at the stream job. 

    Thanks

    Roman  



    • Edited by Roman Kiss Saturday, November 12, 2016 9:50 AM
    • Proposed as answer by Roman Kiss Monday, November 14, 2016 9:51 AM
    Saturday, November 12, 2016 9:50 AM