A glossary of platform words and phrases
The Electric Imp architecture makes use of a number of terms which are unique to the platform. It also includes common terms but gives them specific meanings. Below is a list of these terms and their definitions in the context of the Electric Imp platform.
— Indicates the term is primarily relevant to development
— Indicates the term is primarily relevant to production
imp applications comprise two parts: the impCloud™-hosted agent and the device, both connected directly and securely on a one-to-one basis. This unique approach allows the application to be segmented for greater efficiency: the agent specializes in memory and Web IO intensive tasks, while the device focuses on physical IO and local processing. The agent also operates as an intermediary between the device and Internet-based resources, such as cloud services, and remote control apps on phones and tablets. Agents also continue to run even when a device has temporarily gone offline, for example to enter a deep sleep state to conserve battery power. So even if the device is asleep, the application as a whole is still operational.
An agent’s identifier. It is unique for each combination of device ID (from the device with which the agent is uniquely associated) and plan ID used to enroll the device. It is used externally as the path to an agent at the base URL
agent.electricimp.com — you can see the agent ID in the agent’s full agent URL, in other words. It is also used internally, for example, to bind an agent to its server.save() persisted data.
The action of registering a newly manufactured production device with the impCloud and which assigns the device to the Production Device Group to which the product’s application firmware will be deployed. Blessing is performed by factory firmware temporarily running on the device in the factory.
The optical data transmission process by which an imp-enabled device is configured for local network access and passed the enrollment credentials it requires to gain access to Electric Imp’s impCloud.
A software development kit for Android or iOS mobile devices that allows customers to integrate BlinkUp into the mobile apps they will supply to their end-users to manage connected production devices.
This is the password a customer must enter to convert a specified production device to a development device. It is not the same as the customer’s account password.
Any hardware product that incorporates an imp to bring it Internet connectivity and compute power. Devices can range from simple breakout boards for application development to complete products, such as air-conditioning units, power breakers and running machines.
Devices fall into two categories: development and production. Development devices are registered to a developer account. Production devices are those that will undergo blessing in the factory and then be purchased by end-users.
The impCentral API entity by which devices are organized. A device, whatever its type, is assigned to a Device Group. It will then run whatever code is deployed to that group. There are various types of Device Group, each derived from the type of device it can contain: Development, Factory, Production, Pre-factory/Factory Test and Pre-production/Test Blessed.
A unique identifier that distinguishes one device (and therefore its on-board imp) from another. Developers see their devices’ IDs in impCentral. An end-users may find their device’s ID etched on the product or presented by the product’s mobile app. However the ID is presented, it may be used to identify the device during, say, support calls. How — and whether — the device ID is provided to an end-user is the customer’s choice. The device ID is usually a four-digit prefix followed by its imp’s MAC address.
A newly assembled imp-based unit in the factory that has yet to be blessed for end-use. The DUT will be powered and then enrolled and configured for factory network access by a factory BlinkUp fixture, after which it receives the same factory firmware that has been deployed to the fixture. This firmware tests the DUT and then, if those tests are passed, blesses it. With blessing, the DUT becomes a production device.
The process by which a device attempts to gain authorization to access the Electric Imp impCloud. Enrollment success depends on the credentials — enroll token and plan ID — passed to the impCloud during the enrollment process, and on whether the device is intended for development or production. Developers’ devices are enrolled when a device is configured for development by using the Electric Imp mobile app. End-users’ devices are enrolled when the product is configured using BlinkUp integrated into a customer’s mobile app.
A one-time authorization token (technically, a nonce) used to validate a BlinkUp operation. It is issued by Electric Imp’s impCloud and passed to the app that is performing BlinkUp to configure a device. The token is sent to the device during BlinkUp and, once the device has connected to the local network, is relayed to the impCloud, which compares it to the token it transmitted to the app at the start of the enrollment process. Once this comparison had been made, the token is destroyed.
A special imp-based device used within the factory to configure newly manufactured production devices for factory network access using the BlinkUp process. To perform this task, the fixture runs factory firmware.
Special software that is run within the factory. It is used on a factory BlinkUp fixture to configure newly manufactured devices for factory network access. Once those devices have been configured, they will download and run the same factory firmware, which will then perform tests on those devices and bless devices that pass the tests. As such, the factory firmware comprises two code paths: one for the factory BlinkUp fixture, the other for the device under test. Factory firmware is developed and tested in impCentral using a Factory Test Device Group.
A one-time enrollment token used to validate a factory BlinkUp operation. It is issued by Electric Imp’s impCloud upon request from the factory BlinkUp fixture that is performing BlinkUp on newly assembled devices under test (DUTs). The token is sent to the DUT during BlinkUp and, once the DUT has connected to the local network, is relayed to the impCloud, which compares it to the token it transmitted at the start of the process. Once this comparison had been made, the token is destroyed.
A database record in Electric Imp’s impCloud which links a production device to a customer’s account. A global bond is the result of the blessing process and it should be considered permanent. An end-user can’t remove their device’s global bond, but customers can for development and testing purposes.
A type of impModule™ — a component that brings Internet connectivity and compute power to a device. It runs the device portion of the code that makes up the connected product’s application firmware. Individual imps can be distinguished by their MAC address.
The new, next-generation online development environment used to create imp applications and the agent and device code they are constructed from. impCentral allows developers to switch development and factory devices to different device groups for development and testing, and to log information posted by those devices while they are running.
impCentral also provides access to production functionality for those users with a commercial relationship with Electric Imp, including production management, and factory code development and testing.
Electric Imp’s highly secure, massively scalable public cloud. Here agents are instantiated within Squirrel virtual machines akin to those maintain by impOS and interact with their devices and external wen services. The impCentral web app communicates with agents and devices via the impCentral API, a front-end for the impCloud’s core services. Mobile apps and devices undergoing enrollment also communicate with these core impCloud services.
The device-side operating system which manages the device’s Internet connectivity and mediates communication between the virtual machine-hosted Squirrel application code and external peripherals connected via GPIO and/or standard buses.
The identifier which differentiates one device’s user from another. Each developer has a plan ID, a ‘development plan ID’, that is generated when they create their Electric Imp account. End-user plan IDs (‘production plan IDs’) are generated when the end-user enrolls a production device using BlinkUp. Depending on the requirements of the application, end-user plan IDs may be retained throughout the end-user’s ownership of the device, or re-generated every time the device needs to be re-configured, for example when the end-user changes their local WiFi network details.
The impCentral entity which embodies a connected product, including all of the many and various units of code — development and production; application and factory; version after version — which are used, or have been used, by that product.
The facility by which a blessed production device can be temporarily set to post log data for the purposes of customer support. Production logs are viewed in impCentral. Unlike development devices, blessed production devices do not normally transmit log data.
A one-time authorization token used to validate a BlinkUp operation. It is issued by Electric Imp’s impCloud and passed to a customer’s BlinkUp SDK-based mobile app which is performing BlinkUp to enroll a production device for end-use. The token is sent to the device during BlinkUp and, once the device has connected to the local network, is relayed to the impCloud, which compares it to the token it transmitted to the app at the start of the process. Once this comparison had been made, the token is discarded.
A mechanism by which information generated by the factory firmware and key events in a production device’s life — blessing and BlinkUp — can be passed from Electric Imp’s impCloud to a customer’s own server.