An In-depth Reference For imp-enabled Device Production
This guide provides an in-depth guide to the Electric Imp Connected Factory, and to the Electric Imp Connected Factory Process with which it is controlled. If you would prefer to begin using the Connected Factory Process immediately, for initial lab-based testing and then for production, please make use of the Connected Factory Quick Start documentation, which has been prepared to get you up and running as fast as possible.
The following short video demonstrates the essentials of the Connected Factory Process:
A Production Device is any imp-enabled unit that is intended specifically for sale and end-use rather than for development. The procedure by which a newly assembled device, called a Device Under Test (DUT), becomes a Production Device is called Blessing, and this is what the Connected Factory Process has been designed to perform. In order to be blessed, a DUT must be connected to the Internet and able to access the Electric Imp impCloud™. It is configured to do so using a technique called BlinkUp™.
A Connected Factory is where blessing takes place. It may be part of an existing assembly line or be a facility in its own right. For example, you may choose to have your connected devices assembled by a contractor in Asia then shipped to your own plant where they will undergo the Connected Factory Process separately.
The Connected Factory Process governs the preparation of the DUT to access the impCloud, testing the DUT and, if the tests are passed, blessing the DUT. The Connected Factory Process is the same whether you are an Public impCloud customer or you are taking advantage of Electric Imp’s Private impCloud service. In the discussion that follows, references to the impCloud apply equally to Public and Private impClouds. Where the process takes a different path for Private impClouds than it does with the Public impCloud, this will be indicated in the text.
In order to take advantage of the Connected Factory Process, you must be an Electric Imp Customer. impCentral’s production facilities, which are used to set up and then operate the Connected Factory Process are not made available to holders of free developer accounts unless they are granted access to a customer account as a collaborator.
For a given connected product, the Connected Factory Process has two major phases: pre-production and production. Each of these phases comprises a number of distinct stages which are listed and described below. The pre-production phase involves setting up and testing the Connected Factory Process in preparation for the manufacture and provisioning of products that will be compatible with the Electric Imp Platform, followed by the implementation of the Process with impCentral’s production tools.
The production phase concerns the actual operation of the Connected Factory Process within a Connected Factory.
It is strongly recommended that you make use of impCentral’s factory test facility during the pre-production phase. Indeed, setting up and using the test environment forms the majority of this document. This is because the test environment operates just like the production environment. It allows you to thoroughly check your factory firmware and its operation with working BlinkUp Fixtures and DUTs before you go into production.
Lab testing does not eliminate the need to verify the process within your chosen Connected Factory partly because of physical differences between the test and production locations, but mostly because of differences between their respective networks and Internet connectivity. However, thorough testing in the lab can save considerable time and cost later on, especially if your Connected Factory is in another country and on another continent.
After production may come further phases, but since these will be customer- and product-specific — for example, final device assembly; labelling and packaging for shipment; and unit processing for logistics and inventory management — they are not covered here. They are not a part of the Connected Factory Process and take place once it has been completed.
Finally, there are post-production tasks: actions which you may take once the production run is in progress or has been completed. Such tasks are primarily concerned with releasing application software updates to Production Devices in the field, and obtaining information, such as device logs, for technical support and real-world testing purposes. Though not specifically a part of the Connected Factory Process, these post-production tasks use some of the same impCentral functionality used to configure and implement the Connected Factory Process, from which they follow on logically, and so are covered in this document.
Your application firmware comprises not only the device-side software that will run on your connected product (the device), but also the impCloud-hosted code (the agent) which is the device’s gatekeeper, mediating the device’s access to other Internet-based resources.
You develop your application firmware using impCentral, or with your own tools and the impCentral API to upload your code to the impCloud and transfer it to your Development Devices. Application firmware is developed within Development Device Groups and later deployed to Production Devices via Production Device Groups. Each group belongs to a single Product. Products are how impCentral embodies a connected product or family of products, with multiple device groups for different types and/or versions of device and their respective software releases.
When your application firmware is ready to be transferred to devices, you create a specific instance of your code called a Deployment. Each deployment is distinguished by its SHA, and the date and time at which it was created. A deployment represents a fixed build of your application firmware at that specific point in time. The creation of a deployment and its delivery to a Development Device Group’s devices is managed automatically by the impCentral code editor when you click Build and Force Restart or one of the other options in the code editor’s Build pop-up. However, you will need to deploy code to Production Device Groups manually.
In order to make a deployment available to impCentral’s production facilities, it must first be Promoted. This can be achieved either by clicking the code editor’s Promote button after you click Build and Force Restart, or by subsequently navigating to the Product’s list of Development Device Groups and clicking Deployments under MANAGE for the desired group. Locate the required deployment in the Deployments list and click Settings under MANAGE. In the Deployment’s settings, ensure the deployment’s Promoted checkbox is set:
Note Promotion applies to the deployment, not to your code per se. If you subsequently update your application firmware’s code, and need to make the new version available for production use, you will need to manually promote the new deployment; the existing deployment will not be updated, and the new deployment is not automatically promoted. This is to ensure that only those versions expressly judged to be suitable for deployment to Production Devices are able to be deployed via impCentral.
Factory firmware comprises Squirrel code which runs on DUTs in the Connected Factory before they receive the application firmware they will run in the field as Production Devices. Factory firmware lies at the heart of the Connected Factory Process: it mediates all of the tasks detailed in the production phase. In short, it is responsible for testing and blessing all DUTs before they come off the assembly line and are distributed to end-users.
The factory firmware also runs on your BlinkUp Fixtures, the factory devices which set up DUTs to contact the impCloud and receive the factory firmware themselves. You must therefore equip your factory firmware with code paths for each of the two types of device — DUTs and BlinkUp Fixtures — and carefully ensure that these code paths are not executed on the wrong type of device:
Note Electric Imp provides a free-to-use code library, FactoryTools, to help you with this task.
The same factory firmware (top) runs in both a factory BlinkUp Fixture, such as the Electric Imp impFactory™ (left), to
transmit WiFi and Electric Imp impCloud access credentials, and on a production device (right) to test the hardware
Factory firmware is developed in impCentral using a Test Factory Device Group. You create device code and agent code; factory firmware agents can be used to enable communication between a DUT and the BlinkUp Fixture: for example, to relay device-specific information that the BlinkUp Fixture will output via a connected label printer or laser-etching station. Similarly, fixtures and DUTs can use their agents to post or retrieve data from Internet-connected resources.
To create a new Test Factory Device Group, navigate to a Product’s Development area then select the Test Factory Device Groups sidebar icon (). Now click the Create New Device Group button: in the Create Test Factory Device Group panel that appears, provide a name for the new group and click the Create button:
Factory firmware makes use of a selection of imp API methods collectively known as the factory API. Some calls are mandatory, others optional. For instance, your factory firmware must include these two calls:
The following factory API methods and properties are optional:
For more detailed guidance on the role of these methods and on preparing your factory firmware, please see ‘Writing, Testing And Using Factory Firmware’.
You will need to construct or purchase your BlinkUp Fixture before you begin testing your factory firmware. Electric Imp offers for purchase a ready assembled BlinkUp Fixture, the impFactory™, which is also available as a reference design if you wish to build your own.
At minimum, a BlinkUp Fixture requires just an LED to transmit the BlinkUp signal and a means to initiate the BlinkUp transmission: a button may be pressed manually by an assembly line operator, or a wire can send a signal from a sensor in the assembly line. This is demonstrated in this basic BlinkUp Fixture, which is suitable for testing your Connected Factory Process set up, but is not intended for installation on the assembly line.
Your BlinkUp Fixture should initially be assigned to a Test Factory Device Group. This is done by first adding it to your Electric Imp account using the Electric Imp mobile app. Navigate to the Product’s Test Factory Device Groups list and click Code under MANAGE for the chosen group. This opens the code editor; click on the Assign Devices button and select the fixture from the list of devices presented to you:
Only one BlinkUp Fixture is required for each assembly line but you may prepare and use as many as you like. BlinkUp Fixtures can be re-assigned to a different Test Factory Device Group or Factory Device Group — even onese that are part of a different Product — in order to be used again for different production runs.
It is essential that you test your configuration of the Connected Factory Process before you go into production. This can be done very easily in your lab in a way that works exactly as if you were working in a production environment. This lab-based testing allows you to thoroughly check your factory firmware and its operation with working BlinkUp Fixtures and DUTs.
impCentral provides two event-triggered webhooks which you can use to link the Connected Factory Process to your own record-keeping systems. These webhooks are applied separately to Test Factory Device Groups (in the impCentral factory test environment) and to Production Device Groups (in the production environment). The webhooks will not be triggered if they have not first been configured. Webhooks are configured in the chosen device group’s Settings panel:
The two webhooks are:
To configure either webhook, you must provide the URL of either an endpoint on your server, a third-party logging service, or even a development device’s agent. The impCloud automatically posts an HTTP request with a data payload in JSON format to the endpoint when the named event takes place.
Every Test Factory Device Group allows you to thoroughly evaluate your Connected Factory Process and all iof its key components: factory firmware, BlinkUp Fixtures, DUTs and Production Devices. Not only can you run the factory firmware on BlinkUp Fixtures assigned to the Test Factory Device Group, but these BlinkUp Fixtures can be used to set up DUTs for impCloud access so that they can receive and run the factory firmware themselves.
In testing, factory firmware calls to the factory API’s server.factoryblinkup() and server.bless() methods are fully functional. DUTs that have undergone blessing by way of a Test Factory Device Group are called Test Blessed Devices and will appear in the Test Factory Device Group’s Test Blessed Devices list, accessed by navigating to the group and clicking the Test Blessed Devices sidebar icon (). From here their details and logs can be examined:
To test bless devices, you will need to specify which application firmware they should automatically receive after blessing. To do so, you will need to have promoted an application firmware deployment, as described in Step 1, above. To register the promoted deployment for use by the Test Factory Device Group’s Test Blessed Devices, click the Deploy button in the Test Blessed Devices list, and then select the promoted application firmware deployment from the list in the panel that impCentral now presents to you. You must provide a brief description of the deployment, and then you can click the Deploy button:
You can subsequently choose when a Test Blessed Device receives its target application firmware:
The former is the recommended setting for production and so is the default option within the production environment. It also the default for the test environment. However, you may choose to use the second option, and this can be selected in the Test Factory Device Group’s Settings panel. See Step 4, above for instructions on accessing the Settings panel.
One of the many advantages provided by the impCentral factory test environment is that it yields fully functional Test Blessed Devices which are functionally identical to the Production Devices your Connected Factory will eventually produce. You should therefore use your Test Blessed Devices to test the BlinkUp SDK-based app that you will need to provide to the end-users of your Production Devices once your product goes on sale.
Production Devices, like all imp-enabled devices, need to be enrolled into the Electric Imp impCloud before they can function as fully connected products. Development Devices and BlinkUp Fixtures are enrolled using the Electric Imp app; Production Devices are enrolled using an app of your own which incorporates the BlinkUp SDK to embed the optical data transmission and device enrollment functionality. The first time an end-user enrolls a given device, it is called Activation, and in addition to enrolling the device, it may also be used to provide the on-board imp with local WiFi network credentials, if that is how your product connects to the Internet.
Having developed your app, you can test it using Test Blessed Devices. This is no different to using Production Devices in that the activation experience is identical, provided you are using DUTs for testing which are functionally identical to the DUTs that your Connected Factory will operate on. View Test Blessed Devices’ logs as detailed in section 4.2, above.
Once you have completed testing to your satisfaction, you are ready to complete the set up of your Connected Factory Process. This involves preparing the Factory Device Group (for factory firmware and BlinkUp Fixtures) and Production Device Group (for application firmware and Production Devices) which will be using during production. These have to be created and set up manually; they will not be set up for you as part of the test process.
To make use of your application firmware and factory firmware in the production environment, you need to promote your chosen firmware deployments. You will have done this already for your application firmware, in order to make use of application firmware in the test environment. However, to begin production, you will need to promote your factory firmware.
To do so, navigate to your Product’s Test Factory Device Groups list and click Deployments under MANAGE. Find the desired deployment (the most recent ones are listed first) and click Settings under MANAGE. The Deployment Settings panel will appear — make sure its Promoted box is checked. Add a description as it will help you distinguish one promoted deployment from another later on. You can also note the date and time of the deployment, and the deployment’s SHA. Click Update:
The remaining Connected Factory Process set up work takes place within impCentral’s Production zone: click on Production Zone under MANAGE in your account’s Products list, or if you have already selected a Product, click Production in the navigation bar under the name of your product:
Note impCentral’s production-related functionality is highlighted in green to distinguish it from development and test functionality, which is highlighted blue.
The green left-hand sidebar provides access to your Product’s Production Device Groups () and Factory Device Groups (). You must create the Production Device Group first as it will be needed when you subsequently create the Factory Device Group. In each case, from the list of device groups click the Create New Device Group button to add a new group.
Creating a Production Device Group involves selecting the application firmware deployment that will be sent to Production Devices automatically once they are blessed. Only promoted deployments are available for use in production. Locate your promoted application firmware deployment (from Step 1, above) in the list of available deployments using its date, SHA and description, then select it. You must also enter a name for the new group. Finally, click the Create Production Device Group button:
You can add as many Production Device Groups to your Product as you need. They are all created as described above. For example, you may wish to roll out updated application firmware to a selection of Production Devices for in-field testing before deploying to all Production Devices. In this case, promote the new application firmware deployment, create a new Production Device Group (‘B’) using the promoted code, and then add devices from the first Production Device Group (‘A’) to the new one. Upon re-assignment, the devices will receive the new code (or will do so when they next connect to the impCloud).
When you are happy with the new release, transfer all remaining devices from A to B. In due course, when you update your application code, deploy the update to A and move a small number of devices from B to A.
To assign Production Devices, navigate to the Product’s list of Production Device Groups then click Devices under MANAGE. If you have already selected the Production Device Group, click on the Production Devices icon () in the left-hand sidebar. Select multiple devices, then click the Assign button at the top of the list to select a new Production Device Group to move the selected devices to.
By default, when new application or factory firmware is deployed to, respectively, a Production Device Group or a Factory Device Group, it is left to the device’s own code whether they should update immediately. This is called a Conditional Restart and requires that the firmware (of whatever type) supports Polite Deployment. If this is the case, a given device may choose to defer the firmware update if it is performing a critical task that should not be interrupted. To accept the firmware update, the device must manually restart. If the device is offline, it will receive the update notification when it next connects, and can choose at that point how to proceed.
When you create a Production Device Group and select its initial deployment, that deployment is set to Conditional Restart for you. If you wish to change this, you can simply redeploy (ie. duplicate) the deployment: if you are already viewing the Production Device Group, click on the Deployments sidebar icon (), or navigate to the Product’s Production Device Groups list and click Deployments under MANAGE for the chosen group. Now click Redeploy under MANAGE for the source deployment. impCentral will create a duplicate deployment; you can now change the Restart Options (section 3 of the panel) and change the deployment’s description if you wish. Finally, click the Deploy button:
If the firmware does not support Polite Deployment, or you choose Forced Restart when you create a new deployment, then all devices within the target device group (of whatever type) that are online will immediately restart and receive the new firmware. Offline devices will receive the update when they next connect.
You can choose when a Production Device receives its application firmware:
The former is the default and the recommended setting as it ensures Production Devices can run application firmware as soon as end-users power them up. However, you may choose to use the second option, and this too is set in the Production Device Group’s settings: navigate to your Product’s list of Production Device Groups, then click Settings under MANAGE for the chosen group:
This setting can be updated at any time.
Whether you made use of impCentral’s webhooks during testing or not, you may wish to make use of them in production. In the production environment, they are only available to Production Device Groups. This is in contrast to the test environment. Webhooks are configured in the chosen Production Device Group’s settings: navigate to your Product’s list of Production Device Groups, then click Settings under MANAGE for the required group (see the section above).
The two webhooks are:
To configure either webhook, provide the URL of an endpoint on your server, a third-party logging service, or even a development device’s agent. The impCloud automatically posts an HTTP request with a data payload in JSON format to the endpoint when the named event takes place.
Creating a Factory Device Group requires that you select a Production Device Group as its target. This is done for you in the test environment, but in production you need to do this yourself. When you create a new Factory Device Group, you will see a list of the Product’s Production Device Groups. Select one, give the group a name, and click the Create Factory Device Group button:
You also need to select the factory firmare you promoted earlier. Click on Deployments under MANAGE. This presents a list of code deployments made to the device group. Click the New Deployment button. In the panel that appears, locate a promoted factory firmware deployment using its date, SHA and description, and then select it. Enter a description for this new deployment and then click the Deploy button:
Note This procedure is how you will make new deployments to your Production and Factory Device Groups. You must create each deployment under the appropriate type of device group: you can’t, for example, create a deployment intended for a Production Device Group from within a Factory Device Group Deployments list; you must select Production Device Groups from the left-hand sidebar first.
Lastly, click on Fixtures icon () in the left-hand sidebar. Alternatively, click Fixtures under MANAGE from the Product’s Factory Device Groups list. Click the Assign button.
In the Assign Devices panel that now appears, enter the device ID(s) of your factory BlinkUp fixture(s) in the box on the left-hand side. The Product and Device Group to which these fixtures will be assigned have been set for you, so just click the Assign button:
When you create a Factory Device Group, you must choose its target: the Production Device Group to which DUTs configured by the Factory Device Group’s BlinkUp Fixtures will be automatically assigned upon blessing. However, the target is not fixed and can be changed as you add further Production Device Groups.
Navigate to a Product’s Factory Device Groups list and click Settings under MANAGE for the chosen Factory Device Group. All of the Product’s Production Device Groups will be listed here. If there are a large number of them, you may need to navigate the list’s pages using the arrow buttons () to find the one you want. Select the new target and click Update. All DUTs blessed from this point will be assigned to the new target.
The production phase of the Connected Factory Process involves using your BlinkUp Fixture on the assembly line to configure each newly assembled DUT in turn. As you saw in the test environment, this prepares each DUT to connect to the impCloud and to receive the assigned factory firmware.
This part of the Connected Factory Process takes place entirely within the Connected Factory. It does not require the use of impCentral. The following diagram summarizes what takes place on the assembly line:
This flow comprises four key operations:
However the DUT connects to the Internet — WiFi, Ethernet or cellular — in the Connected Factory, it requires a factory enrollment token with which to authenticate itself to the Electric Imp impCloud. It receives this token from the BlinkUp Fixture via BlinkUp, which also sends factory network access credentials, if required. BlinkUp takes approximately five seconds.
A DUT’s progress while being configured and then connecting to the impCloud will be indicated on its LED with a selection of these patterns.
To view the logs for a Production Device, locate its Production Device Group and click Devices under MANAGE. Locate the device in the list and then click on its name. You will now be presented with the device’s information readout. Click on the LOGS tab to begin viewing logs for that device. Production logging can be used to help you monitor the factory process and to debug your factory firmware while it is running on a proper assembly line.
The DUT runs the deployed factory firmware. The DUT must be blessed for end-use, ie. become a Production Device, or it will be rejected by the impCloud when an end-user attempts to activate it. If the device is not blessed, it must be considered a development device: to be used by you and your developer colleagues, but not by an end-user.
Once blessed, the DUT is now a Production Device and has been registered with the Electric Imp billing system. It has also been assigned to its Production Device Group. Whenever an update to the application firmware is deployed to this group, the Production Device will receive the new code automatically and without end-user intervention. This bond is effectively permanent; unlike a development device, the end-user cannot change the blessed device’s application firmware.
The successful completion of this stage of the factory process will be signalled to your server if you have made use of the Blessing webhook.
The factory firmware should be coded to clear the now-blessed Production Device’s network settings and enrollment token. This ensures that the unit will be in a clean state when an end-user activates their newly purchased device.
The Production Device will download its intended application firmware at this time, unless you have elected to have the software download once an end-user has activated the device in the field, as shown above.
Downloading the application firmware immediately is the default, and will take place as soon as the callback function executed by the sever.bless() call completes. For this reason, it’s important to include the call to imp.clearconfiguration() within that callback.
Given rigorous testing in the lab before you move to the Connected Factory, the Connected Factory Process should proceed smoothly, as has been demonstrated time and again by many Electric Imp customers. If you do experience difficultly, there are a number of key factors you should consider before contacting Electric Imp for assistance.
When a DUT first connects to the impCloud, it checks whether it is running the most up-to-date version of impOS™ that it has been allowed to run. If an update is available, this will be downloaded and installed now: the status LED will go solid green for the duration of the upgrade process. This is not an indication that blessing was a success — the DUT has not yet downloaded and executed your factory firmware.
The update duration is relatively short but dependent on local Internet conditions — connectivity, the presence of a proxy, etc. — so you should not assume your factory firmware will run after a measured time. The duration of the ‘BlinkUp → possible update → restart → test-and-bless’ cycle will likely be different between your lab and your factory, and may even differ between DUTs, depending on connectivity conditions.
When updating is complete, the DUT will restart, re-connect, and download and run the factory firmware — subject to the potential issues described below.
If BlinkUp failed (indicated by a fast red flash, or the LED continuing to slowly flash orange), check the physical placement of the DUT relative to the BlinkUp Fixture’s emitter. During the testing phase, you may also wish to check the DUT’s BlinkUp circuit design and whether the product’s industrial design is impeding the signal path to the sensor.
If BlinkUp succeeded (three seconds of solid green followed by red and amber flashes) but the DUT doesn't connect to the impCloud, check the network credentials embedded in or retrieved by the factory firmware and passed into the server.factoryblinkup() call.
Make sure the BlinkUp Fixture is configured for network access using the Electric Imp mobile app.
Note If you are private impCloud customer, you will need to use your own BlinkUp web app in development mode.
If your factory firmware includes tests of the DUT hardware, you should feed the result of those tests as a single Boolean value into the server.bless() call. This ensures that the DUT’s LED will signal red if the hardware test failed, allowing a factory operator to identify the faulty unit and remove it. As that is the same effect as blessing itself failing, your factory firmware should include log messages to help you determine where the point of failure lies. If it is in the hardware test section of your factory firmware, check the code and/or the DUT hardware manually.
Blessed devices cannot be re-blessed, so if a DUT appears to be failing after it has already been successfully blessed, check that it is not still blessed.
If a DUT is connected but is not indicating bless success or failure, check that the promoted factory firmware’s blessing flow includes the key server.bless() call and that it has not been disabled for development testing.
Factory BlinkUp Fixtures will not be able to perform factory BlinkUp if they are not assigned to a Factory Device Group. To assign a fixture to a different Product, you need to first remove it from the Factory Device Group that it is currently assigned to. Once that's done, you can’t use it to configure DUTs for that same Factory Device Group until it is re-assigned to it.
This issue is commonly seen with customers who are testing multiple factory flows simultaneously using the same fixture. Either label the fixture with the name of the Product which contains the Factory Test Device Group or Factory Device Group to which it is currently assigned, or obtain sufficient fixtures so that each Product has its own unit.
DUTs which leave the factory in an unblessed state and end up in the hands of end-users are called factory escapes. These devices will not work for end-users.
To avoid factory escapes, take care to ensure that all DUTs are tracked and that only Production Devices are placed in product packaging and dispatched from the factory. We strongly recommend that you print a self-adhesive label which can be attached to Production Devices and/or their packaging — or they can be laser-etched — when they are successfully blessed. You can use your factory firmware’s agent code to relay device information to the printing/etching station to ensure each label or mark is tied to a specific device.
Devices coming off the production line without a mark or label should be considered faulty and sent back for re-work. They should not remain in the production flow. This can help to significantly minimize factory escapes.
Post-production tasks center on actions which you may take once the production run is in progress or has been completed. Such tasks are primarily concerned with updating Production Devices in the field, and obtaining information, such as device logs, for technical support and real-world testing purposes.
The Electric Imp Platform makes it very easy to promote and deploy updates and improvements to application firmware. This may be done at any time, and does not require action on the part of your end-users.
Deploying an update is a two-stage process, both steps being conducted in impCentral:
These two operations are performed separately in order to provide you with an opportunity to identify and correct issues in the chosen version before deployment takes place. Deployment is irrevocable, but issues can be quickly rectified by promoting and then deploying a subsequent version of the code.
You may choose to develop updates in the original Development Device Group or in a new Development Device Group created for the purpose — the choice is yours. Similarly, if you want to deploy the update to a subset of your production devices, you simply create a new Production Device Group to which the updated code’s promoted SHA will be deployed (see Step 5.3, above) and then migrate a proportion of the first group’s production devices to the new own. On assignment, they will receive the new group’s deployed code. When the update meets will QA approval, you can move the remainder of your production devices to the new group. The original group can later be re-used to sample the next update.
Deployment is the final step in the update process. Once a new SHA is deployed to the chosen Production Device Group, every Production Device assigned to that group will receive the new software. Devices which are powered down or sleeping at this point will update when they next come online. If you are making use of Polite Deployment, online devices may choose not to update immediately but defer installation until a critical task has completed. These devices must restart manually to apply the update.
It is possible to unbless Production Devices, a process which makes the target device able to be used for development. To perform this task, locate the relevant Production Device Group and click Devices under the MANAGE column. Locate the device in the list and then click Delete under MANAGE. The device will now be unblessed.
If you know the ID, MAC address or agent URL of the target device, you can use the device lookup option in the devices menu () to call up the device’s details. Now look for the Actions menu at the top right of the view and select Delete from it to unbless the device (if it is a Production Device).
To view the logs for a Production Device, locate its Production Device Group and click Devices under MANAGE. Locate the device in the list and then click on its name. You will now be presented with the device’s information readout. Click on the LOGS tab to begin viewing logs for that device.
All device groups include a data readout, the Dashboard, to provide you with useful information about and insights into the devices assigned to the group. The Dashboard is particularly useful for Production Device Groups, to view statistics collated from millions of devices in the field, but it is available to all device group types. To view a group’s Dashboard, click on the group’s name from any of the Product’s device group lists. If you have already selected a group, view its Dashboard by clicking the Dashboard sidebar icon ().
The Dashboard comprises three sections. first of these provides useful information about the device group: the Product to which it belongs; the number of devices currently assigned to it; and the firmware Deployment currently applied to the group:
The second section provides aggregate device-impCloud communications data, either in terms of the number of messages passing in (to devices) or out (to the impCloud), or the volume of data transmitted. Click on the Bytes button to switch to the messages view, and back again:
Move the cursor across the chart to view data for specific times. Click the refresh button () to update the chart at any time.
Click on the date value to select a different end date. How much device data the chart will compile depends on whether you select Days, Hours or Minutes: the previous 30 days, seven days or 24 hours, respectively:
The final section presents a global map pinpointing the approximate location of the group’s devices based on their IP addresses. Click on the World button to select a US view, or vice versa:
Device locations are derived from known relationships between IP address and geography, but some international Internet Service Providers may span their host nation’s IP addresses across multiple territories, so this data can only ever be an approximation.