iotivity
Registering multiple OCF Servers created in one app to OCF cloud
Hello, I need help so I'm posting this as an issue here.
I am currently developing a ZigBee bridge app, and I want to register several Virtual OCF Devices mapped with ZigBee devices to the plgd cloud and control them from the user app.
Before doing this, I am first testing using an example to see if the OCF Servers created in one app are properly registered in the plgd cloud.
So, I modified the MultiDeviceServer example in the Android environment by adding cloud-related sources, and provisioned the CloudConfResURI included in the OCF Server. However, when I tested it, I found that the first OCF Server was registered in the cloud, but the second or third device was not registered.
Can anyone give me some advice on this phenomenon? Is there a limitation that only the first OCF Server among multiple OCF Server devices can be registered to the cloud in one app?
The plgd-dev branch is used as the iotivity-lite library, and OCF Cloud is tested using the previous plgd-dev/cloud source.
I suspect there is some correlation between the device index, cloud context, and cloud manager, but I am having difficulty resolving it because I do not know the exact flow of the iotivity library source. If there is a problem, it is expected to be a problem within iotivity-lite.
Hello @Askidea,
I recommend switching to the master branch instead of the plgd-dev branch, as the latter is now considered obsolete. The master branch is fully compatible with plgd-dev/hub.
Regarding the cloud manager in iotivity-lite, it has been implemented to support such scenarios theoretically. You would need to start the cloud manager for each device like this:
for (size_t device = 0; device < max_devices; ++device) {
oc_cloud_context_t *ctx = oc_cloud_get_context(device);
if (ctx) {
oc_cloud_manager_start(ctx, cloud_status_handler, NULL);
}
}
Afterward, you must onboard each device separately, and each device should have its own authorization code.
To get started, I recommend upgrading your iotivity-lite to the latest master branch.
@Askidea I just tested it, and there were indeed some issues.
These issues have been addressed in this PR: https://github.com/iotivity/iotivity-lite/pull/532. Additionally, I have extended the apps/cloud_server.c to allow for specifying the number of devices (servers) that will be created.
To onboard a device, you can use the client application available here: https://github.com/plgd-dev/client-application.
@jkralik Thank you for your comments.
The reason for using the plgd-dev branch is because the source code that supports the ZigBee bridging function was applied based on that branch. Perhaps more precisely, it is the ocfbridging branch. I also want to apply the latest branch, but it is not easy to apply the ZB bridging source to the latest branch.
Anyway, I applied the changes you made in the commit 34f2a48 to build the iotivity library and applied it to the MultiDeviceServer app, but it was not successful. It is probably coupled with some other part of the library code.
So, if I'm using the plgd-dev branch and not the latest branch, could you give me some advice on what parts of the code I need to change or check to resolve this issue?
The https://github.com/iotivity/iotivity-lite/tree/ocfbridging branch is 1000+ commits behind master, that's a bit problematic, lots of work has been done since. I guess it was a not fully finished feature...? Or @jkralik any idea why it was not merged into master back in 2020?
The https://github.com/iotivity/iotivity-lite/tree/ocfbridging branch is 1000+ commits behind master, that's a bit problematic, lots of work has been done since. I guess it was a not fully finished feature...? Or @jkralik any idea why it was not merged into master back in 2020?
@Askidea Could you please identify the functions you're using in your application that are not available in the master branch? Additionally, the second question pertains to who will be responsible for porting these changes to the master branch, as it is a time-consuming task.
@Askidea Could you please identify the functions you're using in your application that are not available in the master branch? Additionally, the second question pertains to who will be responsible for porting these changes to the master branch, as it is a time-consuming task.
Indeed, at a quick glance it might take few weeks. There is a Bridging specs in https://openconnectivity.org/developer/specifications/ , so I guess the branch is supposed to be the implementation of it. Bridging seems like useful feature, especially in IoT world which has many different protocols, but we're pretty booked out already...
@jkralik I don't want you to do a detailed source analysis for 2020. I just wanted to know roughly what parts are related to enable multi-device cloud login in 2020. And I don't think there will be any function that the current master branch cannot support for bridge implementation. Anyway, in the current situation, I think it is difficult to log in to the cloud for multiple devices using the iotivity library in 2020. I created two devices in the MultiDeviceServer app, started the cloud manager on each, and tried logging in to the cloud by provisioning CloudConfResURI, but it showed abnormal behavior. There seems to be a problem with device index handling in the iotivity library stack.
So, I plan to change direction and proceed by porting the existing development source code to the latest master branch source.
Thanks.
So, I plan to change direction and proceed by porting the existing development source code to the latest master branch source.
Yeah that would be for the best. I only took a quick glance, but it doesn't look too complicated. Since it is not in master the feature should be disabled, thus hidden behind a feature macro (OC_BRIDGE or OC_BRIDGING) - when the macro is not defined the code should be ifdef-ed out. So all the code from the branch must be guarded by the feature macro, but otherwise it should be possible to just copy the code to master.