Hi Geesara,
I would rather argue that the level of information that we are going to
expose here is too low-level in terms of what an end-user would expect
from a so-called "Smart Home Analytics" system.
The type of user stories that you have described here only carries a common
set of analytics requirements that any sort of analytics system would
decide as good-to-have.
But, this is not the higher-level need or end goal of a "Smart Home
Analytics" system should be.
Consider few user-stories as follows.
[1] Depending on the continuous data being pumped by a set of motion
sensors that a user has placed in various locations in his house and
based on the fact that there is currently no one in the house,
consider how cool it could be if we can detect any suspicious activity by
the exact location and
alert the user, let's say by SMS and show any necessary information
and possible actions to take on a dashboard.
[2] Depending on the continuous data being pumped by a set of energy usage
meters that a user has placed in all the electric items in his house and
based on the average energy usage patterns in history for the past few
months, consider how cool it could be if we can predict how his energy
consumption will be
for the next few days in the month, show corresponding information on
a dashboard and if it's going to be high and costly, suggest any possible
usage plans to minimize it.
[3] Depending on the continuous data being pumped by a set of humidity
sensors, wind speed meters placed in the garden and based on predicted
weather information
for the day received from weather stations, consider how cool it could
be if we can predict how much water is needed to be applied for plants in
the garden today
and alert the user of corresponding actions and show any necessary
information in the form of a dashboard gadget.
This is where we should ideally aim when thinking of a sample analytics
story for a Smart Home and make sure that we provide the necessary
development infrastructure
in terms of our middleware stack for any third-party developer to build
such similar end-user experiences on top of our platform.
We already have the key ingredients in terms of this rich middleware stack
that I am talking about.
[1] We do have our Connected Device Management Framework and on top of
that, our IoTServer building up for registering any type of smart device to
the platform and aquire data.
[2] We do have our Data Analytics Server, Complex Event Processor and
Machine Learner building up together in order to perform any sort of
analytics related work.
[3] And finally, we do have our Dashboard Server on top all these to govern
the visualization aspect of captured information.
We just need to find the missing links and connect the dots.
Cheers,
Dilan.
*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware
On Wed, Jul 13, 2016 at 5:19 PM, Geesara Prathap <[email protected]> wrote:
> Hi All,
>
> Since we do have all the basic components which are required to build a
> fully fledged real world analytics story with IoT Analytics Framework,
> there was a suggestion that we need to build some analytics stories in the
> context of IoT Analytics. So along with that, this is one of the examples
> we are going to build.
>
> In this use case, we are mainly focusing on analyzing sensor data in a
> timely manner. So when sensors are publishing data it may be required to do
> analytics in real time and do some decision making on a particular event
> stream and so on. Then it goes on with batch processing in order to
> summarize sensor data for later usage. Once raw data is available we will
> be able to do some predefined machine learning tasks so as to perform
> some sort of real work scenarios like model learning, anomaly detection
> and so on. So this explains how the high-level architecture of this
> project is.
>
>
> [image: homeAutomationSystem.jpg]
>
> Figure 01: High-level architecture
>
> In the initial cut, we are to take a wide variety of dataset which
> contains several types of sensor data from real sensors. This resource[1]
> is provided datasets that have been collected for two successive months. So
> it seems to match our requirement as well.
>
> So these are the selected sample sensor information with some sample
> dataset.
>
> 1.
>
> Circuits
>
> CircuitName,CircuitNumber,TimestampUTC,RealPowerWatts,ApparentPowerVAs
>
> WashingMachine,14,1341047872,1.262,1.963
>
> FridgeRange,15,1341047872,5.196,8.41
>
> 2. Individual energy meters
>
>
> MeterName,TimestampUTC,RealPowerWatts,CircuitNumber
>
> livingroom:subwoofer,1341047975,10,4
>
> basement:washingmachine,1341048003,0,14
>
> 3. Dimmable and non-dimmable switches
>
>
> SwitchName,TimestampUTC,MaxRealPowerWatts,DimProportion,
> CircuitNumber
>
> kitchen:sink,1341047877,65,0,18
>
> Kitchenhall:lights1,1341047880,195,0,18
>
> 4. Voltage and frequency data on both electrical phases
>
> TimestampUTC,FrequencyHz,VoltageVolts
>
> 1338887835,59.978,121.832
>
> 1338887836,59.978,121.832
>
> 5. Environmental data (indoor and outdoor)
>
>
> TimestampUTC,insideTemp,outsideTemp,insideHumidity,outsideHumidity,windSpeed,windDirectionDegrees,windGust,windGustDirectionDegrees,rainRate,rain,windChill,heatindex
>
> 1341048000,73.580002 ,59.180004 ,45.0,83.333336 ,0.0 , ,0.0 , ,0.0 ,0.0
> ,59.180004 ,59.180004
>
> 6. Door open/close
>
> DoorSensorName,TimestampUTC,OpenOrClosed
>
> kitchen:refrigerator,1341054545,1
>
> kitchen:refrigerator,1341054552,0
>
>
> 7. Motion detector data
>
> MotionSensorName,TimestampUTC,MotionOrNoMotion
>
> kitchen:corner,1341056647,0
>
> livingroom:corner,1341056652,1
>
>
> Requirement Analysis Phase :
>
> - - - - - - - - - - - - - - - - - - - - - - - - -
>
> [a] Key contextual areas, currently identified as important for showing
> analytics related data :
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> [1] Sensors based on each household view analytics
>
> [2] Sensors based on each floor view analytics
>
> [3] Sensors based on custom group view analytics
>
> [4] Analytics related for individual sensors. This might be varied from
> sensor to sensor.
>
> [b] Dashboard Types, currently on consideration :
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> Based on the data analyzed and based on users who would interact with a
> dashboard, we can define a generic dashboard which will be filtered based
> on users.
>
> [1] Generic User Dashboard - Dashboard for a user
>
> view all the sensor details and its current status and group level
> analytics in a hierarchical manner.
>
>
> [c] Analyzed user stories:
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> User Story Relevance - { Role : End User }
>
> User Story 1 (with 1st highest prominence) :
>
> A user should be able to see sensor counts which belong to the given
> system appropriate graph views with respect to following states of
> connectivity.
>
> [1] Active - Meaning a sensor has been able to communicate with the server
> at least once within a specified threshold of time
>
> [2] Inactive - Meaning a sensor has not been able to communicate with the
> device at least once within the specified threshold of time
>
> [3] Blocked - Meaning the communication in between a sensor and the device
> has been blocked due to either being inactive for a long period of time
>
> In here sensors communicate with the device. So sensors current status are
> updated through the device.
>
> User Story 2 (with 2nd highest prominence) :
>
> A user should be able to see counts appropriate graph views with respect
> to sensors with following states of alerts.
>
> [1] Ok - Meaning sensors with this alert type shouldn’t be given any
> prominence upon devices with other alert types
>
> [2] Warning - Meaning sensors with this alert type should be given less
> prominence upon devices with "Danger" alert type
>
> [3] Danger - Meaning devices with this alert type should be given more
> prominence upon devices with other alert types
>
> After getting sensor information from each sensor then this information
> needs to be summarized in a hicheiracial manner: floor level, home level
> and so on.
>
>
> User Story 3 (with 3rd highest prominence) :
>
> A user should be able to see sensor counts with appropriate graph views
> with respect to following groups.
>
> [1] User defined groups - Meaning sensor counts, the summary of current
> status of sensors and reasons for being malfunctioned based on custom
> groups defined by users.
>
> [2] Sensor group based on each floor - Meaning what are the sensors which
> are installed into a given floor as well as the summary of current status
> of sensors and reasons for being malfunctioned.
>
> [3] Also based on houses
>
> User Story 4 (with 4th highest prominence) :
>
> Viewing group level analytics and individual sensor analytics
>
> There should be a mechanism for viewing group level analytics and
> individual sensor analytics. Because each sensor may contain a different
> way of representing its analytics. Also, data retrieval from sensors also
> might vary from sensor to sensor. So group level analytics would be
> summation of individual analytics views or some sort of aggregation of
> them.
>
> User Story Relevance - { Role : Device plugin developer }
>
>
> User Story 5 (with 5th highest prominence) :
>
> A user should be able to install new sensors which already been registered
> under given user into any appropriate location.
>
> When device plugin developer is creating device type which may includes
> several types of sensors. If a user is required particular device type
> instance, then it needs to be registered under requested user, Afterward,
> he will able to pick existing sensors and install into any appropriate
> location. Upon sensor is being installed into a proper location, meta
> information such as sensor coordinates, floor number needs to be provided
> in order to fulfill installation process. Also update, remove and replace
> functionality are required for particular sensor type.
>
>
> 1. http://traces.cs.umass.edu/index.php/Smart/Smart
>
> Thanks,
> Geesara
>
> --
> Geesara Prathap Kulathunga
> Software Engineer
> WSO2 Inc; http://wso2.com
> Mobile : +940772684174
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
