I had an offline discussion and got an explanation from chathuraD. The problem here could be explained with a simple use case: Android has a set of features but an instance of an android device doesn't have the feature that is definied in the device type definition(eg: *Android OS supports enabling/disabling fingerprint but the smart phone hardware doesn't have a fingerprint scanner*).
In our current implementation we don't support this. This is because we have assumed that the device type has a set of feature and it is available across all the instances. Therefore in the current approach when we send an operation to a device and if the device doesn't support it then it sends a feedback. This is not a synchronous flow and the user does not get a realtime feedback whether the operation can be executed on the device or not. However to solve this issue what we have todo is to maintain information about the features a device(an instance) supports, This information can be sent from the device when it enrolls/updates. In addition we need some form of a compliance check to see whether the device has the particular feature before sending this operation to the device. Implementing above requirement will provide a good feed back mechanism to the user. @Chathura, In CDMF context we have defined that features is some thing that we operate to. Sending read operation from server to device would be just one use case but it doesn't need to be always, device can be programmed to push data for a given interval or set a policy and trigger with a conditional push. Therefore IMHO I think we need a separation. Please correct me if I am wrong. Thanks, Ayyoob *Ayyoob Hamza* *Software Engineer* WSO2 Inc.; http://wso2.com email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> On Wed, Nov 2, 2016 at 3:44 PM, Chathura Ekanayake <[email protected]> wrote: > Yes.. in the feature definition xml I sketched out, there are multiple > criteria under <FilteringCriteria> tag. > > On Wed, Nov 2, 2016 at 2:55 PM, Chathura Dilan <[email protected]> wrote: > >> Hi Chathura, >> >> How about having multiple criteria under one feature so we can better >> address all the scenarios. >> >> >> On Wed, Nov 2, 2016 at 12:36 PM, Chathura Ekanayake <[email protected]> >> wrote: >> >>> Regarding sensors, we can consider them as features, where the action >>> they support is "read value". If we are using polling method to trigger >>> operations, read operation can have a parameter with an endpoint to send >>> sensor reading. >>> >>> - Chathura >>> >>> On Wed, Nov 2, 2016 at 12:30 PM, Chathura Ekanayake <[email protected]> >>> wrote: >>> >>>> I think we can define a feature (or an operation) with: >>>> >>>> A) Feature code - to identify the feature >>>> B) Filtering criteria - to identify devices which can perform the >>>> operation >>>> C) Operation parameters - Additional details needed by the operation >>>> >>>> Restriction criteria such as device type, group ID, device version >>>> (better a range of versions) can come under B. So whenever an operation is >>>> invoked, IOT platform should evaluate device details against B and decide >>>> whether to permit the operation. If permitted, it can get C from the user >>>> (or from an external system) and add an operation record in DB with A and C >>>> against the device ID. >>>> >>>> With this we can use feature schema similar to what Ruwan has proposed: >>>> >>>> <Features> >>>> <Feature code="abc"> >>>> <Name>abc</Name> >>>> <Description>this is a feature</Description> >>>> <FilteringCriteria> >>>> <Criteria name="deviceType">DT1</Criteria> >>>> <Criteria name="version">[2.0,3.5)</Criteria> >>>> </FilteringCriteria> >>>> <FeatureProperties> >>>> <Property name="prop1">place_holder</Property> >>>> <Property name="prop2">place_holder</Property> >>>> <Property name="prop3">place_holder</Property> >>>> </FeatureProperties> >>>> </Feature> >>>> </Features> >>>> >>>> Regards, >>>> Chathura >>>> >>>> >>>> >>>> On Wed, Nov 2, 2016 at 10:41 AM, Ayyoob Hamza <[email protected]> wrote: >>>> >>>>> @Harshan, agree its a concern. Location/DeviceInfo/ApplicationList >>>>> operation triggers even if the device doesn't support it. we need to make >>>>> this device type specific. >>>>> >>>>> *Ayyoob Hamza* >>>>> *Software Engineer* >>>>> WSO2 Inc.; http://wso2.com >>>>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>>>> >>>>> On Wed, Nov 2, 2016 at 10:11 AM, Harshan Liyanage <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Ayyoob, >>>>>> >>>>>> Yes you are correct. But I took the barometer as an example. However >>>>>> there may be real scenarios where some devices does not have GPS so that >>>>>> we >>>>>> can't access the location info. In such cases we need to disable >>>>>> "Location" >>>>>> operation for those devices. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Harshan Liyanage >>>>>> EMM/IoT TG >>>>>> Mobile: *+94765672894* >>>>>> Email: [email protected] >>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>> lean.enterprise.middleware. >>>>>> >>>>>> On Wed, Nov 2, 2016 at 10:07 AM, Ayyoob Hamza <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> @Harshan, sensors are not part of features(correct me if I am >>>>>>> wrong), This is why there was a requirement raised for sensor >>>>>>> management as >>>>>>> part of device management and we had an implementation to support >>>>>>> this(from >>>>>>> shabir) which is not merged yet. >>>>>>> >>>>>>> [1] https://github.com/wso2/carbon-device-mgt/pull/407 >>>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwso2%2Fcarbon-device-mgt%2Fpull%2F407&sa=D&sntz=1&usg=AFQjCNGLqXZzNEVnTBLB5rugQeJWfFmnNQ> >>>>>>> [2] https://github.com/wso2/carbon-device-mgt-plugins/pull/394 >>>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwso2%2Fcarbon-device-mgt-plugins%2Fpull%2F394&sa=D&sntz=1&usg=AFQjCNFHWDeJJW5WCMCeENFnDo6271makQ> >>>>>>> >>>>>>> >>>>>>> *Ayyoob Hamza* >>>>>>> *Software Engineer* >>>>>>> WSO2 Inc.; http://wso2.com >>>>>>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>>>>>> >>>>>>> On Wed, Nov 2, 2016 at 9:54 AM, Harshan Liyanage <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Dilan, >>>>>>>> >>>>>>>> +1 for the idea. But we also need to consider the device model when >>>>>>>> comes to the features. For example there may be Android devices where >>>>>>>> some >>>>>>>> sensors like barometer is not present. This will be mostly applicable >>>>>>>> to >>>>>>>> the mobile device types because IOT devices will have their own plugin >>>>>>>> independent of the device model (correct me if I'm wrong). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Harshan Liyanage >>>>>>>> EMM/IoT TG >>>>>>>> Mobile: *+94765672894* >>>>>>>> Email: [email protected] >>>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>>>> lean.enterprise.middleware. >>>>>>>> >>>>>>>> On Wed, Nov 2, 2016 at 9:14 AM, Jasintha Dasanayake < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi All >>>>>>>>> >>>>>>>>> Yes.. , engaging with a plugin repository like eclipse vorto would >>>>>>>>> be great idea for IOT , we can provide set of extension point (we may >>>>>>>>> already have) where custom plugins can be plugged in >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /Jasintha >>>>>>>>> >>>>>>>>> On Wed, Nov 2, 2016 at 7:53 AM, Ruwan Yatawara <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Nov 2, 2016 at 7:23 AM, Ayyoob Hamza <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> different >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am with Ayyoob in that the term "feature" sounds very much >>>>>>>>>> something from the mobile world. But if you think about it, any >>>>>>>>>> functionality that a user sees on the dashboard of a device type is a >>>>>>>>>> feature. So I am +1 for bringing feature definition down to the >>>>>>>>>> mobile >>>>>>>>>> plugin in form like. >>>>>>>>>> >>>>>>>>>> <Features> >>>>>>>>>> <Feature code="abc"> >>>>>>>>>> <Name>abc</Name> >>>>>>>>>> <affectedVersion>5.0.0</affectedVersion> >>>>>>>>>> <Description>this is a feature</Description> >>>>>>>>>> <FeatureProperties> >>>>>>>>>> <Property name="prop1">place_holder</Property> >>>>>>>>>> <Property name="prop2">place_holder</Property> >>>>>>>>>> <Property name="prop3">place_holder</Property> >>>>>>>>>> </FeatureProperties> >>>>>>>>>> </Feature> >>>>>>>>>> </Features> >>>>>>>>>> >>>>>>>>>> But somewhere down the line when it comes to orchestrating device >>>>>>>>>> integration flows, we most definitely as Ayyoob mentioned, have to >>>>>>>>>> take a look at Vorto... which is very cool IMO. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks and Regards, >>>>>>>>>> >>>>>>>>>> Ruwan Yatawara >>>>>>>>>> >>>>>>>>>> Associate Technical Lead, >>>>>>>>>> WSO2 Inc. >>>>>>>>>> >>>>>>>>>> email : [email protected] >>>>>>>>>> mobile : +94 77 9110413 >>>>>>>>>> blog : http://ruwansrants.blogspot.com/ >>>>>>>>>> https://500px.com/ruwan_ace >>>>>>>>>> www: :http://wso2.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Jasintha Dasanayake**Associate Technical Lead* >>>>>>>>> >>>>>>>>> *WSO2 Inc. | http://wso2.com <http://wso2.com/>lean . enterprise . >>>>>>>>> middleware* >>>>>>>>> >>>>>>>>> >>>>>>>>> *mobile :- 0711-368-118* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Regards, >> >> Chatura Dilan Perera >> *Associate Tech Lead** - WSO2 Inc.* >> www.dilan.me >> > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
