A table of information relevant to factory configurations
Device + Agent
Table — keys differ between agent and device
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:
|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
|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
|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
|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;
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.
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...
Please see our sample factory firmware for concrete examples of this code’s use.
Note Agents’ imp.configparams table is populated at start-up.