Hi Ruwan, +1 for this, Having the communication history through a common stream will help us to build an analytics solution for health status, anomaly detection .. etc.
On Mon, May 8, 2017 at 12:35 PM, Ruwan Yatawara <[email protected]> wrote: > Hi Everyone, > > I am working on $subject as part of the effort in trying to provide dig > down analytics for devices. > > The resulting graph would look something like the following (Please > disregard portion reading connected-unterminated), with the help of [1] and > will give an would indicate whether the device in question was able to get > back to IoT Server in a timely manner at the expected monitoring frequency > specified. > [image: Inline image 1] > *Source: [2]* > we can't infer whether the device is disconnected from the server using the raw history data points right?. We might need todo some form of a time series analytisis on the device to server communication (This will vary depend on the frequency of the communication for each device type) and then predict the device status. The communication history data will help us build a solution for the health status. > Whilst attempting this I noticed that we do not have an auditing mechanism > in place to record important activities, as yet. If you take this flow, for > example, the monitoring frequency is something configurable and will change > from time to time. We need to know at which point the transition was made. > > Therefore I propose, that we come up with a central audit table to record > system activities, like updates to platform configurations, in a central > table. Each activity can have a logging code, and we can purge these > records from time to time, based on data growth. > +1 we do this only for operation, but we should have this for all the internal communication. > > I also propose that we, take out the option for users to enable/disable > data publishing from the agent side, and make it implicit. The agent by > default makes a call to the server to send device information, instead of > making the device make another call to DAS to provide location information, > we can derive the location information at the server side from the device > information payload and push it to DAS. > I think this is how its been implemented for the EMM Usecases, correct me if I am wrong. We publish from the IoT Core to DAS through thrift. *Ayyoob Hamza* *Senior Software Engineer* WSO2 Inc.; http://wso2.com email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
