Previously, any OMA-DM campaign included only one FOTA upgrade attempt. For example, an OMA-DM campaign may begin at 12:00 AM UTC which is when the device(s) are notified. This request is queued in the network for 4 hours and if the device was powered off during that window, the campaign would be considered a failure. And a new campaign would need to be created.
This feature introduced a network-aware campaign experience specific for OMA-DM. Now, after that 4 hour window fails, ThingSpace and the Verizon network will queue this device in the network indefinitely for an upgrade. The next time it powers on, it will be notified for upgrade and the campaign will begin. If that campaign fails, it will be queued up again indefinitely. See the campaign timing documentation for more detail. This new behavior has implications on the device firmware history API and get information about an upgrade API.
The existing product feature set included managing software/firmware for devices certified for Verizon FOTA using OMA-DM, LWM2M, and HTTP protocols. This release introduces many new capabilities for LWM2M devices when using the new /v3 API. Existing behavior has not changed for the /v1 and /v2 APIs.
The new /v3 APIs for LWM2M devices includes these new features:
POST /licenses/{account}/cancel
DELETE /licenses/{account}/cancel
GET /licenses/{account}/cancel
GET /files/{account}
POST /files/{account}
PUT /files/{account}
POST /campaigns/files/{account}
The existing product feature set was based on managing software/firmware for compatible OMA-DM and LWM2M devices using Firmware-over-the-Air (FOTA) technology. When LWM2M or OMA-DM campaigns begin, the respective service sends a message to the device and instructs it to fetch the new firmware update (push-based). Those capabilities still exist and are accessible via the /v1 set of APIs.
This release introduces an entirely new system and stack for managing software/firmware on compatible devices. The new system and stack is dependent on device-client compatibility:
The new APIs are very familiar but have some different features. One notable difference with the new system is that the campaign time is dependent 1) on when the campaign windows are set and 2) how often the devices check-in (pull-based) inside the desired campaign windows.
The following /v2 APIs are now available for devices using HTTP-based FOTA. They are similar to the existing OMA-DM- and LWM2M-based FOTA, but you should review the API Reference to understand the nuances, particularly the change in the endpoint URIs.
GET /subscriptions/{acc}
GET /licenses/{acc}
POST /licenses/{acc}/assign
POST /licenses/{acc}/remove
POST /campaigns/{acc}
GET /campaigns/{acc}/{campaignId}
DELETE /campaigns/{acc}/{campaignId}
PUT /campaigns/{acc}/{campaignId}
PUT /campaigns/{acc}/{camapignId}/dates
POST /callbacks/{acc}
PUT /callbacks/{acc}
GET /callbacks/{acc}
DELETE /callbacks/{acc}
GET /software/{acc}
GET /devices/{acc}
GET /reports/{acc}/devices/{deviceId}
GET /reports/{acc}/campaigns
GET /reports/{acc}/campaigns/{campaignId}/devices
GET /logging/{acc}/devices
PUT /logging/{acc}/devices
DELETE /logging/{acc}/devices
PUT /logging/{acc}/devices/{deviceId}
DELETE /logging/{acc}/devices/{deviceId}
GET /logging/{acc}/devices/{deviceId}/logs
GET /logging/{acc}/devices/{deviceId}/checkInHistory
GET /devices/{account}
clientType
query string to only return devices of the specified client type (device management protocol).GET /firmware/{account}
clientType
query string to only return firmware that is applicable to the specified client type (device management protocol).POST /callbacks/{account}
GET /devices/{account}
PUT /upgrades/{account}/upgrade/{upgradeId}
{"success": true}
for successful completion:DELETE /licenses/{account}/cancel
DELETE /callbacks/{account}/name/{service}
DELETE /upgrades/{account}/upgrade/{upgradeId}
DELETE /licenses/{account}/cancel
Deletes the entire list of cancellation candidate devices.Initial release of the ThingSpace Software Management Services API.