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).




From: <> On Behalf Of Farid BENAMROUCHE via
Sent: Wednesday, May 6, 2020 11:13 AM
To:; 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 :





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.






Kishen Maloor

Intel Corporation


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



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!

Join to automatically receive all group messages.