Date   

Re: Hello, I am Seo Dong-sung, a master researcher at Hanyang University.

JayOh
 

Hi there,

1. Resource with URI "/oic/res" is used for resource discovery, and all the other resources (including custom resources) are children of that "/oic/res" resource.
      ex)  /oic/resource        <--- you should send "Get" request to this resource to get the list of custom resources below
              --> /custom/resource1
              --> /custom/resource2
              ....

This means that not only resource-server but also resource-client knows this resource, "/oic/res", and uses it for resource discovery. 
The reason why you were not able to discover the resource "/mir/test" that you want it to be is because you removed the resource "/oic/res".
Don't remove the "/oic/res" resource by changing its name, do register your resource "/mir/test" by using the iotivity-api 
then try again. :) 
 

2. I'd like to suggest you share your codes for better understanding & commenting. :)




2020년 7월 9일 (목) 오전 12:25, 서동성 <sds1zzang@...>님이 작성:

Hello, I am Seo Dong-sung, a master researcher at Hanyang University.

 

We contacted you to ask technical questions about IoTivity.

 

Currently, IoTvity version is downloaded from git and is running on Raspberry Pi.

 

I want to add or change the Resource URL in the OCF Server part, but it doesn't work so I send an email. The questions are:

 

1. I want to replace the /oic/res Resource with the resource I specified, /mir/test, but I would like to ask what to do.

I found that /iotivity/examples/OCFSecure changes /oic/res to ocf_svr_db_server_RFNOP.json or ocf_svr_db_server_RFOTM.json, then compiles (sudo scons examples/OCFSecure –j 2 TARGET_TRANSPORT=IP) and the .dat file is changed. It doesn't change, but it doesn't seem to change the URL properly. I would like to know a solution to this. There should be other compilation methods, but I'd like to ask if the .json file is changed to .dat or is it forced to change using the cbor library.

 

2. When I run the current OCF Server sample source, I want to change the payload value and url in /switch to /test, but I know that this part is in switch_introspection.json. However, I changed the /test and additionally changed the resource, but it does not change when I run it.

 

Thank you for your reply.


Hello, I am Seo Dong-sung, a master researcher at Hanyang University.

서동성 sds1zzang@...
 

Hello, I am Seo Dong-sung, a master researcher at Hanyang University.

 

We contacted you to ask technical questions about IoTivity.

 

Currently, IoTvity version is downloaded from git and is running on Raspberry Pi.

 

I want to add or change the Resource URL in the OCF Server part, but it doesn't work so I send an email. The questions are:

 

1. I want to replace the /oic/res Resource with the resource I specified, /mir/test, but I would like to ask what to do.

I found that /iotivity/examples/OCFSecure changes /oic/res to ocf_svr_db_server_RFNOP.json or ocf_svr_db_server_RFOTM.json, then compiles (sudo scons examples/OCFSecure –j 2 TARGET_TRANSPORT=IP) and the .dat file is changed. It doesn't change, but it doesn't seem to change the URL properly. I would like to know a solution to this. There should be other compilation methods, but I'd like to ask if the .json file is changed to .dat or is it forced to change using the cbor library.

 

2. When I run the current OCF Server sample source, I want to change the payload value and url in /switch to /test, but I know that this part is in switch_introspection.json. However, I changed the /test and additionally changed the resource, but it does not change when I run it.

 

Thank you for your reply.


Re: Protecting against concurrent requests

Kishen Maloor
 

Hello,

 

> OK, thanks for confirming. It looks like the same issue would occur for GET requests as well - if

> `oc_do_get` is interrupted (before the request is dispatched, and another thread begins building a new root

> object).

 

Yes, but more generally, it would be best to synchronize every API call being made from a different thread

(i.e. different from the thread running the stack's message pump) as the APIs are not thread safe.

 

This is in fact the case for all those sample apps that present a command-line UI, and those samples

illustrate where/how this synchronization needs to happen.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of Josh Milburn <josh@...>
Date: Sunday, June 7, 2020 at 4:12 PM
To: "Nash, George" <george.nash@...>
Cc: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: Re: [dev] Protecting against concurrent requests

 

Hi George,

 

OK, thanks for confirming. It looks like the same issue would occur for GET requests as well - if `oc_do_get` is interrupted (before the request is dispatched, and another thread begins building a new root object).

 

We'll make sure that our application logic protects against this. Thanks!

 

 

 

On Fri, Jun 5, 2020 at 2:18 AM Nash, George <george.nash@...> wrote:

If you have a situation that two threads may call oc_init_post then you must prevent both threads calling oc_init_post at the same time.  You must add a mutex or some other similar guard before calling oc_init_post and then you can release it after calling oc_do_post.  The same is true for oc_init_put and oc_do_put.

 

George Nash

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of josh@...
Sent: Wednesday, June 3, 2020 11:00 PM
To: iotivity-dev@iotivity.groups.io
Subject: [dev] Protecting against concurrent requests

 

I'm particularly interested in how the following scenario is prevented:

1. Code from one thread ("A") in the application calls `prepare_coap_request` (which in turn, calls `oc_rep_new`, resetting the current CBOR encoder state). For example, this might happen by someone calling `oc_init_post`.
2. Thread "A" sees a 'success' from `oc_init_post`, and calls `oc_rep_begin_root_object` and begins building a request body
3. Thread "A" is interrupted by higher priority thread "B" which calls `oc_init_post`. 
4. Thread "B" completes and sends request
5. Control is returned to thread "A", which continues trying to build a request body, but the data is now meaningless (since the state of `g_encoder` and `root_map` in `oc_rep.h` have been modified

Looking over the example apps, most seem to provide protection against this by ensuring that requests are not created in interrupts, and/or requests are sent via a menu driven interface. Are there further safeguards against this concurrency issue, is it actually a nonissue, or am I misunderstanding something here?


 

--

Joshua Milburn, P.E. | Senior Embedded Systems Engineer

+1 (724) 612 7788 | Skype: jjmilburn

Subscribe to Angaza’s newsletter
Twitter | Facebook | LinkedIn | YouTube


Re: Protecting against concurrent requests

Josh Milburn
 

Hi George,

OK, thanks for confirming. It looks like the same issue would occur for GET requests as well - if `oc_do_get` is interrupted (before the request is dispatched, and another thread begins building a new root object).

We'll make sure that our application logic protects against this. Thanks!



On Fri, Jun 5, 2020 at 2:18 AM Nash, George <george.nash@...> wrote:

If you have a situation that two threads may call oc_init_post then you must prevent both threads calling oc_init_post at the same time.  You must add a mutex or some other similar guard before calling oc_init_post and then you can release it after calling oc_do_post.  The same is true for oc_init_put and oc_do_put.

 

George Nash

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of josh@...
Sent: Wednesday, June 3, 2020 11:00 PM
To: iotivity-dev@iotivity.groups.io
Subject: [dev] Protecting against concurrent requests

 

I'm particularly interested in how the following scenario is prevented:

1. Code from one thread ("A") in the application calls `prepare_coap_request` (which in turn, calls `oc_rep_new`, resetting the current CBOR encoder state). For example, this might happen by someone calling `oc_init_post`.
2. Thread "A" sees a 'success' from `oc_init_post`, and calls `oc_rep_begin_root_object` and begins building a request body
3. Thread "A" is interrupted by higher priority thread "B" which calls `oc_init_post`. 
4. Thread "B" completes and sends request
5. Control is returned to thread "A", which continues trying to build a request body, but the data is now meaningless (since the state of `g_encoder` and `root_map` in `oc_rep.h` have been modified

Looking over the example apps, most seem to provide protection against this by ensuring that requests are not created in interrupts, and/or requests are sent via a menu driven interface. Are there further safeguards against this concurrency issue, is it actually a nonissue, or am I misunderstanding something here?



--

Joshua Milburn, P.E. | Senior Embedded Systems Engineer

+1 (724) 612 7788 | Skype: jjmilburn

Subscribe to Angaza’s newsletter
Twitter | Facebook | LinkedIn | YouTube


Re: Protecting against concurrent requests

George Nash
 

If you have a situation that two threads may call oc_init_post then you must prevent both threads calling oc_init_post at the same time.  You must add a mutex or some other similar guard before calling oc_init_post and then you can release it after calling oc_do_post.  The same is true for oc_init_put and oc_do_put.

 

George Nash

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of josh@...
Sent: Wednesday, June 3, 2020 11:00 PM
To: iotivity-dev@iotivity.groups.io
Subject: [dev] Protecting against concurrent requests

 

I'm particularly interested in how the following scenario is prevented:

1. Code from one thread ("A") in the application calls `prepare_coap_request` (which in turn, calls `oc_rep_new`, resetting the current CBOR encoder state). For example, this might happen by someone calling `oc_init_post`.
2. Thread "A" sees a 'success' from `oc_init_post`, and calls `oc_rep_begin_root_object` and begins building a request body
3. Thread "A" is interrupted by higher priority thread "B" which calls `oc_init_post`. 
4. Thread "B" completes and sends request
5. Control is returned to thread "A", which continues trying to build a request body, but the data is now meaningless (since the state of `g_encoder` and `root_map` in `oc_rep.h` have been modified

Looking over the example apps, most seem to provide protection against this by ensuring that requests are not created in interrupts, and/or requests are sent via a menu driven interface. Are there further safeguards against this concurrency issue, is it actually a nonissue, or am I misunderstanding something here?


Protecting against concurrent requests

Josh Milburn
 

I'm particularly interested in how the following scenario is prevented:

1. Code from one thread ("A") in the application calls `prepare_coap_request` (which in turn, calls `oc_rep_new`, resetting the current CBOR encoder state). For example, this might happen by someone calling `oc_init_post`.
2. Thread "A" sees a 'success' from `oc_init_post`, and calls `oc_rep_begin_root_object` and begins building a request body
3. Thread "A" is interrupted by higher priority thread "B" which calls `oc_init_post`. 
4. Thread "B" completes and sends request
5. Control is returned to thread "A", which continues trying to build a request body, but the data is now meaningless (since the state of `g_encoder` and `root_map` in `oc_rep.h` have been modified

Looking over the example apps, most seem to provide protection against this by ensuring that requests are not created in interrupts, and/or requests are sent via a menu driven interface. Are there further safeguards against this concurrency issue, is it actually a nonissue, or am I misunderstanding something here?


Re: iotivity lite bridge - oc_remove_device

George Nash
 

My educated guess as to why you did not see the /bridge/vodslist the first time you tried device spy would be because the bridge device was not yet been onboarded.

 

According to the security specification devices being bridged are not discoverable till the bridge device is onboarded.

 

The vodslist is only updated once a virtual device is actually onboarded. Till then the list will be empty.

 

You asked in another email thread how testing was being done. Most of the testing has been done using OCF’s conformance and test tool (CTT)  I have also done some minor testing by writing small test programs to test against.  Unlike the dummy_bridge these are not checked into the branch since they not good code to reference.

 

I looked into the “OCF Resource to BLE Mapping Specification” and I did not find anything reguarding pin codes.

 

You can try to initiate Bluetooth pairing as a result of the ownership transfer method using pin code.

 

Personally I would split them into two tasks.

 

  1. Pair the Bluetooth device to the bridge device only.  Now the bridge device knows about the Bluetooth device and can expose it as a virtual device.
  2. After the Bluetooth device has already been paired onboard the virtual device using justworks OTM or PIN OTM. (OTM: ownership transfer method).

 

If you are able to get them working as two separate steps then you could try pairing the Bluetooth device a part of the PIN OTM process.

 

The ocfbridging branch is still a work in progress. If you are experiencing any issues or have suggestions please let me know I will try and help you out.  If you think you have found a bug feel free to create an issue and assign it to George Nash (that’s me).

 

George

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of Farid BENAMROUCHE via groups.io
Sent: Wednesday, May 6, 2020 11:13 AM
To: iotivity-dev@iotivity.groups.io; Maloor, Kishen <kishen.maloor@...>
Subject: Re: [dev] iotivity lite bridge - oc_remove_device

 

Never mind, I got the device spy tool working (not sure why the first time it didn't discover the virtual devices)

 

Now I see that if I add a new virtual device, it must be discovered first, then onboarded (with pin code if needed instead of just work)

 

Thank you, I have enough material to continue

 

 

Le lundi 4 mai 2020 à 15:56:20 UTC+2, Maloor, Kishen <kishen.maloor@...> a écrit :

 

 

Hello,

 

Please take a look inside the "ocfbridging" branch.

 

There's some in-progress work over there that should directly address your need. Specifically, it adds infrastructure that allows an application to

dynamically attach and detach virtual OCF Devices based on the presence of related entities in any 3rd party technology. The states of those virtual Devices

are persisted over the duration of their use. Further, this framework incorporates the specified semantics with respect to discoverability (on the OCF side) of

virtual Devices to fulfill some security requirements outlined in the OCF bridging specification.

 

You should be able to build an application that interacts with Bluetooth devices (your code), and map those to virtual OCF Devices using the said infrastructure.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "
fariouche@..." <fariouche@...>
Date: Saturday, May 2, 2020 at 11:50 AM
To: "
iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] iotivity lite bridge - oc_remove_device

 

Hello,

I've finished to read the OCF specification, and as far as I understand for the bridge, each discovered device is associated to a virtual OCF device.
I would like to bridge some bluetooth devices.
So I discover them, pair them (here I think I missed something. How do we pair a bluetooth device that requires a pin?), and then I create a device using oc_add_device() with its associated resources.
So far so good.
But I need to know the "index" of this new virtual device. (currently I have a counter incremented each time I add a device)
However, if the bluetooth device is removed, there is no oc_remove_device() function.... and this will also need the oc_add_device function  to return the index too.

Looking at the code, I see that the oc_add_device() just add a device struct to an array (static or dynamically allocated).
The index is then used everywhere to reference this device.

Maybe a simple solution is to:
1- change the implementation to have to look into the array for a free slot, and associate the index.
2- return this index
3- add oc_remove_device(int index), taking care of de-registering properly the associated resources (or return an error and let the user remove the resources first before calling this function)

I have the feeling that it will not be that easy, so here I am asking you what you think?

Thank you for you help!


Re: iotivity lite bridge - oc_remove_device

Farid BENAMROUCHE
 

Never mind, I got the device spy tool working (not sure why the first time it didn't discover the virtual devices)

Now I see that if I add a new virtual device, it must be discovered first, then onboarded (with pin code if needed instead of just work)

Thank you, I have enough material to continue


Le lundi 4 mai 2020 à 15:56:20 UTC+2, Maloor, Kishen <kishen.maloor@...> a écrit :


Hello,

 

Please take a look inside the "ocfbridging" branch.

 

There's some in-progress work over there that should directly address your need. Specifically, it adds infrastructure that allows an application to

dynamically attach and detach virtual OCF Devices based on the presence of related entities in any 3rd party technology. The states of those virtual Devices

are persisted over the duration of their use. Further, this framework incorporates the specified semantics with respect to discoverability (on the OCF side) of

virtual Devices to fulfill some security requirements outlined in the OCF bridging specification.

 

You should be able to build an application that interacts with Bluetooth devices (your code), and map those to virtual OCF Devices using the said infrastructure.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Saturday, May 2, 2020 at 11:50 AM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] iotivity lite bridge - oc_remove_device

 

Hello,

I've finished to read the OCF specification, and as far as I understand for the bridge, each discovered device is associated to a virtual OCF device.
I would like to bridge some bluetooth devices.
So I discover them, pair them (here I think I missed something. How do we pair a bluetooth device that requires a pin?), and then I create a device using oc_add_device() with its associated resources.
So far so good.
But I need to know the "index" of this new virtual device. (currently I have a counter incremented each time I add a device)
However, if the bluetooth device is removed, there is no oc_remove_device() function.... and this will also need the oc_add_device function  to return the index too.

Looking at the code, I see that the oc_add_device() just add a device struct to an array (static or dynamically allocated).
The index is then used everywhere to reference this device.

Maybe a simple solution is to:
1- change the implementation to have to look into the array for a free slot, and associate the index.
2- return this index
3- add oc_remove_device(int index), taking care of de-registering properly the associated resources (or return an error and let the user remove the resources first before calling this function)

I have the feeling that it will not be that easy, so here I am asking you what you think?

Thank you for you help!


Re: iotivity lite bridge - oc_remove_device

Farid BENAMROUCHE
 

Just finished reading and playing with the ocfbridging branch.
So far, it seems to have all I need.
Still, I have some questions. After playing with the dummy bridge example and using Device Spy to read /bridge/vodlist, I have an empty list (even if I try to select 1 in the menu to simulate light 1 or 7 to start the virtual discovery.)
So I must have missed something. What client (if any) are you using for testing the bridge?
I know it is a work in progress, but if I can help, let me know.

Other question: If my Bluetooth device requires a PIN code for pairing, how do I do that with OCF to transfer the pin code request and return the user's pin code? Do I have to do something myself using a dedicated resource?

Thanks


Le lundi 4 mai 2020 à 15:56:20 UTC+2, Maloor, Kishen <kishen.maloor@...> a écrit :


Hello,

 

Please take a look inside the "ocfbridging" branch.

 

There's some in-progress work over there that should directly address your need. Specifically, it adds infrastructure that allows an application to

dynamically attach and detach virtual OCF Devices based on the presence of related entities in any 3rd party technology. The states of those virtual Devices

are persisted over the duration of their use. Further, this framework incorporates the specified semantics with respect to discoverability (on the OCF side) of

virtual Devices to fulfill some security requirements outlined in the OCF bridging specification.

 

You should be able to build an application that interacts with Bluetooth devices (your code), and map those to virtual OCF Devices using the said infrastructure.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Saturday, May 2, 2020 at 11:50 AM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] iotivity lite bridge - oc_remove_device

 

Hello,

I've finished to read the OCF specification, and as far as I understand for the bridge, each discovered device is associated to a virtual OCF device.
I would like to bridge some bluetooth devices.
So I discover them, pair them (here I think I missed something. How do we pair a bluetooth device that requires a pin?), and then I create a device using oc_add_device() with its associated resources.
So far so good.
But I need to know the "index" of this new virtual device. (currently I have a counter incremented each time I add a device)
However, if the bluetooth device is removed, there is no oc_remove_device() function.... and this will also need the oc_add_device function  to return the index too.

Looking at the code, I see that the oc_add_device() just add a device struct to an array (static or dynamically allocated).
The index is then used everywhere to reference this device.

Maybe a simple solution is to:
1- change the implementation to have to look into the array for a free slot, and associate the index.
2- return this index
3- add oc_remove_device(int index), taking care of de-registering properly the associated resources (or return an error and let the user remove the resources first before calling this function)

I have the feeling that it will not be that easy, so here I am asking you what you think?

Thank you for you help!


Re: iotivity lite bridge - oc_remove_device

Farid BENAMROUCHE
 

great thanks, I will have a look then and keep you posted

Le lundi 4 mai 2020 à 15:56:20 UTC+2, Maloor, Kishen <kishen.maloor@...> a écrit :


Hello,

 

Please take a look inside the "ocfbridging" branch.

 

There's some in-progress work over there that should directly address your need. Specifically, it adds infrastructure that allows an application to

dynamically attach and detach virtual OCF Devices based on the presence of related entities in any 3rd party technology. The states of those virtual Devices

are persisted over the duration of their use. Further, this framework incorporates the specified semantics with respect to discoverability (on the OCF side) of

virtual Devices to fulfill some security requirements outlined in the OCF bridging specification.

 

You should be able to build an application that interacts with Bluetooth devices (your code), and map those to virtual OCF Devices using the said infrastructure.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Saturday, May 2, 2020 at 11:50 AM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] iotivity lite bridge - oc_remove_device

 

Hello,

I've finished to read the OCF specification, and as far as I understand for the bridge, each discovered device is associated to a virtual OCF device.
I would like to bridge some bluetooth devices.
So I discover them, pair them (here I think I missed something. How do we pair a bluetooth device that requires a pin?), and then I create a device using oc_add_device() with its associated resources.
So far so good.
But I need to know the "index" of this new virtual device. (currently I have a counter incremented each time I add a device)
However, if the bluetooth device is removed, there is no oc_remove_device() function.... and this will also need the oc_add_device function  to return the index too.

Looking at the code, I see that the oc_add_device() just add a device struct to an array (static or dynamically allocated).
The index is then used everywhere to reference this device.

Maybe a simple solution is to:
1- change the implementation to have to look into the array for a free slot, and associate the index.
2- return this index
3- add oc_remove_device(int index), taking care of de-registering properly the associated resources (or return an error and let the user remove the resources first before calling this function)

I have the feeling that it will not be that easy, so here I am asking you what you think?

Thank you for you help!


Re: iotivity lite bridge - oc_remove_device

Kishen Maloor
 

Hello,

 

Please take a look inside the "ocfbridging" branch.

 

There's some in-progress work over there that should directly address your need. Specifically, it adds infrastructure that allows an application to

dynamically attach and detach virtual OCF Devices based on the presence of related entities in any 3rd party technology. The states of those virtual Devices

are persisted over the duration of their use. Further, this framework incorporates the specified semantics with respect to discoverability (on the OCF side) of

virtual Devices to fulfill some security requirements outlined in the OCF bridging specification.

 

You should be able to build an application that interacts with Bluetooth devices (your code), and map those to virtual OCF Devices using the said infrastructure.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Saturday, May 2, 2020 at 11:50 AM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] iotivity lite bridge - oc_remove_device

 

Hello,

I've finished to read the OCF specification, and as far as I understand for the bridge, each discovered device is associated to a virtual OCF device.
I would like to bridge some bluetooth devices.
So I discover them, pair them (here I think I missed something. How do we pair a bluetooth device that requires a pin?), and then I create a device using oc_add_device() with its associated resources.
So far so good.
But I need to know the "index" of this new virtual device. (currently I have a counter incremented each time I add a device)
However, if the bluetooth device is removed, there is no oc_remove_device() function.... and this will also need the oc_add_device function  to return the index too.

Looking at the code, I see that the oc_add_device() just add a device struct to an array (static or dynamically allocated).
The index is then used everywhere to reference this device.

Maybe a simple solution is to:
1- change the implementation to have to look into the array for a free slot, and associate the index.
2- return this index
3- add oc_remove_device(int index), taking care of de-registering properly the associated resources (or return an error and let the user remove the resources first before calling this function)

I have the feeling that it will not be that easy, so here I am asking you what you think?

Thank you for you help!


iotivity lite bridge - oc_remove_device

Farid BENAMROUCHE
 

Hello,

I've finished to read the OCF specification, and as far as I understand for the bridge, each discovered device is associated to a virtual OCF device.
I would like to bridge some bluetooth devices.
So I discover them, pair them (here I think I missed something. How do we pair a bluetooth device that requires a pin?), and then I create a device using oc_add_device() with its associated resources.
So far so good.
But I need to know the "index" of this new virtual device. (currently I have a counter incremented each time I add a device)
However, if the bluetooth device is removed, there is no oc_remove_device() function.... and this will also need the oc_add_device function  to return the index too.

Looking at the code, I see that the oc_add_device() just add a device struct to an array (static or dynamically allocated).
The index is then used everywhere to reference this device.

Maybe a simple solution is to:
1- change the implementation to have to look into the array for a free slot, and associate the index.
2- return this index
3- add oc_remove_device(int index), taking care of de-registering properly the associated resources (or return an error and let the user remove the resources first before calling this function)

I have the feeling that it will not be that easy, so here I am asking you what you think?

Thank you for you help!


Re: Iotivity lite state

George Nash
 

The changes have been cherry-picked to master.  They are waiting for a review to be merged.

 

https://gitlab.iotivity.org/iotivity/iotivity-lite/-/merge_requests/112

 

George

 

From: Maloor, Kishen <kishen.maloor@...>
Sent: Wednesday, April 22, 2020 5:30 PM
To: Nash, George <george.nash@...>; fariouche@...; iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity lite state

 

Thanks, George. If you could cherry-pick those specific changes to master, that should satisfy the immediate request.

 

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: "Nash, George" <george.nash@...>
Date: Wednesday, April 22, 2020 at 8:06 PM
To: "Maloor, Kishen" <kishen.maloor@...>, "fariouche@..." <fariouche@...>, "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: RE: [dev] Iotivity lite state

 

The API that I added is only concerned with the ownership status e.g. owned vs. unowned. Any other configuration status is not part of the change.  What other configurations were you interested in?

 

It should not be too hard to cherry-pick that specific change to master.

 

Kishen if you would like me to do that I could have it done tomorrow.

 

You could also checkout the `ocfbridging` branch. If you want to use those APIs before they go through the full review process.

 

You will find three new functions and a callback function

Callback `oc_ownership_status_cb_t` (the callback gives the UUID, logical device index and a bool value indicating if the device’s status is owned or unowned)

Function `oc_add_ownership_status_callback`

Function `oc_remove_ownership_status_callback`

Function `oc_is_owned_device`

 

 

I have kept the `ofcbridging` branch up to date with master so you should be able to use the new APIs without making any additional modifications to your code.

 

George

 

 

 

From: Maloor, Kishen <kishen.maloor@...>
Sent: Wednesday, April 22, 2020 4:43 PM
To: fariouche@...; iotivity-dev@iotivity.groups.io
Cc: Nash, George <george.nash@...>
Subject: Re: [dev] Iotivity lite state

 

Hello,

 

We've recently added such an API, but it exists on a branch along with some other in-progress work.

George, would it be possible to submit this specific change to master?

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Wednesday, April 22, 2020 at 7:27 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Iotivity lite state

 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


Re: Iotivity lite state

Kishen Maloor
 

Thanks, George. If you could cherry-pick those specific changes to master, that should satisfy the immediate request.

 

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: "Nash, George" <george.nash@...>
Date: Wednesday, April 22, 2020 at 8:06 PM
To: "Maloor, Kishen" <kishen.maloor@...>, "fariouche@..." <fariouche@...>, "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: RE: [dev] Iotivity lite state

 

The API that I added is only concerned with the ownership status e.g. owned vs. unowned. Any other configuration status is not part of the change.  What other configurations were you interested in?

 

It should not be too hard to cherry-pick that specific change to master.

 

Kishen if you would like me to do that I could have it done tomorrow.

 

You could also checkout the `ocfbridging` branch. If you want to use those APIs before they go through the full review process.

 

You will find three new functions and a callback function

Callback `oc_ownership_status_cb_t` (the callback gives the UUID, logical device index and a bool value indicating if the device’s status is owned or unowned)

Function `oc_add_ownership_status_callback`

Function `oc_remove_ownership_status_callback`

Function `oc_is_owned_device`

 

 

I have kept the `ofcbridging` branch up to date with master so you should be able to use the new APIs without making any additional modifications to your code.

 

George

 

 

 

From: Maloor, Kishen <kishen.maloor@...>
Sent: Wednesday, April 22, 2020 4:43 PM
To: fariouche@...; iotivity-dev@iotivity.groups.io
Cc: Nash, George <george.nash@...>
Subject: Re: [dev] Iotivity lite state

 

Hello,

 

We've recently added such an API, but it exists on a branch along with some other in-progress work.

George, would it be possible to submit this specific change to master?

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Wednesday, April 22, 2020 at 7:27 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Iotivity lite state

 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


Re: Iotivity lite state

George Nash
 

The API that I added is only concerned with the ownership status e.g. owned vs. unowned. Any other configuration status is not part of the change.  What other configurations were you interested in?

 

It should not be too hard to cherry-pick that specific change to master.

 

Kishen if you would like me to do that I could have it done tomorrow.

 

You could also checkout the `ocfbridging` branch. If you want to use those APIs before they go through the full review process.

 

You will find three new functions and a callback function

Callback `oc_ownership_status_cb_t` (the callback gives the UUID, logical device index and a bool value indicating if the device’s status is owned or unowned)

Function `oc_add_ownership_status_callback`

Function `oc_remove_ownership_status_callback`

Function `oc_is_owned_device`

 

 

I have kept the `ofcbridging` branch up to date with master so you should be able to use the new APIs without making any additional modifications to your code.

 

George

 

 

 

From: Maloor, Kishen <kishen.maloor@...>
Sent: Wednesday, April 22, 2020 4:43 PM
To: fariouche@...; iotivity-dev@iotivity.groups.io
Cc: Nash, George <george.nash@...>
Subject: Re: [dev] Iotivity lite state

 

Hello,

 

We've recently added such an API, but it exists on a branch along with some other in-progress work.

George, would it be possible to submit this specific change to master?

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Wednesday, April 22, 2020 at 7:27 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Iotivity lite state

 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


Re: Iotivity lite state

Kishen Maloor
 

Hello,

 

We've recently added such an API, but it exists on a branch along with some other in-progress work.

George, would it be possible to submit this specific change to master?

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Wednesday, April 22, 2020 at 7:27 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Iotivity lite state

 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


Iotivity lite state

Farid BENAMROUCHE
 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


GitHub Stars & Go-OCF Cloud

Jozef Kralik
 

Hello all!

We are trying to join the open collective to receive some sponsorship for the go-ocf/cloud project. As we did some github project reorganization and moved everything under the cloud repository, we have unfortunately 5 starts.

May I please ask you to star this https://github.com/go-ocf/cloud repository, so we can join the open collective? Distribute further please.


Thanks a lot for your support.
Best,
Jozef


Re: Iotivity Client

elizabethnathaniaw93@...
 

Hi George,
So I figure it out in what time my server is. For now, I'm not implement the oic.r.time.stamp yet but I will note it for later use.
Yes, I prefer the 'update now' option. But in the OCF specification, they said that they have the manually triggered software update with change the pstat attribute. But I don't understand how it works. For now, I will use the software update resource.
And I've succeeded to implement the oc_rep_to_json. Now I can continue the next step of my research. Thank you so much. Stay safe and stay healthy.

Regards,
Elizabeth


Re: Project status

Kishen Maloor
 

Hello,

 

> For what I guess, iotivity (now iotivity-clasic) is not maintained in favor of iotivity-

> lite (old iotivity-constrained).

 

Well, they are two independent projects, but yes, iotivity-classic has no active

contributors/maintainers. iotivity-lite is being updated and maintained.

 

> - Device builder have a template to generate code for iotivity-lite. Its currently

> working ?

 

Yes.

 

> - The build system have some patches for mbedtls.

 

Yes, they are required to support some security features of the OCF specifications.

 

> For what I see aplying them makes the mbedtls api incompatible with upstream, not ?

 

I think the impact to upstream APIs is minimal. I beleve those patches larglely add new

stuff to the library internals that did not exist on the upstream.

 

> This patches would be at anypoint integrated into mbebtls original/upstream code?

 

No, there is no such plan at the moment.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of David Suárez <david.sephirot@...>
Date: Wednesday, March 18, 2020 at 5:03 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Project status

 

Hi,

Whats the current iotivity projects status ? For what I guess, iotivity (now iotivity-clasic) is not maintained in favor of iotivity-lite (old iotivity-constrained).

On other way, Im interested in packaging this library(s) for Debian. Currently im packaging ocf specs and device builder. This makes me ask some questions that probably can be resolved here:

- Device builder have a template to generate code for iotivity-lite. Its currently working ?

- The build system have some patches for mbedtls. For what I see aplying them makes the mbedtls api incompatible with upstream, not ? This patches would be at anypoint integrated into mbebtls original/upstream code?

Thanks !