Skip to main content

Activating New 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 (factory 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 credentials it needs to connect to a local WiFi network. BlinkUp also provides the device with an enrollment token which is used to verify that the device requesting access to the impCloud is one being enrolled. BlinkUp is sometimes also used to pass a plan ID to the device — during BlinkUp, plan IDs differentiate one device user from another.

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 tokens, each used according to the circumstances of the enrollment:

Enrollment Token Type Device to be Enrolled Token Sent By
Developer Development devices
Factory BlinkUp fixtures
Electric Imp mobile app
Factory Pre-blessed devices (DUTs) Factory BlinkUp Fixture
Production Blessed devices (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, which retrieves a factory enrollment token but no plan ID. Instead of running application firmware, the device that has been enrolled receives and runs the 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 developer’s Development Device Groups, causing it to receive and run the application code most recently deployed to the Device Group. If it is subsequently re-enrolled, the device remains assigned to the same Development Device Group.
  • When a factory BlinkUp fixture has been enrolled, it appears in impCentral as an unassigned device — it can now be manually assigned to any of the customer’s Factory Test Device Groups or Factory Device Groups. In either case, it receives and runs the factory firmware code most recently deployed to its assigned Device Group. If it is subsequently re-enrolled, the device remains assigned to the same Device Group.
  • When a DUT on the assembly has been enrolled, it automatically receives the factory firmware deployed to the Factory Device Group to which the enrolling factory BlinkUp fixture has been assigned.
  • When a blessed production device has been enrolled, it will run the application firmware deployed to the Production Device Group to which it was assigned at blessing.

The following are the only public impCloud enrollment flows that Electric Imp supports:

  • Factory 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 factory 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
 

The App Testing Enrollment Flow

One exception to the rules outlined above is permitted in order to allow easy testing of BlinkUp SDK-based apps (ie. users of production plan IDs) using development devices (ie. those usually enrolled with developer plan IDs).

If — and only if — the device has previously been enrolled with the Electric Imp app and been assigned to a Device Group, then it will continue to run the application firmware deployed to that Device Group even if it is enrolled with a production plan ID.
 

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 will need to 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 will need to 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 will need to re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.

It is no longer necessary and undesirable to 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 blessed devices or on development devices.
 

Unsupported Enrollment: imp001-specific Flows

Because the imp001 card is removable, it can be taken from a development or blessed device and placed in a device of a different type — or even a different imp001-based product. Again, these 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 imp001 cards should only be used in development devices. Their use in factory BlinkUp fixtures is no longer be supported; please replace any imp001-based fixtures with imp module-based fixtures immediately as they will cease to work from March 1, 2018.

Blessed 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 will need to re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.

Blessed Device with a Different Product’s Production 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 will need to re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.

Blessed Device with a Factory imp001

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 will need to re-enroll the device using the customer’s BlinkUp SDK-based app when the device next disconnects.