Activating imp-Enabled Devices
Which Device Enrollment Flows Do We Support?
Enrollment is the process by which an imp-enabled device is granted access to the Electric Imp impCloud™. There are variations on this process for all of the key types of device that might seek access to the impCloud: Development Devices in the lab, factory devices (BlinkUp™ Fixtures and Devices Under Test (DUTs)), and Production Devices in the field.
Enrollment is closely related to BlinkUp, which is the means by which an imp-enabled device receives the enrollment token it subsequently uses to verify its request for access to the impCloud. BlinkUp is sometimes also used to retrieve a plan ID for the device — plan IDs differentiate one device user from another.
The first time a Production Device is enrolled, the process is called activation.
What follows is a description of the current enrollment process, the recommended flows that will ensure successful device enrollment, and guidance on what will be observed when unsupported flows are employed.
Enrollment Tokens And Plan IDs
There are different types of enrollment token, each used according to the circumstances of the enrollment:
| Enrollment Token Type | Device to be Enrolled | Token Sent By |
|---|---|---|
| Developer | Development Devices BlinkUp Fixtures |
Electric Imp mobile app |
| Factory | DUTs/ Test DUTs |
BlinkUp Fixtures |
| Production | Production (ie. Blessed) Devices/ Test Production Devices |
Customer’s BlinkUp SDK-based app |
In addition, there are two different types of plan ID, each used according to the target device’s intended user:
| Plan ID Type | User Type Identified | Plan ID Sent to Device Only By |
|---|---|---|
| Developer | The Electric Imp account with which the enrolled device will be associated | Electric Imp mobile app |
| Production | The Production Device’s end-user | Customer’s BlinkUp SDK-based app |
Factory enrollment does not make use of plan IDs.
Supported Enrollment Flows
Production and Developer enrollment involves the following stages:
Click for a larger version
Customers’ BlinkUp SDK-based apps typically retrieve a new production plan ID each time a device is configured. The Electric Imp app retrieves the developer’s single plan ID when the developer logs into the app.
Factory enrollment is slightly different in that no mobile app is used: BlinkUp is driven by factory hardware, a BlinkUp Fixture, which retrieves a factory enrollment token but no plan ID. Instead of running application firmware, the device that has been enrolled receives and runs its assigned factory firmware.
If the impCloud cannot enroll any device for some reason — for example, the token is invalid, or of the wrong type — it sends a rejection in response to the device’s enrollment request. What the immediate effect of this rejection will be will depend upon the enrollment circumstances. Possible outcomes are discussed later in this article.
- When a development device has been enrolled, it appears in impCentral™ as an unassigned device. It can now be manually assigned to any of the account’s Development Device Groups, causing it to receive and run the application firmware most recently deployed to the group. If it is subsequently re-enrolled, the device remains assigned to the same Development Device Group.
- When a BlinkUp Fixture has been enrolled, it appears in impCentral as an unassigned device. It can now be manually assigned to any of the account’s Test Factory Device Groups or Factory Device Groups. In either case, it receives and runs the factory firmware most recently deployed to its assigned group. If it is subsequently re-enrolled, the device remains assigned to the same (Test) Factory Device Group.
- When a DUT has been enrolled, it automatically receives the factory firmware deployed to the Test DUT Device Group or DUT Device Group set in impCentral as the enrolling (Test) Factory Device Group’s target.
- When a Production Device has been enrolled, it will run the application firmware deployed to the Test Production Device Group or Production Device Group to which it was assigned at blessing.
The following are the only public impCloud enrollment flows that Electric Imp supports:
- BlinkUp Fixtures should only be enrolled using the Electric Imp mobile app (ie. using a development token and a developer plan ID).
- Development Devices should be initially enrolled using the Electric Imp mobile app (ie. using a development token and a developer plan ID).
- DUTs should only be enrolled using BlinkUp Fixtures.
- Production Devices should only be enrolled using the customer’s BlinkUp SDK-enabled app (ie. using a production token and a production plan ID).
The following flowchart will help you choose the correct enrollment flow:
Click for a larger version
App Testing
BlinkUp SDK-based apps are intended to be use to enroll Test Production Devices and Production Devices. These devices are the outcome of the Connected Factory Process, but it may be inconvenient at a certain time to set up this Process solely to produce one or two devices that can be used for app testing. For this reason, impCentral allows you to assign development devices to Test Production Device Groups. Once so assigned, these devices are effectively blessed and so may be enrolled with your BlinkUp SDK-based app. This streamlined procedure is no substitute for the full test process, which you will need to perform in any case, to create and test your factory firmware and to verify your factory settings.
- For more information on app testing, please see How To Test BlinkUp SDK-based Apps.
Unsupported Enrollment Flows
The following actions are not supported by Electric Imp and should not be implemented by customers. They are included here to help you understand what you may have done wrong if you are experiencing unsuccessful enrollments or other unexpected device/agent behavior: for example, a device that enrolls but has no agent.
Blessed Production Device, Development Token, Developer Plan ID
This is typically a blessed device being enrolled using the Electric Imp mobile app, possibly by an end-user attempting to convert a purchased product into a development device.
The device will signal that BlinkUp has failed (a red flash) and boot its existing production application firmware. Its network credentials are cleared, so that the user must re-configure using the customer’s BlinkUp SDK-based app when the device next disconnects.
Blessed Production Device, Development Token, Production Plan ID
The device will run the application firmware deployed to the Production Device Group of which it is a member. Its network credentials are cleared, so that the user must re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.
Blessed Production Device, Production Token, Developer Plan ID
This is typically where a customer has hard-coded their developer plan ID into their BlinkUp SDK-based app to facilitate app testing.
The device will run the application firmware deployed to the Production Device Group of which it is a member. Its network credentials are cleared so that the user must re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.
Note Do not include developer plan IDs in your apps. If you are doing so, please remove it and make use of the production plan IDs supplied by the BlinkUp SDK. Test your app on (Test) Production Devices. Please see How To Test BlinkUp SDK-based Apps for further details.
Unsupported imp001 Enrollment Flows
The following flows are not supported but are described here to help you understand what you may have done wrong if you are not experiencing successful enrollments or other unexpected device and/or agent behavior.
Note The use of imp001 cards in BlinkUp Fixtures is no longer supported. Please use Fixtures based on imp modules.
Production Device Fitted With A Development imp001
The imp001 will receive the production application firmware assigned to the device, but it will have no agent. Its network credentials will be cleared so that the user must re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.
Production Device With A Different Production Device’s imp001
The imp001 will receive the production application firmware assigned to the device, but it will have no agent. Its network credentials will be cleared so that the user must re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.
Production Device With A Factory imp001
Note This flow has now been eliminated; impCentral does not use or support factory imps.
If the imp001 and the device are associated with the same account, the factory imp001 will receive the factory firmware it has been associated with, and it will proceed to test and re-bless the device.
If they are not associated with the same account, the imp001 will receive the device’s assigned production application firmware. Its network credentials will be cleared so that the user must re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.