Hi Shabir, IMO, your concern would race mainly in cases where it happens to manage complex device types. In such scenarios, there could be use-cases in which we have to maintain multiple instances of the same sensor type to capture same data, but with varying contexts.
For example, in a refrigerator, we may use two temperature sensors, one to measure the same inside cooling compartment (context 1) and the other to measure the same inside freezing compartment (context 2). Even we may use a group of temperature sensors, in the same context to get an averaged and more accurate result. In either case, to correctly classify the data been sent by these sensors, we need to identify not just the temperature reading and the device, but also the identity of the sensor and the measuring context. So the argument that you make seems to be valid and it's applicable not just to "sensors", but also to "actuators" of a registered device type. Regards, Dilan. On Monday, July 11, 2016, Shabir Mohamed <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > [+Adding Architecture] > > ------------------------------------- > *Shabir Mohamed* > *Software Engineer* > WSO2 Inc.; http://wso2.com > Email: [email protected] > Mobile: +94 77 3516019 | +94 71 6583393 > > On Sun, Jul 10, 2016 at 6:30 PM, Geesara Prathap <[email protected]> wrote: > >> Hi Shabir, >> >> Is it required at to separately manage generic sensor-types (Temperature, >> GPS, Distance etc) at the framework level which can be utilised by the >> device type writers when writing the plugin for their own device-type >> >> *or else * >> >> Do we not have a separately managed reusable set of sensor-types but only >> add it as an extension to the existing plugin implementation which enables >> new device-type plugin writers to DEFINE their own sensor-types at the time >> of writing the plugin. >> >> I think we have to consider both approaches which you are suggesting . >> Let's say somebody who has a sensor network which needs to be connected >> with IoTS. Initially, he will define what are the meta information, >> payload, stream definition and so on which requires for a given sensor. >> After initial process is done, if he needs to add a sensor which already >> defined into a new device type he may able to pick existing sensor >> definition if the framework is supported or else he has to follow the same >> procedure in order to register a sensor type into a device type. >> >> Thanks, >> Geesara >> >> On Sun, Jul 10, 2016 at 3:45 PM, Shabir Mohamed <[email protected]> wrote: >> >>> Hi, >>> >>> In terms of analytics in the CDM-Framework, we currently contain only >>> data related to specific device-types. All the streams against which data >>> is collected is directly bound to a device-type registered to the >>> framework. >>> >>> However, in the build up to the IoT Analytics Framework it was noticed >>> that there exists a requirement to be able to single out meta information >>> with regards to the exact origin of the data itself; as in the sensor >>> information (location, type) from where the data originated. >>> >>> For an example if we study a single device-type with TWO different >>> temperature sensors (mounted on it) pumping data into the IoTServer: >>> >>> The current approach persists this data against a single temperature >>> stream. Whilst it is possible to state that these temperatures came from >>> "THIS" specific device, it is NOT possible to identify from which sensor >>> itself (from the 2 that are on the device) that the data came from. >>> >>> Hence the need arises to be contain the information with regards to the >>> sensors/actuators attached to the device-types registered in the >>> CDM-Framework. That is to be able to manage meta-information of the UNITS >>> from where data come into the Server or the UNITS to which >>> commands/controls are sent to from the Server. >>> >>> The need for this was initially brought up by Ayyoob in the email thread >>> with subject: >>> *"[Architecture] Adding/Managing Sensor information on CDMF"* >>> >>> *Having understood the above need, in the discussion to implement it >>> rises one specific concern to be addressed.* >>> >>> Is it required at to separately manage generic sensor-types >>> (Temperature, GPS, Distance etc) at the framework level which can be >>> utilised by the device type writers when writing the plugin for their own >>> device-type >>> >>> *or else * >>> >>> Do we not have a separately managed reusable set of sensor-types but >>> only add it as an extension to the existing plugin implementation which >>> enables new device-type plugin writers to DEFINE their own sensor-types at >>> the time of writing the plugin. >>> >>> >>> The former case has the advantage of allowing the writers to re-use >>> already existing sensor-types and to write only new ones as and when >>> necessary and the latter makes the sensor definition more flexible and >>> ensures that the CDM-Framework ONLY caters to device management without >>> complicating with sensors. >>> >>> Your thought on this will be much helpful. >>> >>> Thanks and Regards >>> ------------------------------------- >>> *Shabir Mohamed* >>> *Software Engineer* >>> WSO2 Inc.; http://wso2.com >>> Email: [email protected] >>> Mobile: +94 77 3516019 | +94 71 6583393 >>> >> >> >> >> -- >> Geesara Prathap Kulathunga >> Software Engineer >> WSO2 Inc; http://wso2.com >> Mobile : +940772684174 >> >> > -- *Dilan U. Ariyaratne* Senior Software Engineer WSO2 Inc. <http://wso2.com/> Mobile: +94766405580 <%2B94766405580> lean . enterprise . middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
