Did anyone get mbed-cloud-client to work?

Mbed OS
1

Hi,

I have been trying to implement a mechanism to upgrade device firmware over the air. Mbed-cloud-client seems like a good choice. I was able to compile the example project, and register it in mbedcloud portal. Up to this point the process seems quite straight forward and smooth.

I am then stuck at the step to create firmware upgrade manifest. According to documentation that is now hosted on IzumaNetworks, I will need a vendor and class id that can be obtained from dashboard under Device identity > Factory. Unfortunately I am unable to find such section.

image
image761×377 26.8 KB

I have contacted IzumaNetworks for help, but I’m not sure they will respond anytime soon if ever. So if you have successfully gone through the evaluation process, please advise.

Thanks,
ZL

2

Hello,

to be honest after Pelion was sold by ARM I do not tried it anymore and also because it is paid service.
But definitely give us an info about the progress, it can be interesting for someone.

BR, Jan

3

The new owner(IzumaNetworks) doesn’t seem to be putting any effort into further development at the moment. I spent a good two days going through the documentation and so far couldn’t find an example that works out of box. The missing feature (Device identity > Factory) seems like a roadblock we as users cannot work around. So I will give up on this.

4

Hei,

how did you try to contact the Izuma Networks support?

The Mbed OS specific examples have not been updated in a while, but all the SW there should still work as is.

The vendor ID and class ID are used when filtering the devices for update. You can just invent these any way you like, or use any uuid generator. You just need to be consistent when using them.

The update_default_resources.c will have this information in it, when you create it with the manifest-tool.

If you want to use factory provisioning (to which you should have a commercial account) - you just need to put the same values in the fcu.yml file.

Here’s an example:

update_default_resources.c -file

// vendor-id: "adaceddf-f4c3-4036-9a53c71b1955aa50"
const uint8_t arm_uc_vendor_id[] = {
    0xAD, 0xAC, 0xED, 0xDF, 0xF4, 0xC3, 0x40, 0x36,
    0x9A, 0x53, 0xC7, 0x1B, 0x19, 0x55, 0xAA, 0x50
};
const uint16_t arm_uc_vendor_id_size = sizeof(arm_uc_vendor_id);

// class-id: "2d489ba1-b2ab-42b6-9105-5d5562a4a0d1"
const uint8_t arm_uc_class_id[] = {
    0x2D, 0x48, 0x9B, 0xA1, 0xB2, 0xAB, 0x42, 0xB6,
    0x91, 0x05, 0x5D, 0x55, 0x62, 0xA4, 0xA0, 0xD1
};
const uint16_t arm_uc_class_id_size = sizeof(arm_uc_class_id);

In fcu/config/fcu.yml file I have then this:

############################################################
# Firmware Integrity (for firmware update)
############################################################

# File location for update auth certificate
# Original one here, created with the script
# update-auth-certificate-file: <%= ENV['FCU_RESOURCES_DIR'] %>/update-auth-certificate.der
# Use the one created with manifest-dev-tool init - Izuma-Credentials/.manifest-dev-tool -folder
update-auth-certificate-file: <%= ENV['FCU_RESOURCES_DIR'] %>/dev.cert.der
# Vendor-Id - UUID string that represents the vendor (for example, "fa6b4a53-d5ad-5fdf-be9d-e663e4d41faf")
vendor-id: "adaceddf-f4c3-4036-9a53c71b1955aa50"
# Class-Id - UUID string that represents the device class (for example, "4a5fa6b3-5fef-fe9d-bee4-66e41f3e4daf")
class-id: "2d489ba1-b2ab-42b6-9105-5d5562a4a0d1"

When doing manifests, you need to use the same values also there - manifest.yml

more manifest.yaml 
vendor:
    vendor-id: 1a3896d41a594783980fcfca1d355838
device:
    class-id: c280e8c41dac4c3d904c85ebb554e298
priority: 1
...

Now, for not using something because it is commercial - bear in mind there is no free lunch. Running the services costs money, time and effort. Someone has to pay for it. The services you use for free are paid by someone - be it Google (you sell your privacy, you get adverts etc.) or anyone else.

I hope we can get you unblocked, but - for serious use - you must agree also on commercial terms.

5

By the way, there’s more documentation for the device management in here: https://developer.izumanetworks.com/

6

The documentation by the way does not say you can find vendor ID and class ID in the dashboard. It says you can find them in the fcu config you did when you provisioned the devices (directly following the link you gave).

image
image771×428 39.3 KB

There are quite a few steps in the process, so it can get a bit complicated. I wish it was much simpler, but with security comes a bit of complexity.

7

Hi Janne,

Thank you so much for replying. I did generate vendor and class id with manifest-tool, with that I was able to generate a manifest, upload to dashboard, create a campaign. Then there is the issue to build bootloader and main application etc. etc. At that point I just gave up. I guess with your new information and some effort we can still get Pillion to work.

We really just need a mechanism to deliver firmware update occasionally, and our devices are already always connected to our own server. With that in mind, I was able to build a basic prototype with MCUboot in a matter of hours. Main application downloads new firmware and saves it into a storage known to bootloader and notify it and restart system. It is quite a straightforward process. There are also security issues, but I feel the signing, and encryption facilities provided by MCUboot should be adequate enough for us. The component and delta upgrade provided by Pelion are nice to have but not a must at our scale.

I am not against paying for services if they can reduce entry barrier or are cheaper/quicker than to develop in-house. In the case of FOTA, my two bigger concerns are: 1) technical issues related to having two certificates and making secure requests to two server system(Pelion and our own). 2) regulatory issues related to having another 3rd party service provider.

Thanks for your information again and best regards,
ZL

8

This is where the documentation tripped me off. The documentation seems to indicate FCC is a required step in the work flow, and account grandfathered from Mbed just doesn’t have the feature required to evaluate FCC.

image
image1106×359 29.7 KB