+1.
Ruwan on the graph the redline that shows as disconnect will became a heart
beat in IoT server?
-Chintana
On Wed, May 10, 2017 at 4:24 AM, Inosh Perera <[email protected]> wrote:
> Hi Ruwan,
>
> I also propose that we, take out the option for users to enable/disable
> data publishing from the agent side, and make it implicit.
> This was added in an extensible way so that data /log publishing to
> outside systems such as splunk can be done by using the extension points
> for custom scenarios.
>
> Regards,
> Inosh
>
> On 9 May 2017 10:09 a.m., "Srinath Perera" <[email protected]> wrote:
>
>> +1 for auditing table
>>
>> On Mon, May 8, 2017 at 2:45 PM, Ayyoob Hamza <[email protected]> wrote:
>>
>>> 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
>>>
>>>
>>
>>
>> --
>> ============================
>> Srinath Perera, Ph.D.
>> http://people.apache.org/~hemapani/
>> http://srinathsview.blogspot.com/
>>
>
--
Chintana Wilamuna | Associate Director/Solutions Architect | WSO2
<http://wso2.com/> Inc.
408 429 3321 | http://engwar.com/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
