Create App Library Oem Branding
This page explains the recommended OEM and branded fixture workflow. Read this before creating the final fixture entry on the Vision Web Service.
The RDM Manufacturer ID together with the RDM Device Model ID identifies the exact fixture type. These two values cannot be changed after a fixture is released. Changing them would mean that fixtures already in the field may no longer be recognized. Descriptions, images, website URLs, resources, and names can still be changed later.
Recommended workflow
1. Development sample
Create a fixture in your company and use your own naming scheme, your RDM Manufacturer ID, and your RDM Device Model ID. This fixture is used for internal development, demonstrations, and customer samples. It does not need to be visible publicly in the app.
RDM Manufacturer: your company Manufacturer ID
RDM Device Model ID: your fixture-specific Device Model ID
Example with the Vision Core Module:
When the sample is finished and verified, request a release on the fixture page. Until release, the fixture remains internal and only authorized accounts can access it.
2. Customer sample
After the sample is released, ship it to the customer for testing. If the customer wants a branded fixture, continue with the branded production fixture. If no branding is required, you can continue directly with production.
3. Branded production fixture
For a branded product, adapt the firmware and product data to the customer's requirements. The released product should use the brand's final RDM information if the brand needs to own the fixture identity.
RDM Manufacturer: brand's Manufacturer ID
RDM Device Model ID: brand's fixture-specific Device Model ID
Create a separate fixture on the server with the brand's final product information.
After the branded fixture entry is ready, you can share access to the fixture with the brand so they can maintain product data or release information if required.
Bootloader for branded fixtures
A separate bootloader may be created for each branded version of a fixture. However, if one common bootloader shall be used for the supplier-branded product and all customer-branded variants, the signing identity and the identity advertised to the app must be handled separately.
In this example, the same product is sold under the Chinese Supplier Brand and under two different Customer Brands.
Bootloader requirements
| Requirement | Supplier Brand | Customer 1 Brand | Customer 2 Brand |
| Bootloader must accept firmware signed with | Supplier RDM Manufacturer ID + Supplier RDM Device Model ID | ||
| Bootloader must read from the application firmware and advertise to the app | Supplier RDM Manufacturer ID + Supplier RDM Device Model ID | Customer 1 RDM Manufacturer ID + Customer 1 RDM Device Model ID | Customer 2 RDM Manufacturer ID + Customer 2 RDM Device Model ID |
| If the application firmware is unavailable or invalid, the bootloader must advertise | Supplier RDM Manufacturer ID + Supplier RDM Device Model ID | ||
Application firmware requirements
| Requirement | Supplier Brand | Customer 1 Brand | Customer 2 Brand |
| Application firmware update file must be signed with | Supplier RDM Manufacturer ID + Supplier RDM Device Model ID | ||
| Application firmware contains and advertises to the app | Supplier RDM Manufacturer ID + Supplier RDM Device Model ID | Customer 1 RDM Manufacturer ID + Customer 1 RDM Device Model ID | Customer 2 RDM Manufacturer ID + Customer 2 RDM Device Model ID |
In summary: the signing identity is always the Supplier Identity. The identity advertised to the app is the respective brand identity when valid application firmware is running. If the application firmware is unavailable or invalid, the bootloader advertises the Supplier Identity.
This allows one common bootloader to be used for all branded variants, while each bootloader that has, or previously had, valid application firmware still identifies the product using the correct customer-specific brand identity.
