Thanks for the great use cases, we'll consider them too, as the first attempt we are trying to show what we collect in a meaningful way, then one by one we'll be adding predictions and grouped analytics on top of this.
Regards Suho On Fri, Jul 22, 2016 at 10:09 AM, Malith Jayasinghe <[email protected]> wrote: > + for doing advanced analysis/prediction based on the data is received > from sensors. Each of these scenarios will require different types of > analysis and prediction algorithms. It might be a good idea to figure out > which ones are important and then work in that order. > > Note that it is important to have the ability to visualize these > information in real-time (e.g. energy consumption of devices etc) and being > able to summarize these information (e.g. total energy consumption of all > heating devices, all cooling devices etc) in real time and also being able > to compare different sets of data (e.g. total energy consumption in two > different days etc) . These type summarizations and comparisons will not > require advanced analysis. > > On Wed, Jul 20, 2016 at 10:46 AM, Dilan Udara Ariyaratne <[email protected]> > wrote: > >> 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 >> >> > > > -- > Malith Jayasinghe > > > WSO2, Inc. (http://wso2.com) > Email : [email protected] > Mobile : 0770704040 > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *S. Suhothayan* Associate Director / Architect & Team Lead of WSO2 Complex Event Processor *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
