Hi Ayyoob, That was the my concern as well. However we can consider the device-model instead of the device instance because ultimately all the supported features of a device will be dictated by the device model & vendor. By that way we can avoid lots of duplicate data. We can get this information from the device instance while it's enrolling as you have suggested. Then we can insert it to the tables only if that device model does not exists in the database.
Thanks, Harshan Liyanage EMM/IoT TG WSO2 On Nov 2, 2016 10:03 PM, "Ayyoob Hamza" <ayy...@wso2.com> wrote: > 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: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> > > On Wed, Nov 2, 2016 at 3:44 PM, Chathura Ekanayake <chath...@wso2.com> > 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 <chathu...@wso2.com> >> 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 <chath...@wso2.com> >>> 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 <chath...@wso2.com> >>>> 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 <ayy...@wso2.com> 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: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> >>>>>> >>>>>> On Wed, Nov 2, 2016 at 10:11 AM, Harshan Liyanage <hars...@wso2.com> >>>>>> 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: hars...@wso2.com >>>>>>> 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 <ayy...@wso2.com> >>>>>>> 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: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> >>>>>>>> >>>>>>>> On Wed, Nov 2, 2016 at 9:54 AM, Harshan Liyanage <hars...@wso2.com> >>>>>>>> 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: hars...@wso2.com >>>>>>>>> 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 < >>>>>>>>> jasin...@wso2.com> 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 <ruw...@wso2.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Nov 2, 2016 at 7:23 AM, Ayyoob Hamza <ayy...@wso2.com> >>>>>>>>>>> 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 : ruw...@wso2.com >>>>>>>>>>> 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
