imp.configparams

Description

imp.configparams is a property of the global imp object. It is a table in which device and agent configuration details are stored. The table currently contains the following supported keys:

Device

Key	Type	Description
factory_imp_device_id	String	The device’s ID if it has been enrolled for factory use, or absent from the table. Note The ID provided by the Device Under Test (DUT) that of the BlinkUp™ fixture which configured it, not its own

Agent

Key	Type	Description
factory_imp_device_id	String	The ID of the agent’s device if it has been enrolled for factory use, or absent from the table. Note The value provided by the DUT’s agent is the ID of the DUT’s fixture, not its own
factory_fixture_url	String	The URL of the BlinkUp fixture that configured the agent’s device. This is available to the agents of DUTs only, it is absent otherwise
deviceid	String	The ID of the agent’s connected device, whether it is a factory device or not

Keys will be absent from imp.configparams tables when they are not relevant to the device or agent, so always check for a key’s presence before taking action.

The deviceid key provides a way for an agent in day-to-day use to know the ID of the device it is bound to without having to ask the device:

local theDeviceID = imp.configparams.deviceid;

Deprecation Note

The keys factory_imp, factoryfirmware (on both agent and device) and is_factory_fixture (on the device only) are deprecated. They are no longer required in factory firmware and should not be used. Existing code using these keys should be updated to remove them.

If you wish to differentiate between fixtures in your DUT code flow (eg. to determine along which particular assembly line the DUT is moving), please use the value of factory_imp_device_id instead. This value is unique and is available on cellular imps.

When is imp.configparams Populated on the Device?

The contents of imp.configparams is populated during the imp’s communication with the impCloud™ during start-up. The table does not currently contain information that the imp itself ‘knows’; all of the information is supplied by the server. On a cold start, imp.configparams will be filled before Squirrel starts running. However, in the event of a warm boot, Squirrel starts immediately but does not connect to the server. Therefore it may be some time before imp.configparams is populated. Until this happens, imp.configparams contains no data.

Code which makes use of imp.configparams should ensure that under warm boot conditions the imp has opportunity to populate imp.configparams before it is read. This can be guaranteed by allowing the imp to go idle, ie. to reach a point where no Squirrel is running. The best way to do this is to embed your code in a function that will be called when the imp has gone idle:

// Check that the DUT is in the factory...
imp.onidle(function() {
    ...
});

Please see our sample factory firmware for concrete examples of this code’s use.

Note Agents’ imp.configparams table is populated at start-up.