Hi,
I have tested following functionalities
- Create Device Type with HTTP transport
- Create Device Type with MQTT transport
- Create device instances for above device types
- Publish device events
- Device operation flow.
- Sample installation and virtual firealarm flow.
-
>
>
>
> I think we can recommend using the provided JAX-RS API and provide SDKs
> for different platforms to program against this API. SDK can support basic
> operations such as get operations, publishing data, etc.
>
+1, Since we have a clear contract for the devices that uses http and mqtt
transp
>
>
>>
>> *How to register a device type?*
>> 1) Create A Device Type:
>>
>> curl -X POST http://localhost:8280/api/device-mgt/v1.0/admin/device-types
>> -H 'authorization: Bearer 77d11b5e-2363-3c99-afb3-c0381600b977' -H
>> 'content-type: application/json' -d '{"name":
>> "firealarm","deviceTypeMe
>
>
> 1). Provide a way to map feature-permissions for the device types that are
> being created using the API.
>
we can allow this capability to be used for the pluggable device type but I
think we cannot allow to create new permissions during runtime, since this
permission hierarchy is visible to
This won't tackle the problem Musthaq suggested which requires validation
in the backend.
*Ayyoob Hamza*
*Senior Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
On Tue, May 9, 2017 at 10:01 AM, Ayyoob Hamza wrote:
&
Hi,
We had a similar requirement to have a fine grained access for users in
IoTS and we went with the approach of assigning permission for scope rather
than roles.
*Ayyoob Hamza*
*Senior Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2
formation, instead of
> making the device make another call to DAS to provide location information,
> we can derive the location information at the server side from the device
> information payload and push it to DAS.
>
I think this is how its been implemented for the EMM Usecases, correct me
i
@Sumedha,
Yes, it does in the context of the API. we can use the same permissions in
the feature. The issue is that the permission in the API does not get
propagated to the device context.
@Chathura
> What does it mean if a role R1 has access to device group G1, but doesn't
> have permission to a
[1] https://github.com/wso2/carbon-device-mgt/blob/master/
components/device-mgt/org.wso2.carbon.device.mgt.common/
src/main/java/org/wso2/carbon/device/mgt/common/authorization/
DeviceAccessAuthorizationService.java
Thanks
*Ayyoob Hamza*
*Senior Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy..
Hi Chathura,
>>>
I have a doubt looking at the above diagram on why we have webapps as part
of the app management. Since we are focusing on app managment capabilies to
the device types, shouldnt it only be device types.
3. App types are plugable to the app management core.
>>>
>> Are we making t
have to think of a generic solution on how to deploy the artifacts
for the tenants.
In addition to recievers, we are using publishers and
tenant-specific summarisation scripts, does these gets undeployed when the
tenant is unloaded ?.
Thanks,
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso
Hi All,
I have tested following:
- Tested below flows using the reference device types
implementation(Virtual firealarm, Connected cup, Raspberry pi).
- Operation flow
- Policy
- Batch Analytics
- Real time analytics
- Tested Android Device Management APIs
- Teste
.
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Hi Dilan,
> Does this mean we can basically have a ready-to-use device plug-in
> implementation, just by configuring a descriptor file ?
>
Yes thats the idea, In here the plugin means the osgiService which contains
the definition of the device type. we found from the existing device type
that it
Please find my comments inline.
> Hi All
>>>
>>> Currently IOT communicates with APIM components via Java/OSGI api's and
>>> services. Therefore $subject is needed to properly decouple and make IOT
>>> cloud ready.
>>> Consider the following points where IOT uses APIM. Sub-points are huw
>>> i'm
>
> 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
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 1681
2%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 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%2
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
.device.mg
t.extensions.device.type.deployer
Thanks,
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/
/compon
ents/webapp-authenticator-framework/org.wso2.carbon.
webapp.authenticator.framework.
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
___
Architecture mailin
some other features that we can support as a future
requirement is to support swagger annotation. Which is to read and publish
along with the api. This way we could create the documentation in store.
Thanks,
Ayyoob
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com
Milan, Please find my comments inline.
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
On Wed, Aug 3, 2016 at 8:47 AM, Milan Perera wrote:
> Hi all,
>
> In CDMF, we are currently heading towards OAu
*WSO2 IoT Server 1.0.0 Alpha Released*
We are pleased to announce WSO2 IoT Server 1.0.0 alpha release. It can be
downloaded from
https://github.com/wso2/product-iots/releases/tag/v1.0.0-alpha
WSO2 IoT Server is an extensible, open-source, multi tenant, Internet of
Things Platform for implementing
Hi Prabath,
+1, thought the same that we should map our existing model to a developer
easy model.
>
> My proposal is that, you can quite easily turn this model into a
> "descriptor-driven" implementation, which will greatly enhance the
> usability of the device management framework, as below.
>
Hi Geeth,
Looks cool and as my understanding I see that there are two capabilities
that has been described here.
1) Trigger operations through tasks.
2) Searching devices based on its attributes.
I assume, in the dynamic case what we do is to keep the last snapshot of
the data. which in the server
if we can find a solution for both of this then we can allow
writing queries.
Thanks
Ayyoob
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
On Mon, Mar 28, 2016 at 4:26 PM, Nuwan Dias wrote:
> Having to pub
whether this needs to be handled in DAS level? rather I see that it
needs to be handled in the high level API that we provide to expose the
data.
Thanks
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
On Sa
e features as
default and have others in another profile.
Please provide us your suggestion regarding this.
Thanks,
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
___
Ar
mode the above information will be grabbed in the
authorization framework in the valve and will allow the request only for
the allowed tenant users.
WDYT about the above flow and if there are anything that we have missed
then please let us know?
Thanks,
*Ayyoob Hamza*
*Software Engineer*
WSO
>
> On Mon, Feb 8, 2016 at 11:06 PM, Ayyoob Hamza wrote:
>
>> Hi Prabath,
>> Please find the comments inline.
>>
>>>
>>> I assume this is a server level configuration. How do we handle
>>> multitenancy in this scenario...?
>>>
&
> Please make sure that when bearer tokens are used for authentication, MQTT
> runs over TLS..
>
Just having a doubt on whether isn't this supposed to be enforced by the
client or does it needs to be enforced by the server since it supports both
the communication.
Thanks
__
Hi Prabath,
Please find the comments inline.
>
> I assume this is a server level configuration. How do we handle
> multitenancy in this scenario...?
>
After authentication is successful it returns an object which consist of
username and tenantId of the authenticated client[1]. This object is then
Hi Harshan
>
> In the step 11, you have mentioned that the device sends authentication
> request, generate access and refresh tokens and send it to device. However
> you need client credentials (client key, secret) in-order to generate
> access tokens. How are you planing to get these client crede
or this implementation is available in [2][3].
[1] http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
[2] https://github.com/wso2/andes/pull/517
[3] https://github.com/wso2/carbon-business-messaging/pull/256
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@w
+1 and made the changes to have a specific username and as default it would
be "Bearer"[1].
[1]
https://github.com/ayyoob/extensions/tree/master/messagebroker-extensions
*Ayyoob Hamza*
___
Architecture mailing list
Architecture@wso2
ny other.
[1] http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
[2] http://eprints.port.ac.uk/15538/1/oauth_mqtt3.pdf
[3] http://www.hivemq.com/blog/mqtt-security-fundamentals-oauth-2-0-mqtt
[4]
https://github.com/ayyoob/extensions/tree/master/messagebroker-extensions
*Ayyoob Hamza*
*Sof
@Dulitha and @ Sachith
I see both your comments ends with the same question whether we need to
have event stream definition for each sensor type or do we need to maintain
a separate event stream for each sensor type on a device type ?.
eg: stream definition:
Use Case 1 : org.wso2.devices.temperat
is is just a thought as to how we can extend CDMF to cater sensor
management. Please give us your comments and suggestions on $subject
Thanks,
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%2
[Reattaching the image]
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
On Thu, Aug 6, 2015 at 3:21 PM, Ayyoob Hamza wrote:
> Hi All,
> This is the current $subject. This is currently deployed in
:9763/firealarm-webapp/
Sample application to control a firealarm
Regards,
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
___
Architecture mailing list
Architectu
42 matches
Mail list logo
