Electric Imp’s impCentral™ is the new, next-generation version of the Electric Imp IDE. It provides a much more flexible and far more scalable foundation for developing and deploying high-volume IoT products based on the Electric Imp Platform than the IDE allows.
impCentral is being made available to allow you to try out its new features without affecting any of your existing models in the IDE. This introduction to impCentral will help you understand how the new app works to bring you powerful yet flexible code and device management functionality.
For owners of free Electric Imp development-only accounts who are working solely on their own projects, getting started with impCentral is straightforward: there are some terminology and user-interface changes to learn, but the broad process of writing code and running it on your devices is much the same as it is in the IDE. You will need to understand the relationship between Products and Development Device Groups, and how they differ to models.
Electric Imp Enterprise account holders, and free account holders who are collaborating on shared Enterprise accounts, will also need to understand how the different types of Device Group — Development, Production, Factory and Test Factory — are applied and how they interrelate. They will need a firm grasp of how factory BlinkUp fixtures are assigned in impCentral, how the new web app is used to deploy code to Production and Factory Device Groups, and how Test Factory Device Groups can be used to pre-flight your production process and factory setup before you go into production.
Electric Imp now maintains two Public ImpClouds: one hosted on Microsoft Azure, the other on Amazon Web Services (AWS). All existing accounts are hosted on AWS, but new accounts may be created on either impCloud. Accounts on the two impClouds are not linked in any way: even if you possess the same username on both impClouds, you will not be able to access one account’s Products and devices from the other account. Owning a given username on one impCloud does not guarantee you the same username on the other.
In addition to this introduction to impCentral, we have also prepared a set of FAQs to answer commonplace questions about the new system.
impCentral should work on almost any desktop browser. However, only the following browser versions are formally supported and targeted for new features:
To maintain compatibility with impCentral, you are advised to enable automatic browser updates. We will always support the two most recent vendor supported versions at any given time. As new versions of these browsers are released, support for the earlier of the two previously favored versions will end: we will not test new features and updates with older browsers.
impCentral does not currently include all of the app’s planned production functionality, so some of what follows will not yet be visible even to users with production privileges. Holders of free Electric Imp accounts will only be able to access impCentral’s code development functionality. The following is a list of functionality not implemented or only partially implemented:
impCentral will be very familiar to anyone who has used the IDE. However, a number of small changes have been made to the way its key features are accessed. These changes make access to the components of your product quicker and easier. If you are unfamiliar with the IDE, please see the IDE User Guide.
Like the IDE, impCentral has a bar at the top of its browser window which contains the devices menu (), the help menu (), ‘What’s New’, and the account menu. The devices menu now provides quick access to all of the development devices available to the account owner (via the ‘My Development Devices’ link) both assigned and unassigned. It also includes the device-search field into which you can enter a device’s ID, its MAC address or an agent ID:
The account menu can be used by account owners to make changes to their email address or update their login password — select ‘Account Settings’ — or to log out of impCentral.
Note The following sections introduce some new terms to describe the way Electric Imp applications are organized in impCentral, including Product, Device Group, Development Zone and Production Zone. These terms are explained in more detail later in this document.
Below the top bar is a new ‘breadcrumb’ navigation bar, which initially presents the currently selected account. When you log in, this will be your own account. If you have access to other accounts as a collaborator, clicking on ‘Account ’ will pop up a list of available accounts that you can choose from. The currently selected account is highlighted in this list:
Clicking on the account in the navigation bar will show the displayed account’s Products. Products are impCentral’s way of encapsulating Electric Imp-based applications. Selecting one (by moving the mouse pointer onto its listing and clicking either the ‘Development Zone’ or ‘Production Zone’ link in the ‘MANAGE’ column) will add it to the navigation bar:
The Development Zone and the Production Zone are impCentral’s two primary areas of functionality. Holders of free Electric Imp accounts only have access to the Development Zone, unless they have also been granted access to an Enterprise account as a collaborator. The Zones are color-coded: blue for development, green for production.
Below the name of the Product is a pop-up list of the account’s most recently accessed Products (‘Product ’) so you can quickly jump to other Products. Next to this menu is a switch which moves you between Development and Production Zones for the currently selected Product ( ). If the selected account does not have permission to access impCentral’s production functionality, Production Zone will remain inactive and not respond to clicks.
impCentral provides a new component, the Device Group, to help you organize devices. Development Device Groups are where you gather development devices to run test code; a Development Device Group is the minimum you need to get working on a Product. Indeed, whenever you create a Product, you are invited to create a Development Device Group too. When you select a Development Device Group, impCentral presents a code editor where you write code and test it by deploying it to the devices assigned to the Device Group. Clicking on a Product in the navigation bar will show that Product’s Development Device Groups. You must be in the Development Zone to see this list.
You can have as many Development Device Groups as you need to develop your Product’s code. For example, you might have a Development Device Group for each regional or functional variant of your product. Moving the mouse pointer onto a Development Device Group and clicking the ‘Code’, ‘Deployments’ or ‘Devices’ link in the ‘MANAGE’ column will add the Device Group to the navigation bar:
Again, the menu below the Device Group’s name in the navigation bar provides access to a pop-up list of all of the Product’s Device Groups relevant to the current zone: Development and Factory Test groups in the Development Zone, Production and Factory groups in the Production Zone.
Whenever an item on the navigation bar is selected, impCentral adds a context-sensitive column of options to the left side of the screen. Clicking the ‘Account’ entry in the navigation bar, for example, shows three icons which, when clicked, respectively present lists of the account’s Products, of the account’s collaborators and of the account’s devices. The Products list is selected initially:
Clicking on the Products item in the navigation bar displays two icons in the side panel which, when clicked, present lists of the account’s Development or Test Factory Device Groups — the ‘D’ and the ‘F’ symbols indicate which is which. The Development Device Groups list is selected initially:
Clicking on the Device Groups item in the navigation bar displays three icons which, when clicked, present the code editor, the deployment history and a list of devices assigned to the selected Device Group. The code editor is selected initially:
The code editor icon indicates the status of the code it currently has loaded: unsaved draft code (indicated by the label ‘DRAFT’), or read-only already deployed code (indicated by the label ‘SHA’):
The code editor section, below, explains the difference between these two code editor modes.
Clicking on the devices icon () will take you to one of two device lists:
For more information on testing the factory process with Test Factory Device Groups, see ‘Testing Factory Firmware and Blessing’, below.
If you are able to access a Product’s Production Zone and do so, you will see icons which, when clicked, present the Product’s Production Device Groups and its Factory Device Groups:
Clicking ‘Devices’ (Production Device Groups) or ‘Fixtures’ (Factory Device Groups) from a list of either of these production entities will call up a list of, respectively, Production Devices or Factory BlinkUp Fixtures assigned to the group. Clicking ‘Deployments’ will call up a list of code deployments made to the group. In either case, the side panel changes to allow you to switch quickly between these two list views (devices and deployments):
impCentral displays lists of items — Products, Device Groups, Devices, Deployments etc. — in a standard, consistent way. The items are listed in a table with columns that are relevant to the type of item being listed:
Column headings with triangles () can be clicked to re-order the table by sorting the column entries alphabetically and numerically, alternating between ascending order (triangle points up) and descending order (triangle points down).
Some column headings feature question marks () — click on these to get more information about the meaning of the information in the column.
Many lists have a selection column at the far left: use the checkboxes to select or deselect multiple items. The checkbox in the table’s headings bar can be used to select or deselect all the items on the page. The row of buttons above the table are used to apply actions to selected list items. impCentral will disable these bulk-action buttons until a selection is made. If that selection contains items that do not respond to an action, the button that triggers that action will be disabled. For example, if you select both assigned and unassigned devices from the Devices list, the ‘Restart’ button will remain disabled because unassigned devices can’t be restarted this way. De-select the unassigned devices, and the ‘Restart’ button will become enabled for the selected assigned devices.
Lists are paginated, and you can use the far-right arrow buttons () to navigate between pages. These buttons are only active if there are more than one page of items available to view.
All lists have a ‘MANAGE’ column at the far-right of the table. This contains actions specific to the item type and which will be applied to the highlighted item only. To apply an action to multiple items, select them using their checkboxes and the buttons discussed above.
Lists of items which you or your collaborators can create — Products and Device Groups — will features a context-sensitive ‘Create New…’ button above the page-navigation buttons:
impCentral’s code editor is an improved version of the IDE code editor: it features the standard agent and device code panes, and a pane in which the logs for a device assigned to the host Development or Test Factory Device Group can be viewed by selecting that device from the list at the bottom left:
The log pane also displays a device’s ID and its agent’s URL. A convenient new ‘Assign more devices’ button appears in the device list to allow you to add more of the account’s unassigned devices to the Device Group.
The code editor’s code panes will preserve their contents between sessions, but to deploy the displayed code to all the devices assigned to the Device Group, you need to click the ‘Build’ button:
To make code available to collaborators and to impCentral’s Production Zone, it must be deployed (using ‘Build’) and then promoted using the ‘Promote’ button:
This button will not be present if the currently selected account has not granted you access to production functionality.
The ‘Deployments’ view lists all the deployments made to the Device Group (code is deployed by clicking on the code editor’s ‘Build’ button). Deployments are listed with their the date and time of deployment, SHA value and whether they were also promoted. They are listed in date order, most recent first:
You can click on a deployment’s SHA in order to display its code in the code editor. The Code icon in the Side Panel will now feature the ‘SHA’ label, and the agent and device code panels will show a lock icon to indicate that they cannot be edited. Once code is deployed — ie. it has been assigned its SHA — it cannot be changed (though it can still be promoted). To work on code that has been deployed, select its SHA from the ‘Deployments’ list and then click on the code editor’s ‘Edit’ button (which only appears in the SHA mode):
This causes the deployment’s code to be copied to a new draft within the code editor. You will be asked if you wish to overwrite an existing draft — if you do, the code editor goes into Draft mode, and its Side Panel icon will now feature the ‘DRAFT’ label. Make your changes and then click ‘Build’ to generate a new deployment.
Individual deployments can be deleted from the ‘Deployments’ list. You can’t delete the most recent deployment, and impCentral preserves all deployments made to Production and Factory Device Groups (see below).
You can also click on ‘Settings’ under the ‘MANAGE’ column to provide a description of the deployment.
In impCentral, a SHA is used to reference code, not the build number (as used in the IDE). SHAs are generated from the code and the account owner when you click the ‘Build’ button in the code editor. The SHA is displayed immediately in the readout to the right of the code editor’s action buttons:
Above, the Code Editor button area before ‘Build’ is clicked. After the button is clicked, the SHA is displayed:
The SHA will also appear as a new entry in the Deployments list. You can also click on the triangle to the right of the ‘Draft’ button to get a pop-up list of the most recent deployments made to the Device Group:
Once you have clicked ‘Build’, the code editor disables the ‘Build’ button until you make changes to the code. This is to prevent you accidentally making multiple deployments of identical code, all of which will therefore have the same SHA.
If the same code is deployed to two separate Device Groups in Products owned by a single account, they will again both have the same SHA. This is to allow you to discover which Device Groups are running the same code.
Deploying new code to a Device Group stages the code — the devices will receive the code when they actively connect to the impCloud, usually by restarting. The most recent deployment made to a Device Group is called its ‘Current’ deployment.
Device Groups can also be set to have a ‘Minimum Supported’ deployment. This is essentially a baseline version — a given device cannot run software that was deployed before the Minimum. A Device Group’s Current and Minimum deployments are marked in the ‘Deployments’ list.
These deployment types are used primarily during a polite deployment. Polite deployment is a feature of the imp API and your application code which allows the latter to defer an impOS or Squirrel update until it has completed a critical task. If polite deployment is implemented in your application code, you can use impCentral to trigger either forced or conditional restart when you either make a deployment, or simply tell a Device Group to restart its devices.
A forced restart is the same as restarting any device whose application doesn’t suport polite deployment: if the device is not running the latest code, it will restart and receive it now.
A conditional restart has two possible outcomes. If the device is running a version of the code that isn’t the most recent deployment and the code is from a deployment made before Minimum, then it will be forced to upgrade to the latest deployment, ie. Current.
If the device is running a version of the code that isn’t the latest one, but the code is Minimum or later, then the application will be given the chance to defer the upgrade using its polite deployment support.
Minimum and Current are initially the first deployment made to a Device Group. As further deployments are made, Current will always be the most recent deployment, but Minimum will not change until more than ten deployments have been made. From that point, Minimum always stays ten deployments behind Current, unless you use impCentral to adjust it upwards. Minimum can never be adjusted downwards. If you move Minimum up, afterwards, as new deployments are made, it will again remain unchanged until Current is ten deployments ahead, after which it will always be ten deployments behind Current.
To use this facility with Development and Test Factory Device Groups, click on the triangle to the right of the ‘Build’ button and select either ‘Build and Force Restart’ or ‘Build and Conditional Restart’:
‘Build’ itself will always stage the deployed code without triggering a restart: devices must be restarted manually to receive the deployed code. Individual devices can be restarted using the controls in the code editor’s log pane device list:
For Production and Factory Device Groups, the choice is made when you deploy code to them by selecting ‘Deploy’ from the ‘MANAGE’ column in their respective Production Zone lists. In the ‘Deploy’ panel, select either ‘Forced’ or ‘Conditional’ as required:
Again, if your application code doesn’t support polite deployment, all restarts are *de facto* forced. And forced deployments will always override an application’s own polite deployment support.
The first thing to understand about impCentral is that there are no models. Instead there are Products and Device Groups. Each Product in your account embodies a single Electric Imp-based product or product family. It can include any number of Device Groups, as required by your development process, production workflow and the nature of your product.
Development and Production Device Groups are similar to, respectively, the development and production models used in the IDE. But while the IDE limits you to one model per product — because the model is the product — impCentral’s Products essentially allow you to make use of multiple models per product.
Let’s look at each of impCentral’s new elements.
Products encompass all the different types of code — application and factory; development and production — that are required to develop a product, to put it into production, and to make it successfully operate in the field. Products are a little like models in that respect, but they don’t hold code or have devices assigned to them directly. Instead, they contain Device Groups, and these are the entities to which devices are assigned and code is deployed.
Example Terry is building a connected weather monitor called Meteor and powered by the Electric Imp Platform. At the start of development, he creates a new Product in impCentral and names it “Meteor” for the product he is designing.
Device Groups in the Development Zone — Development Device Groups and Test Factory Device Groups — combine code and devices in much the same way that development models do in the IDE. However, they are part of a Product rather than a standalone entity. These Device Groups are used solely for code development, whether you are working on your application firmware in a Development Device Group, or your factory firmware in a Test Factory Device Group.
Test Factory Device Groups are only available to Electric Imp Enterprise accounts, or to free accounts which have been granted access to them as a collaborator. When viewing their own accounts, free-account holders will not be able to work with Test Factory Device Groups, only Development Device Groups.
Each of these Device Groups includes a code editor where you work on your software, as described above. When you click ‘Build’ in the code editor, impCentral automatically stages the new code and causes all of the devices assigned to the Device group to restart so that they receive the new software. The code is also listed in the Device Group’s Deployments list, which can be viewed by clicking on the Deployment History icon () in the Side Panel. There is also a device icon () which, when clicked, presents a list of devices. If you are viewing a Development Device Group, they will be the development devices assigned to the Development Device Group. If you are viewing a Test Factory Device Group, they will be any Test Blessed Devices activated by the Factory Test Fixtures assigned to the Device Group.
Clicking on the Code icon () takes you back to the code editor.
Example Under his Product “Meteor”, Terry creates a Development Device Group called “Meteor App Code 1.0.0”. This will be where he develops the first release of his connected weather monitor’s application firmware, and where he will deploy it to his development hardware for testing. Later, Terry creates a Test Factory Device Group called “Meteor Factory Firmware 1.0.0” under which he will develop his factory firmware and deploy it to a test factory BlinkUp fixture as he tests and optimizes his factory set-up ahead of production.
A Test Factory Device Group doesn’t only allow you to develop factory firmware and deploy it on prototype factory fixtures (called ‘Factory Test Fixtures’). It also allows you to use those fixtures to pre-flight the factory process by configuring development devices and/or newly assembled devices from your factory’s production line. These devices will then run the Device Group’s factory firmware, just as they would if were they in a real factory environment. The will even be blessed. This allows you to fully test your factory firmware across the production cycle before you deploy it to production-grade factory BlinkUp fixtures.
Clicking on the Devices icon () in the Side Panel while viewing a Test Factory Device Group will present a list of all the Test Blessed Devices which have gone through the factory pre-flight process. The list is in the form of the code editor’s log pane, so you can easily view the log output of your Test Blessed Devices:
Example Terry tests his factory flow by assigning an impFactory™ unit to a Meteor Test Factory Device Group. In the lab, he uses the impFactory to perform BlinkUp on a set of hand-build Meteors, which will then run the Device Group’s factory firmware and, eventually, be test-blessed. He can then test his Meteor BlinkUp app on these devices as if they were real end-user oriented units, to verify the production flow and the end-user set-up process.
In the Production Zone, Device Groups are used solely to organize production hardware: devices that have come off the factory assembly line after blessing (placed in Production Device Groups), and the factory BlinkUp fixtures used to configure newly assembled devices for factory network access. They are not used to develop code.
This makes production management in impCentral much more flexible and powerful than it is in the IDE. Previously, all of a given product’s production devices ran the same code, so it was impossible to set some of them to run, for example, a modified version of their application code — perhaps a new version targeting a specific geography, or one that adds a new feature that you want to test in the field. impCentral’s Device Groups make it easy to take an arbitrary number of production devices, create a new Device Group for them, and thus switch them to different code from the others. And you can have as many Device Groups in your Product as you need. A device can be assigned to only one Device Group at any one time.
In addition to Production Device Groups, there are Factory Device Groups, which organize factory BlinkUp fixtures. You deploy your latest factory firmware (developed in a Test Factory Device Group and then promoted to production) to Factory Device Groups. Again, you can have as many Factory Device Groups as you need. For example, your Product can support multiple factory firmware, one for each of the different application firmware you will install on your production devices — say, different versions for the variants of your product that will ship to different territories.
Example Having begun producing and selling Meteors, Terry decides to add a new software feature. He creates a new Development Device Group, “Meteor App Code 1.1.0”, to develop and test the new code in the lab. When the code is ready, Terry elects to release the code to a small group of end-users as a field trial. He creates a new Production Device Group, assigns those users’ Meteors to it and deploys the 1.1.0 code to the new Group. All other production devices, new and existing, continue to use the code promoted from “Meteor App Code 1.0.0” until Terry is happy with the trial’s outcome and chooses to migrate all production devices to the new Group.
impCentral allows you to manage devices in new ways. Let’s look at each type of device in turn.
When you add a new development device to your Electric Imp account using the Electric Imp mobile app and BlinkUp™, the device will be in an unassigned state, just as before. All of the devices you add to your own account can listed by selecting ‘My Development Devices’ from the Devices menu () in impCentral’s top bar.
impCentral’s account view provides a list of all of the devices assigned to the currently selected account — look for the device icon () in the Side Panel — and from here you can assign them to any Development or Test Factory Device Group under any of the current account’s Products. The list includes devices owned by other accounts but assigned to a Device Group under this account.
Example Terry’s hardware team has completed a number of Meteor prototypes that are ready to be used to test the monitor’s application firmware. Terry adds them to his account using the Electric Imp app then assigns them to the Development Device Group “Meteor App Code 1.0.0”. He goes to the code editor and clicks the ‘Build’ button to check, compile and save the latest draft of his code, which is then deployed to the prototype units.
A Device Group’s list of assigned devices includes a ‘Details’ option under the ‘MANAGE’ column. This pops up a convenient readout of key device information: its ID, MAC address, agent URL, imp type and more. A tabbed interface allows you to switch between the device’s details, its most recent log messages, and its activity history: its assignments, enrollments, blessings and when it has been unassigned.
Like development devices, factory BlinkUp fixtures are added to an Electric Imp account using the Electric Imp mobile app. Newly added fixtures are also unassigned, but you have a choice about where to assign them: to a Test Factory Device Group or to a Factory Device Group.
You assign a factory BlinkUp fixture to a Test Factory Device Group because you want to use it to test your in-development factory firmware. Within a Test Factory Device Group, the factory test fixture and factory firmware can be used to active pre-production devices in the lab as if they were being processed in your factory. Test Factory Device Groups therefore give you the capability to pre-flight your factory process before you go into production. This can both speed up your time to market and reduce your costs.
When you create a Test Factory Device Group and use its test fixtures to activate devices, impCentral manages any Test Blessed Devices for you — you can view a list of them by clicking the Devices icon () in the Side Panel.
You can also assign a factory BlinkUp fixture straight to a Factory Device Group. Typically, this is done before a fixture is sent to the factory for installation, or with a factory collaborator’s shared device.
Under the IDE, factory BlinkUp fixtures were assigned to production models by recording the MAC addresses of their on-board factory imps under the production model’s factory settings. This has changed. It is now sufficient simply to assign the factory BlinkUp fixture to one of a Product’s Factory Device Groups. Factory Device Groups ‘know’ which Production Device Group the devices they configure will be automatically assigned to upon blessing — it’s their ‘target’, which you specify when creating the Factory Device Group.
Note impCentral does not support the use of imp001-based factory fixtures, only fixtures based on imp modules (imp002, imp003, imp004m, imp005).
Example Terry constructs a simple LED-based factory BlinkUp fixture to test his factory firmware, which he has been preparing in the Test Factory Device Group “Meteor Factory Firmware 1.0.0”. He adds the fixture to his account using the Electric Imp app and then assigns it to “Meteor Factory Firmware 1.0.0”. He goes to the Device Group’s code editor and clicks the ‘Build’ button to check, compile and save the latest draft of his factory code, which is then deployed to the fixture, which is now ready to configure prototypes for test-blessing.
If you need or want to re-configure a factory BlinkUp fixture and it is currently assigned to a Factory Device Group or Factory Test Device Group, you must unassign it or re-assign it to a Development Device Group first.
Production devices are factory assembled devices which have been activated, tested and blessed. They receive their application firmware after they have been blessed, either immediately (the default) or when have been first configured by an end-user. During blessing, a production device is assigned to a specific Production Device Group — its application firmware is the code deployed to that Group.
How does the impCloud know which Production Device Group to assign a newly blessed production device to? The Factory Device Group to which the factory BlinkUp fixture that configured the device under test also records the target Production Device Group to which production devices blessed by that Factory Setup’s factory firmware — remember, the factory firmware runs on both BlinkUp fixtures and devices under test — should be assigned after blessing.
As we’ve seen, development devices are assigned not to Products but to Device Groups in the Development Zone. Since these Device Groups always belong to a Product, to move a generic development device from Product A to Product B, all you have to do is move it from one of Product A’s Device Groups to one of Product B’s. impCentral allows you to do this with the standard device-assignment panel: just select a different Product and Device Group.
Production devices are not generic, because their hardware and application firmware are typically very tightly integrated. As such, it doesn’t generally make sense to move such a unit from one Product to another and, indeed, this process is not supported for blessed devices. Don’t forget, though, that blessed production devices can be moved to other Production Device Groups within the Product. This is the recommended way to manage multiple versions of the same product: set the the Product to the product family, and maintain one or more Production Device Groups for each family member.
If you are using generic units to test your factory flow — using a Test Factory Device Group — you may well wish to re-use such hardware with other Products. In this case, you can use impCentral to unbless the units after they have been test-blessed. Once unblessed, the devices can be re-used in any other test-blessing flow.
Factory BlinkUp fixtures can be moved between Products because what ties them to a given Product is the factory firmware they are currently running, not their hardware capabilities. Again, re-using a fixture for another Product is just a matter of re-assigning it to a Factory Device Group under another Product.
Managing production in impCentral involves creating at least one Production Device Group and at least on Factory Device Group. This takes place in impCentral’s Production Zone, which becomes accessible when you select a Product to work on.
You will assign your factory BlinkUp fixture(s) to the Factory Device Group. You will deploy your production factory firmware to the Factory Device Group and thus to all the fixtures assigned to it. In addition, you will set the Factory Device Group’s target: this is the Production Device Group to which DUTs configured by the Factory Device Group’s fixtures will be automatically assigned upon blessing.
When you create a new Factory Device Group, impCentral will expect you to set the new group’s initial target so you must have already created a Production Device Group for the Product. You can change the group’s target by clicking on ‘Settings’ under the ‘MANAGE’ column in the Product’s Factory Device Groups list:
Clicking on ‘Deployments’ under the ‘MANAGE’ column in the Product’s Factory Device Groups list will call up a list of factory firmware deployments made to the group.
Clicking on ‘Fixtures’ under the ‘MANAGE’ column in the Product’s Factory Device Groups list will call up a list of the factory BlinkUp fixtures assigned to the group. From this list you can re-assign any of these fixtures (for example, when you wish to re-use them for a different Factory Device Group within this Product or under another Product entirely), restart them or gain further information about them, just as you can with development devices.
When you create a Production Device Group, impCentral expects you to select promoted application firmware to deploy to the new group. As such, you must have taken code in one of the Product’s Development Device Groups and promoted it for deployment to production.
Clicking on ‘Settings’ under the ‘MANAGE’ column in the Product’s Production Device Groups list opens up a panel in which you can change the group’s name, add a description and choose when devices assigned to the group receive their application firmware.
By default, this takes place immediately after blessing: the production device will be sent its application code one second after the device is blessed (ie. there is sufficient time to run post-bless callback in your factory firmware). This enables out-of-the-box operation by the device's end-user. However, you may choose to have device not receive its application firmware until it has been activated (first end-user BlinkUp). This should be selected if you are performing device activation in the factory.
In addition, the Production Device Group Settings also allows you to set webhooks which will be triggered when key events in a Production Device’s lifecycle take place. Please see the webhook documentation for more information.
Clicking on ‘Deployments’ under the ‘MANAGE’ column in the Product’s Production Device Groups list will call up a list of application firmware deployments made to the group.
Clicking on ‘Devices’ under the ‘MANAGE’ column in the Product’s Factory Device Groups list will call up a list of the Production Devices that have been assigned to the group. From this list you can re-assign any of these devices — typically, this is done to re-assign devices to a Production Device Group to which alternative application code has been deployed.
To make code available to collaborators, or for deployment to factory or production devices, it must first be promoted. This is done by clicking the ‘Promote’ button in the code editor, just as was the case with the IDE.
If you only have a free Electric Imp account and you are viewing your own account, you will not see the ‘Promote’ button, but you may see the ‘Promote’ button if you have been granted access to another account as a collaborator and are viewing that account.
Promoted code is stored in the impCloud and is identified by its SHA, which is calculated when you click on the ‘Build’ button in the code editor. You can also append notes to the code, akin to applying a message when you are making a commit using a version control tool, such as git. Promoted code can’t be changed. If you need to update promoted code, you copy it to the code editor by clicking on the code editor’s ‘Edit’ button (only shown when you are viewing read-only code) and then promoting the new code as a new deployment.
Production and Factory Device Groups retain all deployments made to them (for audit purposes). Old deployments can be deleted from Development and Test Factory Device groups, via the Deployments list.
Once promoted, code can be deployed to one or more of the Product’s Factory and Production Device Groups. When a deployment takes place, any online devices already assigned to the target Device Group are restarted, and so receive and run the deployed code. Devices which are offline will receive the deployed code when they next come back online.
The list of a Production Device Group’s devices is organized into those devices which have been activated by an end-user (enrolled) and those which have been not yet been activated. Customers can choose to convert any production device into a development device (unblessing) by clicking ‘Delete’ in the ‘MANAGE’ column of the device list.
If you know the device ID and/or MAC address of the unit in question, you can enter this information in the ‘Device Lookup’ field in the Devices menu (). The device details page that will now appear has an ‘Actions’ menu in the top right corner: selecting ‘Delete’ from this menu will unbless the device (provided it is a production device).
The device detail page mentioned above is also used to view production device logs in impCentral. Simply use ‘Device Lookup’ to locate the specific production device you are interested in and, on the device details page, click the ‘LOGS’ tab.
Inviting other account holders to work on your account’s Products, Device Groups, code and devices in impCentral works much the same as it did under the IDE. If you click on your account in the impCentral navigation bar, you’ll see the collaborators icon () on the left side of the window — click this to open the familiar collaboration interface where you can add collaborators to your account and chosen what access privileges they have — and therefore what impCentral functionality they can make use of while viewing your Products.
Potential collaborators must first be invited to access your account — an invitation they need to respond to before they are granted access.
Once a collaborator has accepted your invitation and logged into impCentral using their own Electric Imp account, they can click on the arrow alongside the left-most entry in the navigation bar to switch between their own account (marked ‘personal account’) and the shared account (and any other shared accounts they are collaborating on.
You can view a full list of the actions that account collaborators may perform on a shared account here.