If we store supported features with device data as discussed, we can avoid
having device details based filtering criteria in feature schema.
- Chathura
On Wed, Nov 2, 2016 at 10:40 PM, Ayyoob Hamza wrote:
> That was the my concern as well. However we can consider the device-model
>> instead of
>
> 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 fr
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
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 enablin
Yes.. in the feature definition xml I sketched out, there are multiple
criteria under tag.
On Wed, Nov 2, 2016 at 2:55 PM, Chathura Dilan 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:
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
wrote:
> Regarding sensors, we can consider them as features, where the action they
> support is "read value". If we are using polli
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
i
Hi All,
Operation can be descried as set of actions that can be carried out on a
device. As an example if we take 'Camera Operation'; enabling and disabling
camera can be carried out on a device. Without the actions we are calling
it 'Camera Feature'. There could be several features which is speci
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, de
@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/
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
wr
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
@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>
Hi Harshan,
Even in the perspective of mobile phones, a sensor differs from a feature.
A feature is an action that is materialized via one or more actuators,
whereas a sensor is just a sensory input from which we read a set of
values. if we take the barometer example. A phone may or may not have a
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 wrote:
>
> On Wed, Nov 2, 2016
On Wed, Nov 2, 2016 at 7:23 AM, Ayyoob Hamza 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 fea
Agree with what you have stated.
Features is a word that is familiar in the context of mobile, We actually
map this into actuators(things that we can operate) in a device context. so
we can map features into operation however in the current context feature
definition does not give any meaning abou
17 matches
Mail list logo
